Subject: Re: [nvo3] Application of a time slot in this ietf meeting//Re: New draft: Path Detection in VXLAN Overlay Network

From: "Dacheng Zhang" <[email-masked]>
Date: Thu, 02 Jul 2015 00:04:13 +0800

HI, Shahram:

Thanks for the comments.

See my reply inline please..

Cheers

Dacheng

发件人:  Shahram Davari <[email-masked]>
日期:  2015年6月30日 星期二 上午2:12
至:  dacheng de <[email-masked]>
抄送:  "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]"
<[email-masked]>, Dapeng Liu <[email-masked]>
主题:  RE: [nvo3] Application of a time slot in this ietf meeting//Re: New
draft: Path Detection in VXLAN Overlay Network

I read your draft and I don't think it can get the information that you
claim it does.

For example you have ingress interface TLV to record the ingress port of the
ingress PE. First of all this interface is already communicated by the
controller to the Ingress PE.

Ingress/egress interface are refer to the interfaces on the data path. The
controller will use another interface to communicate with the PE
 
SD> What I mean is that the controller is asking the PE to inject this test
packet to a tunnel via a specific PE interface. So the controller already
knows which PE interfaces the packet is going to use.

Dacheng\ That is why For the ingress PE, only EIID is mandatory.

Secondly if you want to test the Correct IP forwarding you can just use BFD
for the outer IP. If you like to use UDP, you could do BFD over UDP over IP.

BFD works at layer 2. It’s mainly used to test whether the layer 2 data path
is connected. In contrast, our method is focusing on the tracing function.
(Our solution can help find out which switch on the path is broken.)
 
SD> The way you have defined it does not test anything in L2, since your
packet is not exercising any L2 forwarding. Your packet is L3 forwarded all
the way.

Dacheng\  I am trying to understand your point and please correct me if I am
wrong. The purpose of this work is to check the error of paths over a l3
network. (Pleas see figure 1.)

Thirdly, your draft can't get the egress interface information of the egress
PE, since there is nothing (No MAC or IP address) in your VXLAN payload that
can be forwarded by the egress PE to the egress interface.

Two TLV (IIID/EIID) could be used to record the ingress/egress interfaces ID
of current router the OAM packet is  flowing through. For the ingress PE,
EIID is mandatory while for the egress PE IIID is mandatory. For the
intermediate router, both IIID and EIID are mandatory. So, for the egress,
EIID does not have to be transported to the controller.
 
SD> I know you have TLV. But what I mean is that there is nothing in your
draft that makes your packets to be L2 forwarded. For example you are not
doing any (VXLAN/VNI forwarding) of your packet. As an example assume you
packet arrives at the Final Egress PE.  The Egress PE can’t forward this
packet based on the IP destination address since it is 127/8.

Dacheng\ Ok, our objective is to check the paths between vteps. So, the
egress PE does not have to forward this packet to the tenant. Note we
mentioned that  for the egress PE only IIID is mandatory.

Fourthly the path trace that you describe does not work. How does an
intermediate router know it has to send a copy of this packet to CPU? The
only method is to use TTL expiry, which already exists in IP trace route.

In our method, o bit in VxLAN is used to indicate it’s a OAM packet, which
should be copy to CPU. One OAM packet is able to trace n devices on the
path, while TTL expire method needs n OAM packets to trace. Of course if you
assume that the intermediate devices do not support our solution, our
mechanism will not work properly then.
 
SD> Are you suggesting that the intermediate routers need to do deep packet
inspection and after finding this magical bit copy it to CPU? This is a
layer violation and should NOT be done.  You should not make decision on any
layer when layers above it are not terminated.
 
Basically you are expecting intermediate routers to look in to the packet,
skip outer Ethernet, Skip IP, check IP payload is UDP, check UDP-Dest port
is VXLAN, then check a specific bit in VXLAN header in order to decide to
copy to CPU or not.  This is architecturally wrong by any means.

Dacheng\ Yes, we expect the intermediate routers can look into the packet.
Our experiments have shown that this solution works very well and
significantly reduce the complexity of detecting errors in complex networks.
Hope other people can give us some comments on this argument.

Regards, 

Shahram

