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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf