Hi Deepak, What you are describing is very narrow scenario, which has its own pitfalls. Inline for my comments. > On Nov 3, 2015, at 7:10 PM, Deepak Kumar (dekumar) <[email protected]> wrote: > > Hi Shahram/Sam, > > This solution is hardware centric with controller and policy needs to be > created on each hop. > This solution is not applicable for all scenarios. > > Policy example > Match peer vtep ip == destination ip of packet destination port 4789, pd bit > action punt and drop. > Match peer vtep ip!=destination ip destination port == 4789, pd bit action > punt and forward. If you want to employ policy for every vtep and on every device in the network, IMO, a bad design to start with. > > Now drop takes care of leak scenario from leafs. > > Now controller eats up the packet so no issue of loop. > Also in network packet is going as data packet as per vxlan rule of max ttl > so not sure where's loop. You mean there cannot be loops in n/w, just because TTL is used? (loop life is dependent on ttl)
> If loop is there oam and data both will suffer. Yes both will suffer. You use OAM to detect whether data plane has problem or not. With this, it will compound the problem. > > Loop with controller can be avoided but that's outside the scope. > > Alibaba is also operator and using this data center for cloud services. > > I agree Ttl expiry will also work but that's software solution and separate > draft not this draft intention. If you already have a solution, why invent a new one? Are you saying controller is not efficient and cannot perform oam efficiently with existing ttl mechanism? :D > > On Concern of policy application controller will apply the policy and if > network is not hardware oam capable they won't initiate it and use software > oam method. Well, you have the answer right there. In other words, if a device cannot support your proposed solution, you will revert back to ttl solution. why don’t you just use that solution instead? > > We evaluated multiple Asic and found out solution can be done on multiple > broadcom and custom Asic and Alibaba network is running on 2 different > Broadcom Asic. And your point being? :D -sam > > Thanks > Deepak > > Sent from my iPhone > > On Nov 4, 2015, at 11:29 AM, Sam Aldrin <[email protected] > <mailto:[email protected]>> wrote: > >> 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. >> >> Secondly, imagine when there exists a loop. In fact, they do exist even in >> controller based networks. >> >> Speaking as an operator, as mentioned yesterday, this will cause packet >> storm and unintended consequences. >> >> Why are we solving the problem when it doesn’t exist? >> >> -sam >> >>> On Nov 3, 2015, at 6:02 PM, Shahram Davari <[email protected] >>> <mailto:[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] >>> <mailto:[email protected]>] >>> Sent: Tuesday, November 03, 2015 5:53 PM >>> To: Shahram Davari; [email protected] <mailto:[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] <mailto:[email protected]>> on behalf >>> of Shahram Davari <[email protected] <mailto:[email protected]>> >>> 日期: 2015年11月4日 星期三 上午9:33 >>> 至: "[email protected] <mailto:[email protected]>" <[email protected] >>> <mailto:[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] >>> <mailto:[email protected]>https://www.ietf.org/mailman/listinfo/nvo3 >>> <https://www.ietf.org/mailman/listinfo/nvo3>_______________________________________________ >>> nvo3 mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> <https://www.ietf.org/mailman/listinfo/nvo3>
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
