Inline for my comments with %sam. > On Jul 19, 2015, at 10:42 AM, Dacheng Zhang <[email protected]> > wrote: > > Hi Sam, > > Thanks for providing detail comments, please see inline [Dacheng]. > > Cheers > > Dacheng > > > 发件人: nvo3 <[email protected] <mailto:[email protected]>> on behalf of > aldrin ietf <[email protected] <mailto:[email protected]>> > 日期: 2015年7月6日 星期一 下午10:59 > 至: "Deepak Kumar (dekumar)" <[email protected] <mailto:[email protected]>> > 抄送: Shahram Davari <[email protected] <mailto:[email protected]>>, > maxpassion <[email protected] <mailto:[email protected]>>, tom > <[email protected] <mailto:[email protected]>>, nvo3 <[email protected] > <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>>, > "[email protected] > <mailto:[email protected]>" > <[email protected] > <mailto:[email protected]>>, liyizhou > <[email protected] <mailto:[email protected]>> > 主题: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network > > Let me weigh in my comments. > > - Do not think punt + forward is a good design. More importantly, the amount > of traffic it generates in uncontrolled. Majority of the OAM mechanisms > within IETF are source driven and I do not see the need, why we have to > digress from that. If there is, it should be clearly laid out in the draft > > [Dacheng] punt+ forward logic packet always go through the right data path > without any modification. In our solution, we have one packet generated in > the data path and all the replies happen on the out of band controller path > and thus OAM traffic is low compared to TTL expiry method. %sam - If it is out-of-band as you say, why are you worried about 1 packet vs many packets? I do not subscribe to this as a real problem as the existing mechanism already solves without doing the h/w enhancement this draft asks. > > Lets take example of Datacenter with 800 Leafs and before we allow customer > VMs traffic to start an operational team want to verify all the data path in > the network so they have confidence in the network. > Now In our design is faster to find all the path, why as we are not source > driven to wait for response from the Leafs and we generate less traffic in > the data path. %sam - Leaf? Are you talking about multicast network or individual destination addr/prefixes? Secondly, are you testing connectivity to those destination addresses or traces to those addresses? I do not subscribe to the case you are eluding to that number of packets by existing source driven is bottleneck to discover whether connectivity is established or not. If you use this model, I’d argue that, when destination nodes (leaf in your terms) are coming up, it would infact generate more traffic as the packets from intermediate routers generate response packets for every ping packet you send, while the connectivity is being verified every time. But if you say, I won’t set the replication+forward bit in that case, then the purpose of doing this enhancement is moot. > > Eg:- 6 hop network, single vtep – vtep our solution has 1 OAM frame. If we > have 32 path in the network then we will send 32 Frames once they know all > the sport by which new path is exercised. > TTL solution even if it’s Out of Band has 6 Send frames at least. Now if we > have 32 path in the network. In case of ECMP it’s 32 x 6 Frames = 192 Frames. > > Now 800 VTEP you can see the combination and increase of OAM frames in the > fabric between 2 solutions. %sam - As I described above, if you are trying to do, while the network is coming up, you will generate more packets than you describe above, as you will be repeating multiple times to check the connectivity. > > Our Solution require looking for “PD” bit similar to proposed in Vxlan-gpe > except position of this bit is different. In our solution we need all the > switches to be aware of this, but if switches are not aware backup mechanism > proposed other draft can be used. > > Also our method reduces cpu and memory load on controller, because it has to > generate 6 time less frames per Vtep in the network. > > > - What if there exists a loop? This scenario should be documented > > > [Dacheng] We are following the exact packet format as VxLan header and not > modifying the underlay of Vxlan Header except 1 bit so TTL loop should be > caught by underlay TTL expiry. %sam - You lost me there. How does underlay takes care of loop and avoid packet not getting replicate+forward? > > - In regards to security, redirecting responses to controller opens up can of > worms. I am sure others could chime in here, as well. If the designed > proposed in this draft opens up the responses to go, other than source, it > just opens up the network to be exploited with just one OAM packet. > > [Dacheng] Between Controller and Switches security can be established by > existing mechanism. > > Lets take for example OAM can’t be started from ports which are not connected > to controller and even reply are sent on these ports. Again these ports are > dedicated port and controller and switch should use existing security > mechanism to configure and packet insert and response for OAM. > > If this is not satisfactory Authentication TLV can be added to message. %sam - How you implement solution is secondary(second step). When you are redirecting the the responses to an outside entity and other than source, with your proposed mechanism, one spoofed packet could sniff out entire network. This is to be clearly documented and implications are to be identified as well. > > - If the detection could be done with TTL mechanism (like others said), what > is the rationale to introduce a requirement where, entirely new support needs > to be added, without much of a gain. > > [Dacheng] We can provide our deployment results. Also we have answered it > above. %sam - Sure. I’d like the requirement to be justified before solution could deliberated upon. > > > - Lastly, what if some/many nodes do not support the OAM extensions, as > proposed? > > [Dacheng] Again it’s controller functionality, Controller can understand > which nodes don’t support this functionality and in that scenario packet is > never punted but still forward in data path. %sam - How does controller determine that?
> Also controller in this scenario can decide not to use our mechanism but to > fallback to existing OAM mechanism or new mechanism which are backward > compatible. %sam - That is exactly my point. If existing mechanism already be able to do that, why invent a new solution? I do not think number of packets and efficiency(which I do not agree either) justifies a new solution, additional complexity, limited to specific model this solution could be administered, etc. cheers -sam > > Thanks, > > -sam >> On Jul 6, 2015, at 1:30 PM, Deepak Kumar (dekumar) <[email protected] >> <mailto:[email protected]>> wrote: >> >> TTL use is fine and it works with existing hardware, but what this document >> is trying to provide another alternate approach where all devices are OAM >> capable and can look at O bit. >> In carrier Ethernet, CFM also generates Link trace message (single message) >> and all mip reply with link trace reply from both ingress and egress MIP >> along the path. >> >> As per my understanding what this draft is adding MIP in the ip network as >> whole network is OAM capable (especially datacenters), and the MIP are >> copying the packet and cpu is filling the ingress and egress interface from >> actual forwarding copy of packet, along the path and redirect to controller >> but packet keeps forwarding like normal data packet. >> >> R1 —— R2—— R3 >> >> Now if packet keeps forwarded in hardware in R2, and MIPs are placed on all >> interfaces, then you get correct ingress interface when R2 ingress mip is >> hit and correct egress interfce when R2 egress mip is hit and thus ingress >> and egress interface is provided. >> >> With TTL approach, once packet is punted to cpu, we can also figure out >> egress interface by calling hardware forwarding hashing algorithm, but then >> it’s cpu driven and not hardware copy of the exact data frame. Now >> forwarding hashing algorithm should be able to find the exact physical link >> if virtual links are present. >> >> Thanks, >> Deepak >> >> From: Shahram Davari <[email protected] <mailto:[email protected]>> >> Date: Monday, July 6, 2015 at 12:01 PM >> To: "[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>>, Li Yizhou <[email protected] >> <mailto:[email protected]>>, tom <[email protected] >> <mailto:[email protected]>>, dekumar <[email protected] >> <mailto:[email protected]>> >> Cc: "[email protected] >> <mailto:[email protected]>" >> <[email protected] >> <mailto:[email protected]>>, nvo3 >> <[email protected] <mailto:[email protected]>>, maxpassion <[email protected] >> <mailto:[email protected]>> >> Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network >> >> I agree. You should use TTL. TTL use will also solve layer violation issue. >> >> Thx >> SD >> >> From: nvo3 [mailto:[email protected] <mailto:[email protected]>] On >> Behalf Of [email protected] <mailto:[email protected]> >> Sent: Monday, July 06, 2015 6:21 AM >> To: liyizhou; tom; dekumar >> Cc: [email protected] >> <mailto:[email protected]>; nvo3; >> maxpassion >> Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network >> >> If we use TTL, at least we could say the path between ingress and egress >> node is OK if OAM is OK. Because the OAM packet goes through exactly the >> same forwarding behavior as the data packets. But for the mechanims in this >> document, if OAM is OK, we could not say the data path is OK. We could only >> get to know that the link between the nodes along the path is OK. That's the >> difference between this new OAM and other OAM mechanism (e.g., TTL based). >> >> Regards >> Lizhong >>> >>> From: Liyizhou <mailto:[email protected]> >>> Date: 2015-07-06 14:58 >>> To: Lizhong Jin <mailto:[email protected]>; 'Tom Herbert' >>> <mailto:[email protected]>; 'Deepak Kumar (dekumar)' >>> <mailto:[email protected]> >>> CC: [email protected] <mailto:[email protected]>; 'Dapeng Liu' >>> <mailto:[email protected]>; >>> [email protected] >>> <mailto:[email protected]> >>> Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network >>> Hi Lizhong, >>> >>> No matter which way we use to capture a packet for further diagnose, it >>> always involves additional operations. Here following real data path is >>> guaranteed. >>> >>> If we take receiving packet along the path as positive, there may be little >>> chance of false negative, e.g. data path is ok but replication of frame at >>> some node is not working so that the central sever misinterprets it as a >>> loss of the packet. However the next node will receive that packet and >>> report it correctly in most of the cases. In extreme corner case, there is >>> no more node along the path or all nodes have breaking replication >>> function. Then it might be a false negative. I kind of think it happens in >>> almost all the OAM mechanisms. Little chance like TTL=0 is not handled >>> correctly, the response of ping is not generated correctly, etc. >>> >>> I do not see a chance for false positive. >>> >>> Thanks, >>> Yizhou >>> >>> -----Original Message----- >>> From: Lizhong Jin [mailto:[email protected] <mailto:[email protected]>] >>> Sent: Monday, July 06, 2015 12:29 PM >>> To: Liyizhou; 'Tom Herbert'; 'Deepak Kumar (dekumar)' >>> Cc: [email protected] <mailto:[email protected]>; 'Dapeng Liu' >>> Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network >>> >>> Hi Yizhou, >>> The OAM packet with "copy/replicate" action will have different logic in >>> the chip with the normal data packet (e.g., the OAM packet will generate >>> "copy/replicate" action by special logic, and replicate one copy from >>> original packet, but normal data packet may not have these logic in some >>> design). That means they will have different data path in the chip. And >>> loss of OAM packet could not be ensured that normal data packet is also >>> data, and normal packet loss could not infer that OAM packet will also be >>> lost. >>> >>> Lizhong >>> >>> > -----Original Message----- >>> > From: Liyizhou [mailto:[email protected] <mailto:[email protected]>] >>> > Sent: 2015年7月6日 11:12 >>> > To: Lizhong Jin; 'Tom Herbert'; 'Deepak Kumar (dekumar)' >>> > Cc: [email protected] <mailto:[email protected]>; 'Dapeng Liu' >>> > Subject: RE: [nvo3] New draft: Path Detection in VXLAN Overlay Network >>> > >>> > Hi Lizhong, >>> > >>> > I believe "copy" here means replicate. The original data packet will >>> > be keeping going to the final destination. >>> > >>> > Thank, >>> > Yizhou >>> > >>> > -----Original Message----- >>> > From: nvo3 [mailto:[email protected] <mailto:[email protected]>] >>> > On Behalf Of Lizhong Jin >>> > Sent: Monday, July 06, 2015 9:59 AM >>> > To: 'Tom Herbert'; 'Deepak Kumar (dekumar)' >>> > Cc: [email protected] <mailto:[email protected]>; 'Dapeng Liu' >>> > Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay Network >>> > >>> > Hi guys, >>> > In the draft, it says: >>> > Each network device receives the Path Tracking packet from its >>> > upstream device, makes a copy of it and passes the copy to its CPU. >>> > >>> > That means the OAM packet will have different data path with the >>> > normal packet. The normal packet will not have "copy" action in the >>> > datapath. Then how could the OAM packet detect the liveness of the >>> > datapath? Did I missed something? >>> > >>> > Regards >>> > Lizhong >>> > >>> > > -----Original Message----- >>> > > From: Tom Herbert [mailto:[email protected] >>> > > <mailto:[email protected]>] >>> > > Sent: 2015年6月29日 23:37 >>> > > To: Deepak Kumar (dekumar) >>> > > Cc: [email protected] <mailto:[email protected]>; Dapeng Liu >>> > > Subject: Re: [nvo3] New draft: Path Detection in VXLAN Overlay >>> > > Network >>> > > >>> > > On Mon, Jun 29, 2015 at 6:48 AM, Deepak Kumar (dekumar) >>> > > <[email protected] <mailto:[email protected]>> wrote: >>> > > > Hi Dapeng Liu, >>> > > > >>> > > > I support idea of hardware and controller based Path detection and >>> > > > tracking where whole network is OAM capable and packet keeps >>> > > > forwarding >>> > > in hardware. >>> > > > I believe you guys presented this solution in ONS summit also. >>> > > > You should explicitly call out in draft that this solution is not >>> > > > backward compatible and all switches require to be OAM capable in >>> > > > hardware to look at new bit to punt and copy the packet even in >>> > > > underlay. >>> > > > >>> > > VXLAN-GPE already defines an OAM bit. If all the hardware needs to >>> > > be updated anyway, why not just move to that and avoid having to >>> > > worry about the compatibility problem? >>> > > >>> > > Thanks, >>> > > Tom >>> > > >>> > > > Thanks, >>> > > > Deepak >>> > > > >>> > > > From: Dapeng Liu <[email protected] <mailto:[email protected]>> >>> > > > Date: Saturday, June 20, 2015 at 10:04 AM >>> > > > To: <[email protected] <mailto:[email protected]>> >>> > > > Subject: [nvo3] New draft: Path Detection in VXLAN Overlay Network >>> > > > >>> > > > Hello all, >>> > > > >>> > > > We have submitted a draft for path detection in VXLAN overlay >>> > > > network. >>> > > > http://datatracker.ietf.org/doc/draft-pang-nvo3-vxlan-path-detecti >>> > > > <http://datatracker.ietf.org/doc/draft-pang-nvo3-vxlan-path-detecti> >>> > > > on >>> > > > / >>> > > > >>> > > > The draft proposes a method for path detection in VXLAN network >>> > > > and it defines the path detection packet format by using one >>> > > > reserve bit in the VXLAN header. >>> > > > >>> > > > Comments & suggestions are welcomed. >>> > > > >>> > > > >>> > > > -- >>> > > > Dapeng Liu >>> > > > >>> > > > >>> > > > _______________________________________________ >>> > > > 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] <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
