Subject: Final draft of response to the OIF

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 26 Aug 2005 12:27:16 +0100

Thanks to all who have commented so far.

Here is an updated draft. I plan to send by the end of August, so furhter
comments should be made quickly.

Thanks,
Adrian

======

To: Jim Jones, OIF Technical Committee Chair
From: Adrian Farrel and Kireeti Kompella,
          WG Co-Chairs for IETF CCAMP
Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors
Subject: Response to your questions about GMPLS parameters.

Dear Jim,

Thanks for your correspondence about the questions with respect to GMPLS
parameters that arose before and during your interoperability testing.
CCAMP is pleased to receive such questions and is glad to have the
opportunity to explain the intended operation of the GMPLS protocols.

Much of the material supplied below can be simply extracted from the
relevant RFCs.

> 1. Use of the NCC and RCC fields for STS-3c/VC-4 connections
>
> During OIF testing it was noted that some ambiguity exists in the
> specification of encoding of NCC, RCC and NVC for certain types of
> connections: NCC and RCC for an STS-3c/VC-4 connection can be set to 0
or
> to 1 depending on which example of RFC 3946 is followed.
>
> 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).

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.

We believe that this final sentence should read "greater than or equal to
1," and that this interpretation resolves all of your issues and makes the
text consistent with the examples.

We plan to issue a revision to RFC 3946 to make this clarification. The
text of this clarification still needs to be agreed by the CCAMP working
group, but the draft revision contains the nodes as updated below with the
addition of a third note as shown.

   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 implies a number of contiguous components greater than or
      equal to 1.

   Note 3: Following these rules, when requesting a VC-4 signal, the
      RCC and the NCC values must be set to 0 whereas for an STS-3c SPE
      signal, the RCC and the NCC values must be set 1. However, if
      local conditions allow and since the setting of the RCC and NCC
      values is locally driven, the requesting upstream node MAY set
      the RCC and NCC values to either SDH or SONET settings without
      impacting the function. Moreover, the downstream node SHOULD
      accept the requested values if local conditions allow. If these
      values can not be supported, the receiver downstream node MUST
      generate a PathErr/NOTIFICATION message (see Sections 2.2 and
      2.3, respectively).

> 2. Setting of NVC for VCAT connections
>
> It was also noted that the setting of NVC may be somewhat ambiguous for
> the case where diverse connections are used within a single VCAT group.
> Each individual RSVP session controls a single connection, but the
> connection is part of a larger VCAT group and carries VCAT encoding of
the
> H4 byte. Clarification is requested from IETF CCAMP and ITU-T Q.14/15 as
> to the correct setting of NVC for this case (0 or 1?). It should be
noted
> that this case may occur with a VCAT group with only a single initial
> member, and that the NVC may provide an indication that VCAT encoding of
> the H4 byte is in use for the connection.

A VCn-Xv group split into X components requires each of its component to
be signaled with the NVC value set to 1. This setting is regardless of how
the components are established.

> 3. Length of the Interface Switching Capability TLV
>
> Although the Interface Switching Capability TLV defined by CCAMP for
> SONET/SDH connections was not used for the testing, it was noted that
the
> text describing the length of the Interface Switching Capability TLV
> defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly
> ambiguous due to the use of padding bytes.
>
> RFC 3630 states that "The TLV is padded to four-octet alignment; padding
> is not included in the length field (so a three octet value would have a
> length of three, but the total size of the TLV would be eight octets)."

Yes. Section 2.3.2 of RFC3630 gives a definitive statement of the meaning
of the length field and the use of padding, and provides an example.

> Reading of the encoding in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
> specifies that the length of the TLV for TDM is 41 bytes plus 3 bytes of
> padding, and should be given in the length field as 41 bytes rather than
> 44. OIF requests verification of this interpretation from the experts in
> IETF CCAMP group.

Note that the Interface Switching Capability Descriptor defined in
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link
TLV. Sub-TLVs and TLVs follow the same encoding rules.

