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 protected]] Sent: Monday, July 06, 2015 11:23 AM To: Liyizhou Cc: Lizhong Jin; Tom Herbert; Deepak Kumar (dekumar); [email protected]; Dapeng Liu Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network 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 protected]> wrote: > > 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-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 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
