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

Re: Final draft of response to the OIF



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. So
   long as it is written down clearly, *any* unambiguous
   control plane encoding is adequate.

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

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.

Thanks,
Adrian