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 - What if there exists a loop? This scenario should be documented - 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. - 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. - Lastly, what if some/many nodes do not support the OAM extensions, as proposed?
-sam > On Jul 6, 2015, at 1:30 PM, Deepak Kumar (dekumar) <[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] > https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
