Subject: Re: Final draft of response to the OIF

From: Bert Klaps <[email-masked]>
Date: Thu, 01 Sep 2005 10:43:45 +0200

Hi Dimitri,

Note 2 refers to transparent STS-N/STM-N signals only (signal types 7 
through 12), OIF is requesting clarification on the coding of STS-3c SPE
versus VC-4 (both signal type 6).

Since VC-4 == STS-3c SPE it should be possible to swap both terms
without making a technical change which is not the case for examples 1
and 8. Any such difference is confusing and a potential interworking
problem.

Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE
with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE
elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc
identical (examples 3 and 9) but not their base signal ?!?...

Regards,
Bert Klaps

dimitri papadimitriou wrote:
> ben,
> 
> the purpose of the sentence you were initially pointing out addresses as 
> generic rule more than the specific case under discussion (reason why i 
> pointed to this note 2) from the initial clarification asked by the OIF 
> - ditto
> 
> "Clarification is requested from IETF CCAMP as to which setting is 
> considered correct, or if both settings should be accepted (this 
> procedure was used during testing at Supercomm)."
> 
> hence, any further discussion is involving much more than the requested 
> clarification since questioning the logic behind the settings specified 
> in this RFC; as these are pure conventions we may debated them forever, 
> however, it suffice that one logic gets consensus (with all what it 
> implies), which is the case otherwise this would have not become an RFC
> 
> ---
> 
> 
> Mack-Crane, T. Benjamin wrote:
> 
>> Dimitri,
>>
>> Note 2 on page 6 refers to transparent mode, which is a
>> different thing altogether.  I think this encoding is
>> poorly chosen as well (and may not allow for the full
>> flexibility of equipment that provides various levels
>> of transparent STS-N/STM-N switching), but that is not
>> currently under discussion.
>>
>> Regards,
>> Ben
>>
>>> -----Original Message-----
>>> From: dimitri papadimitriou [mailto:[email-masked]] Sent: 
>>> Wednesday, August 31, 2005 2:38 PM
>>> To: Mack-Crane, T. Benjamin
>>> Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort; [email-masked]
>>> Subject: Re: Final draft of response to the OIF
>>>
>>>
>>> to clarify:
>>>
>>>
>>>> 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.
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>
>> ============================================================
>> 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: [email-masked]
Date: Thu, 1 Sep 2005 13:52:31 +0200

huub,

> > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET base spec)
> > you will that your interpretation is not the one specified in this
> > recommendation
> >
> > " Super rates services are mapped into and transported as STS-Nc SPE
> > [N=3X there X = 1, 4, 16, 64 or 256]"
>
> Somehow you left out the last part between the square brackets:
> "or SDH VC-4 or VC-4-Xc, where X=N/3]"
>
> This clearly means that an STS-3c == VC-4 == super rate of STS-1.

indeed but we are not discussing this issue or put this "equivalence" under questioning (in fact this is reproduced in the signal type 6 definition) the RFC took as logic (control plane) to set the RCC value when the notation of the signal included a "c" we could have created yet another exception but we did not - for several reasons -

> > this is exactly what we used in RFC 3946

--
================================================================

http://www.gironet.nl/home/idefiks/
http://members.chello.nl/hhelvoort/

================================================================
Always remember that you are unique...just like everyone else...

---

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Tue, 6 Sep 2005 16:20:10 -0500

Hi All,

It is interesting to note that the technically correct body text
in RFC3946 (which would typically be considered normative)
is being considered a 'typo' and subject to editorial change,
while an example in an annex is being preserved although
it appears to be in error according to the body text.

A few more comments in-line below.

