Subject: Re: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd

From: "Samer Salam (ssalam)" <[email-masked]>
Date: Wed, 11 Dec 2013 00:00:47 +0000

Hi Greg,

Thanks again for your comments. Please find comment resolution/responses on the Requirements/Framework draft inline…

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 19 November, 2013 4:56 AM
To: Samer Salam <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "Sam Aldrin ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "John E Drake ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "Vengada Prasad Govindan (venggovi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd

Dear Authors, et. al,
very useful and timely raised questions. Please find my comments to both documents below. Greatly appreciate your kind consideration and am looking forward to the discussion.

                Regards,
                                Greg

draft-salam-l2vpn-evpn-oam-req-frmwk-01

  *   Use cases. Multi-carrier E-VPN. Ethernet Service OAM is instrumented, through MEG Level hierarchy, to present customer, provider, and operator scopes of OAM. If multi-carrier E-VPN is viable use case, then support of MEP and its functionalities becomes a MUST for provider and operator scopes. Then, if multi-carrier E-VPN is viable use case, there might be new requirements towards E-VPN Network OAM.
  *   Sec.1.1 s/Public/Packet/

Fixed.

  *   CFM … defines concept … Maintenance Association …

Added.

  *   Sec.1.3 MEG, Maintenance Entity Group, is object of Y.1731 equivalent to MA of CFM. Note that MEG is used in MPLS-TP OAM as well.

Added MA to the terminology section (picked the CFM terminology to use consistently for the document, also per your comment below)

  *   Definition of MIP is not correct. MIP can terminate certain OAM, both Ethernet and MPLS-TP, frames, e.g. ETH-LB.

Good catch, fixed.

  *   Maintenance Domain, as mentioned in 1.1, is object of CFM and is not used in Y.1731. Suggest use consistent terminology, either CFM or Y.1731.

Good point, went with the CFM terminology.

  *   Figure 2, can use EFM (Ethernet First Mile) OAM instead of 802.3 OAM. (Note that there are two Figure 2 in the document – Section 2.1 and Section 3.1.1.2.1)

Fixed figure number.

  *   Section 2.2
     *   Characterize whether MEP on PEs SHOULD be Up, Down or both.

Added.

  *   Section 2.4
     *   Would BFD (RFC 5880, RFC 5881, RFC 5883, RFC 5884, and RFC 5885) be applicable as well as RFC 6428?

RFC 5885 doesn't apply, as it is highly unlikely to use pseudowires as an underlying transport mechanism for EVPN. A more likely case would be pseudowire access into EVPN network, but in this latter case RFC 5885 acts as a Network OAM, rather than a Transport OAM.  By the same token,  for RFC 6428, the LSP related mechanisms apply (Not the PW). The rest apply. Updated the section accordingly.

  *   Section 2.6
     *   I think that OAM interworking is most useful when it exists between proactive OAM mechanisms whether it in peer-to-peer or client-server model. I don’t see that there’s requirement of proactive Network OAM. Should there be one? E.g. “E-VPN Network OAM SHOULD provide both proactive and on-demand mechanisms of monitoring its data plane operation and data plane conformance to state of its control plane.”

