This document provides a factual and concise summary of work, events, and points of view that have developed since the JWT, a summary that's timely and sorely needed as few in the industry outside the project (or even inside the project) can make sense of it. It also provides a thorough and accessible analysis of the costs to service providers, vendors, the market, and the end user that divergent MPLS OAM solutions will create. As such, I think the IETF has a duty to move forward with its publication; the considerations it raises are of significant importance to the Internet community. It's also noteworthy that the proponents of a non-IETF MPLS OAM technology have been unwilling thus far to document the supposed technical problems with standard MPLS/MPLS-TP OAM in an Internet draft. If one didn't know better, one might be tempted to suppose their concerns were more political than technical. Following are LC comments/suggestions on the draft, all minor and editorial. --- Suggest adding a reference to RFC 5921 in first paragraphs of abstract/introduction. --- The terms "inter-working" and "interworking" both appear repeatedly throughout; it would be good to pick one. --- Section 1.1, 4th paragraph: s/which are applicable/that are applicable/ --- Section 1.1, last sentence: s/development and deployment making/development and deployment, making/ --- Section 1.2, 2nd paragraph: s/it was considered/it was judged/ --- Section 1.2, 3rd paragraph: OLD Indeed, one of the key differences between the two environments is the choice of MPLS-TP OAM solution which makes a circular argument. NEW Indeed, one of the key differences cited between the two allegedly distinct environments is the choice of MPLS-TP OAM solution, which makes a circular argument. END --- Section 1.2, next-to-last paragraph: s/normal IETF, consensus-driven/normal consensus-driven IETF/ --- Section 3.1, first paragraph: OLD In MPLS-TP, MPLS was extended to satisfy the transport network requirements in a way that was both compatible with MPLS as has already been deployed, and MPLS and with the IETF envisioned it would develop in the future. NEW In MPLS-TP, MPLS was extended to satisfy the transport network requirements in a way that was compatible both with MPLS as has already been deployed, and with MPLS as the IETF envisioned it would develop in the future. END --- Section 3.1, 2nd paragraph: s/philosophies that have lead/philosophies that have led/ --- Section 3.2, 2nd paragraph: OLD MPLS has been deployed in operational networks for approximately a decade, with the existing MPLS OAM techniques widely deployed in operational networks. NEW MPLS has been deployed in operational networks for approximately a decade, and the existing MPLS OAM techniques have seen wide deployment. END s/MPLS based/MPLS-based/ --- Section 3.3, first paragraph: s/can transition/can cross/ --- Section 3.3, 2nd paragraph: s/exiting network layer/existing network layer/ s/fast connectivity protocol/fast connectivity verification protocol/ --- Section 3.4, first paragraph: Second sentence needs rephrasing; maybe: OLD In an isolated system this may be the case, however when, as is usually case with communications technologies, simplification in one element of the system introduces a (possibly non-linear) increase in complexity elsewhere. NEW In an isolated system this may be the case. In an interconnected system such as a communications network, however, simplification in one element of the system may increase complexity elsewhere, and this increase may be non-linear. END --- Section 3.4, 2nd paragraph: OLD However, when we drive OAM complexity out of one network element at the cost of increased complexity at a peer network element we loose out economically and, more importantly, we loose out in terms of the reliability of this important network functionality. NEW However, when we drive OAM complexity out of one network element at the cost of increased complexity at a peer network element, there is no economic benefit and, more importantly, the reliability of the network is compromised. END --- Sections 4.1-5.3: Suggest expanding acronyms and adding references. --- Section 4.3, first paragraph: OLD Every time a new codec is deployed, translation between it and all other deployed codecs must be performed available within the network, each participating node must be able to handle the new codec. Translation between codec is expensive and can lead to reduced quality. NEW Every time a new codec is deployed, translation between it and all other deployed codecs must be performed within the network; codec translation is expensive and can lead to reduced quality. In addition, each participating node must be able to handle the new codec. END --- Section 4.3, 3rd paragraph: OLD The application layer of the Internet is, however, predicated on a business model that allows for free or shared software (such as in open source developments), and is only possible with the existence of a royalty free codec. This, together with the specific characteristics of transmission over lossy packet networks comprised requirements equivalent to a major difference in functionality, and led to work in the IETF to specify a new codec. NEW The application layer of the Internet is, however, predicated on a business model that allows for the use of shared, free, and open-source software; this model requires the existence of a royalty-free codec. This, together with the specific characteristics of transmission over lossy packet networks, comprised requirements equivalent to a major difference in functionality, and led to work in the IETF to specify a new codec. END --- Section 5.2: This paragraph talks about 802.16 d/e and then mentions 802.16a; is this intentional? --- Section 6.1, 2nd paragraph: s/the protocols rules/the rules/ --- Section 6.1, 3rd paragraph: s/the protocols rules/the rules/ --- Section 6.1, 4th paragraph: s/These are obvious issues/There are obvious issues/ --- Section 6.3.1.1, last paragraph: s/route trace function/route trace functions/ --- Section 6.3.2: s/Sections/sections/ --- Section 6.3.2.1, 4th paragraph: s/in is necessary/it is necessary/ --- Section 6.3.2.1, last paragraph: s/working and is protection/working and protection/ --- Section 7.1, 2nd paragraph: s/will not will/will/ --- Section 7.1, last paragraph: This paragraph is a bit vague. It should probably be recast to be specific about the phase of work that's nearing completion and how this phase relates to the overall requirements and joint work plan. --- Section 7.3, 2nd paragraph: s/One of stated/One of the stated/ --- Section 7.4, last paragraph: s/family, makes/family makes/ --- Section 7.5, first paragraph: s/as in the in the/as in the/ --- Cheers, -d _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf