[RTG-DIR] RTG-DIR Review: draft-ietf-opsawg-oam-overview-08.txt

[Alexander Vainshtein <[e-mail]>]

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-opsawg-oam-overview-08.txt

Reviewer: Alexander ("Sasha") Vainshtein

Review date: 23-Jan-13

IETF LC End Date: Not known

Intended status: Informational



Summary:



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



To some extent these concerns reflect my personal and potentially biased position with regard to OAM.



In addition, I'd like note that this is my second review of this draft. The previous one has been done in August 2011 and dealt with the -05 version of the draft (the review is attached). Following this review I've hold a series of email exchanges and off-line meetings with some of the authors in an attempt to resolve the issues I've raised; but this process has not ever been completed.



My current review hence is mainly focused on resolution (or lack thereof) of the concerns I've raised in the previous review round. This can be also considered as a bias (of a kind). Hence I ask - again - the Routing ADs to take my comments with a grain of salt.



Comments:



The needs of the assumed target audience are not fully addressed in the draft:



Just as in the previous reviewing cycle, I assume that the intended target audience of the draft consists of various "beginner" groups.

The current version does not contain any indications that this assumption is wrong (actually I did not find anything special about target audience in the draft). Taking into account ongoing OAM-related activities at the IETF (e.g., draft-mmm-bfd-on-lags), a good overview document would be indeed most useful for these groups.



Based on this assumption I've then suggested that in order to provide appropriate guidance to the target audience, the draft should:



1.       Include a section on historical background of OAM - not addressed in the reviewed version of the draft.

a.       The single sentence "OAM was originally used in the world of telephony, and has been adopted in packet based networks" that has served as a somewhat short background section has disappeared in this version of the draft

b.      IMHO and FWIW absence of such a section makes it difficult for, say, a reader with the background in OAM in SONET/SDH and/or OTN networks to understand why OAM in packet networks is so different.

2.       Present a clear view of OAM functionality and its relationship to various "planes" of networking - at best, partially addressed in Section 1.2. However, the new text seems potentially misleading to me, e.g.:

a.       The statement "often the on-demand tools may be activated by the management" seems to suggest that on-demand OAM tools can be also activated in some other way. If the intention has been activation of such tools via the control plane, clarification would be very much in place

b.      Connectivity Verification (CV) is mentioned as one of the "OAM building blocks" (in Section 1.1), and the draft explains that CV is used to verify that it is used "to verify that the OAM messages are received through the expected path". However, the draft does not explain that the expected path is defined either by the management or by the control plane, so that the entire CV function does not make much sense without this interaction.

3.       Explain the importance of fate-sharing of OAM and user traffic flows in packet networks - at best, partially addressed by the current version of the draft:

a.       The term "fate-sharing" does not appear in the draft at all

b.      The draft mentions that in MPLS-TP "OAM packets and the user traffic are required to be congruent" (Section 3.4.1). However, this is not extended to OAM tools for other IETF-owned technologies (IP, IP/MPLS).

A side note: I am not sure that "congruent flows" and "fate-sharing flows" mean exactly the same thing. E.g., in IP/MPLS networks LSPs created by LDP are supposed to be congruent with IP flows, but they are not fate-sharing.

4.       Explicitly map the notions, terms and methods that have been adopted from technologies owned by other SDOs (ITU-T and IEEE 802) to IETF-owned technologies - not addressed. E.g.:

a.       The term "interface" that is, from my point of view one of the basic notions in the IETF networking, appears in the draft just 3 times:

                                                  i.      Two of the search hits are in the title of RFC 5837 (which is listed in the draft as one of the OAM tools without any explanation and then again as a normative reference)

                                                ii.      The remaining hit is in Section  2.2.3 in the context of differences in MEP definitions between ITU-T Y.1731 and IEEE 802.1ag and deals with bridge interfaces, i.e., out of scope



A side note: At the same time the draft mentioned the importance of placement of an MP (ingress, egress or forwarding function) in Section 2.2.3. I will present my concerns regarding this text later.



b.      The draft mentions ICMP ping and Traceroute as an "OAM tools", but it does not even try to explain:

                                                  i.      What constitutes the ME in which these tools operate

                                                ii.      What are its MEPs and MIPs etc. (see also some comments below)

