[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Final draft of response to the OIF



I prefer Ben's solution of having one encoding for STS-3c and VC-4.

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> Sent: Tuesday, August 30, 2005 19:12
> 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
<snip>