[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FYI: WorldCom Vote/Comments - ITU-T Y.1710 (Corr. 1) and Y.1711
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 "tsg13q3@itu.int" 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.