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 protected]> 日期: 2015年7月17日 星期五 下午4:16 至: dacheng de <[email protected]>, "Deepak Kumar (dekumar)" <[email protected]>, Shahram Davari <[email protected]>, "[email protected]" <[email protected]>, liyizhou <[email protected]>, tom <[email protected]> 抄送: "[email protected]" <[email protected]>, nvo3 <[email protected]>, maxpassion <[email protected]> 主题: 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 protected]> Date: Thursday, July 9, 2015 at 9:41 AM To: "Deepak Kumar (dekumar)" <[email protected]>, Shahram Davari <[email protected]>, "[email protected]" <[email protected]>, liyizhou <[email protected]>, tom <[email protected]> Cc: "[email protected]" <[email protected]>, nvo3 <[email protected]>, maxpassion <[email protected]> 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 protected]> on behalf of "Deepak Kumar (dekumar)" <[email protected]> 日期: 2015年7月7日 星期二 上午6:49 至: Shahram Davari <[email protected]>, "[email protected]" <[email protected]>, liyizhou <[email protected]>, tom <[email protected]> 抄送: "[email protected]" <[email protected]>, nvo3 <[email protected]>, maxpassion <[email protected]> 主题: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network Hi Shahram, From: Shahram Davari <[email protected]> Date: Monday, July 6, 2015 at 1:46 PM To: dekumar <[email protected]>, "[email protected]" <[email protected]>, Li Yizhou <[email protected]>, tom <[email protected]> Cc: "[email protected]" <[email protected]>, nvo3 <[email protected]>, maxpassion <[email protected]> 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 From: Deepak Kumar (dekumar) [mailto:[email protected]] Sent: Monday, July 06, 2015 1:31 PM To: Shahram Davari; [email protected]; liyizhou; tom Cc: [email protected]; nvo3; maxpassion Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network 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 protected]> Date: Monday, July 6, 2015 at 12:01 PM To: "[email protected]" <[email protected]>, Li Yizhou <[email protected]>, tom <[email protected]>, dekumar <[email protected]> Cc: "[email protected]" <[email protected]>, nvo3 <[email protected]>, maxpassion <[email protected]> Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network I agree. You should use TTL. TTL use will also solve layer violation issue. Thx SD From: nvo3 [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, July 06, 2015 6:21 AM To: liyizhou; tom; dekumar Cc: [email protected]; nvo3; maxpassion Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network 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 <mailto:[email protected]> > > Date: 2015-07-06 14:58 > > To: Lizhong Jin <mailto:[email protected]> ; 'Tom Herbert' > <mailto:[email protected]> ; 'Deepak Kumar (dekumar)' > <mailto:[email protected]> > > CC: [email protected]; 'Dapeng Liu' <mailto:[email protected]> ; > [email protected] > > Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network > > 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 protected]] > > Sent: Monday, July 06, 2015 12:29 PM > > To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)' > > Cc: [email protected]; 'Dapeng Liu' > > Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network > > > > 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 > > > >> > -----Original Message----- > >> > From: Liyizhou [mailto:[email protected]] > >> > Sent: 2015年7月6日 11:12 > >> > To: Lizhong Jin; 'Tom Herbert'; 'Deepak Kumar (dekumar)' > >> > Cc: [email protected]; 'Dapeng Liu' > >> > Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network > >> > > >> > 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 protected]] On Behalf Of Lizhong Jin > >> > Sent: Monday, July 06, 2015 9:59 AM > >> > To: 'Tom Herbert'; 'Deepak Kumar (dekumar)' > >> > Cc: [email protected]; 'Dapeng Liu' > >> > Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network > >> > > >> > 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 protected]] > >>> > > Sent: 2015年6月29日 23:37 > >>> > > To: Deepak Kumar (dekumar) > >>> > > Cc: [email protected]; 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 protected]> 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 protected]> > >>>> > > > Date: Saturday, June 20, 2015 at 10:04 AM > >>>> > > > To: <[email protected]> > >>>> > > > 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-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. > >>>> > > > > >>>> > > > Comments & suggestions are welcomed. > >>>> > > > > >>>> > > > > >>>> > > > -- > >>>> > > > Dapeng Liu > >>>> > > > > >>>> > > > > >>>> > > > _______________________________________________ > >>>> > > > nvo3 mailing list > >>>> > > > [email protected] > >>>> > > > https://www.ietf.org/mailman/listinfo/nvo3 > >>>> > > > > >>> > > > >> > > >> > > >> > _______________________________________________ > >> > nvo3 mailing list > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
