RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

[Gregory Mirsky <[e-mail]>]

Hi Sam, et. al,
I only noted that I don’t believe that it is possible to distinguish between path failure and failure of a node along that path without very sophisticated fault correlation heuristics usually associated with the NMS.
With so extensive and interesting discussion it is bit hard to understand current state of the document and suggest any specific text. I’m looking forward for the version that incorporates this round of discussion.

                Regards,
                                Greg

From: Sam Aldrin [mailto:[e-mail]]
Sent: Thursday, April 03, 2014 3:51 PM
To: Gregory Mirsky
Cc: Xialiang (Frank); [e-mail]; Ali Sajassi (sajassi)
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Greg, Frank et al,

Any proposal to have clear text is always welcome. So, kindly propose the text on what you would like to see.

Sam

Sent from my iPhone

On Apr 3, 2014, at 3:24 PM, Gregory Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Dear Sam and Frank,
even though we’re discussing requirements and framework of EVPN OAM I wonder if you can give reference to  OAM method that can differentiate or distinguish between path and node failures as implied in:
3. Yes, a representative path maps to a test flow. This is a simple function, and is actually a degenerate case of the per user-flow OAM, because test fields are specified for the N-Tuple. That's why it is mandatory. As to the details of the mechanism, that is left to the solution draft – after all, this is the requirements and framework draft, it does not cover the solution details for implementation.
[Frank] : From my personal view, I don’t think the paragraph describing the requirement of a representative path is clear enough. For example, why can it be used for node failure detection but not path failure detection?
Whether one uses for node or path failure detection is for the solution to decide. This is requirements draft. If you think better wording is required, please do propose, will consider that.

                Regards,
                                Greg

From: L2vpn [mailto:[e-mail]] On Behalf Of Sam Aldrin
Sent: Monday, March 31, 2014 7:12 PM
To: Xialiang (Frank)
Cc: [e-mail]<mailto:[e-mail]>; Ali Sajassi (sajassi)
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Frank,

Comments inline.
On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) <[e-mail]<mailto:[e-mail]>> wrote:



Hi Samer,
Please see inline:

From: Samer Salam (ssalam) [mailto:[e-mail]]
Sent: Tuesday, April 01, 2014 5:03 AM
To: Xialiang (Frank); Ali Sajassi (sajassi); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Hi Frank,

Thanks for your comments. Please find responses below:

1. In this draft, we cite RFC 6136 as reference, and hence we do not repeat the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM layering etc.). Regarding Discovery, please note that E-VPN has automatic discovery built-in via the Inclusive Multicast Route and the Ethernet A-D Route. Hence, no further mechanisms are required.

2. Per user flow means a traffic stream that maps to actual user data, with a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port…).  The reason why this is different between Network & Service OAM is because the Service OAM mechanisms may or may not be able to support per-flow OAM, depending on the  service layer and its associated OAM capabilities. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the service OAM, it is not possible to perform per-flow continuity check, as the destination MAC address is set by the protocol to a multicast address.

3. Yes, a representative path maps to a test flow. This is a simple function, and is actually a degenerate case of the per user-flow OAM, because test fields are specified for the N-Tuple. That's why it is mandatory. As to the details of the mechanism, that is left to the solution draft – after all, this is the requirements and framework draft, it does not cover the solution details for implementation.
[Frank] : From my personal view, I don’t think the paragraph describing the requirement of a representative path is clear enough. For example, why can it be used for node failure detection but not path failure detection?
Whether one uses for node or path failure detection is for the solution to decide. This is requirements draft. If you think better wording is required, please do propose, will consider that.



4. Test packets can be either unicast or multicast. The problem we are describing here is that relying on normal packet counters in unreliable given that E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints A, B and C. Let's say we are interested in measuring the loss between A and C. A sends a packet to C, but it gets dropped. Now B also sends to C and that packet is delivered. If we were to examine the packet counter on C, we will find that the counter shows 1 packet received. But that doesn't mean that we have 100% packet delivery rate between A and C. The packet actually came from another source and hence the packet counter on C is ambiguous. Unless the implementation keeps packet counters per-flow (which will be expensive and impractical), it is not reliable to use packet counters to measure loss in a technology that supports multipoint-to-multipoint connectivity.
[Frank] : Yes. This clarification is more clear than the current content of draft~~ Also, I think “a statistical means of approximating packet loss rate” you proposed in draft is not the suitable solution for this problem. Actually, this is more an implementation issue, i.e., we can set the same value of flow characteristics for a test flow to ensure all test flow packets send/receive between 2 nodes exactly.
Again, this is requirement draft only. What you are eluding to is how one should perform, which clearly falls in solution category. As Samer clarified earlier, using actual data packet counters doesn’t meet the requirements, hence ‘synthetic' measurement is required.

-sam



Regards,
Samer

From: "Xialiang (Frank)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 18 March, 2014 12:07 AM
To: Samer Salam <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Hi authors,
I have reviewed this important draft, and have some comments as below:
1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity point of view, I think there are some part missing: EVPN MEP and MIP, Discovery, Data Path Forwarding, Scalability, Transport/Application Independence;
2. In section 3.1.1.1, what is the definition of per user flow? Why is it different to support it between E-VPN Network OAM and E-VPN Service OAM?
3. In section 3.1.1.1, does the section of "a representative path" mean using test flow to detect the node failure? if yes, how to do? Is it a necessary requirement of proactive fault detection?
4. In section 3.2.1, I do not quite understand the describing reason for the inaccuracy of Loss Measurement. Do you mean that test packets of Loss Measurement are all BUM packets? Can you clarify why peer MEPs will receive some unnecessary packets? Why not use unicast packets for Loss Measurement?

Hoping for your feedback~~

B.R.
Frank