reply liaison #029.02 - trac.tools.ietf.org€¦ · Web viewResolution color convention: Green...

IETF LC Comments on MPLS-TP OAM Framework (v09)

Resolution color convention:Green – resolution agreed among editors;Grey – resolution agreed among editors, detailed text changes to be done/agreed;Cyan – resolution to be confirmed/discussed with the comments author;Yellow – action point pending to solve the comment.

# Comment proposal Resolution1. Alexander Vainshtein – 15 November 2010

Discussion about what does it mean disabling a MIP

No proposed text A disabled MIP should drop all the OAM packets addressed to it. Text added to section 3.4.

2. Alexander Vainshtein – 15 November 2010

Are MIPs bound to specific Managed Entities (LSPs)?

No proposed text We think section 3.4 clarifies that a MIP is part of a MEG hence bound to the MEG.

Text added to section 3.4. to clarify that the identity of the MIP is not necessarily unique to the MEG. E.g. all nodal MIPs in a node COULD have a common identitiy.


Discussion about the term “per-interface MIP”

Use "in-MIP" and "out-MIP" instead

We think that “in-MIP” and “out-MIP” terminology is also confusing. With co-routed bidirectional LSPs, the in-MIP in one direction coincides with the out-MIP in the reverse direction.

A definition of the term "interface" to clarify that it is a logical rather than physical entity has been added in section 1.2.

4. Thomas Morin – 20 November 2010

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...).

No proposed text The scope of this document is not to provide an overview of/pointer to the OAM solution documents.

The intention of this document is to provide the framework and a protocol-neutral description of the OAM functions.

The relationship with existing MPLS and MPLS-TP OAM documents is clarified by the statement:In line with [14], existing MPLS OAM mechanisms will be used wherever possible and extensions or new OAM mechanisms will be defined only where existing mechanisms are not sufficient to meet the requirements. Extensions do not deprecate support for existing MPLS OAM capabilities.

Text added in section 1 to clarify the scope of the document to provide a protocol neutral description of the required functions and dataplane OAM architecture.

Text on OAM packet fate sharing and identification moved from section 3.2 to section 1.

A further clarification offered on E-LSPs and L-LSP w.r.t fate sharing


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.

No proposed text Text changed to clarify the point


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.

No proposed text Introduction rephrased to clarify the scope of the document.Text added to clarify that extensions discussed in this framework may end up as aspirational capabilities and may be determined to be not tractably realizable in some implementations.


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

No proposed text Text added to section 1:

This framework makes certain assumptions as to the utility and frequency of different classes of measurement that naturally suggest different functions are

(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

implemented as distinct OAM flows or messages. This is dictated by the combination of the class of problem being detected and the need for timeliness of network response to the problem. For example fault detection is expected to operate on an entirely different time base than performance monitoring which is also expected to operate on an entirely different time base than in band management transactions.

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.

No proposed text This comment is related to comment 3.

The interfaces and forwarding engine represent a functional representation of the LSR behavior not its physical implementation.

Text added to section 3.3:

Conceptually these “per interface MIP locations” can be mapped to the MPLS architecture by associating the MIP points with ILM/NHLFE processing, such that the MIP positioning within a node bookends the NHLFE processing step of how a packet is handled by an LSR/LER (either prior to or post label processing and packet forwarding). A nodal MIP makes no representation as to where in a nodes packet handling process a MIP is located.


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]

No proposed text If the source MEP is always used then there is no CC but only CC+CV.

MPLS WG consensus is to support both CC and CC+CV modes.

The CC-V rate should be the one configured by the operator. However, the OAM messages should "self-dentify" their periodicity to allow establishing exit criteria for a misbranching defect.

We think that no text changes are required.


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

No proposed text Text added to section 3.7.

The definition of what a "bud node" has been added based on the comment.

OAM packets. if I'm correct, then it probably needs to be fixed in some kind of way.


A8 - Issues related to point-to-multipoint:* 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)

No proposed text The last paragraph of section 3.7 has been updated to resolve this issue.


A8 - Issues related to point-to-multipoint:* 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)

No proposed text Actually the current text is applicable only to co-routed bidirectional p2p.Text has been rephrased to cover unidir (p2p and p2mp cases) as well associated bidir p2p.


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

No proposed text The case of TTL-expiry at a node that was not intended for, needs to be covered.

Also the TTL expiry at a node not supporting MPLS-TP OAM is expected to be silently discarded (no IP header to process…).

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?).

Text added to cover the case where an OAM packet is sent to whichever MIPs exist at a given TTL distance.

