Below are my comments on this draft, these are in addition to the comments
that I have provided previously. I also support the comments that propose
the deletion of sections 4, 5 and 6.
I have numbered my comments (1-12) to simplify identification for those
who wish to respond.
I do not support approval of this draft in its current form.
Regards,
Malcolm
1) Two encapsulations for PW OAM
The draft provides the Reasons for Selecting a Single Solution for MPLS-TP
OAM. However, two different encapsulations have been defined for OAM
messages in the MPLS-TP PW. One uses just the ACh the other uses both the
GAL and ACh. These two encapsulations must be identified and rationalized
in the context of selecting a single solution. Particular attention
should be paid to the text from RFC5317 quoted in section 1.1 “…the
architecture allows for a single OAM technology for LSPs, PWs…”
2) Quote from RFC5317
Section 1.1 includes the following:
[RFC5317] includes the analysis that "it is technically feasible that
the existing MPLS architecture can be extended to meet the
requirements of a Transport profile, and that the architecture allows
for a single OAM technology for LSPs, PWs, and a deeply nested
network."
The context of this quote from slide 113 should be clarified; slide 12
states of RFC 5317 states:
This presentation is a collection of assumptions, discussion points and
decisions that the combined group has had during the months of March and
April, 2008
This represents the agreed upon starting point for the technical analysis
of the T-MPLS requirements from the ITU-T and the MPLS architecture to
meet those requirements
Proposal: Insert the following text before the quoted text:
[RFC 5317] provides a collection of assumptions, discussion points and
decisions that the JWT has had during the months of March and April, 2008.
This represents the agreed upon starting point for the technical analysis
of the T-MPLS requirements from the ITU-T and the MPLS architecture to
meet those requirements. Included in this analysis is the statement that
"it is technically feasible that the existing MPLS architecture can be
extended to meet the requirements of a Transport profile, and that the
architecture allows for a single OAM technology for LSPs, PWs, and a
deeply nested network."
3) Section 1.2 The Development of a Parallel MPLS-TP OAM Solution
The section should be deleted or rewritten since it includes a number of
assertions that have not been substantiated and are not supported by a
significant number of participants.
4) Consistent with existing MPLS OAM
Section 3.3 states:
Given this intention for compatibility, it follows that the MPLS-TP
OAM protocols should be consistent with the existing, deployed MPLS
OAM
This statement requires further clarification and justification since:
a) The existing MPLS OAM tools use an IP encapsulation, the MPLS-TP OAM
tools use a GAL/ACh encapsulation; and:
b) The only existing deployed OAM tools were BFD and LSP Ping, all the
other OAM tools are new so it is difficult to understand the concept of
compatible.
5) MPLS as a Convergence Technology
Section 3.2 includes the statement:
“When we arrive at our destination of TCP/IP/MPLS running directly over
fiber, the operators will use MPLS OAM tools to make this work.”
This statement is technically incorrect; MPLS must be encapsulated in a L2
and L1 protocol before it can be transmitted over a physical media.
Further I have seen no evidence that network operator will use MPLS to
maintain the optical network infrastructure e.g. amplifiers, WDM couplers
etc.
The section is based on the assumption that the network will rapidly
converge to being just IP/MPLS. This is not a universally accepted view.
Section 3.2 should be deleted.
6) Section 3.3 End to end OAM
I agree that end to end OAM is important for maintaining a service.
However, we also need OAM to maintain the transport infrastructure that is
independent of the services (or even the presence of a service).
Section 3.3 also states:
This is a design paradigm that has guided the IETF in the development
of its exiting network layer connectivity OAM protocols. For each
network layer protocol there is only one ping, trace route, or fast
connectivity protocol, and amongst these there is a common design
approach.
This is not correct the IETF have defined multiple protocols for PWs.
Section 3.3 should be deleted or rewritten
7) Section 3.5 Interworking
I agree that interworking adds complexity and should be avoided. However
this section includes a large amount of general considerations that are
not relevant to MPLS-TP OAM for example:
Universal deployment of both OAM protocols … introduces additional
testing
requirements to ensure there are no conflicts when both protocols are
run on a common platform.
The use of the ACh to distinguish between protocols avoids the possibility
of conflicts.
Section 3.5 should be deleted or rewritten
8) Section 3.6. Selection of a Single OAM Solution When There is a
Choice.
This section includes only general considerations; it does not reflect the
reality of the current situation where we already have extensive (300,000+
nodes) and growing deployment of an Ethernet based OAM tool set. The
section should be rewritten to provide guidance given the current
situation.
9) Section 3.7. Migration Issues
This section includes a large number of unjustified assumptions about
implementations (e.g. hardware vs. software). The use of field
programmable hardware is also an “implementer’s choice”. A standard
should not dictate or make assumptions about implementations. Also
network migration is normally considered to be a business decision for a
network operator and not the subject of debate in standards.
Section 3.7 should be deleted.
10) Section 6. Potential Models For Coexistence
This section provides only generalized statement, many of which are not
relevant to the case of MPLS-TP OAM that uses a GAL/ACh encapsulation.
As proposed on email this section should be deleted. Or it should be
rewritten to address the case of MPLS-TP OAM using the GAL/ACh
encapsulation and the analyse the impact of the widespread deployment of
Ethernet based OAM and propose strategies to mitigate any adverse
interactions.
Proposal Delete all text except section 6.3.1 (note 6.3.1.1 and 6.3.1.2
should be deleted).
Also text to describe the rules for the interconnection of domains that
use the MPLS OAM tools and domains that use the Ethernet based OAM tools
should be added e.g.:
“Any LSP or PW that interconnects between a domain that uses the MPLS tool
set defined in [I-D.ietf-mpls-tp-oam-analysis] and a domain that normally
uses the Ethernet tools must use the MPLS tool set.”
11) Section 7. The Argument For Two Solutions
This section should be deleted, or those who are proposing the second
solution should be invited to provide text. See the detailed comments
11a) – 11e)
11a) - The IETF solution is taking too long to standardize
This statement and section 7.1 should be deleted. Or Section 7.1 should be
updated to include the actual time line:
January 2008 the ITU had an OAM solution that was based on Ethernet OAM.
However the IETF stated that the encapsulation used violated the MPLS
architecture. On this basis the ITU decided not to approve the
Recommendation.
In March and April the JWT evaluated the possible solutions and set the
expectation that a solution would be standardized in 2009.
In March 2009 the first version of draft-bhh-mpls-tp-oam-y1731 “MPLS-TP
OAM based on Y.1731” was posted.
In February 2011 the approval process on draft new Recommendation G.8013
“Operations, Administration and Maintenance mechanisms for MPLS-TP
networks using the tools defined in G.8013/Y.1731” (as updated at the
Beijing experts meeting) was initiated.
11b) - Commonality with Ethernet solutions is beneficial.
7.2. Commonality with Ethernet OAM misses the point that commonality is
desirable not for peer interworking but to simplify translation of defects
in a server to a client.
Section 7.2 also states:
While this might be a valid discussion point when selecting the
single OAM solution for MPLS-TP, it is countered by the need to
achieve OAM consistency between MPLS and MPLS-TP networks. One might
make the counter argument that if there is a strong need to make
MPLS-TP as similar as possible to Ethernet, it would be better to go
the full distance and simply deploy Ethernet.
Two points must be noted:
a) The IETF should be encouraging the widespread deployment of MPLS not
encouraging the deployment of another technology.
b) As identified in the comments on section 3.3 the only existing MPLS
tools are BFD and LSP ping, so compatibility for new functions such as
loss or delay is not a valid consideration.
Further, at a higher level most networks include both MPLS and Ethernet
and having consistent behaviour will simplify network operations.
11c) - There are two different application scenarios
I do not agree with the assertions made in section 7.3.
11d) - There is no risk of interaction between the solutions
The text in 7.4 does not make it clear how “interaction” will occur given
the use of the ACh to distinguish between protocols. Further current
Transport OSS configure OAM when a connection is established, work is
underway in ccamp to provide signaling extensions to also configure OAM
when a connection is established.
11e) - The market should be allowed to decide between competing
solutions.
It must be noted that 300,000+ nodes using an Ethernet based OAM solution
have already been deployed. These deployments will continue to exist and
grow, this reality should be acknowledged.
12) Section 8. Security Considerations
All text except the first line should be deleted since it contains general
information that is not relevant to the use of a second solution for
MPLS-TP OAM. For example the text:
- One OAM protocol may be used as a vector to attack the other.
Inserting an OAM message of the other OAM protocol onto a link may
cause the service to be disrupted and, because some nodes may
support both OAM protocols, it may be possible to cause the
disruption at a remote point in the network.
How is this possible when the use of the ACh to distinguish between
protocols allows the “other” protocol to be silently discarded.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf