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]<mailto:[email protected]>; 'Dapeng Liu'<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> > > > Date: Saturday, June 20, 2015 at 10:04 AM > > > To: <[email protected]<mailto:[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]<mailto:[email protected]> > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > > _______________________________________________ > nvo3 mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
