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.

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
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.

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.

So, what is the problem again?

--
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

Reply via email to