Text added in section 3.4


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 ?

No proposed text A health warning has been added to section 6.3.1.


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:* 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

No proposed text A health warning has been added to section 6.3.1.

measure is made, but the bandwidth available may not be constant over time


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 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

No proposed text Two way is not applicable to p2mp nor to unidirectional transport paths in general.

Text has been added to section 6.3.1 to clarify this.


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:* 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

No proposed text According to RFC 2544, the processing requirements for OAM test packets are the same as for non-OAM test packets.



A11 - QoS of OAM packets : in multiple sections,

No proposed text Clarifications added through the whole document about applicability to E-LSP and L-LSP cases.

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

No proposed text On the basis of Thomas and Vincent comments the security section has been rewritten.

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)

No proposed text Text in section 3.2 has been rephrased to better clarify.


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): * 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

No proposed text The usage of SPME for monitoring a portion of a transport path is already described in RFC 5960. This document further expands this concept within the context of OAM and identifies potential issues (see section 3.8).The solution of these issues is outside the scope of this document.

We think that no text changes are

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)

required.


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

No proposed text The text states that uniform model requires an out of band return path as the path cannot be within a MEG.

The MPLS WG consensus has been not to preclude the usage of the uniform model for TTL handling nor multi-link techniques and to document what are the implications when this is done.

As for the broader implications of the comment, the framework identifies the issues with achieving the goals by pointing out potential pitfalls.


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.


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)

No proposed text CC and CC-V acronyms added to section 2.1


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

No proposed text We understand B3 should be B2.

We have clarified the differences between source/sink MEP and originating/target MEP and used these terms consistently through the document.

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

No proposed text but a high-level suggestion provided

An ME is never more that two points even in the p2mp case, and the two points are always end points. In case of p2mp transport paths, we have more than one ME.

Text in section 3.1 rephrased based on this suggestion

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"

No proposed text Text changed to avoid the term "TTL addressing" in favor of well-known concept like "TTL distance to the MIP" or "TTL expiry".


B5 - section 3.2 "SPME and TC monitoring":

No proposed text See comment 20

* §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

No proposed text The text has been removed.



* 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).

No proposed text The notions are somewhat different.

TCM is a special case of SPME: we just describe this simple fact in section 3.2 and then use the term SPME only in the rest of the document: the term TCM is an ITU-T term and the intention here is to make clear that the TCM requirement, as defined by ITU-T, has been addressed.

The term nested MEG is used when the nesting relationship is valid for all the MEGs regardless of whether they are LSPs, SPMEs or MS-PWs.

Text has been added to section 3.2 to clarify that TCM is an ITU-T term and that the properties of nested MEG are applicable to all MEGs

(LSPs, SPMEs and MS-PWs). 30. Thomas Morin – 20 November 2010


* 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

No proposed text Text added in section 3.2



* "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) ?

No proposed text The sentence about adjustment for encap has been removed.


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

No proposed text Given layer independency, this is always done. This indication is ignored by the client if there is no OAM support. However, the behavior of a non MPLS-TP client layer is outside the scope of the document.

indication ?Text added to section 3.3 to clarify this.


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 ?

No proposed text Text has been changed to avoid the confusion (reusing the text in the definition section)


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

No proposed text We condensed acronyms to make the read less silly.


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 ?

No proposed text The text is related to transport network environments where IP addressing is not used in the forwarding plane.

Text rephrased as “When an alternative to IP addressing is desired (e.g., MPLS-TP is deployed in transport network environments where IP addressing is not used in the forwarding plane), …”.


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

No proposed text c/at the transport path level/of the ME/


B11 - section 5.1.3 talks about "Performance

No proposed text The table is recommending rates depending on the application, not the application itself.

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 ?

No proposed text Text in section 5.1.3 changed to fix the problem

39. Thomas Morin – 20 November 2010 No proposed text Text in section 5.2 updated to

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 ?)

resolve the issue


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 ?

No proposed text Text in section 5.2.1 updated to clarify the issue.


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

No proposed text Text in section 5.3 updated to clarify the loss of continuity alarm.

The second paragraph of section 5.3 clarifies that the AIS packets are generated by the MPLS-TP client/server adaptation function co-located with the sever MEP that detects a signal fail at the server (sub-)layer.


B16 - section 5.3: "generate packets with AIS information" => should this be understood as "AIS OAM messages" or "OAM packets with AIS

No proposed text Text changed in section 5.3 to address the comment

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 ?

No proposed text Text added to section 5.5.



