Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

From: "Lizhong Jin" <[email-masked]>
Date: Mon, 6 Jul 2015 09:58:44 +0800

Hi guys,
In the draft, it says:
Each network device receives the Path Tracking packet from its upstream device, makes a copy of it and passes the copy to its CPU.

That means the OAM packet will have different data path with the normal packet. The normal packet will not have "copy" action in the datapath. Then how could the OAM packet detect the liveness of the datapath? Did I missed something?

Regards
Lizhong

> -----Original Message-----
> From: Tom Herbert [mailto:[email-masked]]
> Sent: 2015年6月29日 23:37
> To: Deepak Kumar (dekumar)
> Cc: [email-masked]; Dapeng Liu
> Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network
> 
> On Mon, Jun 29, 2015 at 6:48 AM, Deepak Kumar (dekumar)
> <[email-masked]> wrote:
> > Hi Dapeng Liu,
> >
> > I support idea of hardware and controller based Path detection and
> > tracking where whole network is OAM capable and packet keeps forwarding
> in hardware.
> > I believe you guys presented this solution in ONS summit also.
> > You should explicitly call out in draft that this solution is not
> > backward compatible and all switches require to be OAM capable in
> > hardware to look at new bit to punt and copy the packet even in underlay.
> >
> VXLAN-GPE already defines an OAM bit. If all the hardware needs to be
> updated anyway, why not just move to that and avoid having to worry about
> the compatibility problem?
> 
> Thanks,
> Tom
> 
> > Thanks,
> > Deepak
> >
> > From: Dapeng Liu <[email-masked]>
> > Date: Saturday, June 20, 2015 at 10:04 AM
> > To: <[email-masked]>
> > Subject: [nvo3] New draft: Path Detection in VXLAN Overlay Network
> >
> > Hello all,
> >
> > We have submitted a draft for path detection in VXLAN  overlay network.
> > http://datatracker.ietf.org/doc/draft-pang-nvo3-vxlan-path-detection/
> >
> > The draft proposes a method for path detection in VXLAN network and it
> > defines the path detection packet format by using one reserve bit in
> > the VXLAN header.
> >
> > Comments & suggestions are welcomed.
> >
> >
> > --
> > Dapeng Liu
> >
> >
> > _______________________________________________
> > nvo3 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nvo3
> >
>

---

From: Liyizhou <[email-masked]>
Date: Mon, 6 Jul 2015 03:11:59 +0000

Hi Lizhong,

I believe "copy" here means replicate. The original data packet will be keeping going to the final destination.

Thank,
Yizhou

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Monday, July 06, 2015 9:59 AM
To: 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]; 'Dapeng Liu'
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi guys,
In the draft, it says:

Regards
Lizhong

> updated anyway, why not just move to that and avoid having to worry 
> about the compatibility problem?
> 
> Thanks,
> Tom
> 
> > Thanks,
> > Deepak
> >
> > The draft proposes a method for path detection in VXLAN network and 
> > it defines the path detection packet format by using one reserve bit 
> > in the VXLAN header.
> >

---

From: Shahram Davari <[email-masked]>
Date: Mon, 6 Jul 2015 03:22:39 +0000

How does a node know it should copy these packet to CPU?

Is it by looking inside the packet without terminating the outer layer? Why not use TTL expiry?

Regards,
Shahram

> On Jul 5, 2015, at 8:12 PM, Liyizhou <[email-masked]> wrote:
> 
> Hi Lizhong,
>

---

From: "Lizhong Jin" <[email-masked]>
Date: Mon, 6 Jul 2015 12:28:49 +0800

Hi Yizhou,
The OAM packet with "copy/replicate" action will have different logic in the chip with the normal data packet (e.g., the OAM packet will generate "copy/replicate" action by special logic, and replicate one copy from original packet, but normal data packet may not have these logic in some design). That means they will have different data path in the chip. And loss of OAM packet could not be ensured that normal data packet is also data, and normal packet loss could not infer that OAM packet will also be lost.

Lizhong

> From: Liyizhou [mailto:[email-masked]]
> Sent: 2015年7月6日 11:12
> To: Lizhong Jin; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
> Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network
> 
> Hi Lizhong,
> 
> Each network device receives the Path Tracking packet from its upstream
> device, makes a copy of it and passes the copy to its CPU.
> 
> That means the OAM packet will have different data path with the normal
> packet. The normal packet will not have "copy" action in the datapath. Then
> how could the OAM packet detect the liveness of the datapath? Did I missed
> something?
> 
> Regards
> Lizhong
>

---

From: Liyizhou <[email-masked]>
Date: Mon, 6 Jul 2015 06:18:46 +0000

Currently we are using ACL to capture it. Ideally hardware would be able to do it if a reserved bit is agreed to be used for that.

Why not TTL expiry only? In my understanding, such a approach is useful in:
1. Save sender's effort to repetitively sending packets with different TTL value. One packet will do.
2. Save sender's effort to collect the responses and compile the results. Centralized server will collect the packets and directly show it via some visualized network management tools.
3. Some network disables ICMP generations for security reason to prevent attacks or IP address disclosure. It is pretty common that ping some host is successful while tracert it leads to nowhere. 

Thanks,
Yizhou

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 11:23 AM
To: Liyizhou
Cc: Lizhong Jin; Tom Herbert; Deepak Kumar (dekumar); [email-masked]; Dapeng Liu
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Regards,
Shahram