The ISCD TLV for TDM contains the following fields...
  type       2 bytes
  length     2 bytes
  ---
  switch cap 1 byte
  encoding   1 byte
  reserve    2 bytes
  LSP b/w 0  4 bytes
  LSP b/w 1  4 bytes
  LSP b/w 2  4 bytes
  LSP b/w 3  4 bytes
  LSP b/w 4  4 bytes
  LSP b/w 5  4 bytes
  LSP b/w 6  4 bytes
  LSP b/w 7  4 bytes
  min b/w    4 bytes
  indication 1 byte
            ==
            41 bytes

We presume that your question relates to whether the 3-byte field shown as
"padding" in the TDM-specific figure on page 6 of
draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an
explicit field.

It is an implicit field, and should not be included in the length of the
TLV.

Nevertheless, we take this opportunity to remind the OIF that
implementations of GMPLS protocols should be conservative in what they
send and liberal in what they receive. Thus, an implementation that
receives a TDM ISCD TLV with length 44 should not reject the TLV for this
reason. It should parse the TLV according to the defined fields and skip
the final three bytes. Thus, it should not affect a receiving
implementation if the sending implementation has treated the "padding"
field as implicit or explicit. In the event that a receiving
implementation rejected such a TLV on grounds of the value contained in
the length field being too large, the fault would lie with the receiving
implementation not the sending implementation.

> 4. Use of ADMIN_STATUS in an initial PATH message
>
> Some implementations sent an ADMIN_STATUS object with no flags set in
the
> initial PATH message, i.e., when no status change was being requested.
> Although this did not serve any particular function, it was believed
that
> this could be accepted as RFC3473, sect. 7.2 (page 18) states:
>
> "The absence of the object is equivalent to receiving an object
containing
> values all set to zero (0)."
>
> It was our interpretation based on this text that a node should accept
an
> ADMIN_STATUS object with no flags set in the same way as if the object
was
> missing. Comment on this interpretation is welcome.

The effect of the meaning is as you state, but the intention of the
meaning is reversed. That is, an implementation should accept the absence
of the ADMIN_STATUS object in the same way as if the object was present
with no flags set. That is, the default behavior is to consider the
ADMIN_STATUS object as a standard part of the processing.

We note from your first paragraph that you assume that the ADMIN_STATUS
object is used to change the status of the LSP. This is a
misinterpretation - it is used to control the status of the LSP. Thus, if
there is no change to the status of an LSP, refresh messages must continue
to carry the ADMIN_STATUS object with the same bit setting.

In this way, it is not possible to "drop" the ADMIN_STATUS object without
having the same meaning as transmitting the object with all bits cleared.

> 5. Handling of multiple received ResvConf Request objects
>
> When a connection desires a confirmation that the service (i.e.
> connection) requested is in place, a RESV_CONF_REQ object is included in
> the RESV message. As this object is received by the remote end of the
> reservation, it will send a RESV_CONF message back to the requester.
>
> However, it is unclear whether it is necessary to send a RESV_CONF
message
> when the RSVP connection state is refreshed by subsequent RESV. This
> becomes potentially burdensome, especially when the reservation is being
> rapidly refreshed. Therefore we ask: should the remote end send a
> RESV_CONF message for subsequent RESV messages that still include the
> RESV_CONF_REQ object? Or is it required that the requestor of the
> reservation remove the RESV_CONF_REQ object to prevent the generation of
> further RESV_CONF messages? Comment on this issue from IETF CCAMP is
> requested.

It is fundamental to the implementation of RSVP-TE that there is a good
understanding of the distinction between a trigger message and a refresh
message. This can be achieved by reading section 1.1 of RFC2961.

Following this understanding, you will note that a refresh message does
not cause any processing to be performed at the LSR that receives it (in
this case the ingress). You will also note that refresh processing is not
end-to-end as implied in your text, but is hop-by-hop.

Thus, a downstream LSR that wishes to trigger a new ResvConf message must
make a specific change to the content of the Resv message that it sends in
order to cause a trigger message to be propagated through the network to
the ingress LSR. Such processing is implementation specific but might
include the toggling of the presence of the RESV_CONFIRM object on the
Resv message.

