I can give a simple example. A OpenFlow switch can easily be used to support this function. But of course it is an example, we do not try to argue that we should use Openflow.
发件人: nvo3 <[email protected]> on behalf of Shahram Davari <[email protected]> 日期: 2015年11月4日 星期三 上午9:58 至: dacheng de <[email protected]>, "[email protected]" <[email protected]> 主题: Re: [nvo3] draft--pang--nvo3--vxlan--path--detection--01 The only text I can see is the following: “Each network device receives the Path Tracking packet from its upstream device, makes a copy of it and passes the copy to its CPU. “ I don’t see any mechanism being proposed in the draft. Thx SD From: Dacheng Zhang [mailto:[email protected]] Sent: Tuesday, November 03, 2015 5:53 PM To: Shahram Davari; [email protected] Subject: Re: [nvo3] draft--pang--nvo3--vxlan--path--detection--01 This draft actually proposes a mechanism where the intermediates are required to recognize the vxlan oam packets. If this assumption is broken, the solutions proposed in this draft may not be effective. Cheers Dacheng 发件人: nvo3 <[email protected]> on behalf of Shahram Davari <[email protected]> 日期: 2015年11月4日星期三上午9:33 至: "[email protected]" <[email protected]> 主题: [nvo3] draft-‐pang-‐nvo3-‐vxlan-‐path-‐detection-‐01 Hi, This draft needs to address how intermediate L3 routers are going to see these VXLAN OAM packets, since L3 routers just do L3 routing and don’t look at the payload to see it is VXLAN and then see that these are PD OAM packets. The only option I can think of is TTL expiry, otherwise it won’t work, the way it is defined now, Thx Shahram _______________________________________________ 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
