Hello Dino, always interesting, different people interpret differently.
You seem to talk about controlling where the OAM data flows. I don't think this is what Eric means. As long as a flow is defined in the traditional 3- or 5-tuple way from the IP/UDP packet and as long as every router is mapping the same flow onto the same ECMP egress interface we are fine. The details - the exact algorithm, if the algorithm uses the router-id as an additional hash or whatever else - don't matter. The OAM packet would use the same IP/UDP header as the data packet it's supervising. And the receiver processes OAM packets as "OAM" because of the flag set. > One needs to argue if you really need the granuarlity for the complexity > that will needed to get this partially correct. > Well I think LISP RLOC-probing is good enough, but I am biased. ;-) you are "rich" by having an additional control plane UDP port ;-) I don't see much complexity although I agree that just knowing if the RLOC is alive and ping-able may be enough in many cases. If we can get more like in-band OAM - why not? > If an ITR sends a packet the ETR's address, the middle boxes do not know if > it is a control-packet versus a data-packet. true but e.g. for LISP, while the middle box may have no idea what 4341 and 4342 as udp ports mean, it could still calculate a different hash bucket for ECMP due to the different UDP port. Hmm, my statement is so trivial - I assume you want to say something different with your reply? > I am trying to avoid problems. Seems like things are being over-engineered. > Again. I would say the echo nonce in RFC6830 is not fundamentally different from OAM. The N+E flags trigger some activity on the receiver, similar to OAM. > P.S. Sorry I keep being negative. And if one person says shut up, I'll stop > posting. well, everyone is entitled to his/her opinion and to voice it in his/her personal style. You have a point as I was a bit upset myself about this draft: there is likely more about it, otherwise why would we discuss yet-another-8-byte-header? Fabio offered the simplification the new header offers but for a while we will have 2-3 slightly different headers that need active support in the code or hardware. Actually in terms of code - be it C or Verilog - I'm not sure there is any simplification ever over VxLAN + LISP. But at least the situation of having both VxLAN and LISP can be simplified by having a common umbrella and one common discussion. Personally I think VxLAN-gpe is how the VxLAN/LISP header could have looked like from the start (hindsight is great, I know) and I don't have a technical problem with the draft itself. What is missing is enough context to discuss it. E.g. I'm still not sure why there is a P flag, if for a hard technical reason or for the aesthetics that every field is controlled by a turn-on flag ;-) So I encourage and kindly ask the authors to provide more of this context in the next draft version. Regards, Marc On Thu, 31 Jul 2014 16:16:53 -0700, Dino Farinacci wrote: >> Dino, >> >> Would you re-phrase your response? I am having some trouble parsing it, >> so >> I must be missing something. >> >> First, I think (when you said "... sent from any pair of ports ...") you >> meant to >> say "... sent with any pair of ports ..." - but this is a guess. > > Yes "with" is a better way of stating it. > >> As for making OAM messages traverse the exact same path as data, this is >> what OAM is expected to do. In essence, if data follows a path that >> involves > > Good luck. I do not how you will be able to control each ECMP path at each > path across different vendors as well as the same vendor with different > hashing algorithms. > > One needs to argue if you really need the granuarlity for the complexity > that will needed to get this partially correct. > >> a non-zero number of gates, while OAM does not, the successful delivery of >> OAM is only an approximate indication of the data-path integrity. Any H/W >> that data has to go through, and OAM does not go through, could fail and we >> would see an OAM indication of a valid path through which data either would >> not go, or would be diverted in some unexpected way. > > Well I think LISP RLOC-probing is good enough, but I am biased. ;-) > >> Ordinarily, this should not be a problem for the hardware, as (ordinarily) >> the >> OAM is indistinguishable from data. The hardware works no harder to push >> OAM than it would to push an equivalent amount of data. > > If an ITR sends a packet the ETR's address, the middle boxes do not know if > it is a control-packet versus a data-packet. > >> So, what is the problem again? > > I am trying to avoid problems. Seems like things are being over-engineered. > Again. > > Dino > > P.S. Sorry I keep being negative. And if one person says shut up, I'll stop > posting. > >> >> -- >> Eric >> >> -----Original Message----- >> From: nvo3 [mailto:[email protected]] On Behalf Of Dino Farinacci >> Sent: Wednesday, July 30, 2014 9:13 PM >> To: Larry Kreeger >> Cc: Tom Herbert; David Melman; Marc Binderberger; LISP mailing list list; >> [email protected] >> Subject: Re: [nvo3] Comments on >> http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03 >> >>> I'm assuming that routers and switches will be multipathing based on >>> the UDP port numbers, so I would expect different destination UDP >>> ports to take different equal cost paths. >> >> Well if OAM is going to be effective, messages need to be sent from any >> pair of ports that yield 0 through N modulus so multiple paths can be >> determined. So it doesn't matter with the port number values you use, >> those control packets will be ECMPed as well. >> >> If you are also inferring that you want the OAM packets to go through the >> same data-path of each device on the path, then you will have to put TLVs >> in the data path, which is traditionally not prudent. See my Puneet >> reference from previous email. >> >> Dino >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