c.       The draft effectively ignores recent OAM-related activities as RFC 5837 (see above) and draft-ietf-mpls-tp-mep-mip-map. IMHO and FWIW, these documents are triggered by real-life operational concerns on one hand and implicitly  (as in RFC 5837) or even explicitly deal with relationships between interfaces and nodes on one hand and MPs on the other hand. The caveat about dealing just with published RFCs may or may not be valid per se, but it definitely does not justify lack of any explanations/details regarding RFC 5387.

5.       Expose, rather than avoid, known points of contention in a neutral way - I do not see this as a serious issue now.



The bottom line is that the current version of the draft did not meet my expectations in this regard. This -again - may be because my expectations have been exaggerated or even completely unrealistic, or because the authors had in mind a different target audience and a different purpose. (I've said in my first review that explicitly specifying these (the purpose and the target audience) in the Introduction section would be helpful - but this has not been done either.)


Readability of the draft:

>From my point of view the draft still is not easily readable. I'd like to pint specifically to the following:
not in the least because it contains quite a few inaccurate and/or controversial statements. E.g.:

1.       Some terms and notions are introduced in the draft as if they were quite important, only to be forgotten later. E.g.:

a.       Section 1.1 mentions "Throughput measurement" as one of the 3 main functions of the performance monitoring which, in its turn, is defined as one of the OAM building blocks. However, throughput measurement is not mentioned anywhere else in the draft.

b.      "Communication link" mentioned in Section 2.2.2 is another such example

c.       The first statement in Section 1.1 states that "An OAM protocol is run in the context of a Maintenance Domain,   consisting of two or more nodes that run the OAM protocol, referred to as Maintenance Points (MP)", but, again, Maintenance Domain is not mentioned anywhere else in the draft, leaving the reader to wonder how it is related to MEs, MEGs and the rest of the acronym soup.

2.       Some referenced IETF documents are misrepresented. E.g.,:

a.       MPLS LSP Ping is mentioned in Section 1.3 as an "OAM mechanism for point to point MPLS LSPs". In fact, LSP ping works just fine with LSPs created by LDP, and these are MP2P

b.       In Section 2.2.3 the draft claims that MPLS-TP "uses ... Up/Down MPs" and refers to RFC 6371 as its source. However, the corresponding text in RFC 6371 only mentions Up/Down MEPs. (In this regard it is fully consistent with both IEEE 802.1ag and ITU-T Y.1731).

3.       There are internal inconsistencies in the draft. E.g.:

a.       The naive interpretation of the already quoted statement from section 1.1 (see 1c above) is that "MPs are nodes"

b.      At the same time Section 2.3.3 states that "A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages".


Major Issues:





1.       OAM and its relationship to various network planes: In spite of the authors' attempt to resolve this issue, the concepts of data plane, control plane and management plane still are not properly explored in the draft:

a.       The term "data-plane" (with some modifications) is only found in Section 4.3 when discussing LSP-Ping ("data plane" is also found in the title of RFC 4379)

b.      An additional term "forwarding plane" appears in section 1.2, but nowhere else. The draft does not explain whether it means the same as data plane or not

c.       The terms "control-plane" ("control plane") are a bit more popular. They can be found:

                                                              i.      In Section 1.2 (which states that "OAM tools are defined independent of control plane" and that considerations of the control plane maintenance tools are out of scope)

                                                            ii.      In Section 3.3 (MPLS OAM) that explains that LSP Ping verifies "data-plane vs. control-plane consistency for FEC". This statement is correct, but IMO inconsistent with the previous one (see also my comment about CV above)

                                                          iii.      In Section 3.4 (MPLS-TP OAM) - mainly to explain that control plane is neither mandatory nor precluded in  MPLS-TP

d.      The term "management plane" (with or without dash) appears only in Section 1.2. In addition to the already mentioned ability to operate on-demand OAM tools, ability of these tools to raise alarms is mentioned

                                                              i.      This is definitely a step forward vs. the -05 version

                                                            ii.      While RFC 6427 is now referenced in the draft (it was missing in the previous version), the draft does not mention alarm suppression function. And while it mentions AIS in MPLS-TP it only points to RFC 6327 for the explanation of the consequent actions of AIS.

                                                          iii.      For the sake of completeness, ability to clear alarms should also be mentioned IMO - but this is a very minor issue.

e.      The term "test plane" appears in Section 4.5, but, as already mentioned above,  specific test plane protocols are not discussed in the draft

2.       OAM in connectionless vs. connection-oriented networks

a.       The first sentence in Section 1 states that "OAM is a general term that refers to a toolset for detecting, isolating and reporting connection failures and performance degradation". To me this suggests that OAM is applicable only to connection-oriented networks (if you do not have connections, connection problems do not exist by definition).

b.      The term "connection" appears in some other places in the draft, e.g., the connectivity check "is used to verify the liveness of a connection" (Section 1.1).

c.       At the same time, the draft discusses:

                                                              i.      ICMP Ping (Section 3.1.1) operating in connectionless IP networks

                                                            ii.      LSP-Ping in MPLS networks (Section 3.3). Since LSP-Ping as defined in RFC 4379 is applicable to LSPs set up by LDP, I'd say that it operates in connectionless environment

                                                          iii.      Ethernet OAM (1.5) operating in connectionless Ethernet networks etc.

3.       The Mess of MEs, MPs, MEPs and MIPs.

a.       Please consider the following text fragments

                                                              i.      (In section 2.2.2) OAM tools are designed to monitor and manage a Maintenance Entity (ME).  An ME, as defined in [TP-OAM-FW], defines a relationship between two points of a transport path to which maintenance and monitoring operations apply.

                                                            ii.      (ibid.) Various terms are used to refer to an ME. For example, BFD does not explicitly use a term that is equivalent to ME, but rather uses the term "session", referring to the relationship between two nodes using a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) terminology simply uses the term "LSP" in this context

                                                          iii.      (In Section 2.2.3) A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages. A Maintenance End Point (MEP) is one of the end points of an ME, and can initiate OAM messages and respond to them. A Maintenance Intermediate Point (MIP) is an intermediate point between two MEPs, that does not generally initiate OAM frames (one exception to this is the use of AIS notifications), but is able to respond to OAM frames that are destined to it.

                                                           iv.      (Ibid.) MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of the MP - either at the ingress, egress, or forwarding function of the node (Down / Up MPs).  This placement is important for localization of a connection failure.

