NTAC Peering Working Group

[Scott Brim <>]

I usually don't have much to say here but

You don't know that a traceroute follows the same path as your data
packets in a connectionless environment.  It's likely but you don't
_know_ since (1) routing is per-hop and dynamic, (2) some IPSs and even
some routers treat traceroute/ping differently; and (3) it can be
spoofed (one of my favorite April Fools spoofs was by Louis Mamakos,
messing with paths and RTTs).

On the other hand, an openflow path is managed and does not change
except by management (or failure).  Instead of trying to trace a path
yourself, use your favorite management interface to ask what path it has
configured, and you can have a high level of confidence in the answer.  No?

Scott

On 05/30/13 16:31, Michael H Lambert allegedly wrote:
> Paul,
> 
> On 30 May 2013, at 11:53, Paul Schopis wrote:
> 
>> 4. Substrate comment by Michael - Agreed, it is not very interesting if 
>> all it is used for is IP transport. But not sure I get the comment about 
>> test/diagnostic packets, again I think depends on what it is your trying 
>> to diagnose. Could you elaborate?
> 
> My thoughts were sort of meandering this this direction:
> 
> Let's say I am sitting on a.hawaii.edu and running an application between 
> that host and b.maine.edu (that should make for a long path with lots of 
> devices).  On a traditional IP network, if I do a traceroute I'll feel 
> fairly confident that the traceroute packets are following the same path as 
> my data packets.  However, if I'm running my SDN-aware application on an 
> SDN-enabled network, I probably won't have that same confidence.  The 
> application can provide hints, requests or demands to the network; these 
> can affect the path(s) taken through the network (short-circuiting layer-3 
> completely, perhaps).  Unless sdntraceroute is provided with the same 
> parameters (and maybe not even then if the volume of data affects the 
> path), there is no reason to assume any congruence between the application 
> and traceroute paths, except, perhaps, at the first and last hops.
> 
> An issue now during an initial deployment of an IP network on top of SDN?  
> Probably not.  A problem a few years from now when we are actually 
> leveraging SDN?  Quite likely.
> 
> Michael
> 
>