Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-oam-framework-09

From: Thomas Morin <[email-masked]>
Date: Sat, 20 Nov 2010 16:58:31 +0100

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review. The purpose 
of the review is to provide assistance to the Routing ADs. For more 
information about the Routing Directorate, please see 
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-mpls-tp-oam-framework-09
Reviewer: Thomas Morin
Review Date: 2010-11-20
IETF LC End Date: 2010-11-22
Intended Status: Informational

*Summary:*  "I have significant concerns about this document and 
recommend that the Routing ADs discuss these issues further with the 
authors."

*Comments:*

Beyond the issues I found with the document (see below), I have a 
general concern on the readability of the document.

*Major Issues:*

A1 - It seems to me that the role of this document, among the documents 
defining the MPLS Transport Profile, should be clarified and/or better 
explained. One of my assumptions was that what such a "framework" was 
written to factor out, and document in one place, all of what is common 
to the MPLS-TP OAM solutions, many of which are expected to be defined 
because of the multiplicity of OAM functions that are needed. I would 
expect the document to give a high-level roadmap of the specification 
documents that will be added to obtain full specifications (for 
instance: one document for CC, one for CV, or for LM, one for tracing 
etc. ; with the possibility of grouping the specs for some of these into 
common docs when applicable). I would also expect the document 
introduction to indicate where it stands with reference to already 
defined document on MPLS and MPLS-TP OAM (the important relation ship 
with GACH specs and PW VCCV is only explained in the sub-section on 
SPME...).

A2 - The document has in two places a wording that could lead to 
misunderstandings: the phrase "each OAM solution" is used in 3.3§5 and 
3.3§14, which could be understood as an acknowledgement that multiple 
solution for a same OAM function would be acceptable (eg. multiple 
solutions for MPLS-TP CC) : this is an important point wrt. interop 
issues, and need to be clarified.

A4 - I see also a possible issue related to the status of the document : 
in some places, the wording used, and the level of detail, gives the 
impression that all of what is said in the document will be enforceable 
on all MPLS-TP OAM solution specifications; but at the same time, the 
document is only "Informative" (and is accordingly not written in a way 
that appears to me as appropriate for a Standard Track document; it does 
not look like a specification document and does not claim to be). Maybe 
the solution would be to state clearly which role this document has with 
reference to other OAM specifications documents : only guidelines ?. See 
also comment A5 below.

A5 - Not unrelated to the previous comment, it seems to me that this 
document sometimes goes into very low-level specifications details 
related to the structure of OAM data exchanged between nodes (OAM 
messages, OAM packets etc.) and the procedures on how they are exchanged 
: (a) this does not seem appropriate in a framework document, and (b) is 
here not even done in an homogeneous manner (not done in all places, not 
grouped) and often done in a way that lacks the required precision (the 
required precision for this to play the role of a specification), or 
lacks explanations on the motivations behind the choice made.

In fact, all this gives the feeling that the authors had a very specific 
solution in mind when writing this framework, and wrote the framework 
(or at least parts of it) based on this. Getting consensus on the 
specifics of a solution seems to me as belonging to a specification 
document, which this document does not claim to be. It seems that it 
would be worth considering moving all the details that are low-level 
specs to appropriate solution specification document (and for cases 
where very specific indications would have to be kept, documenting the 
reasons and motivations of why they are in this document).