b.      The last of these statements seems to hint that with just two  mutually exclusive types of MPs (UP/DOWN) it is possible to associated an MP with one of 3 possible placements (ingress, egress or forwarding function).

c.       IMHO and FWIW combining these statements can result in some unexpected (and undesirable) conclusions. E.g.,

                                                              i.      Premises:

*         An MPLS LSP is an ME in the case of LSP Ping

*         An ME defines a point-to-point relationship between two points on a transport path

*         These points are defined at nodes

Conclusion: An MPLS LSP can cross only two nodes (because in IP/MPLS LSP Ping can be initiated from any node participating in an LSP).

                                                            ii.      Premises:

*     BFD as defined in RFC 5880 is an OAM tool (it is listed as such in Table 1 in section 1.4)

*     OAM tools are designed to monitor MEs

*     In the case of a BFD  a BFD session (there are no other sessions in RFC 5880) is an ME

Conclusion: BFD is designed to monitor its own sessions (and hence is completely useless).





A Side Note: The majority of problematic definitions in the draft are based on RFC 6371. IMHO and FWIW this results in 3 types of problems:

*         The authors misinterpret RFC 6371. E.g., it only speaks about UP and DOWN MEPs, not about UP and DOWN MPs , and it does not discuss ingress/egress/forwarding engine placement

*         The authors have tried to extend the definitions from 6371 to other IETF technologies (IP and IP/MPLS). E.g., in MPLS-TP sending LSP-Ping packets from an intermediate node of a co-routed bi-directional LSP towards one of its endpoints is possible, but the responses would not be received by the initiator...

*         Some of the original definitions in 6371 are problematic (among other things, this applies to UP and DOWN MEPs).



Minor Issues:

1.       Limited coverage of performance measurement.

a.       The draft mentions packet loss, delay/delay variation and the (undisclosed) throughput measurement.

b.      At the same time it ignores such issues as duplication and reordering (and does not mention RFC 4347 and RFC 5560 respectively)

