Subject: FYI: WorldCom Vote/Comments - ITU-T Y.1710 (Corr. 1) and Y.1711

From: Dave McDysan <[email-masked]>
Date: Thu, 02 May 2002 15:05:26 -0400

WorldCom has submmited comments on draft recommendations ITU-T Y.1710 (Corr.
1) and Y.1711 to the ITU-T with a vote of "We do not support this text.
Reasons are given in the attachment."

It is not yet clear whether these comments will be handled at the Japan
meeting in July or at the next SG13 meeting in Oct-Nov'02.
WorldCom is trying to get clarification.

These comments have been posted by the ITU-T secretariat at:

http://www.itu.int/itudoc/itu-t/aap/sg13aap/recaap/y.1710c1/arc/ar1.html

and http://www.itu.int/itudoc/itu-t/aap/sg13aap/recaap/y.1711/arc/ar1.html

However, access require a TIES account which an ITU member can request by
sending a form to the ITU-T.  After getting the TIES access, you may sign
up for ITU-T SG13, Question 3, email list "[email-masked]" at
http://www.itu.int/ITU-T/studygroups/com13/edh/subscribe.html

if you want to be part of email discussion on these and other related
comments.

WorldCom has also advised ITU-T SG13,Question 3 participants of these
comments who are responsible for development of these recommendations in
SG13.

If your company is an ITU-T member and is interested in this subject, we
encourage you to participate in the process.

The WorldCom comments on the subject documents are reproduced below for your
information.

Dave

============================================================================
=
		ITU-T Draft Recommendations Y.1710 (Corr. 1)
                  (WorldCom Comments - Additional Review)

1.  General Comments

Although never clearly stated in Y.1710, based upon related discussion
and documents submitted to the IETF, this recommendation appears to
assume that MPLS is a layer two service, requiring OAM functionality
that exists independently of any layer three technology. This
assumption is not consistent with the cited IETF references of
RFC 3031 and 3032, which only address IP over MPLS. Furthermore,
as detailed below, some requirements strive to preclude OAM
mechanisms that rely upon IP.

The IETF has no efforts in place to define MPLS as a layered network
service in its own right. It is incumbent upon those who would
augment MPLS so that it can become a layered service on its own to
explain why existing services, for example, FR and ATM, do not
suffice. This must be done with the concurrence and cooperation of
the IETF, since two bodies developing standards for the same protocol
will likely result in a lack of interoperability.

We suggest that those seeking to use MPLS to deliver multiple services
should explore the IETF PWE3 work. It may be more appropriate to build
OAM functionality into the PWE endpoints than in the MPLS layer as
proposed in Y.1710 and Y.1711.

We also have a number of questions. Can the proposed mechanisms be
implemented without fundamental changes to the deployed MPLS base?
Will the proposed mechanisms provide any useful functionality in the
face of penultimate hop popping? Will the proposed mechanisms provide
any useful functionality in the face of LSP merging? Will the proposed
mechanisms provide any useful functionality in the face of
unidirectional LSPs?

Finally, we believe that there are several process issues with
these proposals:

a. First, in general defining OAM prior to the standardization of a
   service appears to be the wrong order of doing things.

b. Second, defining requirements and a proposed solution to them in
   parallel is an approach that seems to preclude the critical
   examination of alternative solutions. We strongly recommend that
   the ITU-T focus on defining the problem scope and associated
   requirements BEFORE taking up any specific solution.

c. Finally, in the IETF way of doing things it is perfectly acceptable
   for vendors or service providers to develop experimental
   implementations of the protocol(s) defined in Y.1711 and bring the
   results of this work back to the IETF.

2.  Detailed Comments

2.1 Section 1  Scope

- Since the plural is used in "MPLS networks," does the scope include
  MPLS LSPs that traverse multiple service providers? If so, this should
  be explicitly stated.
- Since only RFC 3031 and 3032 are cited as references for MPLS, the
  scope is restricted to IP over MPLS networks. Although other efforts
  are in progress to standardize other services over MPLS, until these
  standards are complete and stable, definition of the means to operate
  and maintain (OAM) them are premature.

2.2 Section 3  Definitions