Note that a ResvConf message is not necessarily reliably delivered
end-to-end. Relying on the receipt of a ResvConf message before doing
something (e.g. turning on the laser) might be a poor idea. GMPLS uses the
Administrative Status object and in particular the R-bit in order to
reliably achieve this function.

> 6. Symmetry of Refresh Reduction usage
>
> During interop testing, we ran into a conflict caused by varying
> interpretations of RFC2961, regarding the use of SRefresh messages and
the
> Refresh Reduction capabilities of the two ends of a given link. One
> interpretation of RFC2961 indicates that setting the Refresh Reduction
> Capability flag in the RSVP header indicates that that interface shall
be
> capable of receiving messages related to Refresh Reduction - including
the
> SRefresh message. This would be true even if the other end of the link
for
> that interface were NOT indicating Refresh Reduction Capability, since
the
> RFC makes no statement about symmetry in this matter.
>
> Another interpretation is that both ends of an interface must indicate
> Refresh Reduction Capability before either end can use such messages,
i.e,
> use of Refresh Reduction on a link is symmetric.
>
> Comment from CCAMP WG on the correct interpretation is requested.

We are confused by your question.
You correctly state that the use of the refresh-reduction-capable bit
indicates the ability of an LSR to support the receipt of refresh
reduction options and messages. To quote from section 2 of RFC2961...
           When set, indicates that this node is willing and capable of
           receiving all the messages and objects described in this
           document.  This includes the Bundle message described in
           Section 3, the MESSAGE_ID objects and Ack messages described
           in Section 4, and the MESSAGE_ID LIST objects and Srefresh
           message described in Section 5.  This bit is meaningful only
           between RSVP neighbors.
This makes no statement about whether the LSR intends to use these options
when communicating with another LSR.

However, you will note that some refresh reduction procedures require that
a message is sent and response returned. In order to make use of the
response, the receiver must be capable of receiving and processing the
response. Thus, it would be usual for an LSR that is capable of sending
refresh reduction options and messages to also set the
refresh-reduction-capable bit.

In summary:
- An LSR must not send refresh reduction options or messages
  to an LSR that is not setting the refresh-reduction-capable
  bit.
- An LSR may send refresh reduction options or messages
  to an LSR that is setting the refresh-reduction-capable bit.
- An LSR that wishes to successfully use responded refresh
  reduction options or messages should set the refresh-
  reduction-capable bit.

Note, finally, that section 2 of RFC 2961 states that "When it is not
known if a next hop supports the extension, standard Path and Resv message
based refreshes MUST be used."

> 7. Sending of ACKs bundled with the RSVP HELLO
>
> During interop testing, it was observed that Message Acks were
piggybacked
> onto RSVP Hello messages, when the receiving end was not using the Hello
> protocol. In this situation, the incoming Hello's were discarded and the
> Acks were lost.
>
> We believe that Message Acks should only be piggybacked onto mandatory
> messages, and not on Hello messages because of this problem. Comment on
> this interpretation is requested.

You use of the terms "bundled" and "piggybacked" are contradictory.

"Bundled" implies the use of the Bundle message.
RFC 2961 states...
   A sub-message MAY be any message type except for another
   Bundle message.
Thus, Ack messages may be bundled with other messages. (Although one might
consider this perverse since the Ack message is only introduced to handle
the case when the Ac/Nack objects have no other message on which they can
be carried.)

Further, RFC 3209 states...
   A Hello message may be included
   as a sub-message within a bundle message.

