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

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

Hi Greg,

Thank you for the response. I have incorporated your comments, more details on the resolution inline, please see @SS:

From: Gregory Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 11 December, 2013 7:09 PM
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: RE: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd

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

@SS: Updated accordingly.
[…]


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

@SS: Added text to clarify the context: the MEPs in question here are not on back-to-back devices, hence proactive monitoring of all ECMP using Continuity Check messages is not possible.
[…]

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

@SS: Ah, now I get your point. Updated.
[…]

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

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

@SS: This could be a could discussion point for the upcoming IETF.

Regards,
Samer

Regards,
Samer