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

Re: Final draft of response to the OIF

Hi folks, a bit of history. At the time the ID was originally written a number of manufacturers had (and still offer) more flexible forms of concatenation rather than the standard SONET/SDH contiguous concatenation. This and the usual standards related compromises lead to the rather general and possibly confusing rules that appear in RFC 3946.

Unknown to us at the time was that none of these proprietary schemes would become standardized. This is mostly due to the greater abilities of Virtual Concatenation (VCAT) which was standardized and since extended beyond SONET/SDH to OTN and PDH.

Hence though RFC3946 encoding seems a bit obtuse the intentions were aimed at future proofing (but part of that future didn't happen). I've tried to make ammends by working with Richard and others to clear things up while minimizing the impact to implementations.

At this point in time is there any other option since this is already a standards track RFC?

Greg B.
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
============================================================