c.       Connectivity measurement (RFC 2678) is referenced and mentioned in the text. But it is not mapped to any of the main performance measurements functions

2.       Proposed classification of the IETF documents (into tools, profiles, infrastructure and miscellaneous) could be useful but is not consistently applied. E.g.,

a.       I do not think that RFC 792 defines an OAM Tool

b.      I have serious doubts that RFC 4556 and RFC 5337 (defining the control plane for the IPPM mechanisms) are "OAM Tools" while all the referenced specific measurement protocols are "Miscellaneous" etc.



Unfortunately could not provide any useful information regarding nits, typos etc. My review is incomplete in this regard, and I owe apologies to Routing ADs, my colleagues in the Routing Directorate and the authors.



Regards,

     Sasha






This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

--- Begin Message ---

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-opsawg-oam-overview-05.txt

Reviewer: Alexander ("Sasha") Vainshtein

Review date: 06-Aug-11

IETF LC End Date: 20-Jul-11 (?)

Intended status: Informational



Summary:



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



To some extent these concerns reflect my personal and potentially biased position with regard to OAM.  So I would like the Routing ADs to take them with a grain of salt.



In the process of review I've maintained private discussions with one of the draft authors (Nurit), and we've advanced in resolving some of the issues. Unfortunately, due to conflicting schedules, this process has not been completed.



Comments:



My concerns with the draft start from the question about its target audience. I have assumes (possibly, incorrectly), that the purpose of this draft is to provide guidance to OAM in IP, IP/MPLS and MPLS-TP networks to various "beginners" groups (including people who have experience with OAM in SONET/SDH, ATM and OTN networks), while "IETF gurus" would hardly need  it anyway  (IETF Area Directors, WG chairs and reviewers for various Directorates are excludedJ). Such guidance would be really useful because OAM-related issues are at the core of multiple discussions raging on some IETF mailing lists for the last several years.



IMHO and FWIW,  in order to provide guidance to what I expected to be the target audience, the draft should:

*       Include  a "Historical Background"  session. A single sentence in Section 1 ("OAM was originally used in the world of telephony, and has been adopted in packet based networks") is hardly sufficient IMHO
*       Present a clear view of OAM functionality and its relationship to various "planes" of networking (data plane, control plane, management plane). In particular, the importance of fate-sharing of OAM and user traffic flows in packet networks should be explained

*       Explicitly map the notions,  terms and methods that have been adopted  from technologies owned by ITU-T and/or IEEE to  IETF-owned technologies.  When such a mapping is not possible, it should be explicitly stated

*       Expose, rather than avoid,  known points of contention regarding various OAM-related issues, preferably without explicitly taking sides.

The draft did not meet my expectations in this regard. This may be because my  expectations have been  exaggerated or even completely unrealistic, or because the authors had in mind a different target audience and a different purpose. At the very least, explicitly specifying these (the purpose and the target audience) in the Introduction section would be helpful.



Instead the draft looks to me like a long (but incomplete) annotated list of references to IETF and non-IETF protocols and mechanisms that deal with certain aspects of OAM in IP, IP/MPLS, MPLS-TP and Ethernet networks.  The guiding principle behind selection of the referenced protocols and mechanisms is not defined in the draft and from my point of view, is questionable, e.g.:



*       Why is the defunct ITU-T Y.1711 considered in detail, while ITU-T I.610 (which has been implemented by virtually all the vendors of ATM equipment) is not even mentioned?

*       Why is IEEE 802.3ah included, while E-LMI (defined by MEF) is not? And what are their analogs (if any) in IETF-owned technologies?

*       Why MPLS-TP client failure indications  document(draft-ietf-mpls-tp-csf-01.txt) is   included but MPLS-TP fault management OAM one  (draft-ietf-mpls-tp-fault-05) is omitted?



>From my point of view the draft  is not easily readable - not in the least because some terms and concepts that have been "borrowed" from  the referenced documents have different meaning in these documents.  E.g.,. in Section 4.1 the draft states that ICMP ping provides "connectivity verification for Internet Protocol". However, in Section 3.2.4 the draft says that "connectivity verification function allows an MP to check whether it is connected to a peer MP or not". Since MPs are not mentioned with regard to ICMP, it is not clear whether "connectivity verification" means the same thing in these two cases.