Agreed. Added.

  *   Section 3.1.1
     *   Please consider splitting the sentence in two with the second being like “… without time bound. Certain actions, e.g. protection switchover or alarm indication signaling, could be associated with events of entering and clearing fault state”.
  *   Section 3.1.1.1
     *   I think that another term for “a specified path taken by a particular user data flow” is “in-band monitoring”.
     *   I think that monitoring of “representative path” may not be reliable test of MEP hosting node liveliness. As I understand, it still verification of the MEP liveliness but out-band. Or it is implied that the target of this monitoring is not the MEP but an ID associated with the node where the MEP defined? Then wouldn’t that be verification of a control plane rather than data plane operation?
     *   What is understood as “test flow”? Is that using methods of active monitoring/measurements when specifically constructed test packets being injected vs. passive monitoring/measurements when data flow(s) used to monitor and measure performance?
     *   “Monitoring of all ECMP paths between MEPs is not a requirement for E-VPN OAM.” Is in regard to concurrent monitoring all paths between two (?) MEPs or to problem of exercising particular paths at-will?
     *   I’m not sure that the last requirement is applicable to E-VPN Service OAM. CFM and/or Y.1731 would not be used differently when monitoring unicast only or unicast and multicast services.
  *   Section 3.1.1.2.2
     *   What is understood by “support RDI”? Is it merely ability to signal LoC defect to remote MEP(s) or ability, as well, to recognize RDI from a remote MEP? Should note that in multipoint MA RDI is not really useful as indicator of unidirectional fault since there’s no indication of with which MEP the sender detected LoC defect. If unidirectional LoC is likely not guarantee of bi-directional fault, then MA MUST be p2p.
  *   Section 3.1.2.2
     *   Connectivity Verification vs. Continuity Check. There’s reference to “connectivity faults” in the first paragraph. Should it be changed to “continuity” or on-demand OAM, at least in E-VPN Service OAM, required to detect mis-connectivity? If “yes”, why the same is not applicable to proactive OAM for E-VPN Service?
  *   Section 3.2
     *   I wouldn’t refer to scheduled on-demand PM tests as “proactive” since these are still bound in time unlike proactive that are not bound in time.
     *   But there is at least one example of truly proactive LM in Y.1731 that uses ETH-CC frames. So, there’s a distinction between proactive and on-demand PM.
  *   Section 3.2.1
     *   Use of Synthetic LM is usually in out-of-service state as test frames expected to be statistically representative of real data flow. LM in mp2mp network can be constructed of set of p2p LM metrics.
draft-vgovindan-l2vpn-evpn-bfd-00
·         Section 2.1.1
o   If there’s a need to have BFD session per ECMP path/EL how such session can be demuxed at the tail if at the bootstrap it would allocate only one myDiscriminator per source IP/FEC combination?
o   Effectively, IMO, there are separate p2p BFD sessions between head and tail of mp2p tunnel. Right?
·         Section 3
o   Since two types of BFD encapsulation available, I think it would be better to require that only one type be used to monitor particular E-VPN at its Network level. Should it say “The same type of BFD encapsulation, either IP or VCCV, MUST be used to monitor all tunnels of the particular E-VPN at its Network level.”
o   s/G-Ach/G-ACh/
·         Section 4
o   Not clear which BFD modes can be used and in what manner as on-demand OAM to troubleshoot and localize fault. AFAIK, BFD-based OAM used primarily as proactive continuity check and LSP Ping as on-demand troubleshooting tool.

---

From: "Samer Salam (ssalam)" <[email-masked]>
Date: Wed, 11 Dec 2013 00:28:10 +0000

Hit "send" instead of "save", further responses inline…

From: Samer Salam <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 10 December, 2013 4:00 PM
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "Sam Aldrin ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "John E Drake ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>, "Vengada Prasad Govindan (venggovi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd

Hi Greg,

Dear Authors, et. al,

                Regards,
                                Greg

Fixed.

Added.

Good catch, fixed.

Fixed figure number.

  *   Section 2.2

Added.

  *   Section 2.4

  *   Section 2.6

Agreed. Added.

  *   Section 3.1.1

Done.

  *   Section 3.1.1.1

Changed.

  *

The intent was that this is a mechanism to verify that the node is alive, provided that the MEP's operation fate-shares the liveness of the PE. The idea is that the messages will use flow entropy parameters corresponding to some test flow (I.E. some MAC, VLAN etc… parameters to represent an example flow – not necessarily a customer flow).

  *
What is understood as “test flow”? Is that using methods of active monitoring/measurements when specifically constructed test packets being injected vs. passive monitoring/measurements when data flow(s) used to monitor and measure performance?

Please see above.

  *

Both. A particular path may not be exercisable because the ECMP hashing is a local function.

  *

Agreed, updated.

  *
  *   Section 3.1.1.2.2

Added clarification to that effect.

  *
     *
  *   Section 3.1.2.2

I am not sure I follow the question here. This section is about on-demand fault localization (I.E. the equivalent of the Linktrace function in CFM).

  *
     *
  *   Section 3.2

Updated.

  *
     *
  *   Section 3.2.1

If this were to rely on data-packet counters, and the solution allows MP2MP connectivity, then this requires maintaining packet statistics per source-destination pair, which is typically not available in implementations. At least for Y.1731, my experience has been that this function was rarely implemented, due to the associated complexity and HW cost implications.

Regards,
Samer

  *
     *

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 11 Dec 2013 23:11:56 +0000

Hi Prasad,
thank you for you careful consideration of my notes. Proposed text tagged with GIM>>.

                Regards,
                                Greg
