Yes Eric, you make a lot of good points. Therefore the promise of OAM is very limited and can mislead at best. ;-)
Dino On Aug 1, 2014, at 11:14 AM, Eric Gray <[email protected]> wrote: > Dino, > > Thanks for the reply. > > I think we are on the same page, but possibly not. > > I don't argue that we should be able to steer an OAM message to follow > a particular path among the multiple equal-cost paths, as long as OAM messages > contain enough entropy to ensure that sending some number of them will result > in having OAM messages traverse each of the multiple equal-cost paths. > Ideally, > the mechanisms used - both in OAM and in path selection at each hop - will > tend > to distribute OAM messages and data on a proportional basis (e.g. - it's bad > if 20% > of the OAM messages go along a path that carries ~50% of the data). > > Indeed, it is not clear what "following the same path" would mean on the > basis of any individual data PDU. In order to do this literally you would > first have to > determine which path the data took and then determine what to put in the OAM > message to make it follow the same path. > > Alternatively, you could clone the parts of a particular data PDU that > are > used by distribution algorithms in each hop, in an OAM PDU that you want to > use > the same path. > > Either of these approaches would be very hard, for all of the reasons > you > mentioned, and maybe a few you did not, and it is unclear to me why you would > need to do this most of the time. Certainly it will be pointless in > proactive OAM. > > If the forwarders on a path are not able to distinguish data from OAM, > it > can be relatively easy to ensure that approximately the same distribution of > OAM > and data is the case. > > One issue that may come up is if the OAM messages have to be sent like > other data packets, with Source and Destination IP address and > transport-layer > port information of the source and sink of the OAM itself, and these fields > are all > that are included in any mechanism used to distribute traffic across multiple > paths, > then the OAM will all traverse the same path. > > One approach to dealing with this is to add one or more fields used to > provide the entropy that would otherwise be missing, and require every hop to > include this field (or these fields) in path selection. > > Where this can cause trouble is if the field(s) are included in path > selection > only if the PDU is an OAM message. In this case, while the entropy is there > to allow > OAM message to provide full coverage, there is extra logic required in > traversing a > series of hops (where each may have multiple path choices for forwarding) > that is > used to determine if the message is an OAM message. > > In this case, by definition, the forwarding devices will be > distinguishing OAM > from data (using the extra logic) and this results in a "different path" (at > the micro > level, because of the extra logic - that may itself be subject to failure). > > The issue is less about the fact that the OAM PDU follows a different > path > in the network from that a corresponding data PDU would follow (though it > may); > it is that every OAM PDU will "follow" a different logical path within the > node itself. > > Alternatively, the field(s) can be examined in every PDU. This > eliminates > the risk of "path differentiation" (at the micro-level) because of the use of > extra > logic steps, but introduces a requirement that any PDU source MUST be careful > about value(s) it puts in these fields (or risk having its flows distributed > across > multiple paths). This can complicate domain ingress devices (for example, a > tunnel entry point), and reduce overall entropy for distribution of data PDUs. > > -- > Eric > > -----Original Message----- > From: Dino Farinacci [mailto:[email protected]] > Sent: Thursday, July 31, 2014 7:17 PM > To: Eric Gray > Cc: Larry Kreeger; 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 > Importance: High > >> 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