More specifically:
- the document implies that there are multiple types of OAM packets, and 
even specifies one of these types, going as far as to indicating that 
there is a common type for Continuity Checks and Connectivity 
Verification ("CC-V OAM packets") : isn't it a level of detail more 
appropriate in a specification rather than in a framework ? and if done 
in a framework, shouldn't we expect this to be more exhaustive ?
- the definition section seem to impose a certain structure in the OAM 
data (OAM "packets" containing OAM "messages" themselves containing OAM 
"information elements") ; this seems a too low level of detail in a 
framework, which I think is confirmed by the fact that this structure is 
not really leveraged in the rest of the document (where "information 
element" is rarely used, and where most of the time "packet" is used)  
[as a side node, this seem to possibly exclude a solution allowing a 
piece of OAM information to be split across multiple packets, e.g. to 
cope with MTU issues]
- in many different places, the text introduces names (with a capital 
letter) of some specific fields or information in OAM packets or 
messages ("Period" (5.1.1.3), "Target MIP" (3.4)), but this is not done 
evenly across the document since in some places the text is, 
appropriately, worded in a more abstract manner (such as "OAM messages 
must carry information on...")
- even though this is not introduced clearly, after reading the 
document, the reader will understand that most OAM packets are periodic ;
why this choice is made should at the very least be explained (periodic 
messages is not unexpected for pro-active monitoring messages, but less 
obvious for alarms report, remote defect indication...)
- imposing that all OAM packets directly carry information about the 
period is a too low-level detail for a framework (not to mention 
defining the name of the "field" of the OAM "packet") : why exclude an 
OAM solution where the periodicity would be announced once but not 
repeated in all packets, or other solutions...?
- the document indicates that on-demand connectivity verification 
messages/packets will be sent in "bursts" but no reason for this choice 
is given: why not only one ? why send the packets in a burst rather than 
spaced in time ?... (and... what *exactly* makes a sequence of packets a 
"burst"...) ; note that section 7.1.1 does not use on burst, and 
introduce reliability in the OAM exchange by using an ACK message

A6 - The document, when introducing the notions of "Up MEP", "Down MEP" 
and "MIP" (sections 3.3 and 3.4), introduces an assumption of the 
internal design of an LSR : first of all, I note that this is unusual, 
since protocol specifications are usually written independently of such 
aspects and this seems like a good idea because the internals of an LSR 
are not standardized, and second I see a possible practical limitation 
due to the specific assumption being made : the assumption being made is 
that an LSR is made of multiple interfaces with a "forwarding engine" in 
the middle, and I fail to clearly see the implications in cases where 
the forwarding engine function is distributed in the LSR with parts of 
the work done in interfaces ; furthermore in cases where the node is 
multi-chassis, it seems possibly limiting to not be able to put MIPs in 
each possible place inside the LSR.  It seems to me that either the 
specs chooses to talk about what is inside a node, but then should not 
restrict what can be done, or the spec should try to not make any 
assumption of how a node is internally designed.

A7 - Beyond these comments on the nature of the document, I would have 
the following concerns about how CCCV is designed here:
   * there seem to be a lot of complexity brought by the choice of 
mixing CC and CV in the same packets
   * things would seem simpler if a source MEP identifier was always be 
used, including for CC
   * on the periodicity of "CC-V" messages: the document implies that 
periodicity is configured on *both* source and sink MEPs, and both must 
match (at least for bidir.), but nevertheless OAM messages 
"self-identify" their periodicity, and specifies procedures to detect 
misconfiguration of the period: this looks to me as more complex than 
needed and seems to me as offering opportunities for things to break
[Of course, all of this is relatively "low-level", and as per my other 
comment, could possibly be moved and discussed into specification 
documents, in which case this comment can be ignored]

A8 -  Issues related to point-to-multipoint:
  * the functional model imposes that a MEP terminates all the OAM 
packets that it has received : what about a Down MEP on a node that is a 
bud node for a point-to-multipoint LSP (bud: at the same time a branch 
node and a leaf node for this LSP) ? if it actually terminates all the 
OAM packets received, then it seems that sink MEPs that are below him 
down the point-to-multipoint LSP won't receive any OAM packets. if I'm 
correct, then it probably needs to be fixed in some kind of way.
  * P2MP and OAM scaling : it seems that some of the mechanisms describe 
will have issues to scale when applied to P2MP, more specifically the 
ones where messages are sent back to the source MEP; examples are 
connectivity verification, loss measurements, throughput estimations and 
tracing; the scaling issue is that the source MEP will receive an amount 
of messages proportional to the amount of leaves (made worse by the fact 
that these are bursts in some cases)
  * Lock Reporting : is this mechanism designed also for P2MP ? how does 
a lock on a part of a tree impacts other parts of the tree that are not 
between the portion locked and the leaves below the portion locked ?  (I 
could guess an answer, but I believe the document should be explicit)

A9 - "TTL addressing": with a fresh eye, my first reaction was to find 
this mechanism a bit clunky given that the idea consist in overriding 
the TTL mechanism (which is aimed at reducing the impact of loops) for 
an OAM purpose, and that in such a case one may wonder what happens 
when/if these two mechanisms enter in competition.
It could be claimed that IP traceroute is somehow a precedent, but 
traceroute is not a key building block of the IP architecture (OAM is a 
key part of MPLS-TP architecture), traceroute is also only used for 
tracing.
So, I would say that such a particular mechanism would at the very least 
deserve being introduced in a dedicated sub-section (vs. being buried at 
the end of a section), and that this section could say more on the side 
effects of this choice and how they are handled : for instance referring 
to section 3.2 on SPME (that talks about that) and also describing the 
expected behavior when/if an OAM message TTL-expires at a node that was 
not the intended one (and possibly a node not supporting MPLS-TP OAM?).

A10 - Throughput estimation (section 6.3.1): I'm highly skeptical of how 
such a feature will be applicable in practice because of the following:
  * the use of this feature may create congestion in the network: will 
an operator use this feature if it may impact have side-effects on 
customers ?
  * existing congestion in the network may impact the measurements: will 
the throughput estimation be useful ?
  * the estimation obtained will only reflect the bandwidth available at 
the moment when the measure is made, but the bandwidth available may not 
be constant over time
  * the option of having "two-way" throughput estimation looks to me as 
uselessly increasing the complexity : as noted, the same result is 
achievable with two one-way measurements, and it will not be limited by 
the bandwidth of the return path
  * if the two-way option is kept, it should be noted that it will not 
scale for point-to-multipoint
  * as noted in the document, the feasibility of line-rate processing 
the OAM packets may severely limit the use of this feature; and just 
saying that "Whether OAM packets can be processed at the same rate as 
payload is implementation dependent" does not make issues go away: what 
about interop between an equipment able to line rate process OAM packet 
and another not able to ?  I'm wondering why injecting data packets (non 
OAM packets) one-way and counting what is received on the other end 
wouldn't meet the goal ; it seems to me that it would avoid issues 
related to line rate processing of OAM packets

A11 - QoS of OAM packets : in multiple sections, indications are given 
on the PHB that will be chosen for OAM packets: while I can see how this 
applies to E-LSPs (PHB determined by the Traffic Class field of the MPLS 
header), I don't understand how this can work in the case of L-LSPs 
where only the drop precedence (not the whole PHB) is determined by the 
TC field, while the scheduling class is determined based on the label of 
the packet (common to all packets of the LSP, whether they are "real" 
data or OAM).  The text gives the impression that only the E-LSP case is 
considered (contrarily to assumptions of the MPLS-TP framework).

A12 - Security: Section 8 is honest, but at the same it is hard to 
ignore that what it is saying is something close to "we describe 
features that can disrupt a network, which is vulnerable to MITM attacks 
and we think that crypto is not going to be applicable, so we will just 
assume that the network is physically secured".
Of course, a possible comparison would be a routing protocol like ISIS: 
it is also vulnerable to MITM attacks and today operator seem to be 
happy enough with assuming that the network is physically secured. But 
contrarily to what is described here, IS-IS is not used between 
non-trusted domains, and there are described crypto solution to mitigate 
these risks. Furthermore, since MPLS-TP OAM is supposed to be able to 
run even without IP, it cannot I guess get away with saying "let's use 
IPSec between LSRs".
So, I don't really know how this would be fixable, but at the very 
least, it seems to me that the document should indicate that the area 
which needs to be trusted extends usual administrative domain 
boundaries, since the OAM designed here is supposed to be able to cross 
domain borders, and that as a result, it should be recommended that the 
OAM that a domain accepts from another domain should be filtered/policed 
in some kind of way.
(I'm looking forward on how security area people will react if this 
review this, but maybe we should warm up the defibrillators.)

A13 - Comments on "Sub-Path Maintenance Elements" (section 3.2): it 
seems to me that there are two strong limitations to the use of SPME, 
which may prove problematic (too limiting):
   * one is the fact that SPME seem to be only applicable to co-routed 
transport path ("[SPMEs], [...] are instantiated to provide monitoring 
of a portion of a set of co-routed transport paths [...). ") : with an 
external eye, it seems that having the possibility to do OAM on parts of 
a path is equally important for all other types of transport path (bidir 
assoc., unidir p2p, unidir p2mp)
   * another one is the fact that to do OAM on a portion of a transport 
path it is required to modify the dataplane an add another layer of MPLS 
encapsulation: at the very least, I would expect reasons to be given for 
excluding a solution that would allow OAM to be done on a portion of a 
transport path, as it would seem to me as offering more flexibility (the 
document *does* identify limitation or complexity due to the addition of 
a new layer to do OAM on a portion of a path)

A14 - It seems to me that there is sometimes a discrepancy between the 
high level of expectation on how fine-grained and precise the OAM will 
be and the obstacles that are identified and that will make these 
expectations hard to meet in some cases, not always with solutions being 
described.
Here are a few examples:
    * SPME and TTL addressing : section 3.2 (§6 item 2) indirectly tells 
us that the use of the uniform model for TTL handling (copying the TTL 
between layes) will break "TTL addressing" of the MIPs, but still claim 
that it should be possible for the operator to use the uniform model ; 
unless it is explained how the "MIP addressing" mechanism can be 
adjusted to cope with the uniform model for TTL handling, this seems 
totally contradictory
    * Multilink : the document acknowledges the fact that link 
aggregation has to be allowed, and at the same time that it will reduces 
the effectiveness or even defeat the purpose of the OAM defined here 
(sections 4.6, 5.5.3 and 6.2.3). One issue is that it seems to me that 
what stops working well when multilink is used is only partially 
documented (if I'm correct nothing is said on the fact that the OAM 
defined here will not meet the purpose of continuity checks done on an 
LSP end-to-end if multilink is used somewhere in the path ; same for 
delay measurements)
    * discrepancy between the aims of packet loss measurements and the 
identified obstacles to have very precise measurements (5.5.2, 5.5.3)
I'm not sure that this qualifies as a "Major issue", but I can't help 
express my skepticism.

*Minor Issues:*

B1 - Section 2.1, acronyms:
        * the "CC-V" acronym is not defined => this one is really a bit 
problematic because it seems to carry a lot of assumptions (see comment 
above)

B3 - Section 2.2 "Definitions":

        * "Source MEP" is defined as "A MEP acts as MEP source for an 
OAM message when it originates and inserts the message into the 
transport path for its associated MEG"  =>  it seems to me that this 
definition does not properly cover the case where an out-of-band path is 
used for OAM replies (OAM message is not sent "into the transport path")

       * as defined in 2.2, the terms source and sink MEPs are a bit 
confusing in the case of an OAM function instrumenting a particular 
direction of a transport path, and involving a packet sent by a MEP to 
another MEP and this other MEP replying, because the "source MEP" (being 
defined as the MEP which "originates" an OAM message) is not the same 
one in both cases, and has nothing to do with the source node of the 
transport path - this risk of confusion is made worse by the fact that 
sometimes "originating MEP" is used ; and that diagrams position "sink 
MEPs" on destination nodes ;  the text also uses sentence contradictory 
with this definition "x is [...] transmitted by a sink MEP [...] its 
source MEP [...]" (section 5.2 §1) ;  I wonder if the solution wouldn't 
be to rather define source and sink MEPs, not wrt to who sends OAM 
packets, but wrt. the direction of the transport path being monitored, 
the consistency between these terms must definitely be made better

B3 - on "ME" and "MEG"  definitions

    * Section 3.1 §1 : "a relationship between two points .... The two 
points that define a ME ... . In between the two points ..."
       => what are "points" ? what is exactly their relationship with 
LSRs ?
       => additionally, If I'm correct, "two points" should be replaced 
by "two points (or more in the P2MP case)" to properly cover the P2MP case

    * I found the central notions of "ME" and "MEG" worded in a way that 
does not make the concept very easy to grasp. I don't have practical 
suggestions to improve the text, but maybe the text could have a 
sentence clarifying the following: is a MEP a MEG end point or a ME end 
point ? (my understanding is that even though an MEP is a MEG end point, 
it also an endpoint for the MEs in the said MEP (or, in the P2MP case, 
for one of them).  The fact that MEP are described more in sub-section 
3.3, significantly further down the document, does not help : maybe this 
could also be improved.  Just as an example, reading a sentence like "a 
node at the edge of a MEG always supports a MEP" gives a strange feeling 
that the abstraction introduced are not self supporting.

    * Taking a step back, I wonder if MEPs shouldn't be introduced 
first, then the notion of ME introduced, and  then the notion of MEG ; 
if this is doable, but this for sure would help understand/explain the 
concepts

B4 - there is a significant document readability issue in that questions 
related to how MIP are "addressed" are discussed in the document before 
being introduced (3.2 §6 talks about "MIP addressing" and TTL handling, 
ditto in 3.2 §10, plus in 3.4  "a MIP... may be addressed..." ), and 
even when the corresponding mechanism is explained (section 3.4), the 
link with the "TTL addressing" nickname of the mechanism is not made.  I 
would suggest considering the following options:
   * move the section on MIPs (currently 3.4) before section 3.2
   * in this section, dedicate a sub-section on how OAM messages can 
target a specific MIP, and introduce the TTL addressing idea here
   * also add "TTL addressing" in Section 2.2  "Definitions"

B5 - section 3.2 "SPME and TC monitoring":

    * §2: Does the notion of SPME really excludes, as the text implies, 
the cases of associated bidir. and unidir. ?  If so, this looks to me as 
a possibly strong limitation.

    * §5: "The SPME is monitored using normal LSP monitoring." -> what 
you mean by "normal LSP monitoring" would deserve to be explicited

    * this section is particularly painful to read due to the use of a 
mix of multiple terms for same (or at least very similar notions) : 
Nested MEGs, SPME, and Tandem Connection Monitoring . I think that the 
relationship between these terms should first be explained, and that 
later on only one of these terms should be used.  Moreover, my feeling 
on the "Tandem Connection" is that, even if it may very well have 
historical reasons to exist (in the ITU-T I assume?), it nevertheless is 
really opaque, since a "Tandem Connection" hasn't much to do with a 
"tandem" (which as I understand is closer to one or more things put one 
*after* the other, not one *over* the other or *nested* one in the 
other); I would find this section hugely easier to read if the very 
clear term of "Nested MEG" was used (instead of Tandem Connection 
Monitoring and or SPME).

    * this section would also be easier to understand if it was reminded 
to the reader that what we are talking about is "a hierarchical LSP 
instantiated to monitor a portion of a transport path" ; I took me a 
significant time to infer this (honestly because I did not lookup the 
definition in the MPLS-TP framework) and you'll certainly spare your 
readers some effort if you add this precision, very useful by the way 
since you later talk about the effects of this hierarchy on MPLS-TP OAM

     * "PM statistics need to be adjusted for the encapsulation overhead 
of the additional SPME sub-layer." => the only thing defined as 
"performance monitoring" in this document is packet loss measurements, 
which is not impacted by encapsulation overhead ;  maybe this sentence 
should say "bandwidth estimation" instead (defined in this document as a 
diagnosis test) ?

B6 - section 3.3 §10: "An MPLS-TP MEP sink passes a fault indication to 
its client (sub-)layer network as a consequent action of fault 
detection." => is it always done, or is it optional ?  what if there is 
no OAM on the client side to carry any fault indication ?

B7 - section 3.3: "a per- interface MEP is called "Up MEP" or "Down MEP" 
depending on its location as upstream or downstream relative to the 
forwarding engine":  my initial interpretation of this sentence was 
based on the idea that "downstream" referred to the stream of OAM 
packets flowing from the source MEP to the sink MEP; with this in mind, 
the definition given here was not consistent with the one in 2.1, nor 
with the diagram in figure 3 . After some time, it finally occurred to 
me that the intent was possibly to use "downstream" and "upstream" to 
refer to the client to server direction (with the client over the 
server, ie client up, and server down)...  Assuming I'm correct and have 
guessed the intended meaning, I think that the text should be made more 
explicit on what downstream/upstream means here, or alternatively, avoid 
the use of this ambiguous term, and even look for better terms such as 
client-side MEP and network-side MEP ?

B8 - section 4: this section is quite painful to read due to and 
abundant use of multi-layered acronyms, an example being LSMEG, for "LSP 
SPME ME Group" which expands as (take a deep breath)... "Label Switching 
Protocol Sub-Path Maintenance Element Maintenance Entity Group".... (!!)
    => as a general comment, I think that when introducing acronyms, it 
is sane to think twice and check if on is making the doc easier to write 
and/or easier to read
    => here, the acronyms did not help me as a reader, and I would 
suggest considering removing the acronyms defined at the start of 
section 4 from the document and using the expanded forms instead: "LSP 
ME" or "PW SPME ME" for instance, are not long to write, and are easier 
to interpret than "LME"
or "PSME"
    => I note that these acronyms are not even used in the document : 
more specifically only the variants without the "Group" at the end are 
used... at the very least the text should be revised to remove the 
"Groups" and "G"s from the list at the start of section 4

B9 - section 5.1 §4  "When MPLS-TP is deployed in transport network 
environments where IP addressing is not used in the forwarding plane, 
the ICC-based format for MEP identification is used"  => no reason is 
given  why IP addressing would be excluded in cases where IP is 
available in the control or management plane (even if IP is not used in 
the forwarding plane) : why not allow this ?

B10 - section 5.1.2 §5 and §6: "the MEP [...] declares a signal fail 
condition at the transport path level"  => for a MEP part of an MEG 
monitoring a PW, I would have expected the signal fail condition to be 
declared at the PW level

B11 - section 5.1.3 talks about "Performance Monitoring", but is a 
sub-section of section 5.1 on CCCV : (a) this seems awkward in terms of 
document structure, and (b) it seems to possibly conflict with section 
5.5 that implies that specific packets are used for loss measurements 
(not "CC-V" packets)

B12 - section 5.1.3: Protection Switching item says "default 
transmission period is  3.33ms [...], in order to achieve sub-50ms the 
CC-V defect entry criteria  should resolve in less than 10msec, and 
complete a protection switch within a subsequent period of 50 msec."
     => if the "sub-50ms" window includes the defect detection time, 
then there are only 40ms left to complete protection switching (not 50); 
alternatively, if it does not, then the requirement to detect the defect 
in less than 10ms due not result from the sub-50ms requirement => the 
said paragraph need I think to be corrected in some ways
     => moreover, if I'm correct, the entry criteria defined in 5.1.1.1 
does not meet the "detect in less than 10ms" criteria (3.33ms*3.5 = 
11.655ms) ; for sure, 1.655ms is not much, but it is surprising to see 
at the same time a very high level of precision in the proposed 
parameters (3.5 factor, 3.33ms, 10ms detection time) and an arithmetic 
inconsistency when these parameters are combined: maybe a good idea 
would be to let more freedom to protocol implementers in the values they 
can use for transmission period, and in the target values for detection 
times ?

B13 - section 5.2: why exclude unidirectional transport paths from 
benefiting of RDI ?  (if the restriction is needed then explain why, 
else remove the restriction ?)

B14 - section 5.2.1: "the RDI transmission rate and PHB of the OAM 
packets carrying RDI should be the same as that configured for CC-V" ; 
since the rate of CC-V message depends on the application (section 
5.1.3), how should this sentence be interpreted ?  beyond this, why 
mandate the exact same rate for both ?

B15 - section 5.3:

    * §4 talks about "loss of continuity alarms": I can't be sure what 
alarms mean here, does refer to an OAM message (RDI ?) or to "something" 
sent to the NMS (assuming there is one) ??  => I can't determine whether 
or not a sink MEP sends RDI to the source MEP if it receives AIS for a MEG

    * the whole section does not say clearly which entities may send 
AIS: I would assume all MEPs *and* all MIPs , but it may be nice to make 
it explicit

B16 - section 5.3: "generate packets with AIS information" => should 
this be understood as "AIS OAM messages" or "OAM packets with AIS 
information elements", or more generally as "OAM messages with AIM 
information"?  (see general comment on how this document specifies the 
content of OAM messages)

B17 - section 5.5 (on packet loss measurements) :

   * section 5.5: the text could be more explicit and say more about 
which packets are sent by the source MEP with which information and what 
is sent back by sink MEPs and with which information ?

   * section 5.5 §2: *when* exactly are packets sent *and* received by 
the peer MEP ? the text implies that this would only not be done for 
unidir ; but it seems to my fresh eyes, that using a return path could 
be considered ; either way, could this point be explicited ?

   * section 5.5 §2 says "The LM  transactions are issued such that the 
OAM packets will experience the same queuing discipline as the measured 
traffic [...]" while 5.5.1 says "LM OAM  packets should be transmitted 
with the PHB that yields the lowest discard probability within the 
measured PHB Scheduling Class (see RFC 3260 [16])."
      => it looks to me possibly contradictory to impose that real data 
and OAM LM packets have the same queueing discipline but possibly a 
distinct drop precedence ; maybe this could be rephrase with less risk 
of confusion by using terms such as "drop precedence" and "scheduling class"
      => see also comment A11
      => in any case, having a distinct drop preference for OAM packets 
looks to me as possibly defeating the purpose in some situations: 
indeed, it seems that the measurement error coming from the difference 
of treatment between OAM packets and real data could deserve the same 
worries that the error coming from sampling skew ; why not, for 
instance, allow the operator to selectively use a TC with the highest 
discard probability to estimate the worst case of packet loss ?

   * section 5.5.3 provides possible causes of inaccurate LM ; I think 
additional ones are worth mentioning:
       - the fact that each link in the bundle of links may 
intrinsically have a different packet loss (e.g. one fiber is clean, the 
other is not)
       - the fact that a different hardware queues can be used for each 
link in the bundle of links, possibly with a different packet loss 
behavior when the measure is done (one is full, the other is not)
       => my feeling is that this is not so much a question of 
identifying the possible causes of inaccuracies, than a problem of 
defining what packet loss is being measured, but at the very least, I 
would expect to cover all of the most easily identified ones ; 
alternatively one may consider suggesting that the LM measurement 
technique should be designed so that all possible hardware path for a 
said LSP are tested... ?

B18 - section 6.1: §1 says "network management may invoke periodic 
on-demand bursts of on-demand CV packets, as required in section 2.2.3 
of RFC 5860", but I can't find anything on bursts on RFC5860

B19 - section 6.2: a general comment on this section and its 
sub-sections is that is seems largely redundant with section 5.1 (also 
on CV but the pro-active side), readability would be highly improved if 
this section was highlighting the differences with section 5.1 (such a s 
"mechanisms are the same as section 5.1 with the following exceptions: 
...") and avoid repeating common text as much as possible

B20 - section 6.2.2: AFAICT, the content of this section is identical to 
5.5.2, and could be replaced with a pointer to that section

B21 - section 6.3.2 §4: The fact that it is not possible to send an OAM 
message addressed to the MIP/MEP to unloop the data plane is rather 
surprising. Does this means that a special processing must be applied to 
this message ?

B22 - In many places, it seems that the text has been written with only 
the P2P case in mind, and that - at least the wording - does not take 
into account the case of P2MP...
   - section 6.4 : "to the sink MEP" =>
   - section 5.1 §1 : "between two MEPs" => ditto
   - section 5.1 §3 : "processed by the sink MEP" => ditto
   - section 5.1 §8 : "only the sink MEP" => ditto
   - section 5.1 §13 : "parsed by the sink MEP" => ditto

*Nits:
*
( Nits are editorial or layout items. They are things that would ideally 
be resolved before publication to make the document more readable, and 
may be raised now to save the RFC Editor work. Usually a reviewer will 
not be looking for this type of issue, but may find some in the course 
of their review. )

* Section 2 "terminology and definitions":
    * it would I think be easier to put the section with definitions 
*before* the section giving their acronyms
    * I think that readability would be enhanced if both section 2.1 and 
section 2.2 were each split into two sub-sections, one for things 
already defined in other documents, and another one for things 
introduced by this document itself

* 2.1: the following acronyms are used in the text but not defined: ICC, 
E-LSP, TPE, SPE, EMS, NMS, CC, CV

* 2.2:
   - "Signal Degrade" is defined but not used in the rest of the document
   - "MEP Source" is defined, but in many places in the document "Source 
MEP" is used, I guess the two should be made consistent
   - ditto for "MEP Sink"

* 3.1 §4 "This functional model defines...": this paragraph sounds like 
an ME has the responsibility to monitor and manage a network, ie. that 
an ME is the human operator or an OSS entity of some kind, the text 
should probably be rewritten in a better way

* ditto for 3.3§2 "MEPs are responsible for activating and controlling 
... " : this gives the impression that MEPs are an active entity doing 
actions, while my understanding was that they were points, ie something 
close to a location were something is done

* 3.1 §5 uses the term "originating MEP" : if this is the same a "source 
MEP", then "source MEP" should be used (and if not the difference should 
be explained)

* 3.2 §6 "The SPME would use the uniform model of TC code point  copying 
between" => unfortunate TLA collision between "(T)andem (C)onnection" 
and "(T)raffic (C)lass", even more unfortunate that a lot of people may 
still be more familiar with the old "Exp" name ; I would suggest 
expanding "TC" into "Traffic Class" in this sentence (and a reference 
added to RFC5513 section 4.2 !)

* 3.2 §6 "short pipe for TTL handling": readability possibly improved by 
reminding the reader what the short-pipe model is (no TTL copying)

* 3.2 §8 "As any MIP ... is ... , hence ... " => remove "any" or "hence" ?

* 3.3 §1: "while in the context of an SPME LSRs for the MPLS-TP LSP can 
be ..."
        => missing a comma between "SPME" and "LSRs"
        => this paragraph is not easy to read, and would deserve beind 
rewrittent more clearly

* section 3.3 §15: "It may occur that the Up MEPs of an SPME are set on 
both sides  of the forwarding engine such that the MEG is entirely 
internal to the node." => would be easier to read this way: "It may 
occur that the source and sinks MEPs are on the same node, and are both 
Up MEPs, each on one side of the forwarding engine, such that the MEG is 
entirely internal to the node." ...?

* 3.8:
    - "objectives" => I would suggest saying "requirements" instead of 
"objective"
    - "in transport network" => "in _a_ transport network", or use plural
    - "The monitored or managed transport path condition has to be 
exactly the same irrespective of any configurations necessary for 
maintenance" => if the intent is to include changes of the transport 
path that happens due to local repair or end to end restoration, then 
"any configurations necessary for maintenance" is not very nice, as 
dataplane changes resulting from control plane procedure are not often 
called "configuration" nor "maintenance"

* section 4: "The MEGs specified in this MPLS-TP framework are compliant 
with  the architecture framework for MPLS-TP MS-PWs [4] and LSPs [1]"
    -> I believe the text should say "with the architecture framework 
for MPLS-TP[8], MS-PWs [4] and LSPs [1]"   (add "[8], ")

  * figure 5:
     - is very difficult to understand and its readability would deserve 
being improved in order to ease reading the following paragraphs.
     - adding "LSR" labels in the boxes in the diagram (and making the 
boxes bigger) would be nice
     - putting boxes for LSRs 2 and Y at the same size of the other LSRs 
would be better
     - avoiding the "LSP" label on the boxes for LSR 2 and Y would also help
     - the legend ("   ^---^ ME   ^     MEP  ====   LSP      .... PW") 
would be more readable with each item on a separate line

* 3.2 §9,  4.1 §1 and 5.1§7: "share fate" would sound better than "fate 
share" which is not correct english

* figure 5: "Figure 5 depicts a high-level reference model for the 
MPLS-TP  OAM framework.": I find the use of the "model" term rather 
surprising since what I see looks to me more as an "example", as an 
"illustration", used in the rest of the section to more easily 
illustrate the concepts defined, rather than an high-level abstract 
model (which I expect would not be specific, why not just say "example" 
instead of "model"  ?

* 4.3, figure 6: it seems that this figure could be removed and replaced 
by a reference to figure 5

* 4.4 §1: "with associated maintenance entity" => add "an" after "with"
* 4.5 §1: ditto

* 4.4 §4: "end node" and "intermediate node" could be replaced by the 
wellknowns LER and LSR terms, but in fact it seems that the whole 
paragraph be replaced by a  straightforward shorter sentence: "A LSME 
can be defined between any node (LER or LSR) of a given LSP"

* 4.5 §1: "An MPLS-TP MS-PW SPME Monitoring ME (PSME) is [...] intended 
to monitor an  arbitrary part of an MS-PW between the pair of MEPs 
instantiated  form the SPME independently from the end-to-end monitoring 
(PME)."
    => I cannot parse the sentence correctly as-is, but I can if I 
change it into "instantiated _from_ the SPME independently _of_ the 
end-to-end monitoring (PME)."

* 4.5, figure 8: it seems that this figure could be removed and replaced 
by a reference to figure 5

* section 5, list item 4: "[...] loss  measurement indication of 
excessive impairment of information  transfer capability" => is this 
different than a "packet loss indication" ? if yes, then it would be 
nice to explain more, and if no, then maybe a simpler expression would 
be nicer ?

* section 5.1.2 §2: the text says "If a MEP detects an unexpected 
globally unique Source MEP  ..." but this event is defined in 5.1.1.2 as 
a "mis-connectivity defect" ; hence the text in 5.1.2 would I think be 
better rewritten as "If a MEP detects a mis-connectivity defect"

* section 5.1.3: milliseconds should be abbreviated as "ms" not as 
"msec" (current text has a mix of the two)

* section 5.3 §2: "generates packets with AIS information in the 
downstream direction": to avoid misunderstanding on what "downstream" 
means here (see my comment on Up/Down MEPs), it may be clearer to say 
"toward the sink MEP(s)" rather than "in the downstream direction"

* section 5.6 § 3 and 6.5 §3: "synchronized precision time" => replace 
by "precise time synchronisation" ? ("synchronized precision time" seems 
rarely used, instead possibly in the specific GPS context)

* section 6, last paragraph: "exclusive" => replace by "exclusively" ?
* section 6.1, last paragraph: "target" => replace by "targeted"

* section 6.1§3 : uses the term "originating MEP" : if this is the same 
a "source MEP", then "source MEP" should be used (and if not the 
difference should be explained)

* section 6.3.1 "graphing the percentage of OAM test packets received" 
=> "computing" would be more appropriate than "graphing"

* References: G.806 is given as a "Normative" reference, but it appears 
to me that it is only referred to to complement the Signal Fail and 
Signal Degrade definitions in section 2.1 ; for this reason, a 
possibility would be to move this reference to the "Informative 
references" section.

* in 5 places, the term "segment or concatenated segment" is used, it 
would be great to replace this phrase by "path segment", which is 
usefully precisely introduced by this document as meaning "segment or 
concatenated segment"  ; you could also consider avoiding "concatenated 
segment" in all the other places, and use the "path segment" term instead