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
