2015-11-04 11:04 GMT+08:00 Sam Aldrin <[email protected]>: > > On Nov 3, 2015, at 6:47 PM, Dapeng Liu <[email protected]> wrote: > > > > 2015-11-04 10:29 GMT+08:00 Sam Aldrin <[email protected]>: > >> I expressed the same concern at last IETF meeting, as Shahram raised here. >> Haven’t gotten the explanation yet. >> >> If TTL expiry mechanism is used, then the definition of IP TTL will have >> to be redefined in order to make a copy and forward to next hop. >> But if L3 devices have to read into VXLAN header to determine OAM bit is >> set, they need to implement DPI for the same. >> > > As respond to Shahram's question, there are various ways to implement > this. ACL etc.. > > When there is text related to this, we could discuss. Without that, no > point speculating how it could be done. > > >> Secondly, imagine when there exists a loop. In fact, they do exist even >> in controller based networks. >> > > The PD packet has TTL also to avoid this. > > Having TTL doesn’t avoid, it may minimize the implosion. > > >> Speaking as an operator, as mentioned yesterday, this will cause packet >> storm and unintended consequences. >> > > We are also operator, we do not see problems here. Maybe we need more > clarification and offline discussion to make sure our solution be > understood correctly. > > Please talk to your co-authors. I did spend quite a bit of time to explain > on why it doesn’t work. > > I guess we have answered your question and it indeed works.
> My take on this is, If you have specific needs and vendors are willing to > make it work for you, please go ahead by all means, and you do not need to > standardize that. > If you really need to standardize it, ensure that it doesn’t break other > networks deployments. And VXLAN or similar protocols within NVo3 or IETF > at large, are meant to be used elsewhere as well, ex: DCI etc. > This is an informational document. Why can't hardware and software solutions both coexist. > I haven’t seen technical merits or strong use cases for the intended > method. > > Lastly, OAM DT team could consider this into the discussion. > There is a need for more efficient tool. Dapeng Liu > > -sam > > > Thanks for the comments, > Dapeng Liu > > >> >> Why are we solving the problem when it doesn’t exist? >> >> -sam >> >> On Nov 3, 2015, at 6:02 PM, Shahram Davari <[email protected]> wrote: >> >> I think your assumption is broken. But you have an alternative method and >> that is using TTL expiry. >> >> Thx >> SD >> >> *From:* Dacheng Zhang [mailto:[email protected] >> <[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 >> >> > > > -- > > ------ > Best Regards, > Dapeng Liu > > > -- ------ Best Regards, Dapeng Liu
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
