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

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

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.

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.

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