The explanations that accompany some of these references sometimes focus on unimportant details  while in other cases are simply missing. To give a some examples:



*         In Sections 4.5.2 and 4.5.3 the authors remind the reader that OWAMP uses TCP port 861 and TWAMP - port 862. At the same time, IPPM test plane protocols are only mentioned by referencing the appropriate RFCs

*         In Section 3.2.3 the draft defines the term "Maintenance Entity" (ME). (Inaccuracies of this definition will be discussed below). At the same time an equally important (IMHO) term "Maintenance Entity Group" (MEG), a.k.a. "Maintenance Association (MA), is only defined by reference

*         In Section 4.5.2 the draft mentions security aspects of IPPM protocols. However, these aspects are not even mentioned in Section 4.2. discussing BFD.



I would suggest a careful clean-up of explanatory texts in the draft with special attention on homogeneity of detail.



Major Issues:



OAM and its relationship  to network planes



The following examples illustrate the problem IMO:



1.      The concepts of data plane, control plane and management plane are not explored in the draft:

a.      The term "data-plane" (with some modifications) is only found in Section 4.3 when discussing LSP-Ping ("data plane" is also found in the title of RFC 4379)

b.      The terms "control-plane" ( "control plane") are a bit more popular. They can be found:

                                                              i.      In Section 4.3 (LSP-Ping again)

                                                            ii.      In Section 4.5 (IPPM protocols) where "control plane" and "test plane" protocols are mentioned

                                                          iii.      In the sections dealing with MPLS-TP - but mainly to explain that control plane is neither mandatory nor precluded in  MPLS-TP

c.       The term "management plane" (with or without dash) simply does not appear in the draft

d.      The term "test plane" appears in Section 4.5, but, as already mentioned above,  specific test plane protocols are not discussed in the draft

2.  I have failed to understand relationship between OAM functionality and network management as presented in the draft. To illustrate this point, please consider the following text fragments (conflicting statements are indicated by italics, and my comments are closed in double angle brackets <<...>>):

a.       (Section 1) Other aspects associated with the OAM acronym, such as management, are outside the scope of this  document  <<Management is out of scope>>

b.      (Section 4.6.4)   The FDI function is used by an LSR to report a defect to affected client layers, allowing them to suppress alarms  about this defect << Are not alarms part of management? >>

c.       3.      (Section 4.7.2) When the ETH-CC function detects a defect, it reports one of the following defect conditions:

                                                              i.      Loss of continuity (LOC): Occurs when at least when no CCM messages have been received from a peer MEP during a period of 3.5 times the configured transmission period

                                                            ii.      ... (snipped)...

                                                          iii.      Unexpected period: Occurs when the transmission period field in the CCM does not match the expected transmission period value  << Since transmission period field in ETH-CC is defined by management, this defect reports a management problem>>

d.      (Section 4.7.6)   The Alarm Indication Signal indicates that a MEG should suppress alarms about a defect condition at a lower MEG level, i.e., since a defect has occurred in a lower hierarchy in the network, it should   not be reported by the current node  <<Alarms' suppression again...>>

e.    (Section 4.7.9)   The Y.1731 standard defines the frame format for Automatic Protection   Switching frames. The protection switching operations are defined in  other ITU-T standards. <<Is APS part of OAM?>>

3.   OAM in connectionless vs. connection-oriented networks:

a.      (2a) above suggests that OAM is applicable only to connection-oriented networks (if you do not have connections, connection problems do not exist by definition)

b.      At  the same time, the draft discusses ICMP Ping (Section 4.1) operating in connectionless IP networks, and Ethernet OAM (Sections  4.7 and 4.8) operating in connectionless Ethernet networks.



My suggestion (FWIW) to the authors would be to define the scope of OAM explicitly and clearly - and then remove the sections dealing with protocols and mechanisms that happen to be out of this scope. In particular, explaining the relationship of each specific defect to a specific networking planes would be most helpful.



The Mess  of  MEs, MPs, MEPs and MIPs