On Jun 26, 2015, at 10:15 PM, Dacheng Zhang <[email-masked]>
wrote:
> 
> Dear chairs:
> 
>  
> 
> Can we get a time slot during the nvo3 session in Prague to discuss this
> draft? Dapeng Liu from Alibaba will be the presenter. 15 minutes would be good
> enough. 
> 
>  
> 
> Cheers
> 
>  
> 
> Dacheng
> 
>  
> 
> 发件人: Dapeng Liu <[email-masked]>
> 日期: 2015年6月21日星期日上午1:04
> 至: <[email-masked]>
> 主题: [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
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Dapeng Liu <[email-masked]>
Date: Sat, 4 Jul 2015 01:23:51 +0800

在 2015年7月2日 星期四，上午12:04，Dacheng Zhang 写道：

> 发件人: Shahram Davari <[email-masked] (mailto:[email-masked])>
> 至: dacheng de <[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])>, "[email-masked] (mailto:[email-masked])" <[email-masked] (mailto:[email-masked])>, Dapeng Liu <[email-masked] (mailto:[email-masked])>
> 主题: RE: [nvo3] Application of a time slot in this ietf meeting//Re: New draft: Path Detection in VXLAN Overlay Network
>  
>  
>  
>   
> I read your draft and I don't think it can get the information that you claim it does.
>  
>   
>  
> For example you have ingress interface TLV to record the ingress port of the ingress PE. First of all this interface is already communicated by the controller to the Ingress PE.
>  
>  
>  
>   
>  
> Ingress/egress interface are refer to the interfaces on the data path. The controller will use another interface to communicate with the PE
>   
> SD> What I mean is that the controller is asking the PE to inject this test packet to a tunnel via a specific PE interface. So the controller already knows which PE interfaces the packet is going to use.
>  
>  
>  
>  
>  
> Secondly if you want to test the Correct IP forwarding you can just use BFD for the outer IP. If you like to use UDP, you could do BFD over UDP over IP.
>  
>  
>  
> BFD works at layer 2. It’s mainly used to test whether the layer 2 data path is connected. In contrast, our method is focusing on the tracing function. (Our solution can help find out which switch on the path is broken.)
>   
> SD> The way you have defined it does not test anything in L2, since your packet is not exercising any L2 forwarding. Your packet is L3 forwarded all the way.
>  
>  
>  
>  
>  
> Dacheng\  I am trying to understand your point and please correct me if I am wrong. The purpose of this work is to check the error of paths over a l3 network. (Pleas see figure 1.)
>  
>  
>   
>  
> Thirdly, your draft can't get the egress interface information of the egress PE, since there is nothing (No MAC or IP address) in your VXLAN payload that can be forwarded by the egress PE to the egress interface.
>  
>  
>  
> Two TLV (IIID/EIID) could be used to record the ingress/egress interfaces ID of current router the OAM packet is  flowing through. For the ingress PE, EIID is mandatory while for the egress PE IIID is mandatory. For the intermediate router, both IIID and EIID are mandatory. So, for the egress, EIID does not have to be transported to the controller.  
>   
> SD> I know you have TLV. But what I mean is that there is nothing in your draft that makes your packets to be L2 forwarded. For example you are not doing any (VXLAN/VNI forwarding) of your packet. As an example assume you packet arrives at the Final Egress PE.  The Egress PE can’t forward this packet based on the IP destination address since it is 127/8.
>  
>  
>  
>  
>  
> Dacheng\ Ok, our objective is to check the paths between vteps. So, the egress PE does not have to forward this packet to the tenant. Note we mentioned that  for the egress PE only IIID is mandatory.  
>  
>  
>   
>  
> Fourthly the path trace that you describe does not work. How does an intermediate router know it has to send a copy of this packet to CPU? The only method is to use TTL expiry, which already exists in IP trace route.
>  
>  
>  
>   
>  
> In our method, o bit in VxLAN is used to indicate it’s a OAM packet, which should be copy to CPU. One OAM packet is able to trace n devices on the path, while TTL expire method needs n OAM packets to trace. Of course if you assume that the intermediate devices do not support our solution, our mechanism will not work properly then.  
>   
> SD> Are you suggesting that the intermediate routers need to do deep packet inspection and after finding this magical bit copy it to CPU? This is a layer violation and should NOT be done.  You should not make decision on any layer when layers above it are not terminated.  
>   
> Basically you are expecting intermediate routers to look in to the packet, skip outer Ethernet, Skip IP, check IP payload is UDP, check UDP-Dest port is VXLAN, then check a specific bit in VXLAN header in order to decide to copy to CPU or not.  This is architecturally wrong by any means.
>  
>  
>  
>  
>  
> Dacheng\ Yes, we expect the intermediate routers can look into the packet.  Our experiments have shown that this solution works very well and significantly reduce the complexity of detecting errors in complex networks. Hope other people can give us some comments on this argument.  

[Dapeng Liu] Yes. The deployment assumption in the draft is all the forwarding equipment should support VXLAN and this draft proposes a VXLAN function extension to support the OAM mechanism described in the draft.

----
Dapeng Liu   