- Why is control information excluded from these definitions? How relevant
  are definitions to IP over MPLS from the cited M.20 Recommendation
  intended to define migration from analogue to digital circuits?

2.3 Section 5  Introduction

- What is the basis of determining whether a solution is "architecturally
correct?" Suggest that the reference for a correct architecture be cited and
agreed to,or strike this phrase.
- Suggest that instead of "maintain correct connectivity," what is actually
  required is to "maintain and confirm configured connectivity."  This
should
  also be stated in the bulleted list in the second paragraph.
- The claim in the last sentence that an LSP is tied to availability and QoS
SLAs for customer traffic is suspect. An LSP is only part of an IP service.
For example, IP traffic may be load balanced across more than one LSP, or
may
  traverse router hops that do not use MPLS. Even in a pseudo-wire over MPLS
  application, the entire customer service may not be over MPLS. The fact
that
  MPLS is often only part of the overall service needs to be stated in the
scope and carried throughout the requirements structure.

2.4 Section 6  Motivation for MPLS Functions

- General Comment
  * A number of terms used in this section are not used in the MPLS
standards
    cited in section 2, and should be replaced with standard terminology.
For
    example, the Y.1710 terminology in quotes should be replaced as follows
    with terminology from RFCs 3031 and 3032:

   > "client" = packet or network layer
   > "server" = link layer
   > "MPLS nesting capability" = label stacking
   > "control-plane" = control protocol
   > "user-plane" = forwarding

  * It is unclear why much of this text and reasoning is needed in a
    requirements document. If retained, this text needs definitions of all
    terms and better explanation of the concepts addressed. Some detailed
    comments below attempt to draw out some of the issues with this text.

- Item 1
  * First paragraph: The level of MPLS label stacking is limited by at least
    the MTU size of the link layer.
  * Second paragraph: Need better description or an example of a "MPLS
    control-plane OAM function" in order to provide appropriate motivation.
    . First dash: What is "user-plane" for customer traffic and signalling?
      If these do not have the same processing or failure conditions, then
      is this an implementation issue that is outside the scope of
standards?
      Wouldn't the same argument of the last sentence apply equally to MPLS
      OAM packets?
    . Second dash: This is outside the scope of RFC 3031.
    . Third dash: This is not worded as a problem.
    . Next to last paragraph: The assertion that well defined and
interoperable MPLS control protocols and (as yet undefined) MPLS OAM
mechanisms be defined independently so that they can evolve independently is
questionable.
      For example, as stated earlier, it seems highly desirable that in
order for MPLS OAM mechanisms to confirm configured connectivity that a
dependence of OAM on control protocol configuration makes sense.
	The last paragraph of item 1 that the solution is control-plane independent
appears to be in contradiction with RFC 3031, which requires and IP control
plane in every MPLS LSR.

- Item 2
  * See comment in section 5.  An LSP is not necessarily directly related to
a
    customer service.

- Items 3 & 5
  * Seem to be making the same point.  Also, most of this information is
repeated in section 7.

- Item 6
  * The example of "squelching of traffic" is unclear.  Wouldn't the
preferred
    solution be to correctly direct the traffic?  Is squelching an
intermediate step toward this goal?

- Item 8
  * Interaction of protection and restoration between multiple technological
    layers operating under different paradigms is a complex and as yet not
    completely understood subject.

2.5 Section 7  Requirements for MPLS OAM Functions

- Item 1
  * "on-demand" and "continuous" are not defined.

- Item 2
  * Why is notification of a control protocol not mentioned?

- Item 3
  * This requirement is vague. How would one determine whether a particular
    solution met this requirement? Last sentence is redundant with item 4.

- Item 4
  * The terms "fabric", "swapped" and "self-replication" are not defined in
    the document or any of the references cited. Need a definition of
    "simple loss of LSP connectivity".

- Item 5
  * A very general statement which leaves it unclear as to what the specific
    requirement is on MPLS OAM. Needs clarification.

- Item 9
  * Where is the definition for a LSN? RFC 3032 defines a Label Switching
Router LSR), and suggest use of this term. It appears that this requirement
    would apply to the egress LSR. What happens when penultimate hop popping
is implemented?

- Item 10
  * As mentioned earlier, MPLS is not currently defined as a service and