Caveat: It may well be that the problem is not with the draft I am reviewing but with the concept itself (or at least with the attempts to extend it to IP. IP/MPLS and MPLS-TP networks).  I may be also biased when it comes to this concept. However, if the problem is with the concept, I would expect a useful overview to expose it to the reader and not to hide it.



Going back to the draft, consider the following statements:



1.      (Section 3.2.2)   A Maintenance Entity (ME) is a point-to-point relationship between two Maintenance Points (MP). The connectivity between these Maintenance Points is managed and monitored by the OAM protocol.  A pair of MPs engaged in an ME are connected by a Communication Link

2.      (Section 3.2.3) A Maintenance Point (MP) is a functional entity that is defined at a node in the network, and either initiates or reacts to OAM messages. A Maintenance End Point (MEP) is one of the end points of an ME, and  can initiate OAM messages and respond to them. A Maintenance Intermediate Point (MIP) is an intermediate point between two MEPs, that does not initiate OAM frames, but is able to respond to OAM  frames that are destined to it, and to forward others.

3.      (Section 3.2.3)  The 802.1ag defines a finer distinction between Up MPs and Down MPs. An MP is a bridge interface, that is monitored by an OAM protocol...

4.       (Section 4.1)   ICMP provides a connectivity verification function for the Internet Protocol... ICMP is also used in Traceroute for path discovery.



I suspect that, based on  these fragments (all within two pages in the draft), an OAM beginner would not be able to answer the following questions:

1.      Can a communication link exist without any MPs on it (the chicken and egg problemJ)

2.      Suppose that I have defined a P2P bidirectional communication link with two MEPs  forming an ME.  What would happen to this ME if I add a MIP between the two MEPs?

3.      What is the relationship (if any) between MEPs and interfaces? Or is it just something specific to Ethernet bridges?

4.      Does a MIP really forward OAM frames that are not destined to it?

5.      Operation of ICMP Ping does not require creation of MPs. How does it provide a connectivity verification function for IP?



As a minimum, I would suggest to remove conflicting definitions, to fix typos (e.g., the definition of ME would be less problematic if it referred to a pair of MEPs and not to a pair of MPs) and inaccurate statements (in IP, IP/MPLS and MPLS-TP MIPs do NOT forward OAM packets that are not destined to them - but they do that in Ethernet OAM).



Minor Issues:



Caveat: Each of the issues listed below, if you look at it separately, could be considered as minor. But there seem to be too many of them for my taste.



Connectivity Check vs. Continuity Check



The draft mainly uses the term "Continuity Check". However, from time to time I have seen the term "Connectivity Check" as well, e.g.:

1.      (Section 4.12) A key element in some of the OAM standards that are analyzed in this document is the continuity check. It is thus interesting to present a more detailed comparison of the connectivity check mechanisms defined in OAM standards.

2.      (Section 4.3)  LSP Ping extends the basic ICMP Ping operation (of data-plane connectivity and continuity check)...



The second fragment seems to suggest that connectivity check and continuity check are two different functions.



I would suggest to clean up the text using the term "continuity check" consistently.



Caveat: I have found a similar inconsistency in IEEE 802.1ag (but not in ITU-T Y.1731).



Continuity Check vs. Connectivity Verification



In Section 3.2.4. the draft refers to  RFC 5860 as the ultimate source of information about the difference between Continuity Check and Connectivity Verification. Looking up RFC 5860 (Section 2.2.3), I've learned that connectivity verification is a function that allows an End Point to find out whether it is connected to a specific End Point(s) by means of an expected PW, LSP or Section. At the same time, the draft says (in the same Section 3.2.4) that "A connectivity verification function allows an MP to check whether it is connected to a peer MP or not".  The omitted  words from RFC 5860 "by means of..." make such a definition meaningless IMO; and it is not clear to me if End Points (of Section, LSP or PW) which, presumably, are MEPs, can be extended to be MEPs or MIPs (the draft uses the term MPs).



It is also not clear to me whether the draft considers LSP Ping (see Section 4.3.) functionality "to verify data-plane vs. control-plane consistency for a Forwarding Equivalence Class (FEC)"  as  related to Connectivity Verification. This is especially strange since the draft also states (in the same section)  that "LSP Ping extends the basic ICMP Ping operation"  while Section 4.1 states that "ICMP provides a connectivity verification function for the Internet   Protocol".