---

From: Liyizhou <[email-masked]>
Date: Mon, 6 Jul 2015 06:58:34 +0000

Hi Lizhong,

No matter which way we use to capture a packet for further diagnose, it always involves additional operations. Here following real data path is guaranteed.  

If we take receiving packet along the path as positive, there may be little chance of false negative, e.g. data path is ok but replication of frame at some node is not working so that the central sever misinterprets it as a loss of the packet. However the next node will receive that packet and report it correctly in most of the cases. In extreme corner case, there is no more node along the path or all nodes have breaking replication function. Then it might be a false negative. I kind of think it happens in almost all the OAM mechanisms. Little chance like TTL=0 is not handled correctly, the response of ping is not generated correctly, etc.

I do not see a chance for false positive.

Thanks,
Yizhou

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Yizhou,

Lizhong

> I believe "copy" here means replicate. The original data packet will 
> be keeping going to the final destination.
> 
> Thank,
> Yizhou
> 
> Each network device receives the Path Tracking packet from its 
> upstream device, makes a copy of it and passes the copy to its CPU.
> 
> That means the OAM packet will have different data path with the 
> normal packet. The normal packet will not have "copy" action in the 
> datapath. Then how could the OAM packet detect the liveness of the 
> datapath? Did I missed something?
> 
> Regards
> Lizhong
> 
> > VXLAN-GPE already defines an OAM bit. If all the hardware needs to 
> > be updated anyway, why not just move to that and avoid having to 
> > worry about the compatibility problem?
> >
> > Thanks,
> > Tom
> >
> > > Thanks,
> > > Deepak
> > >
> > > http://datatracker.ietf.org/doc/draft-pang-nvo3-vxlan-path-detecti
> > > on
> > > /
> > >
> > > The draft proposes a method for path detection in VXLAN network 
> > > and it defines the path detection packet format by using one 
> > > reserve bit in the VXLAN header.
> > >

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 6 Jul 2015 21:21:14 +0800

If we use TTL, at least we could say the path between ingress and egress node is OK if OAM is OK. Because the OAM packet goes through exactly the same forwarding behavior as the data packets. But for the mechanims in this document, if OAM is OK, we could not say the data path is OK. We could only get to know that the link between the nodes along the path is OK. That's the difference between this new OAM and other OAM mechanism (e.g., TTL based).

Regards
Lizhong
 
From: Liyizhou
Date: 2015-07-06 14:58
To: Lizhong Jin; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
CC: [email-masked]; 'Dapeng Liu'; [email-masked]
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network
Hi Lizhong,

 
 
Thanks,
Yizhou
 
-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network
 
Hi Yizhou,
 
Lizhong

---

From: Shahram Davari <[email-masked]>
Date: Mon, 6 Jul 2015 18:42:22 +0000

Hi,

Adding a bit or not, doesn't make much difference, since your solution is based on Deep packet inspection. In order words without terminating a layer (IP in this case), you want to go deep in to the packet and check other layers for Copy to CPU action. This is not an architecturally sound design.  Some of the issues such layer violations will cause are:

- How to parse the VXLAN header when IP options are used? 
- How to parse VXLAN header when IPSEC is used?  

In addition as other have pointed out, there I no guarantee that these trace-route packet will follow exactly same path as data packets through the HW.

To fix these issue I suggest using TTL expiry method. Saving senders effort is not a good justification for layer violation. 

Thx
Shahram

-----Original Message-----
From: Liyizhou [mailto:[email-masked]] 
Sent: Sunday, July 05, 2015 11:19 PM
To: Shahram Davari
Cc: Lizhong Jin; Tom Herbert; Deepak Kumar (dekumar); [email-masked]; Dapeng Liu; [email-masked]
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Thanks,
Yizhou

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Monday, July 06, 2015 11:23 AM
To: Liyizhou
Cc: Lizhong Jin; Tom Herbert; Deepak Kumar (dekumar); [email-masked]; Dapeng Liu
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Regards,
Shahram

---

From: Shahram Davari <[email-masked]>
Date: Mon, 6 Jul 2015 19:01:01 +0000

I agree. You should use TTL. TTL use will also solve layer violation issue.

Thx
SD

From: nvo3 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 06, 2015 6:21 AM
To: liyizhou; tom; dekumar
Cc: [email-masked]; nvo3; maxpassion
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

________________________________
Regards
Lizhong

From: Liyizhou<mailto:[email-masked]>
Date: 2015-07-06 14:58
To: Lizhong Jin<mailto:[email-masked]>; 'Tom Herbert'<mailto:[email-masked]>; 'Deepak Kumar (dekumar)'<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network
Hi Lizhong,

Thanks,
Yizhou

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Yizhou,

Lizhong

> Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
> Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
> > Cc: [email-masked]<mailto:[email-masked]>; Dapeng Liu
> > <[email-masked]<mailto:[email-masked]>> wrote:
> > > Hi Dapeng Liu,
> > >
> > > From: Dapeng Liu <[email-masked]<mailto:[email-masked]>>
> > > To: <[email-masked]<mailto:[email-masked]>>
> > > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Mon, 6 Jul 2015 20:30:32 +0000

TTL use is fine and it works with existing hardware, but what this document is trying to provide another alternate approach where all devices are OAM capable and can look at O bit.
In carrier Ethernet, CFM also generates Link trace message (single message) and all mip reply with link trace reply from both ingress and egress MIP along the path.

