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

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

Hi Frank,

We will add text to clarify in the next revision. Thank you for your comments!

Regards,
Samer

From: "Xialiang (Frank)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 2 April, 2014 8:41 PM
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: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Hi Samer,
My suggestions are in line:

From: Samer Salam (ssalam) [mailto:[e-mail]]
Sent: Thursday, April 03, 2014 7:21 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,

Please find my responses inline after yours…

From: "Xialiang (Frank)" <[e-mail]<mailto:[e-mail]>>
Date: Monday, 31 March, 2014 7:00 PM
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: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

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?

It can be used for failure detection of that "representative" path, but the point is that this lacks real practical benefit to the network operator: the path may have been chosen arbitrarily by an OAM solution that constructs test flows using random or pseudo-random entropy generators. Hence, the focus is on what practical information could the network operator glean from this mode of operation, and the answer is: node failure detection. We can update the text to expand on this point.
[Frank] :I suggests you give a clear clarification of the difference between node failure and path failure in this condition by your updates. I think sam’s response in previous email is a good reference.


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.

This is not a new problem. ITU-T Y.1731 and the Metro Ethernet Forum have tackled this very same problem in the recent past, and the approach converged on statistical approximation.
[Frank] :OK!

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.


The draft is not precluding other solutions. It is simply stating that a solution based on synthetic measurement is required. There is no statement that this shall be the only option offered.
[Frank] : OK!

Regards,
Samer

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