No. It was more in reference to your comment about blocking this document. If a draft is brought into WG, it goes through regular process.
> On Nov 4, 2015, at 8:18 PM, Liyizhou <[email protected]> wrote: > > WG do not own the base encapsulation so they can't even work on it. That > seems the implication? > > Yizhou > > > 发件人: Sam Aldrin [mailto:[email protected]] > 发送时间: 2015年11月5日 10:14 > 收件人: Liyizhou > 抄送: Tom Herbert; Haoweiguo; Shahram Davari; [email protected]; Dacheng Zhang; > Deepak Kumar (dekumar) > 主题: Re: [nvo3] draft--pang--nvo3--vxlan--path--detection--01 > > Just so you know, VXLAN RFC was not WG document, rather independent > submission. > As you are bringing this to NVo3 WG and asking for comments, they are given. > There is nothing wrong in either direction, unless you feel it that way. > > -sam > > On Wed, Nov 4, 2015 at 5:46 PM, Liyizhou <[email protected] > <mailto:[email protected]>> wrote: > 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] <mailto:[email protected]>] 代表 > Tom Herbert > 发送时间: 2015年11月5日 6:05 > 收件人: Haoweiguo > 抄送: Sam Aldrin; Shahram Davari; [email protected] <mailto:[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] > <mailto:[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] <mailto:[email protected]>] > > Sent: Wednesday, November 04, 2015 14:51 > > To: Sam Aldrin > > Cc: Shahram Davari; [email protected] <mailto:[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] > > <mailto:[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] > > <mailto:[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] > > <mailto:[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] > > <mailto:[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]https://www.ietf.org/mailman/listinfo/nvo3 > > <http://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] <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
