Re: Final draft of response to the OIF

[WALTER ROTHKEGEL <wrothkegel@lucent.com>]

Adrian,

I support Ben's arguments. I do not see any reason which
would require the two different encodings.

Regards

Walter

On 31.08.2005 01:11, Adrian Farrel wrote:
> 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
>>============================================================
>>
>>
> 
> 
> 


-- 
________________________________________________________________________
Walter Rothkegel, Lucent Technologies Network Systems GmbH, Dept. O-SE
Thurn-und-Taxis-Str. 10-14, 90411 Nuernberg, Germany
Phone: +49 911 526-4084      Fax:   +49 911 526-6299
mailto:wrothkegel@lucent.com