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

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 6 Aug 2011 23:45:56 +0300

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 excluded:)). 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 problem:))

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

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.