* 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 ?

No proposed text A note has been added to clarify that one-way LM is applicable to both unidir and bidir transport paths while two-way LM is applicable only to bidir transport paths (similar note in section 5.6 about DM)



* 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

No proposed text Text changed to use the terms "scheduling class" and "drop precedence" within the whole document.

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

No proposed text Encountering a bundle means the aggregate loss will be summed by the measurement transaction. The only real sources of inaccurancy is misordering.


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

No proposed text Text rephrased to separate the reference to the requirement for on-demand CV from the description of a possible use of on-demand CV.


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

No proposed text The section was intended to be read in isolation.



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

No proposed text Done


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 ?

No proposed text Text rephrased to improve clarity.


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

No proposed text Text changed accordingly (based on the proper context)


Nits:

* Section 2 "terminology and definitions": * it would I think be easier to put the section with definitions *before* the section giving their acronyms

We followed the structure used in other RFCs (e..g, RFC 5654 or RFC 5921).



Nits:

* Section 2 "terminology and definitions": * 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

No proposed text We followed the structure used in other RFCs (e..g, RFC 5654 or RFC 5921).



Nits:

No proposed text Almost all the acronyms have been added: EMS removed from the text

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


Nits:

* 2.2: - "Signal Degrade" is defined but not used in the rest of the document

No proposed text The definition was added to address an ITU-T comment.

We can add few words on pro-active LM/DM about determination of signal degrade or remove the definition from section 2.2.

Given on-going discussions on SD-triggered protection switching I am more in favor of removing the definition.

Action (Italo) – Start a discussion on both ITU-T/IETF mailing lists proposing to remove the definition.


Nits:

* 2.2: - "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"

No proposed text Global changes:

c/MEP Source/Source MEP/c/MEP Sink/Sink MEP/


Nits:

No proposed text The text has been rephrased to improve clarity.

* 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


Nits:

* ditto for 3.3§2 "MEPs are responsible for activat-ing 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

No proposed text c/activating and controlling/originating/


Nits:

* 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 ex-plained)

No proposed text Related to comment 24.

The term "originating MEP" is correct.


Nits:

* 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 !)

TC expanded in section 3.2.

61. Thomas Morin – 20 November 2010 * 3.2 §6 "short pipe for TTL Done

Nits:handling": readability possibly improved by reminding the reader what the short-pipe model is (no TTL copying)


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

Done


Nits:

* 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

No proposed text Paragraph rephrased


Nits:

* 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." ...?

Done with some rephrasing


Nits:

* 3.8: - "objectives" => I would suggest saying "requirements" instead of "objective" - "in transport network" => "in _a_

First bullet: objectives was used instead of requirements because requirements are outside the scope of this document

transport network", or use plural Second bullet: change into "in a transport network"


Nits:

* 3.8: - "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"

No proposed text Network objective rephrased


Nits:

* 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], ")

Reference to [8] added but text rephrased in a slightly different way.


Nits:

* 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

No proposed text Figure improved (taking into account also Dave Black nits).

Changed, for consistency, Figures 6, 7 and 8 (pending resolutions of comments 71 and 75).

Action – Review this comment after resolution of comments

(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

71 and 75.


Nits:

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

The term "fate share" is the accepted industry term.

We think that no text changes are required.70. Thomas Morin – 20 November 2010

Nits:

* 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" ?

No proposed text Reference model is a well-know term.



Nits:

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

Change done but marked with yellow.

Not sure what to do. Dave Black is proposing the opposite and to add another figure to section 4.2.

Action (Dave) – Trigger a discussion between Thomas

and Dave Black72. Thomas Morin – 20 November 2010

Nits:

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

Done


Nits:

* 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"

Done


Nits:

* 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)."

c/ instantiated form the SPME independently from the end-to-end/ instantiated for the SPME independently of the end-to-end/


Nits:

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

Change done but marked with yellow.

Not sure what to do. Dave Black is proposing the opposite and to add another figure to section 4.2.

Action (Dave) – Trigger a discussion between Thomas and Dave Black


Nits:

* 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 ?

No proposed text It is different because it is notified when the packet loss exceeds a specific threshold.

The text has been rephrased to simplify.


Nits:

* 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"

Done


Nits:

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

Done


Nits:

* 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"

There are two sink MEPs: one upstream and one downstream.



Nits:

* section 5.6 § 3 and 6.5 §3: "synchronized precision time" => replace by "precise time synchronisation" ? ("synchronized precision time" seems rarely used,

Done

instead possibly in the specific GPS context)


