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
