NTAC Peering Working Group

[Darrell Newcomb <>]

On May 30, 2013, at 7:52 AM, Steven Wallace wrote:

> I would be asking for an app where the engineer can easily  say to AL2S 
> "what's the path for this flow" and the app responds with the complete path 
> as it exists in realtime.

I've had the above application for IP networks for many years on numerous 
networks consisting of numerous vendor's gear; that's not a new/unique 
capability.

        As with many things the adoption hurdles for entire possible 
population of users are not small.  It's also the case that like all 
meta-views there are many discovery/awareness challenges in the 
people/applications finding a portal into that information.  

        A for-instance about that last point is Perfsonar's longevity of 
effort having not made much headway in use/adoption of node discovery across 
a significant percentage of 'potential' users.   That is despite quite a lot 
of very reasonable efforts by some contributors that I would say are quite 
useful and I appreciate them.  But consider how small the percentage of 
potential users that is actively using those mechanism; then look at the far 
smaller sliver using any sort of novel/efficient-for-users discovery 
techniques to aide broader use vs. just find the same nodes they knew 
existed(ala White Pages).  

---

        Then one can consider the entire class of problems where state 
inspection is far different than having a vantage point on active forwarding 
behavior (Paul's later comment quoted here gets at this same).  
On May 30, 2013, at 8:00 AM, Paul Schopis wrote:
> Understood, but there is a subtle difference between the intended path and 
> the path taken. It's not like I have ever seen an IP/MPLS/Ethernet packet 
> go somewhere unexpected ;-)

        To expect the entire class of failures are at all going to be 'less' 
frequent of an outcome in devices using SDN seem to be folly.  Sure there 
will be variation where specific combinations will have temporally better 
outcomes than others and even possibly sustained advantages over other 
combinations of building-blocks.  Just like anything; folks whom make effort 
can squeeze out defect rate, but that class of failure absolutely will not 
get to zero across a large and diverse population of devices and networks 
with any sort of change rate.  

        Most would probably hazard to estimate this problem area has and will 
continue to be greater for quite some time, though I'm of the opinion that 
this failure rate won't *need* to remain at a higher than historical norms 
for SDN vs. other control systems (the higher level messaging has rarely been 
the root-cause for this class of failure).


None of the above should be read to be a detraction from moving onward with 
SDN deployment and use, but hopefully  helps bring some more grounded points 
to this narrow topic and problem-space.