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

["Samer Salam (ssalam)" <[e-mail]>]

Hi Greg,

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

From: Gregory Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 19 November, 2013 4:56 AM
To: Samer Salam <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>, "Sam Aldrin ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>, "John E Drake ([e-mail]<mailto:[e-mail]>)" <[e-mail]<mailto:[e-mail]>>, "Vengada Prasad Govindan (venggovi)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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.