Regards,
Ben

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Sunday, September 04, 2005 11:05 AM
> To: [email-masked]
> OK.
> So I see two questions here.
> 
> 1. What is meant by RFC3946?
> 2. Do we want to change what is said by RFC3946?
> 
> Question 1 appears to be the question that was asked by the 
> OIF. I think
> we have a clear answer. I think some people are not happy with this
> answer, but that feeds into question 2. My understanding of 
> the answer to
> question 1 is based on the input from the editors of the RFC 
> and reading
> the CCAMP archive. Thus, the response to the question from 
> the OIF is as
> follows:
> 
>    This question about RFC 3946 was raised informally on the CCAMP
>    mailing list at the start of March this year.
> 
>    Even when the signal Type value is the same (i.e. value 6) the
>    NCC, RCC and NVC values depend on the specific signal being
>    requested.
> 
>    From the examples in the annex we have...
> 
>      A VC-4 signal is formed by applying the following
>      settings to a VC-4 Elementary Signal.
>         RCC = 0
>         NCC = 0
>         NVC = 0
>         MT  = 1
>         T   = 0
> 
>      An STS-3c SPE signal is formed by applying the
>      following settings to an STS-3c SPE Elementary
>      Signal.
>         RCC = 1 (standard contiguous concatenation)
>         NCC = 1
>         NVC = 0
>         MT  = 1
>         T   = 0
> 
>    Your question probably arises from the two notes and subsequent
>    paragraph in section 2.1 or RFC 3946. Here it says...
> 
>      Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the
>        Elementary Signal to use must always be an STS-3c_SPE signal
>        type and the value of NCC must always be equal to X.  This
>        allows also facilitating the interworking between SONET and
>        SDH.  In particular, it means that the contiguous
>        concatenation of three STS-1 SPEs can not be requested because
>        according to this specification, this type of signal must be
>        coded using the STS-3c SPE signal type.
> 
>      Note 2: when requesting a transparent STS-N/STM-N signal
>        limited to a single contiguously concatenated STS-Nc_SPE/
>        VC-4-Nc, the signal type must be STS-N/STM-N, RCC with flag 1
>        and NCC set to 1.
> 
>        The NCC value must be consistent with the type of contiguous
>        concatenation being requested in the RCC field.  In particular,
>        this field is irrelevant if no contiguous concatenation is
>        requested (RCC = 0), in that case it must be set to zero when
>        sent, and should be ignored when received.  A RCC value
>        different from 0 must imply a number of contiguous components
>        greater than 1.
> 
>    This final sentence should read "greater than or equal to 1," and
>    was mistyped in the RFC. This change resolves all of your questions
>    and makes the text consistent with the examples.
> 
>    The CCAMP working group is discussing a revision to RFC 3946 to
>    clarify the situation.
> 
> Question 2 is a different issue. Quite a few people have 
> stated that they
> believe that RFC 3946 with its current interpretation by the editors,
> should be changed. At the moment I do not see consensus on 
> this issue and
> frankly I do not see any weighty reason to change although if the
> community shows consensus in favor of a change, that would be 
> fine *if*
> someone does the work.
> 
> My observations on this point are as follows.
> 
> a. This is control plane code. It is definitively not
>    relevant to any interworking in the data plane. 

Nothing CCAMP does is relevant to interworking in the data
plane.  However, the control plane should be reflective of
the data plane.  And the data plane has been made common
for SONET/SDH.  This is the reason that LSP Encoding Type 6 was
depricated (even though at the time there were implementations
that used it).  We have the opportunity to maintain the
same goal of properly reflecting the data plane in the
control structure.  Remember we're talking about a proposed
standard, and taking into account implementation experience.

> So
>    long as it is written down clearly, *any* unambiguous
>    control plane encoding is adequate.

However, not every encoding achieves the goal of unifying
SONET and SDH control.  Furthermore, what has been proposed
doesn't increase interoperability, but rather makes
interoperability less likely.

> 
> b. Even if the data plane signal is identical, there may
>    be value in distinguishing between the SDH and SONET
>    origins of the signal.

Then, as Huub asked, do we also need to distinguish
SONET and SDH encodings at other rates as well?  This
would require a change to the current encodings.

> 
> c. We MUST support existing implementations. That means
>    that whatever encoding rules we end up with, we MUST
>    continue to support the receipt of existing encoding.
>    It seems to me that this dilutes the purpose of any
>    change.
> 
> d. Regardless of the definition of the signal encodings,
>    and regardless of whether fields with the same names
>    are used in the definition of those signals, I find
>    the textual descriptions of NCC and RCC in RFC 3946
>    unambiguous in English. It may be that those
>    descriptions should be changed (or perhaps the names
>    of the fields should be changed?).
> 
> e. At the end of the day you are arguing about whether
>    there is a difference between:
>    - "I would like a shoal of fish, with just one fish
>       in the shoal."
>    and
>    - "I would like just one fish"
>    Do you really have time for this debate?
> 
> f. Changing an RFC does not just happen through email
>    exchanges. Someone has to do the work. If no-one does
>    the work, it is clear to the chairs how much people
>    care about the issue.

The work is straightforward (change '1' to '0' in two places).
I would think the editor(s) could handle this.

> Thanks,
> Adrian