Yet another problematic point is the statement (in Section 4.2.3) that "BFD Echo provides a connectivity verification function", especially since draft-ietf-mpls-tp-cc-cv-rdi-05 in Section 3.5 expands format of the BFD control packets in order to provide CV function, while BFD Echo is not even mentioned in this document.



Last but not least, the draft does not explain whether there is any correlation between the defects detected by the continuity check and those detected by connectivity verification (Section 4.10.3.1 looks  a logical place for this).



Inaccurate Representation of IEEE 802.1ag



In Section 3.2.3 of the draft I have found the following text:



"The 802.1ag defines a finer distinction between Up MPs and Down MPs. An MP is a bridge interface, that is monitored by an OAM protocol either in the direction facing the network, or in the direction    facing the bridge. A Down MP is an MP that receives OAM packets from,    and transmits them to the direction of the network. An Up MP receives OAM packets from, and transmits them to the direction of the bridging entity".



In fact IEEE 802.1ag states (see Section 22.1.3 of that document ) that: "All Up MEPs belonging to MAs that are attached to specific VIDs are placed between the Frame filtering entity (8.6.3) and the Port filtering entities (8.6.1, 8.6.2, and 8.6.4). Separately for each VLAN, there can be from zero to eight Up MEPs, ordered by increasing MD Level, from Frame filtering towards Port filtering".



To me that means that in 802.1ag MEPs are NOT bridge interfaces (since there can be are multiple MEPs per VLAN and multiple VLANs per bridge interface).



Defects, Faults and Failures



In Section 3.2.5 the draft discusses the terms Defect, Fault and Failure. However, these terms seem to apply to the "communication link" which presumably is a data plane entity.



At the same time, "Unexpected Period" and "Unexpected MEP" are mentioned as defects detected by ETH-CC in Section 4.7.2 even if, to the best of my understanding, these conditions are side effects of mis-configuration i.e., a management plane problem.



VCCV: An OAM Mechanism or a Control Channel?



In Section 4.4. the draft states that VCCV "provides end-to-end fault detection and diagnostics for PWs". This seems to point that VCCV is an OAM mechanism/protocol.



However, later in the same section is states that "The VCCV switching function provides a control channel associated with each PW... and allows sending OAM packets in-band with PW data".  And on the next line it explains that "VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP Ping, and BFD" (which are all mentioned as OAM mechanisms providing continuity check and/or connectivity verification in the draft). So it remains completely unclear whether VCCV is an OAM mechanism or just a channel for separating user data from OAM flows.



MEs, MEGs and MEG levels



The draft explicitly defines a Maintenance Entity (ME) in Section 3.2.2, bur defers to MPLS-TP OAM Framework for the definition of the Maintenance Entity Group (MEG). The text defining ME in the draft differs from that in the MPLS-T_ OAM Framework document  (see http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-oam-framework/?include_text=1, Section 2.2). At the same time, it resembles the definition of ME in Section 3.1 of this document.



MEG level is mentioned a couple of times in the draft, but the only explanation given (in Section 4.7.2) is "The MEG level is a 3-bit number that defines the level of hierarchy of the MEG"; and this seems to be the only text in the draft that deals with MEG hierarchy.



Differences between Approaches to Packet/Frame Loss Measurement



I have not found any mention of the fundamental difference between two approaches to measuring packet loss - that of the IPPM WG (based on counting synthetic packets) and that of Y.1731 (based on counting the user packets), even if both are mentioned in the draft.



Nits:



Unidirectional/Bidirectional OAM vs. One-way/Two-way OAM



Both pairs of terms are used in the draft (One-way/Two-way - in Section 4.5.1, Unidirectional - in section 4.12, /Bidirectional - in Section 4.2.2).  Neither  the terms nor their equivalence are explained in the draft.



A Typo:



In section 4.10.3.1:



"Continuity Check and Connectivity Verification (CC-V) are OAM operations generally used in tandem, and compliment each other." - probably should be "complement"?



An Pleonasm:



In Section 4.8.1:



"There are a few differences between the two standards in terms of terminology" - I would suggest "There are a few differences in terminology between the two standards".



Regards,

     Sasha

--- End Message ---