Subject: Re: [trill] FGL "safe" mode in fine labels

From: Erik Nordmark <[email-masked]>
Date: Wed, 03 Apr 2013 21:01:56 -0700

On 3/22/13 8:06 AM, Donald Eastlake wrote:
>> >3a) First, if you are using both VL-Edges and FGL-edges, what is the
>> >interoperabilty model intended to be? If RB1 is VL-only and supports
>> >VLAN 1, but RB3 is an FGL-edge and also accepts traffic on VLAN 1,
>> >what is supposed to happen? Is traffic supposed to be relayed between
>> >those two VLANs? Why or why not?
 >
> I don't quite understand your questions and, like almost everything,
> it depends on whether you are doing 0, 1, or 2 and your topology, at
> least whether your FGL-safe TRILL switches are all contiguous, as they
> should be, or your campus is misconfigured to have disjoint FGL
> islands.

I think Thomas question is not so much about the transit behavior, but 
about the semantics of a VLAN vs. a FGL at the edge.

FWIW VLAN 1 is a bad example, because it special from 802.1's 
perspective. I'll use VLAN 100 below aka VLAN 0x64 (in hex).

When RB1 receives a native packet with VLAN 100 (or a co-located bridge 
tags an untagged from a port configured to tag with VLAN 100), then this 
packet will be encapsulated by TRILL with an inner VLAN 100.

If the port on RB3 (recall, FGL is configured per port at the edge) has 
been configured as a VL port, then the same thing happens on RB3 as on RB1.

But if the port on RB3 has been configured as FGL, then RB3 will map 
VLAN 100 to some FGL. That FGL value could be 0x000064 (i.e., a FGL 
label with the value of 100) or it could be 0x123456.
In neither of those cases will that be equivalent to a packet with VL 
0x064. The VL space is disjoint from the FGL space.

All of the above is orthogonal to how the transit works - whether or not 
there are some VL RBridges or only FGL-safe RBridges in the network.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 03 Apr 2013 21:17:56 -0700

On 3/20/13 2:19 PM, Thomas Narten wrote:

 > The above says to me that you now have a TRILL campus where R1 does
 > process FGL frames and R2 does not. But doesn't that contradict the
 > model:
 >
 >> 1) VL-only (today's deployment), then
 >> 2) A mixture of VL and FGL-safe, until
 >> 3) EVERYone upgraded to FGL-safe, then
 >> 4) FGL-links can be introduced.

FWIW Your use of "FGL-link" is not consistent with the definition in the 
document.
The document defines it as "A link where all of the attached TRILL 
switches are FGL."

I think what you refer to in #4 is what the document calls FGL-edge.

 > Or maybe we are having a violent agreement? if we are at step 2)
 > above, then isn't the entire campus operating in "VL mode"? I.e., at
 > step 2, no one is sending/receiving/processing FGL frames. (Right?)
 >
 > It's not until step 3/4 that you see *any* FGL frames being used. And
 > for that, you can't have *any* RBs still operating only in VL mode -
 > they *all* have to support FGL.

While the above 1-4 is a reasonable way to deploy FGL, the protocol 
mechanisms must be robust against there (perhaps accidentally) being VL 
RBridges when FGL-edges are in use; whether that is because not all was 
upgraded to FGL-safe, or after everything is FGL-safe someone (perhaps 
accidentally) connects one or more VL RBridges to the network.

That is why we have the rules about safety - not forwarding a FGL frame 
to a VL RBridge.

Regards,
    Erik