[snip]

*         Section 4
o   Not clear which BFD modes can be used and in what manner as on-demand OAM to troubleshoot and localize fault. AFAIK, BFD-based OAM used primarily as proactive continuity check and LSP Ping as on-demand troubleshooting tool.
 GVP1> The intent of this Section is to highlight the possible scalability issues that could arise. The term demand-driven manner was used to imply that BFD could be turned ON and OFF as desired, instead of an ALWAYS-ON mode. Do you have any suggestions to improve the text here? Please let us know.

GIM>> Bringing BFD session up has its tax of triple handshake to exchange Discriminator values. Alternative to turning ON and OFF could be dynamically changing Rx and Tx intervals  to a very large value, i.e. minutes if not hours. As I understand, "demand-driven", also referred as "on-demand", OAM tools primarily used for fault localization. LSP traceroute is one of widely used in MPLS networks, ETH-LT (linktrace) - in Ethernet domain. Proactive tools like BFD or CFM primarily used for fault detection. I don't think that BFD needs to be enhanced to match diagnostic capabilities available in LSP Ping/traceroute.

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 12 Dec 2013 03:09:41 +0000

Hi Samer,
thank you for kind consideration of my notes. Am glad that we can snip so many of them. Please find my answers in-line and tagged by GIM>>.

                Regards,
                                Greg

[...]

     *   I think that monitoring of "representative path" may not be reliable test of MEP hosting node liveliness. As I understand, it still verification of the MEP liveliness but out-band. Or it is implied that the target of this monitoring is not the MEP but an ID associated with the node where the MEP defined? Then wouldn't that be verification of a control plane rather than data plane operation?
The intent was that this is a mechanism to verify that the node is alive, provided that the MEP's operation fate-shares the liveness of the PE. The idea is that the messages will use flow entropy parameters corresponding to some test flow (I.E. some MAC, VLAN etc... parameters to represent an example flow - not necessarily a customer flow).

GIM>> Consider Up MEP case. It may be unreachable, i.e. LoC detected, because of problem in bridging element while the hosting node is operational. I think that "fate-sharing" is in area of uncertainty and assumptions. I'd consider explicitly stating all assumptions, i.e. "LoC detection interpreted as failure of the hosting node".
[...]

     *   "Monitoring of all ECMP paths between MEPs is not a requirement for E-VPN OAM." Is in regard to concurrent monitoring all paths between two (?) MEPs or to problem of exercising particular paths at-will?
Both. A particular path may not be exercisable because the ECMP hashing is a local function.

GIM>> This is interesting and hard to crack problem. ECMP may be monitored on link level and AIS-like used to inform client level.
[...]

  *   Section 3.1.2.2

     *   Connectivity Verification vs. Continuity Check. There's reference to "connectivity faults" in the first paragraph. Should it be changed to "continuity" or on-demand OAM, at least in E-VPN Service OAM, required to detect mis-connectivity? If "yes", why the same is not applicable to proactive OAM for E-VPN Service?
I am not sure I follow the question here. This section is about on-demand fault localization (I.E. the equivalent of the Linktrace function in CFM).

GIM>> The complete sentence is "That is, given two PEs A and B, localization of connectivity faults between them requires running fault isolation procedures from PE A to PE B as well as from PE B to PE A."
ETH-LT/linktrace or IP traceroute helpful in localizing continuity failure. I don't think that either is helpful in localizing mis-connectivity defects. My question is about terminology. "Connectivity defect" and "continuity defect" are not the same defects and, I believe, should not be used interchangeably.
[...]

  *   Section 3.2.1

GIM>> Alternatively, passive methods of performance measurement may be considered.

Regards,
Samer

---

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Fri, 13 Dec 2013 11:01:43 +0000

Hello Greg,
    Sincere thanks for your email. Agreed, the BFD sessions could be slowed down to tolerable (large) timer values instead of tearing down and (re)establishing BFD sessions. I will incorporate this change in the next revision of this draft.
Thanks
Prasad

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Thursday, December 12, 2013 4:42 AM
To: Vengada Prasad Govindan (venggovi); Samer Salam (ssalam); Ali Sajassi (sajassi); Sam Aldrin ([email-masked]); John E Drake ([email-masked]); [email-masked]
Subject: RE: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd

Hi Prasad,

                Regards,
                                Greg
[snip]

*         Section 4