NTAC Peering Working Group

[Paul Schopis <>]

Michael,
Got it. I guess I was operating under an assumption that for a test to be 
valid one would have to construct a test packet that "should" follow the same 
path. But you raise an interesting point that path selection can be based on 
a variety of criteria and one may or may not know what all of the domains 
preferences are. 

Your thoughts present an interesting paradigm. On one hand researchers have 
eschewed protocols as being to rigid, but on the other hand if some version 
of consensus (which I would argue is a perhaps an informal protocol) we could 
very well have the Tower of Babel problem. In other words, the flexibility of 
OF may be it's strongest attribute and its strongest weakness. 

P.



Paul Schopis
Chief Technology Officer
OARnet
1224 Kinnear Rd
Columbus, OH 43212
Ph. 614-292-1956
email: 


________________________________________
From: 

 
[]
 on behalf of Michael H Lambert 
[]
Sent: Thursday, May 30, 2013 4:31 PM
To: 

 Routing WG
Subject: Re: [2013-l3-architecture] FOR DISCUSSION: IP over AL2S

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