>  
>  
>   
>  
>  
> Regards,  
> Shahram
>  
>   
>  
>  
>  
> On Jun 26, 2015, at 10:15 PM, Dacheng Zhang <[email-masked] (mailto:[email-masked])> wrote:
> > Dear chairs:
> >  
> >   
> >  
> > Can we get a time slot during the nvo3 session in Prague to discuss this draft? Dapeng Liu from Alibaba will be the presenter. 15 minutes would be good enough.  
> >  
> >   
> >  
> > Cheers
> >  
> >   
> >  
> > Dacheng
> >  
> >   
> >  
> > 发件人: Dapeng Liu <[email-masked] (mailto:[email-masked])>
> > 日期: 2015年6月21日星期日上午1:04
> > 至: <[email-masked] (mailto:[email-masked])>
> > 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.
> >  
> >   
> >  
> > _______________________________________________ nvo3 mailing list [email-masked] (mailto:[email-masked]) https://www.ietf.org/mailman/listinfo/nvo3
> >  
>  
> > [email-masked] (mailto:[email-masked])

---

From: Tom Herbert <[email-masked]>
Date: Fri, 3 Jul 2015 17:06:07 -0700

"The Extendable TLV field contains two TLVs. Both of them are set by
the network devices along the transport path."-- this might be
problematic. From draft-ietf-tsvwg-port-use-11.txt:  "Ultimately, port
numbers numbers indicate services only to the endpoints, and any
intermediate device that assigns meaning to a value can be
incorrect.". A host may legitimately send UDP packets to the VXLAN
port number that aren't actually VXLAN, so if intermediate devices are
modifying these packets based just on destination couldn't this result
in data corruption? Magic numbers like those defined in SPUD or
https://tools.ietf.org/html/draft-herbert-udp-magic-numbers-00 could
mitigate such an issue.

Tom

On Fri, Jul 3, 2015 at 10:23 AM, Dapeng Liu <[email-masked]> wrote:
> [Dapeng Liu] Yes. The deployment assumption in the draft is all the
> forwarding equipment should support VXLAN and this draft proposes a VXLAN
> function extension to support the OAM mechanism described in the draft.
>
> ----
> Dapeng Liu
>
>
>
>
>
>
> Regards,
>
> Shahram
>
>
>
>
> draft? Dapeng Liu from Alibaba will be the presenter. 15 minutes would be
> good enough.
>
>
>
> Cheers
>
>
>
> Dacheng
>
>
>
> 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: Dapeng Liu <[email-masked]>
Date: Mon, 6 Jul 2015 14:35:47 +0800

Hi Tom,  

Thanks for the comments.
The scenario discussed in the draft is: all the host traffic is encapsulated in VXLAN tunnel. So there will be no problem if the host traffic uses VXLAN port number.

--  
Dapeng Liu

在 2015年7月4日 星期六，上午8:06，Tom Herbert 写道：

> On Fri, Jul 3, 2015 at 10:23 AM, Dapeng Liu <[email-masked] (mailto:[email-masked])> wrote:
> >  
> >  
> > 抄送: "[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])"
> > <[email-masked] (mailto:[email-masked])>, Dapeng Liu <[email-masked] (mailto:[email-masked])>

---

From: "Dacheng Zhang" <[email-masked]>
Date: Mon, 06 Jul 2015 14:39:14 +0800

Agree！In our scenario, it is assumed all the traffics that a  intermediate
router has to process are encapsulated within vxlan payloads.

发件人:  Dapeng Liu <[email-masked]>
日期:  2015年7月6日 星期一 下午2:35
至:  Tom Herbert <[email-masked]>
抄送:  Shahram Davari <[email-masked]>, "[email-masked]"
<[email-masked]>, dacheng de <[email-masked]>
主题:  回复： [nvo3] 回复： Application of a time slot in this ietf
meeting//Re: New draft: Path Detection in VXLAN Overlay Network

 Hi Tom, 

Thanks for the comments.
The scenario discussed in the draft is: all the host traffic is encapsulated
in VXLAN tunnel. So there will be no problem if the host traffic uses VXLAN
port number.

-- 
Dapeng Liu

---

From: Tom Herbert <[email-masked]>
Date: Mon, 6 Jul 2015 07:50:52 -0700

> in VXLAN tunnel. So there will be no problem if the host traffic uses VXLAN
I don't understand. You're assuming that *all* traffic generated by
hosts in a network is in VXLAN?

Tom

---

From: "Dacheng Zhang" <[email-masked]>
Date: Tue, 07 Jul 2015 15:47:09 +0800

>hosts in a network is in VXLAN?

In our scenario, yes. For instance, in a DC, vxlan is used to generate a
overlay network. All the traffic generated by hosts will be transferred in
vxlan. The traffic from internet will be encapsulated into a vxlan tunnel
and forwarded to its target host…..