hence
    availability and QoS are not meaningful in the conventional sense.
Also,
    the reference to Y.1711 should be removed. A requirement should not be
    defined in terms of a specific solution.

- Item 11
  * Since only RFC 3031 and 3032 are cited as normative references for MPLS,
    the scope is restricted to IP over MPLS networks. Since only support for
    an IP "client" network is all that is defined, this requirement for OAM
    is premature until protocols (or at least the architecture for them)
    for support of other "client" networks are standardized.

- Item 12
  * Since only RFC 3031 and 3032 are cited as normative references for
MPLS,
    the scope is restricted to IP over MPLS networks. This requirement has
no
    architectural or protocol standards basis.

- Item 14
  * Why preclude observance of normal operation as part of OAM?

- Item 16
  * Second sentence is stated as a solution. Delete.

3.  Additional Comments

Several important requirements are also missing. We note at least the
following:

- Since MPLS LSPs are unidirectional, OAM mechanisms that require
communication
  in the opposite direction cannot rely on the existence of an LSP in the
  opposite direction between the ingress and egress LSR.

- Depending upon interpretation of the scope, support for MPLS OAM across
  multiple service providers may be a requirement.

- When MPLS label stacking is employed, the OAM mechanisms must operate
  correctly at each level of label stacking.

- MPLS OAM must work correctly with and without penultimate hop popping.

- There needs to be some requirements that scope how large the MPLS OAM
  identifier space needs to be. For IP over MPLS, the number of LSPs that
can
  exist can be quite large. If other services are considered (e.g., IP VPN,
PWE3),
  then the identifier space needs to be correspondingly large.

- It is highly desirable to be able to determine the actual path that an LSP
takes.
============================================================================
=
		  ITU-T Draft Recommendations Y.1711
                         (WorldCom Comments - Additional Review)

Since the MPLS OAM mechanisms described in this recommendation are based
on the requirements defined in recommendation Y.1710 (Corr. 1), it will
be premature to approve Y.1711 until the comments submitted by WorldCom
on Y.1710 (Corr. 1) are resolved.  WorldCom's general comments on
Y.1710 (Corr. 1) are also applicable to Y.1711, and are repeated below
for the sake of completeness.

Although never clearly stated in Y.1711, based upon related discussion
and documents submitted to the IETF, this recommendation appears to
assume that MPLS is a layer two service, requiring OAM functionality
that exists independently of any layer three technology. This assumption
is not consistent with the cited IETF references of RFC 3031 and 3032,
which only address IP over MPLS. Furthermore, as detailed below, some
requirements strive to preclude OAM mechanisms that rely upon IP.

The IETF has no efforts in place to define MPLS as a layered network
service in its own right. It is incumbent upon those who would augment
MPLS so that it can become a layered service on its own to explain why
existing services, for example, FR and ATM, do not suffice. This must
be done with the concurrence and cooperation of the IETF, since two
bodies developing standards for the same protocol will likely result
in a lack of interoperability.

We suggest that those seeking to use MPLS to deliver multiple services
should explore the IETF PWE3 work. It may be more appropriate to build
OAM functionality into the PWE endpoints than in the MPLS layer as
proposed in Y.1711.

We also have a number of questions. Can the proposed mechanisms be
implemented without fundamental changes to the deployed MPLS base?
Will the proposed mechanisms provide any useful functionality in the
face of penultimate hop popping? Will the proposed mechanisms provide
any useful functionality in the face of LSP merging? Will the proposed
mechanisms provide any useful functionality in the face of
unidirectional LSPs?

Finally, we believe that there are several process issues with
these proposals:

a. First, in general defining OAM prior to the standardization of a
   service  appears to be the wrong order of doing things.

b. Second, defining requirements and a proposed solution to them in
   parallel is an approach that seems to preclude the critical examination
   of alternative solutions. We strongly recommend that the ITU-T focus
   on defining the problem scope and associated requirements BEFORE
   taking up any specific solution.

c. Finally, in the IETF way of doing things it is perfectly acceptable for
   vendors or service providers to develop experimental implementations of
   the protocol(s) defined in Y.1711 and bring the results of this work
   back to the IETF.