As per my understanding what this draft is adding MIP in the ip network as whole network is OAM capable (especially datacenters), and the MIP are copying the packet and  cpu is filling the ingress and egress interface from actual forwarding copy of packet, along the path and redirect to controller but packet keeps forwarding like normal data packet.

R1 —— R2—— R3

Now if packet keeps forwarded in hardware in R2, and MIPs are placed on all interfaces, then you get correct ingress interface when R2 ingress mip is hit and correct egress interfce when R2 egress mip is hit and thus ingress and egress interface is provided.

With TTL approach, once packet is punted to cpu, we can also  figure out egress interface by calling hardware forwarding hashing algorithm, but then it’s cpu driven and not hardware copy of the exact data frame. Now forwarding hashing algorithm should be able to find the exact physical link if virtual links are present.

Thanks,
Deepak

From: Shahram Davari <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 6, 2015 at 12:01 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Li Yizhou <[email-masked]<mailto:[email-masked]>>, tom <[email-masked]<mailto:[email-masked]>>, dekumar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, nvo3 <[email-masked]<mailto:[email-masked]>>, maxpassion <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Thx
SD

From: nvo3 [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, July 06, 2015 6:21 AM
To: liyizhou; tom; dekumar
Cc: [email-masked]<mailto:[email-masked]>; nvo3; maxpassion
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Thanks,
Yizhou

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Yizhou,

Lizhong

---

From: Shahram Davari <[email-masked]>
Date: Mon, 6 Jul 2015 20:46:08 +0000

Deepak,

If TTL works then why invent a new method. Also this draft is very different from ETH Link Trace, since in Ethernet Link-Trace it is the MAC address that triggers the MIP lookup, while this draft requires deep packet inspection.

UP-MIP (that resides in egress interface) that uses TTL expiry is already defined for MPLS in RFC 7054 and can be used in IP tunnels as well.

Thx
Shahram

From: Deepak Kumar (dekumar) [mailto:[email-masked]]
Sent: Monday, July 06, 2015 1:31 PM
To: Shahram Davari; [email-masked]; liyizhou; tom
Cc: [email-masked]; nvo3; maxpassion
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

R1 -- R2-- R3

Thanks,
Deepak

Thx
SD

Thanks,
Yizhou

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Yizhou,

Lizhong

---

From: aldrin ietf <[email-masked]>
Date: Mon, 6 Jul 2015 13:59:06 -0700

Let me weigh in my comments.

- Do not think punt + forward is a good design. More importantly, the amount of traffic it generates in uncontrolled. Majority of the OAM mechanisms within IETF are source driven and I do not see the need, why we have to digress from that. If there is, it should be clearly laid out in the draft
- What if there exists a loop? This scenario should be documented
- In regards to security, redirecting responses to controller opens up can of worms. I am sure others could chime in here, as well. If the designed proposed in this draft opens up the responses to go, other than source, it just opens up the network to be exploited with just one OAM packet. 
- If the detection could be done with TTL mechanism (like others said), what is the rationale to introduce a requirement where, entirely new support needs to be added, without much of a gain.
- Lastly, what if some/many nodes do not support the OAM extensions, as proposed? 

-sam
> On Jul 6, 2015, at 1:30 PM, Deepak Kumar (dekumar) <[email-masked]> wrote:
> 
> From: Shahram Davari <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Li Yizhou <[email-masked] <mailto:[email-masked]>>, tom <[email-masked] <mailto:[email-masked]>>, dekumar <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, nvo3 <[email-masked] <mailto:[email-masked]>>, maxpassion <[email-masked] <mailto:[email-masked]>>
> From: nvo3 [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; nvo3; maxpassion
>> From: Liyizhou <mailto:[email-masked]>
>> Date: 2015-07-06 14:58
>> To: Lizhong Jin <mailto:[email-masked]>; 'Tom Herbert' <mailto:[email-masked]>; 'Deepak Kumar (dekumar)' <mailto:[email-masked]>
>> CC: [email-masked] <mailto:[email-masked]>; 'Dapeng Liu' <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
>> From: Lizhong Jin [mailto:[email-masked] <mailto:[email-masked]>]
>> Cc: [email-masked] <mailto:[email-masked]>; 'Dapeng Liu'
>> > From: Liyizhou [mailto:[email-masked] <mailto:[email-masked]>]
>> > Sent: 2015年7月6日 11:12
>> > Cc: [email-masked] <mailto:[email-masked]>; 'Dapeng Liu'
>> > From: nvo3 [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Lizhong Jin
>> > Cc: [email-masked] <mailto:[email-masked]>; 'Dapeng Liu'
>> > > From: Tom Herbert [mailto:[email-masked] <mailto:[email-masked]>]
>> > > Sent: 2015年6月29日 23:37
>> > > Cc: [email-masked] <mailto:[email-masked]>; Dapeng Liu
>> > > <[email-masked] <mailto:[email-masked]>> wrote:
>> > > > Hi Dapeng Liu,
>> > > >
>> > > > From: Dapeng Liu <[email-masked] <mailto:[email-masked]>>
>> > > > To: <[email-masked] <mailto:[email-masked]>>
>> > > > http://datatracker.ietf.org/doc/draft-pang-nvo3-vxlan-path-detecti <http://datatracker.ietf.org/doc/draft-pang-nvo3-vxlan-path-detecti>
>> > > > on
>> > > > /
>> > > >
>> > > > [email-masked] <mailto:[email-masked]>
>> > > > https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>
>> > > >
>> > >
>> > 
>> > 
>> > [email-masked] <mailto:[email-masked]>
>> > https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>
>>

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Mon, 6 Jul 2015 22:49:01 +0000

Hi Shahram,

From: Shahram Davari <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 6, 2015 at 1:46 PM
To: dekumar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Li Yizhou <[email-masked]<mailto:[email-masked]>>, tom <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, nvo3 <[email-masked]<mailto:[email-masked]>>, maxpassion <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Deepak,

Agreed. Yes ETH-LT is generated with multicast class2 DA and etype so any of these fields can be used to identify oam packet, In this scenario as we are inside tunnel and to track the packet, Deep packet inspection is required to identify OAM frame if we want to keep it flowing in hardware and identify ingress and egress interface without involving the cpu.

Thanks,
Deepak

Thx
Shahram

To: Shahram Davari; [email-masked]<mailto:[email-masked]>; liyizhou; tom

R1 —— R2—— R3

Thanks,
Deepak

Thx
SD

Thanks,
Yizhou

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Yizhou,

Lizhong

---

From: "Dacheng Zhang" <[email-masked]>
Date: Thu, 09 Jul 2015 12:11:09 +0800

Hi， Shahram：

According to the feedback from the DC manager, this solution is more
efficient. Assume a scenario, there are n paths and the length of each path
is l. Using TTL, n*l packets needs to be generated to check all the paths
while n packets needs to be generated in our solution.

发件人:  nvo3 <[email-masked]> on behalf of "Deepak Kumar (dekumar)"
<[email-masked]>
日期:  2015年7月7日 星期二 上午6:49
至:  Shahram Davari <[email-masked]>, "[email-masked]"
<[email-masked]>, liyizhou <[email-masked]>, tom
<[email-masked]>
抄送:  "[email-masked]"
<[email-masked]>, nvo3 <[email-masked]>,
maxpassion <[email-masked]>
主题:  Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Shahram,

From: Shahram Davari <[email-masked]>
Date: Monday, July 6, 2015 at 1:46 PM
To: dekumar <[email-masked]>, "[email-masked]"
<[email-masked]>, Li Yizhou <[email-masked]>, tom
<[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, nvo3 <[email-masked]>,
maxpassion <[email-masked]>
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Deepak,
 
If TTL works then why invent a new method. Also this draft is very different
from ETH Link Trace, since in Ethernet Link-Trace it is the MAC address that
triggers the MIP lookup, while this draft requires deep packet inspection.

Agreed. Yes ETH-LT is generated with multicast class2 DA and etype so any of
these fields can be used to identify oam packet, In this scenario as we are
inside tunnel and to track the packet, Deep packet inspection is required to
identify OAM frame if we want to keep it flowing in hardware and identify
ingress and egress interface without involving the cpu.

Thanks,
Deepak

UP-MIP (that resides in egress interface) that uses TTL expiry is already
defined for MPLS in RFC 7054 and can be used in IP tunnels as well.
 
Thx
Shahram

TTL use is fine and it works with existing hardware, but what this document
is trying to provide another alternate approach where all devices are OAM
capable and can look at O bit.

In carrier Ethernet, CFM also generates Link trace message (single message)
and all mip reply with link trace reply from both ingress and egress MIP
along the path.

As per my understanding what this draft is adding MIP in the ip network as
whole network is OAM capable (especially datacenters), and the MIP are
copying the packet and  cpu is filling the ingress and egress interface from
actual forwarding copy of packet, along the path and redirect to controller
but packet keeps forwarding like normal data packet.

R1 —— R2—— R3

Now if packet keeps forwarded in hardware in R2, and MIPs are placed on all
interfaces, then you get correct ingress interface when R2 ingress mip is
hit and correct egress interfce when R2 egress mip is hit and thus ingress
and egress interface is provided.

With TTL approach, once packet is punted to cpu, we can also  figure out
egress interface by calling hardware forwarding hashing algorithm, but then
it’s cpu driven and not hardware copy of the exact data frame. Now
forwarding hashing algorithm should be able to find the exact physical link
if virtual links are present.

Thanks,

Deepak

From: Shahram Davari <[email-masked]>
Date: Monday, July 6, 2015 at 12:01 PM
To: "[email-masked]" <[email-masked]>, Li Yizhou
<[email-masked]>, tom <[email-masked]>, dekumar
<[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, nvo3 <[email-masked]>,
maxpassion <[email-masked]>
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Thx
SD

If we use TTL, at least we could say the path between ingress and egress
node is OK if OAM is OK. Because the OAM packet goes through exactly the
same forwarding behavior as the data packets. But for the mechanims in this
document, if OAM is OK, we could not say the data path is OK. We could only
get to know that the link between the nodes along the path is OK. That's the
difference between this new OAM and other OAM mechanism (e.g., TTL based).

Regards

Lizhong
> To: Lizhong Jin <mailto:[email-masked]> ; 'Tom Herbert'
> <mailto:[email-masked]> ; 'Deepak Kumar (dekumar)'
> <mailto:[email-masked]>
> 
> CC: [email-masked]; 'Dapeng Liu' <mailto:[email-masked]> ;
> [email-masked]
> 
> No matter which way we use to capture a packet for further diagnose, it always
> involves additional operations. Here following real data path is guaranteed.
> 
>  
> 
> If we take receiving packet along the path as positive, there may be little
> chance of false negative, e.g. data path is ok but replication of frame at
> some node is not working so that the central sever misinterprets it as a loss
> of the packet. However the next node will receive that packet and report it
> correctly in most of the cases. In extreme corner case, there is no more node
> along the path or all nodes have breaking replication function. Then it might
> be a false negative. I kind of think it happens in almost all the OAM
> mechanisms. Little chance like TTL=0 is not handled correctly, the response of
> ping is not generated correctly, etc.
> 
>  
> 
> The OAM packet with "copy/replicate" action will have different logic in the
> chip with the normal data packet (e.g., the OAM packet will generate
> "copy/replicate" action by special logic, and replicate one copy from original
> packet, but normal data packet may not have these logic in some design). That
> means they will have different data path in the chip. And loss of OAM packet
> could not be ensured that normal data packet is also data, and normal packet
> loss could not infer that OAM packet will also be lost.
> 
>  
> 
> Lizhong
> 
>  
> 
>>> > > Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay
> 
>>> > > Network
> 
>>> > >
> 
>>>> > > > tracking where whole network is OAM capable and packet keeps
> 
>>>> > > > forwarding
> 
>>> > > in hardware.
> 
_______________________________________________ nvo3 mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Saumya Dikshit (sadikshi)" <[email-masked]>
Date: Fri, 17 Jul 2015 08:16:01 +0000

Hi Dacheng,

How is it ensured that incrementing the udp source port (outer header encap) will detect ALL ecmp paths ?
As the ecmp hash algorithm may not be a standard one across device vendors. AFAIK, it’s more of proprietary.

Thanks
Saumya.

From: Dacheng Zhang <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 9, 2015 at 9:41 AM
To: "Deepak Kumar (dekumar)" <[email-masked]<mailto:[email-masked]>>, Shahram Davari <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, liyizhou <[email-masked]<mailto:[email-masked]>>, tom <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, nvo3 <[email-masked]<mailto:[email-masked]>>, maxpassion <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi， Shahram：

According to the feedback from the DC manager, this solution is more efficient. Assume a scenario, there are n paths and the length of each path is l. Using TTL, n*l packets needs to be generated to check all the paths while n packets needs to be generated in our solution.

发件人: nvo3 <[email-masked]<mailto:[email-masked]>> on behalf of "Deepak Kumar (dekumar)" <[email-masked]<mailto:[email-masked]>>
日期: 2015年7月7日 星期二 上午6:49
至: Shahram Davari <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, liyizhou <[email-masked]<mailto:[email-masked]>>, tom <[email-masked]<mailto:[email-masked]>>
抄送: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, nvo3 <[email-masked]<mailto:[email-masked]>>, maxpassion <[email-masked]<mailto:[email-masked]>>
主题: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Shahram,

Deepak,

Thanks,
Deepak

Thx
Shahram

R1 —— R2—— R3

Thanks,
Deepak

Thx
SD

Thanks,
Yizhou

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Yizhou,

Lizhong

> > > Comments & suggestions are welcomed.

_______________________________________________ nvo3 mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Shahram Davari <[email-masked]>
Date: Fri, 17 Jul 2015 13:46:36 +0000

Hi

Why is efficient important? I am assuming trace route is used for diagnostic purpose. So a DC manager will probably run only a few of these trace routes at a time.

Regards,
Shahram

On Jul 8, 2015, at 9:11 PM, Dacheng Zhang <[email-masked]<mailto:[email-masked]>> wrote:

Hi， Shahram：

Hi Shahram,

Deepak,

Thanks,
Deepak

Thx
Shahram

R1 ―― R2―― R3

Thanks,
Deepak

Thx
SD

Thanks,
Yizhou

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Yizhou,

Lizhong

---

From: "Dacheng Zhang" <[email-masked]>
Date: Sat, 18 Jul 2015 10:53:32 +0800

Hi, Saumya:

This is a good question. I think you are right, and here is a problem. We
should change this part according to your comments in the next version.

Thanks a lot! ^_^

Dacheng

发件人:  "Saumya Dikshit (sadikshi)" <[email-masked]>
日期:  2015年7月17日 星期五 下午4:16
至:  dacheng de <[email-masked]>, "Deepak Kumar (dekumar)"
<[email-masked]>, Shahram Davari <[email-masked]>,
"[email-masked]" <[email-masked]>, liyizhou <[email-masked]>,
tom <[email-masked]>
抄送:  "[email-masked]"
<[email-masked]>, nvo3 <[email-masked]>,
maxpassion <[email-masked]>
主题:  Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Dacheng,

How is it ensured that incrementing the udp source port (outer header encap)
will detect ALL ecmp paths ?
As the ecmp hash algorithm may not be a standard one across device vendors.
AFAIK, it’s more of proprietary.

Thanks
Saumya.

From: Dacheng Zhang <[email-masked]>
Date: Thursday, July 9, 2015 at 9:41 AM
To: "Deepak Kumar (dekumar)" <[email-masked]>, Shahram Davari
<[email-masked]>, "[email-masked]" <[email-masked]>, liyizhou
<[email-masked]>, tom <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>, nvo3 <[email-masked]>,
maxpassion <[email-masked]>
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi， Shahram：

Hi Shahram,

Deepak,

Thanks,
Deepak

Thx
Shahram

R1 —— R2—— R3

Thanks,

Deepak

 
Thx
SD

Regards

Lizhong

---

From: "Dacheng Zhang" <[email-masked]>
Date: Mon, 20 Jul 2015 01:42:48 +0800

Hi Sam,

Thanks for providing detail comments, please see inline [Dacheng].

Cheers

Dacheng

发件人:  nvo3 <[email-masked]> on behalf of aldrin ietf
<[email-masked]>
日期:  2015年7月6日 星期一 下午10:59
至:  "Deepak Kumar (dekumar)" <[email-masked]>
抄送:  Shahram Davari <[email-masked]>, maxpassion
<[email-masked]>, tom <[email-masked]>, nvo3 <[email-masked]>,
"[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>, liyizhou
<[email-masked]>
主题:  Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

- Do not think punt + forward is a good design. More importantly, the amount
of traffic it generates in uncontrolled. Majority of the OAM mechanisms
within IETF are source driven and I do not see the need, why we have to
digress from that. If there is, it should be clearly laid out in the draft

[Dacheng] punt+ forward logic packet always go through the right data path
without any modification.  In our solution, we have one packet generated in
the data path and all the replies happen on the out of band controller path
and thus OAM traffic is low compared to TTL expiry method.

Lets take example of Datacenter with 800 Leafs and before we allow customer
VMs traffic to start an operational team want to verify all the data path in
the network so they have confidence in the network.
Now In our design is faster to find all the path, why as we are not source
driven to wait for response from the Leafs and we generate less traffic in
the data path.

Eg:- 6 hop network, single vtep – vtep our solution has 1 OAM frame. If we
have 32 path in the network then we will send 32 Frames once they know all
the sport by which new path is exercised.
TTL solution even if it’s Out of Band has 6 Send frames at least. Now if we
have 32 path in the network. In case of ECMP it’s 32 x 6 Frames = 192
Frames.

Now 800 VTEP you can see the combination and increase of OAM frames in the
fabric between 2 solutions.

Our Solution require looking for “PD” bit similar to proposed in Vxlan-gpe
except position of this bit is different. In our solution we need all the
switches to be aware of this, but if switches are not aware backup mechanism
proposed other draft can be used.

Also our method reduces cpu and memory load on controller, because it has to
generate 6 time less frames per Vtep in the network.

[Dacheng] We are following the exact packet format as VxLan header and not
modifying the underlay of Vxlan Header except 1 bit so TTL loop should be
caught by underlay TTL expiry.

- In regards to security, redirecting responses to controller opens up can
of worms. I am sure others could chime in here, as well. If the designed
proposed in this draft opens up the responses to go, other than source, it
just opens up the network to be exploited with just one OAM packet.

[Dacheng] Between Controller and Switches security can be established by
existing mechanism.

Lets take for example OAM can’t be started from ports which are not
connected to controller and even reply are sent on these ports. Again these
ports are dedicated port and controller and switch should use existing
security mechanism to configure and packet insert and response for OAM.

If this is not satisfactory Authentication TLV can be added to message.

- If the detection could be done with TTL mechanism (like others said), what
is the rationale to introduce a requirement where, entirely new support
needs to be added, without much of a gain.

[Dacheng] We can provide our deployment results. Also we have answered it
above.

- Lastly, what if some/many nodes do not support the OAM extensions, as
proposed? 

[Dacheng] Again it’s controller functionality, Controller can understand
which nodes don’t support this functionality and in that scenario packet is
never punted but still forward in data path.
Also controller in this scenario can decide not to use our mechanism but to
fallback to existing OAM mechanism or new mechanism which are backward
compatible.

Thanks,

-sam
> TTL use is fine and it works with existing hardware, but what this document is
> trying to provide another alternate approach where all devices are OAM capable
> and can look at O bit.
> and all mip reply with link trace reply from both ingress and egress MIP along
> the path.
> 
> whole network is OAM capable (especially datacenters), and the MIP are copying
> the packet and  cpu is filling the ingress and egress interface from actual
> forwarding copy of packet, along the path and redirect to controller but
> packet keeps forwarding like normal data packet.
> 
> R1 —— R2—— R3
> 
> interfaces, then you get correct ingress interface when R2 ingress mip is hit
> and correct egress interfce when R2 egress mip is hit and thus ingress and
> egress interface is provided.
> 
> it’s cpu driven and not hardware copy of the exact data frame. Now forwarding
> hashing algorithm should be able to find the exact physical link if virtual
> links are present.
> 
> Thanks,
> Deepak
> 
> <[email-masked]>, tom <[email-masked]>, dekumar <[email-masked]>
> If we use TTL, at least we could say the path between ingress and egress node
> is OK if OAM is OK. Because the OAM packet goes through exactly the same
> forwarding behavior as the data packets. But for the mechanims in this
>> No matter which way we use to capture a packet for further diagnose, it
>> always involves additional operations. Here following real data path is
>> guaranteed. 
>>  
>> mechanisms. Little chance like TTL=0 is not handled correctly, the response
>> of ping is not generated correctly, etc.
>>  
>> "copy/replicate" action by special logic, and replicate one copy from
>> original packet, but normal data packet may not have these logic in some
>> design). That means they will have different data path in the chip. And loss
>> of OAM packet could not be ensured that normal data packet is also data, and
>> normal packet loss could not infer that OAM packet will also be lost.
>>  
>> Lizhong
>>

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Sun, 19 Jul 2015 17:57:05 +0000

Hi Shahram,

In large scale overlay network with multiple ecmp path, one of the solution draft proposes is also Path Traversal (which is all the path between 2 Vteps).
In this scenario efficiency of OAM message is very important and also OAM packets shouldn’t be high that it start taking bandwidth out of Fabric.

In controller based method, single OAM message is only going in the Datapath.
In TTL expiry without controller we have x number of hope generation and same number of reply in in-band data traffic.
Now this process is repeated for all ECMPs and all Vteps this number will become high and it will take more time for this whole process to complete.

Thanks,
Deepak

From: Shahram Davari <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 17, 2015 at 6:46 AM
To: Dacheng Zhang <[email-masked]<mailto:[email-masked]>>
Cc: maxpassion <[email-masked]<mailto:[email-masked]>>, dekumar <[email-masked]<mailto:[email-masked]>>, tom <[email-masked]<mailto:[email-masked]>>, nvo3 <[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]>>, Li Yizhou <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi

Regards,
Shahram

Hi， Shahram：

Hi Shahram,

Deepak,

Thanks,
Deepak

Thx
Shahram

R1 —— R2—— R3

Thanks,
Deepak

Thx
SD

Thanks,
Yizhou

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Yizhou,

Lizhong

---

From: IETF <[email-masked]>
Date: Mon, 20 Jul 2015 01:33:49 -0700

Inline for my comments with %sam.
> On Jul 19, 2015, at 10:42 AM, Dacheng Zhang <[email-masked]> wrote:
> 
> Hi Sam,
> 
> 发件人: nvo3 <[email-masked] <mailto:[email-masked]>> on behalf of aldrin ietf <[email-masked] <mailto:[email-masked]>>
> 至: "Deepak Kumar (dekumar)" <[email-masked] <mailto:[email-masked]>>
> 抄送: Shahram Davari <[email-masked] <mailto:[email-masked]>>, maxpassion <[email-masked] <mailto:[email-masked]>>, tom <[email-masked] <mailto:[email-masked]>>, nvo3 <[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]>>, liyizhou <[email-masked] <mailto:[email-masked]>>
> [Dacheng] punt+ forward logic packet always go through the right data path without any modification.  In our solution, we have one packet generated in the data path and all the replies happen on the out of band controller path and thus OAM traffic is low compared to TTL expiry method.
%sam - If it is out-of-band as you say, why are you worried about 1 packet vs many packets? I do not subscribe to this as a real problem as the existing mechanism already solves without doing the h/w enhancement this draft asks. 
> 
> Lets take example of Datacenter with 800 Leafs and before we allow customer VMs traffic to start an operational team want to verify all the data path in the network so they have confidence in the network.
> Now In our design is faster to find all the path, why as we are not source driven to wait for response from the Leafs and we generate less traffic in the data path.
%sam - Leaf? Are you talking about multicast network or individual destination addr/prefixes? Secondly, are you testing connectivity to those destination addresses or traces to those addresses? I do not subscribe to the case you are eluding to that number of packets by existing source driven is bottleneck to discover whether connectivity is established or not. If you use this model, I’d argue that, when destination nodes (leaf in your terms) are coming up, it would infact generate more traffic as the packets from intermediate routers generate response packets for every ping packet you send, while the connectivity is being verified every time. But if you say, I won’t set the replication+forward bit in that case, then the purpose of doing this enhancement is moot.
> 
> Eg:- 6 hop network, single vtep – vtep our solution has 1 OAM frame. If we have 32 path in the network then we will send 32 Frames once they know all the sport by which new path is exercised.
> TTL solution even if it’s Out of Band has 6 Send frames at least. Now if we have 32 path in the network. In case of ECMP it’s 32 x 6 Frames = 192 Frames.
> 
> Now 800 VTEP you can see the combination and increase of OAM frames in the fabric between 2 solutions.
%sam - As I described above, if you are trying to do, while the network is coming up, you will generate more packets than you describe above, as you will be repeating multiple times to check the connectivity.
> 
> Our Solution require looking for “PD” bit similar to proposed in Vxlan-gpe except position of this bit is different. In our solution we need all the switches to be aware of this, but if switches are not aware backup mechanism proposed other draft can be used.
> 
> Also our method reduces cpu and memory load on controller, because it has to generate 6 time less frames per Vtep in the network.
> 
> 
> [Dacheng] We are following the exact packet format as VxLan header and not modifying the underlay of Vxlan Header except 1 bit so TTL loop should be caught by underlay TTL expiry.
%sam - You lost me there. How does underlay takes care of loop and avoid packet not getting replicate+forward?
> [Dacheng] Between Controller and Switches security can be established by existing mechanism.
> 
> Lets take for example OAM can’t be started from ports which are not connected to controller and even reply are sent on these ports. Again these ports are dedicated port and controller and switch should use existing security mechanism to configure and packet insert and response for OAM.
> 
%sam - How you implement solution is secondary(second step). When you are redirecting the the responses to an outside entity and other than source, with your proposed mechanism, one spoofed packet could sniff out entire network. This is to be clearly documented and implications are to be identified as well.
> [Dacheng] We can provide our deployment results. Also we have answered it above.
%sam - Sure. I’d like the requirement to be justified before solution could deliberated upon. 
> [Dacheng] Again it’s controller functionality, Controller can understand which nodes don’t support this functionality and in that scenario packet is never punted but still forward in data path.
%sam - How does controller determine that?  

> Also controller in this scenario can decide not to use our mechanism but to fallback to existing OAM mechanism or new mechanism which are backward compatible.
%sam - That is exactly my point. If existing mechanism already be able to do that, why invent a new solution? I do not think number of packets and efficiency(which I do not agree either) justifies a new solution, additional complexity, limited to specific model this solution could be administered, etc.

cheers
-sam
> 
> Thanks,
> 
> -sam
>> On Jul 6, 2015, at 1:30 PM, Deepak Kumar (dekumar) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> _______________________________________________ nvo3 mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>

---

From: Liyizhou <[email-masked]>
Date: Mon, 20 Jul 2015 14:59:49 +0000

Hi Shahram,

I think there are some other aspects why such a approach is required. In a DC, customer (normally the provider) has their own controller which understand their services best (than vendors). They know the traffic pattern, the flow distribution diversity, etc. Such customer needs the highly controllable OAM test as a supplement to conventional way. For example, they may record the hash values which spread the traffic over all the possible paths to minimize the effort for exhaustive path traversal. They may be requiring some information from the intermediate nodes, e.g. counter values, to be sent to the controller for further analysis.

Such an approach provides a way to make it possible for these customized features. It is not supposed to be a replacement of conventional ping/tracert like tools. It is an optional way to give higher manageability that customers have asked for.

BTW even for TTL expiry approach, some DC network disables ICMP to avoid possible security attacks. From that aspect, it is not an always-on solution. (though I agree tracert like tool should be always available to users).

Thanks,
Yizhou

发件人: nvo3 [mailto:[email-masked]] 代表 Shahram Davari
发送时间: 2015年7月17日 21:47
收件人: Dacheng Zhang
抄送: maxpassion; Deepak Kumar (dekumar); tom; nvo3; [email-masked]; [email-masked]; Liyizhou
主题: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi

Regards,
Shahram

Hi Shahram,

Deepak,

Thanks,
Deepak

Thx
Shahram

R1 ―― R2―― R3

Thanks,
Deepak

Thx
SD

Thanks,
Yizhou

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Yizhou,

Lizhong

---

From: IETF <[email-masked]>
Date: Mon, 20 Jul 2015 08:22:23 -0700

Hi Yizhou et al,

Taking one step back, basically this draft proposes new requirements, which I believe are being questioned by myself, Shahram and others. Neither these new requirements are captured in this draft or OAM requirement draft. IMO,  these new requirements should be documented clearly and reviewed as part of that. Having a solution, without agreed requirement is not an ideal way.

cheers
-sam

> On Jul 20, 2015, at 7:59 AM, Liyizhou <[email-masked]> wrote:
> 
> Hi Shahram,
>  
> On Jul 8, 2015, at 9:11 PM, Dacheng Zhang <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi， Shahram：
>  
> 发件人: nvo3 <[email-masked] <mailto:[email-masked]>> on behalf of "Deepak Kumar (dekumar)" <[email-masked] <mailto:[email-masked]>>
> 日期: 2015年7月7日 星期二 上午6:49
> 至: Shahram Davari <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, liyizhou <[email-masked] <mailto:[email-masked]>>, tom <[email-masked] <mailto:[email-masked]>>
> 抄送: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, nvo3 <[email-masked] <mailto:[email-masked]>>, maxpassion <[email-masked] <mailto:[email-masked]>>
> To: dekumar <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Li Yizhou <[email-masked] <mailto:[email-masked]>>, tom <[email-masked] <mailto:[email-masked]>>
> From: Deepak Kumar (dekumar) [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Shahram Davari; [email-masked] <mailto:[email-masked]>; liyizhou; tom
> _______________________________________________ nvo3 mailing list [email-masked] <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>
> https://www.ietf.org/mailman/listinfo/nvo3 <https://www.ietf.org/mailman/listinfo/nvo3>_______________________________________________
> nvo3 mailing list
> [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Mon, 20 Jul 2015 16:31:41 +0000

Hi,

What is the relationship between your draft and the controller based functions. You could also run TTL expiry method via controller initiated method.

Thx
Shahram

From: Liyizhou [mailto:[email-masked]]
Sent: Monday, July 20, 2015 8:00 AM
To: Shahram Davari; Dacheng Zhang
Cc: maxpassion; Deepak Kumar (dekumar); tom; nvo3; [email-masked]; [email-masked]
Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Shahram,

Thanks,
Yizhou

发件人: nvo3 [mailto:[email-masked]] 代表 Shahram Davari
发送时间: 2015年7月17日 21:47
收件人: Dacheng Zhang
抄送: maxpassion; Deepak Kumar (dekumar); tom; nvo3; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Liyizhou
主题: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi

Regards,
Shahram

Hi Shahram,

Deepak,

Thanks,
Deepak

Thx
Shahram

R1 ―― R2―― R3

Thanks,
Deepak

Thx
SD

Thanks,
Yizhou

-----Original Message-----
From: Lizhong Jin [mailto:[email-masked]]
Sent: Monday, July 06, 2015 12:29 PM
To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)'
Cc: [email-masked]<mailto:[email-masked]>; 'Dapeng Liu'
Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network

Hi Yizhou,

Lizhong