Fully agree. ^_^ 在 15-11-5 上午9:46， "Liyizhou" <[email protected]> 写入:
>RFC7348 VxLAN itself is an informational document. IMO, being >informational does not necessarily mean no new bit can be defined. The >document can be improved to clearly state the applicable scenario and >compatibility considerations. However the historical procedural issue >should not be the only or major reason to block the progressing of such >kind of documents. I do not see anything wrong to proceed it with >informational in this case given there exists a clear requirement and >reasonable deployment from it. > > >Thanks, >Yizhou > > >-----邮件原件----- >发件人: nvo3 [mailto:[email protected]] 代表 Tom Herbert >发送时间: 2015年11月5日 6:05 >收件人: Haoweiguo >抄送: Sam Aldrin; Shahram Davari; [email protected]; Dacheng Zhang; Deepak >Kumar (dekumar) >主题: Re: [nvo3] draft--pang--nvo3--vxlan--path--detection--01 > >On Wed, Nov 4, 2015 at 9:31 PM, Haoweiguo <[email protected]> wrote: >> Hi Sam, >> >> The extra bit in VXLAN reserved field has no side effect on regular >> VXLAN forwarding process. The hardware requirements for intermediate >> nodes is also low, the intermediate nodes only need to grab the data >> packets with the OAM flag to control plane using regular ACL, most >> current commertial chipsets can support this behavior. >> > >"The extra bit in VXLAN reserved field has no side effect on regular >VXLAN forwarding process."-- I think this is an assumption based on what >implementations are probably doing currently as opposed to what is >specified by the protocol. The VXLAN RFC does not specify a forwarding >process AFAICT. And, as I mentioned yesterday, VXLAN is not extensible in >its current definition. Unknown reserved bits must be ignored on >reception which means that a receiver that doesn't support PD bit will >assume that the payload is an Ethernet packet and attempt to deliver it >as such. > >Given that this is not the first time someone has tried to extend VXLAN >and it's wide deployment, it might be prudent to try to define a method >to extend the protocol without breaking compatibility. The pseudo packet >(cannot just be called a header) trick will work if the packet is created >such that it is guaranteed to be dropped at a receiver that doesn't >understand the extensions (e.g. put a zero in total length field in case >of IP). Obviously any method should support more than just one extension. >This implies that fields must be precisely ordered, so for an >implementation to parse field, it must be able to calculate the offset of >the field. So the order that fields are defined in VXLAN becomes >important and needs to be spelled out. >The current placement of the PD bit probably would have to change for >instance. The easiest thing to do is define the flag bits left to right, >where to process the n'th bit an implementation must understand the first >n-1 bits (see GRE or GUE), but the n+1 bits and beyond can still be >ignored. > >Tom > > > >The pseudo header trick for extensibility might work >> Thanks, >> >> weiguo >> >> ________________________________ >> From: Deepak Kumar (dekumar) [[email protected]] >> Sent: Wednesday, November 04, 2015 14:51 >> To: Sam Aldrin >> Cc: Shahram Davari; [email protected]; Dacheng Zhang >> >> Subject: Re: [nvo3] >> draft--pang--nvo3--vxlan--path--detection--01 >> >> HI Sam, >> >> Vxlan field that is used is reserved field and so existing Asic based >> hardware won't add this in transmit but receiving packet with reserved >> bit set has no side effect. >> If hardware is programmable their is no issue even in transmit. >> >> Can you give me example of any Asic implementation which will have >> problem, we can add text for user to be careful before turning on the >>solution. >> >> We can even call this extension of vxlan with pd bit. >> >> Thanks, >> Deepak >> >> Sent from my iPhone >> >> On Nov 4, 2015, at 3:09 PM, Sam Aldrin <[email protected]> wrote: >> >> Hi Deepak, >> >> Aren’t you or aren’t you not changing the packet format by introducing >> PD flag bit in the reserved field. i.e changing RFC7348? >> If so, how can you claim to be informational? Is it because RFC is >> informational? >> >> For ex, VXLAN-GPE is in standards track, although it is now in expired >> state. >> >> Irrespective of technical differences, if a specific format is being >> changed, it will impact existing future deployments as well, >> informational or not. >> Being informational does not avoid that. >> >> -sam >> >> On Nov 3, 2015, at 8:03 PM, Deepak Kumar (dekumar) <[email protected]> >> wrote: >> >> HI Sam, >> >> This is good discussion and we are bringing this draft as >> informatiinal draft for narrow scenario for some operators but not for >>other operators. >> >> Ttl solution is too slow at scale and instead of argument we can give >> data of how much time it takes but for some operator that amount of >> time is okay but for some they have will want it to complete it >> quickly. As this being informational solution it's brought to working >> group as hardware driven controller controlled scenario and make its >> language may and should so all the issues it may cause to software vtep >>can be fixed. >> >> Why can't software based and hardware based solution co-exist when >> information draft won't force everyone to implement it. >> >> Thanks >> Deepak >> >> Sent from my iPhone >> >> On Nov 4, 2015, at 12:41 PM, Sam Aldrin <[email protected]> wrote: >> >> 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]> 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]> 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]] >> 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 >> > >_______________________________________________ >nvo3 mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
