[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Final draft of response to the OIF
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.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Adrian Farrel
> Sent: Sunday, September 04, 2005 11:05 AM
> To: email@example.com
> Subject: Re: Final draft of response to the OIF
> 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
> 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
> 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
> 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.
> 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
> 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."
> - "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.