Subject: RE: Final draft of response to the OIF

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Wed, 31 Aug 2005 13:55:21 -0500

Hi Adrian, 

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Tuesday, August 30, 2005 6:12 PM
> To: Mack-Crane, T. Benjamin; Richard Rabbat
> Cc: Huub van Helvoort; [email-masked]
> 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.

Yup.

> 
> > 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.

The example did not adhere to the rule RCC=1 implies NCC>1
which was stated in the RFC (and is technically sound) thus
one could reasonable presume the example was in error.

> 
> 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.

The problem was that both encodings were in use and some
were not liberal in what they received.  That was easily fixed.
If only one encoding was specified, there would have been
no problem.

> 
>  > 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?

Your first line of code is incorrect (uh-oh, more interop problems...;-)

But, what I am concerned about is the possibility of code
like this:

if (rcc==1 && ncc==1) {do behavior A}

if (rcc==0 && ncc==0) {do behavior B}

Which has the potential for creating diversity in behavior
where it should not exist.  Having only one encoding
greatly reduces the chances of this...

> 
> > 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.

Changing the encoding in the example could be considered
editorial, as it's just an example in an annex.
Changing the rule RCC=1 implies NCC>1 to RCC=1 implies NCC>0
is a semantic change (which in my view doesn't make sense,
unless, as Huub suggested, we consider all elementary signals
to be contiguous concatenations of 1 element and then RCC=1
always...:-o)

> 
> 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:[email-masked]]
> > > Sent: Tuesday, August 30, 2005 3:58 PM
> > > To: Mack-Crane, T. Benjamin
> > > Cc: Huub van Helvoort; Adrian Farrel; [email-masked]
> > > 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:[email-masked]]
> > > >>Sent: Friday, August 26, 2005 10:56 AM
> > > >>To: Mack-Crane, T. Benjamin
> > > >>Cc: Adrian Farrel; [email-masked]
> > > >>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
> > ============================================================
> >
> >
> 
============================================================
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
============================================================

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 31 Aug 2005 21:37:40 +0200

> one could reasonable presume the example was in error.

actually your interpretation is not correct - see note 2 of RFC 3946 
(page 6) where the settings RCC=1 can imply NCC=1 is explicitly stated -

this said, one of the reason for this setting wrt the specific point 
raised by the OIF is due to the logic that has been used in making use 
of RCC and NCC value when the signal spelling include a "c" i.e. 
STS-(3xN)c SPE so for STS-3c SPE the setting is a logical consequence of 
N = 1

however, editors have been using a wording for the generic rule which 
has not been understood as expected hence the clarification stated last 
march on this list - and reproduced in the bis version -

in brief, all this doesn't deserve this flurry of e-mails wrt to the 
specific point to be addressed