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

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 2 Apr 2014 03:02:31 +0000

Sam,
Please see my response inline:

From: Sam Aldrin [mailto:[email-masked]]
Sent: Tuesday, April 01, 2014 10:12 AM
To: Xialiang (Frank)
Cc: Samer Salam (ssalam); Ali Sajassi (sajassi); [email-masked]; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Samer,
Please see inline:

From: Samer Salam (ssalam) [mailto:[email-masked]]
Sent: Tuesday, April 01, 2014 5:03 AM
To: Xialiang (Frank); Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
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.

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)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 18 March, 2014 12:07 AM
To: Samer Salam <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 1 Apr 2014 20:20:25 -0700

Inline with %sam.

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

> On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) <[email-masked]> wrote:
> 
> 
> Hi Samer,
> Please see inline:
>  
> To: Xialiang (Frank); Ali Sajassi (sajassi); [email-masked]; [email-masked]
> Cc: [email-masked]
> 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?
%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

> [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)" <[email-masked]>
> To: Samer Salam <[email-masked]>, "Ali Sajassi (sajassi)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: "Samer Salam (ssalam)" <[email-masked]>
Date: Wed, 2 Apr 2014 23:20:50 +0000

Hi Frank,

Please find my responses inline after yours…

From: "Xialiang (Frank)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, 31 March, 2014 7:00 PM
To: Samer Salam <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Hi Samer,
Please see inline:

Hi Frank,

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.

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.

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.

Regards,
Samer

Regards,
Samer

Hi authors,

B.R.
Frank

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 3 Apr 2014 03:41:28 +0000

Hi Samer,
My suggestions are in line:

From: Samer Salam (ssalam) [mailto:[email-masked]]
Sent: Thursday, April 03, 2014 7:21 AM
To: Xialiang (Frank); Ali Sajassi (sajassi); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Hi Frank,

Please find my responses inline after yours...

Hi Samer,
Please see inline:

Hi Frank,

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.

[Frank] :OK!

[Frank] : OK!

Regards,
Samer

Regards,
Samer

Hi authors,

B.R.
Frank

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 3 Apr 2014 21:04:03 +0000

Dear All,
I think that case of e2e Continuity Check failure over path with multi-path segment is an example of multi-layer OAM where fault detection and protection switchover require careful coordination. If such coordination done properly then e2e LoC fault would be informative and deterministic.

                Regards,
                                Greg

From: L2vpn [mailto:[email-masked]] On Behalf Of Sam Aldrin
Sent: Tuesday, April 01, 2014 8:20 PM
To: Xialiang (Frank)
Cc: [email-masked]; Ali Sajassi (sajassi)
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Inline with %sam.

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

Sam,

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

Frank,

Comments inline.

Hi Samer,
Please see inline:

Hi Frank,

%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

-sam

Regards,
Samer

Hi authors,

B.R.
Frank

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 3 Apr 2014 22:24:11 +0000

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:[email-masked]] On Behalf Of Sam Aldrin
Sent: Monday, March 31, 2014 7:12 PM
To: Xialiang (Frank)
Cc: [email-masked]; Ali Sajassi (sajassi)
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Frank,

Comments inline.

Hi Samer,
Please see inline:

Hi Frank,

-sam

Regards,
Samer

Hi authors,

B.R.
Frank

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 3 Apr 2014 15:51:08 -0700

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 <[email-masked]> 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:

---

From: "Samer Salam (ssalam)" <[email-masked]>
Date: Fri, 4 Apr 2014 00:01:45 +0000

Hi Frank,

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

Regards,
Samer

Date: Wednesday, 2 April, 2014 8:41 PM

Hi Samer,

Hi Frank,

Hi Samer,
Please see inline:

Hi Frank,

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.

Regards,
Samer

Regards,
Samer

Hi authors,

B.R.
Frank

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 4 Apr 2014 01:26:50 +0000

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:[email-masked]]
Sent: Thursday, April 03, 2014 3:51 PM
To: Gregory Mirsky
Cc: Xialiang (Frank); [email-masked]; Ali Sajassi (sajassi)
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

Greg, Frank et al,

Sam

Sent from my iPhone

On Apr 3, 2014, at 3:24 PM, Gregory Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Dear Sam and Frank,

                Regards,
                                Greg

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

Frank,

Comments inline.

Hi Samer,
Please see inline:

Hi Frank,

-sam

Regards,
Samer

Hi authors,

B.R.
Frank

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 3 Apr 2014 19:01:32 -0700

Sounds good, Greg and Frank.
Will respin a new version based on your observations.

Sam

Sent from my iPhone

> On Apr 3, 2014, at 6:26 PM, Gregory Mirsky <[email-masked]> wrote:
> 
> Hi Sam, et. al,