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

[Sam Aldrin <[e-mail]>]

Inline with %sam.

On Apr 1, 2014, at 8:02 PM, Xialiang (Frank) <[e-mail]> wrote:

> Sam,
> Please see my response inline:
>  
> From: Sam Aldrin [mailto:[e-mail]] 
> Sent: Tuesday, April 01, 2014 10:12 AM
> To: Xialiang (Frank)
> Cc: Samer Salam (ssalam); Ali Sajassi (sajassi); [e-mail]; [e-mail]
> 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]> 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]; [e-mail]
> Cc: [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.
> [Frank] : I agree with the principle of requirement draft. Actually, What I suggest is better wording for better understanding the goal of representative path check.
%sam - When continuity to a MEP is lost, one could conclude there is a node failure, but IMO, one cannot conclude path has failed as there could be a different load balanced path exist. That is the reason we used the term ‘conclusively’. If one’s implementation could determine it is indeed path failure, so be it. But from requirement point of view, we do not want to enforce node failure = path failure. Which translates to, solution and implementations could innovate to conclusively determine path failure.

Hope this is clear. 

cheers
-sam

> 
> 
>  
> 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. 
> [Frank] : OK
>  
> -sam
> 
>  
> Regards,
> Samer
>  
> From: "Xialiang (Frank)" <[e-mail]>
> Date: Tuesday, 18 March, 2014 12:07 AM
> To: Samer Salam <[e-mail]>, "Ali Sajassi (sajassi)" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[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
>