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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf