Incoming correspondence from the OIF

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

We have received the following email and attachment from the OIF.

I will put these on the web at http://www.olddog.co.uk/incoming.htm

Cheers,
Adrian

========

Dear Mr. Farrel and Mr. Kampella,

On behalf of Jim Jones, OIF Technical Committee Chair, attached please
find
a liaison letter regarding findings from the OIF Interoperability
Demonstration at SUPERCOMM.

Warm Regards,
Stephanie

Stephanie Lazicki / Association Coordinator Optical Internetworking Forum
39355 California Street / Suite 307 / Fremont, CA 94538 USA
Phone: +1.510.608.5928 main / +1.510.608.5916 direct
Fax: +1.510.608.5917
Email: slazicki@oiforum.com
http://www.oiforum.com

Managed by Association Management Solutions (AMS); Forum management,
Meeting and Event Planning http://www.amsl.com

========
Text of attachment...

To: Mr. Adrian Farrel, WG Co-Chair for IETF CCAMP
Mr. Kireeti Kompella, WG Co-Chair for IETF CCAMP
Copy to Alex Zinin and Bill Fenner, IETF Routing Area Directors
From: Jim Jones, OIF Technical Committee Chair
July 25, 2005
Dear Adrian and Kireeti,

The OIF recently concluded a worldwide interoperability demonstration at
Supercomm in June 2005 that successfully focused on dynamic setup of
Ethernet Private Line service over an ASON enabled SONET/SDH network. A
number of issues were encountered during testing that were felt to be of
possible interest to the IETF CCAMP WG, and OIF invites the review and
comment of IETF CCAMP on these issues. They include the following:

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

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.

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)."

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.

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.

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.

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.

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.

8. TSPEC format to be used for Ethernet connections

For the interoperability demonstration, the INTSERV SENDER_TSPEC format
was used. However, it appears to us that the INTSERV SENDER_TSPEC defined
in RFC 2210 is not sufficient to support the Ethernet Private Line
described in MEF and ITU-T documents as the MEF and ITU-T specifications
provide a bandwidth profile description for Ethernet Private Line
connections that includes six parameters described below, and the INTSERV
format does not have fields that correspond with all six parameters.
MEF6 [2] specifies that the Ethernet Bandwidth Profile is specified in
terms of the following parameters: CIR, CBS, EIR, EBS, CM, CF. MEF10 [3]
and G.8011 Am1 [1] define the parameters, summarized below:

CIR (Committed Information Rate): Maximum rate required under normal
conditions, service level guaranteed.
CBS (Committed Burst Size): Limits the number of bytes for a burst while
conforming to CIR.
EIR (Excess Information Rate): Maximum rate required under burst
conditions, no guarantee of performance.
EBS (Excess Burst Size): Limits the number of bytes for a burst while
conforming to EIR.
CF (Coupling Flag) and CM (Colour Mode): Give a choice for different modes
of operation.

RFC2210 defines the following SENDER_TSPEC format for Ethernet Traffic
Parameters as follows:
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 7 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |0| reserved | 6 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(a) - Message format version number (0)
(b) - Overall length (7 words not including header)
(c) - Service header, service number 1 (default/global information)
(d) - Length of service 1 data, 6 words not including header
(e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
(f) - Parameter 127 flags (none set)
(g) - Parameter 127 length, 5 words not including header

Advice of the IETF CCAMP WG or other experts within IETF is solicited
regarding what TSPEC format if any is
suitable to be used for setup of Ethernet connections.

OIF greatly appreciates the input of the IETF CCAMP WG and other IETF
experts in order to reach conclusion
on these issues.
Best regards,

Jim Jones, OIF Technical Committee Chair

cc: Trey Malpass, Lyndon Ong

References:

[1] ITU-T Recommendation G.8011/Y.1307 (2004), Am. 1 (2005), "Ethernet
Services Framework"

[2] Metro Ethernet Forum, MEF 6 - Ethernet Services Definition, Phase 1,
Jun3 2004

[3] Metro Ethernet Forum, MEF.10 - Ethernet Services Attributes Phase 1,
Nov. 2004