Nits:

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

Done


Nits:

* 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)

No proposed text Related to comment 24.

The term "originating MEP" is correct.


Nits:

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

Done


Nits:

* 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.

We think that the source of a definition should be a normative document.


Nits:

* 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

Done

also consider avoiding "concatenated segment" in all the other places, and use the "path segment" term instead

86. David Black – 23 November 2010

[A] There's no summary list of requirements (e.g., checklist) that an OAM solution needs to fulfill in order to be compatible with the framework. Should there be one? I'm not clear on the intended audience for this draft, so "no" with an explanation is an acceptable answer.

No proposed text Requirements are in the requirements document that is normatively referenced.



[B] Unfortunately the draft has a couple of significant acronym problems that start in Section 2.1:

(B-1) SME Section Maintenance Entity Group

If a group was intended, SMEG should be used instead of SME, especially as the following occurs in Section 4:

o A Section Maintenance Entity Group (SME), allowing monitoring and management of MPLS-TP Sections (between MPLS LSRs).

o An LSP Maintenance Entity Group (LME), allowing monitoring and management of an end-to-end LSP (between LERs).

o A PW Maintenance Entity Group (PME),

It looks like the following needs to be done:

- Define both SME and SMEG in Section 2.1

- Suffix a "G" to the SME, LME and SME acronyms in Section 4

- Scan for all other uses of Group and check that the correct

acronym that ends in a G is used.

Edited to change LME to LMEG etc.

allowing monitoring and management of an end-to-end SS/MS-PWs (between T-PEs).

The acronyms in the second two bullets are wrong wrt Section 2.1 - they're defined in Section 2.1 as LMEG and PMEG, which suggests that the G suffix should be used uniformly. In addition, SME is referred to in Section 4.1:

An MPLS-TP Section ME (SME) is an MPLS-TP maintenance entity


(B-2) SPME Sub-path Maintenance Element

It's unclear from the draft whether the E should stands for Element or Entity. While the expansion in Section 2.1 uses Element, Section 2.2 says:

This document uses the term Sub Path Maintenance Entity (SPME) as defined in RFC 5921 [8].

Which is really peculiar because RFC 5921's acronym section says:

SPME Sub-Path Maintenance Element

Nonetheless, the word "Entity" is a better fit to this draft, so I would suggest adding text to equate the use of "Entity" in SPME with RFC 5921's use of "Element", and using "Entity" throughout this draft. That has a beneficial side-effect of simplifying many of the nested acronym expansions, for example:

PSME PW SPME ME

becomes

PSME PW SPME

because both instances of ME become "Management Entity", making one of them redundant.

Text changed to keep alignment with RFC 5921: SMPE is Sub-Path Maintenance Element

89. David Black – 23 November 2010 No proposed text Paragraph rephrased

[C] Section 5.1.3 says:

For statically provisioned transport paths the above parameters are statically configured; for dynamically established transport paths the configuration information are signaled via the control plane.

This appears to assume that addition or removal of destinations on the mp side of any p2mp path while the path is in operation is always entirely statically configured or always entirely dynamically configured for. I'm not clear on what the situation is here, so there are at least 3 possibilities, the correct one of which ought to be added near the end of Section 3.1:

- This is not possible: dynamic destination addition/removal for an

operating p2mp path is not permitted, independent of whether

the p2mp path was dynamically or statically configured.

- The assumption is correct. If the p2mp path is dynamically

configured, destination add/drop is dynamically configured;

if the p2mp path is statically configured, destination

add/drop is statically configured.- The assumption is incorrect. Each destination

add/drop can bedynamically or statically configured

independent of howthe p2mp path was configured.


[D] The security considerations section should include specific mention of injection of LKI request OAM packets as a vector for a denial-of-service attack (this is an obvious way for a man-in-the-middle to quickly cause serious havoc). That would be a good specific example to add to the end of the current security considerations paragraph that requires the network to be physically secure against man-in-the-middle attacks.

No proposed text Done


Nits

Proposed text in the mail Done with the exceptions of the comments conflicting with comments 68, 71 and 75.


Discussion about SPME (section 3.8)

Proposed new text for section 3.8 sent to the mailing list

Text in section 3.8 rephrased based on mailing list discussion.

93. Vincent Security section has been rewritten taking the comment into account

reply liaison #029.02 - trac.tools.ietf.org€¦ · Web viewResolution color convention: Green...

Documents

Transcript of reply liaison #029.02 - trac.tools.ietf.org€¦ · Web viewResolution color convention: Green...