Therefore, it acceptable for a Ack and Hello messages to be bundled
together.
The processing rules (RFC 29610 for Bundled messages are such that each
sub-message is processed in its own right, and the non-support/non-use of
Hello messages should not impact the processing of other messages.

On the other hand, "piggybacked" implies the use of the Ack/Nack objects
within a Hello message.

Section 4.1 of RFC2961 states that Ack/Nack objects may be included in the
"standard" RSVP messages, and shows where they are placed. However, RFC
3209 defines the Hello message as not including the Ack/Nack objects...

   <Hello Message> ::= <Common Header> [ <INTEGRITY> ]
                              <HELLO>

Since RFC 3209 post-dates RFC 2961, this definition is definitive and the
Ack/Nack objects should not be present on the Hello message.

Give that section 5.3 of RFC 3209 states...
   The Hello Message is completely OPTIONAL.  All messages may be
   ignored by nodes which do not wish to participate in Hello message
   processing.
...it is not particularly important what the message format rules are. An
implementation that chooses to place an Ack/Nack object in a Hello message
knows that the object might be discarded unprocessed.

> 8. TSPEC format to be used for Ethernet connections

The CCAMP working group is currently discussing the use of GMPLS for
control of Ethernet devices. We will respond to this point in a separate
email.

Best regards,
Adrian Farrel
Kireeti Kompella

---

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Fri, 26 Aug 2005 09:57:07 -0500

Hi Adrian,

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.

I also do not understand the RCC=1 NCC=1 encoding, since the rule
contained in the current RFC actually makes more sense.  If there is
only
one signal element, there is no contiguous concatenation, by definition.
So I fail to see the usefulness of these encodings.

Regards,
Ben

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Friday, August 26, 2005 6:27 AM
> To: [email-masked]
> Subject: Final draft of response to the OIF
> 
> > Reading of the encoding in 
> draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
============================================================
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: Huub van Helvoort <[email-masked]>
Date: Fri, 26 Aug 2005 19:54:07 +0200

Hello Ben,

> 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

> 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

> If there is

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.

> Ben

Cheers, Huub.

-- 
================================================================
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 31 Aug 2005 00:47:40 -0400

Hi Adrian,

I have some sympathy with Ben's comments, it seems like a single
value would simplify configuration the most.  We were able to work
around the problem at the OIF test, but the number of vendors was
limited and it did cause some initial headaches.

Short of a single value, maybe a slight rewording of your text would
make
a stronger recommendation that implementations be able to accept
both, e.g.:

  " Note 3: Following these rules, when requesting a VC-4 signal, the
      RCC and the NCC values must be set to 0 whereas for an STS-3c SPE
      signal, the RCC and the NCC values must be set 1. However, if
      local conditions allow (e.g., no differentiation of VC-4 vs.
STS-3c
      format is required), then the requesting upstream node MAY set
      the RCC and NCC values to either SDH or SONET settings without
      impacting the function, and the downstream node SHOULD accept
      either of the requested values. If the received value cannot
      be supported, the receiver downstream node MUST generate
      a PathErr/NOTIFICATION message (see Sections 2.2 and
      2.3, respectively). "

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, August 30, 2005 4:12 PM
To: Mack-Crane, T. Benjamin; Richard Rabbat
Cc: Huub van Helvoort; [email-masked]
Subject: Re: Final draft of response to the OIF

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
>
> > From: Richard Rabbat [mailto:[email-masked]]
> > Sent: Tuesday, August 30, 2005 3:58 PM
> > To: Mack-Crane, T. Benjamin
> > Cc: Huub van Helvoort; Adrian Farrel; [email-masked]
> > 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
> > >
> > >
> > >
> > >>From: Huub van Helvoort [mailto:[email-masked]]
> > >>Sent: Friday, August 26, 2005 10:56 AM
> > >>To: Mack-Crane, T. Benjamin
> > >>Cc: Adrian Farrel; [email-masked]
> > >>Subject: Re: Final draft of response to the OIF
> > >>
> > >>Hello Ben,
> > >>
> > >>You wrote:
> > >>
> > >>
> > >>
> > >>If there is agreement that they should be the same, we should also

> > >>look at higher order contiguous concatenated signals:

> > >>STS-768c == VC-4-256c
> > >>
> > >>
> > >
> > >These signals are already encoded the same way (for instance see 
> > >examples 3 and 9 in RFC 3946).
> > >
> > >
> > >

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

---

From: "Stephen Shew" <[email-masked]>
Date: Wed, 31 Aug 2005 11:32:00 -0400

I prefer Ben's solution of having one encoding for STS-3c and VC-4.

> Sent: Tuesday, August 30, 2005 19:12
> > 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.
> 
> > 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:
> 
> > 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
> 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
<snip>