[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