NTAC Peering Working Group

[Grover Browning <>]

VLANs/Trill gets you the link failure faster but FRR gets you the path 
restoration faster, correct? 

We seem to have three issues here, the topology, the L2 mechanism, and the L3 
restoration mechanic. I believe the L2 mechanism was decided in the calls 
over the last couple of months; a combination of VLAN paths and SDN paths.

On the topology, I agree with the full mesh approach Michael. Mimicking the 
in/out behavior of L3 doesn't seem to have any real advantages and at least 
one major disadvantage. 

L3 restoration is a more interesting discussion, I think. FRR gets the I2 L3 
system up to the state of modern communication networks. If it's not a 
distraction then I'd also like to see a greater effort put in to a kind of 
"member availability" figure. Some way to calculate availability and 
"impaired but not down" figures for a set of BGP connections. IE: move the 
discussion from individual restoration technologies to a more holistic view 
of member availability. While reducing a path restoration to <100ms is a 
great goal I'd also like to see us move toward 100% member availability. 



On May 24, 2013, at 11:50 AM, Michael H Lambert 
<>
 wrote:

> On 24 May 2013, at 10:04, Grover Browning wrote:
> 
>> Full mesh with MPLS FRR/BFD.
> 
> Trying to see past my knee-jerk, religious, "MPLS is Evil" initial 
> reaction...
> 
> Let's assume that at some point in the not-too-distant future we have 
> solid, full-featured implementations of OpenFlow version x.y, where ((what 
> we need) <= x.y < (what we want)).  What do we want the IP-over-AL2S 
> topology to look like at that time?  If it's a full mesh of SDN-configured 
> paths, then why not start out with a topology that mimics that goal.  If 
> it's not, then we might want to go in some other direction in the interim.  
> I would conjecture that a full mesh is a reasonable approach, at least 
> until we have a tight(er) coupling among SDN, routing protocols and 
> real-time flow switching.
> 
> As an alternative to MPLS/FRR/BFD, how about traditional VLANs on top of 
> TRILL rather than spanning tree?
> 
> Michael