[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Final draft of response to the OIF
Hi Adrian,
I have some sympathy with Ben's comments, it seems like a single
value would simplify configuration the most. We were able to work
around the problem at the OIF test, but the number of vendors was
limited and it did cause some initial headaches.
Short of a single value, maybe a slight rewording of your text would
make
a stronger recommendation that implementations be able to accept
both, e.g.:
" Note 3: Following these rules, when requesting a VC-4 signal, the
RCC and the NCC values must be set to 0 whereas for an STS-3c SPE
signal, the RCC and the NCC values must be set 1. However, if
local conditions allow (e.g., no differentiation of VC-4 vs.
STS-3c
format is required), then the requesting upstream node MAY set
the RCC and NCC values to either SDH or SONET settings without
impacting the function, and the downstream node SHOULD accept
either of the requested values. If the received value cannot
be supported, the receiver downstream node MUST generate
a PathErr/NOTIFICATION message (see Sections 2.2 and
2.3, respectively). "
Cheers,
Lyndon
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Adrian Farrel
Sent: Tuesday, August 30, 2005 4:12 PM
To: Mack-Crane, T. Benjamin; Richard Rabbat
Cc: Huub van Helvoort; ccamp@ops.ietf.org
Subject: Re: Final draft of response to the OIF
Hi Ben,
> A long time ago an agreement was reached to unify the SDH and SONET
> encodings, since carriers did not want to manage unnecessary
> differences.
Good motivation.
Presume that here you are not really talking about the SDH and SONET
encoding, but rather the control plane encodings.
> What implementations have done as a result of the bad example in RFC
> 3946 is unfortunate, and leads to interop problems -- and thus the
> item from the OIF.
Whether the example is bad or not clearly depends on the encoding rules
specified in the RFC.
With the clarification from the Editors, it would appear that the
example is good. Now, you can object to the encoding rules, but that
doesn't mean that the example is bad.
I have not heard of any interop problems. Centrainly the message from
the OIF did not report any such problems. My understanding is that there
were no interope problems, merely a question about intended encodings.
With the rule of "liberal in what you receive" I would not expect any
interop problems.
> This is our opportunity to fix the example and
> removed the problem (and then folks can simplify their
> implementations). If the difference remains, there will be
> opportunity for creating more interop problems (if implementations
> behave differently for the different encodings).
I'd like to clarify the extent of the simplification that you are
proposing in people's implementations. You are suggesting replacing a
line of code that says:
if ( (rcc==1) && (ncc == 0 || ncc == 1) )
with a line of code that says
if ( (rcc==1) && (ncc == 1) )
Why is this a big deal?
> So, rather than make things more complicated by modifying an accepted
> rule (RCC=1 requires NCC>1), retaining two encodings for the same
> signal, and adding notes to attempt to explain the interworking
> options, it is much easier to correct the example.
Again, I think you are misrepresenting what the authors are doing. In
their view they are not changing the rules, but correcting an editorial
mistake. In their opinion the example is already correct.
Now, I don't want to start any voting here, but I see several people who
are expressing support for the ideas in
draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying
make the change the other way. If I was to judge consensus today, it is
pretty clear how I would call it.
Let's hear some opinions from other people who have an interest in this
work.
Thanks,
Adrian
>
> This is good engineering practice, in my view.
>
> Regards,
> Ben
>
> > -----Original Message-----
> > From: Richard Rabbat [mailto:richard@us.fujitsu.com]
> > Sent: Tuesday, August 30, 2005 3:58 PM
> > To: Mack-Crane, T. Benjamin
> > Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org
> > Subject: Re: Final draft of response to the OIF
> >
> > Ben,
> > Adrian's final draft of the response is most inclusive. From what
> > you said earlier, it seems that you've already coded it in one way
> > (whichever) but are accepting both sets of values for NCC & RCC
> > (both 1 or 0).
> > Is there an engineering problem with the text of the response
> > besides that you would be able to remove those couple of lines of
> > code? if so, we should solve it.
> > Richard.
> >
> >
> > Mack-Crane, T. Benjamin wrote:
> >
> > >Hi Huub,
> > >
> > >See in-line below.
> > >
> > >Regards,
> > >Ben
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl]
> > >>Sent: Friday, August 26, 2005 10:56 AM
> > >>To: Mack-Crane, T. Benjamin
> > >>Cc: Adrian Farrel; ccamp@ops.ietf.org
> > >>Subject: Re: Final draft of response to the OIF
> > >>
> > >>Hello Ben,
> > >>
> > >>You wrote:
> > >>
> > >>
> > >>
> > >>>I proposed a simple (and I think technically sound) solution to
> > >>>item #1 and saw no objections, however the answer has not
changed.
> > >>>
> > >>>I do not understand the reason for different encodings for
> > >>>VC-4 and STS-3c SPE. I think they should be the same, unless
> > >>>there is a technical need to distinguish them.
> > >>>
> > >>>
> > >>If there is agreement that they should be the same, we should also
> > >>look at higher order contiguous concatenated signals:
> > >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c
> > >>STS-768c == VC-4-256c
> > >>
> > >>
> > >
> > >These signals are already encoded the same way (for instance see
> > >examples 3 and 9 in RFC 3946).
> > >
> > >
> > >
> > >>>I also do not understand the RCC=1 NCC=1 encoding, since the rule
> > >>>contained in the current RFC actually makes more sense.
> > >>>
> > >>>
> > >>However indicating the number of signals concatenated in NCC makes
> > >>your first objective impossible: STS-3Xc == VC-4-Xc so there will
> > >>always be a difference of a factor 3 between STS and VC-4 encoding
> > >>
> > >>
> > >
> > >All the encodings of contiguous concatenated signals use VC-4
> > >(STS-3c SPE) as the base, so the NCC values are the same. This was
> > >done to align SONET and SDH encodings.
> > >
> > >
> > >
> > >>>If there is
> > >>>only
> > >>>one signal element, there is no contiguous concatenation,
> > >>>
> > >>>
> > >>by definition.
> > >>
> > >>In fact a single signal is always contiguous concatenated ;-)
> > >>
> > >>
> > >>
> > >>>So I fail to see the usefulness of these encodings.
> > >>>
> > >>>
> > >>NCC = 1 would normally not occur, so it could be used for this
> > >>specific case of SONET signals transported in an SDH world, or SDH
> > >>signals transported in SONET land.
> > >>And if these signals would not cross borders the value NCC > 1 can
> > >>be used.
> > >>
> > >>
> > >
> > >The SDH and SONET encodings have been aligned in all cases except
> > >this one (VC-4, STS-3c SPE). So these should also be aligned.
> > >
> > >
> > >
> > >>>Regards,
> > >>>Ben
> > >>>
> > >>>
> > >>Cheers, Huub.
> > >>
> > >>--
> > >>================================================================
> > >> http://members.chello.nl/hhelvoort/
> > >>================================================================
> > >>Always remember that you are unique...just like everyone else...
> > >>
> > >>
> > >>
> > >============================================================
> > >The information contained in this message may be privileged and
> > >confidential and protected from disclosure. If the reader of this
> > >message is not the intended recipient, or an employee or agent
> > >responsible for delivering this message to the intended recipient,
> > >you are hereby notified that any reproduction, dissemination or
> > >distribution of this communication is strictly prohibited. If you
> > >have received this communication in error, please notify us
> > >immediately by replying to the message and deleting it from your
> > >computer. Thank you. Tellabs
> > >============================================================
> > >
> > >
> > >
> >
> ============================================================
> The information contained in this message may be privileged and
> confidential and protected from disclosure. If the reader of this
> message is not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient, you
> are hereby notified that any reproduction, dissemination or
> distribution of this communication is strictly prohibited. If you have
> received this communication in error, please notify us immediately by
> replying to the message and deleting it from your computer. Thank you.
> Tellabs ============================================================
>
>