Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt

[Phanidhar Koganti <[e-mail]>]

From: [e-mail] [mailto:[e-mail]] On Behalf Of Anoop Ghanwani
Sent: Wednesday, November 21, 2012 12:50 AM
To: Donald Eastlake
Cc: Radia Perlman; [e-mail]
Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt


On Mon, Nov 19, 2012 at 8:29 PM, Donald Eastlake <[e-mail]<mailto:[e-mail]>> wrote:
Hi Radia,

On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman <[e-mail]<mailto:[e-mail]>> wrote:
> Ah.  So the intent is that an FGL RBridge must be able to parse either VL or
> FGL, which would allow an edge RB that only supports VL to work OK, and to
> have some number of VLANs (4000 of them) that would be reachable via old
> edge RBs?
Yes on parsing. But it is hard to be sure no FGL frame can get to a VL
RBridge. Say you have VLRB1 connected to the campus through FGLRB2.
And FGLRB2 is connected to FGLRB3. What if connectivity appears
between VLRB1 and FGLRB3 and perhaps the link between FGLRB2 and
FGLRB3 breaks? How can you stop FGL frames from going between FGLRB2
and FGLRB3 via VLRB1 keeping in mind that you have to assume no
changes in the old VL RBridges? (Without multi-topology. With
multi-topology, it's relatively easy.)

FGL frames should never be forwarded to an RB that doesn't
support FGL.  This is easy to figure out since IS-IS can tell us
what the capabilities of an RBridge are before forwarding to
that RBridge begins.  And as a result of this requirement, we
should probably disallow FGL and non-FGL bridges being
reachable from the same RBridge port, otherwise it would be
challenging to implement this control for multicast frames.
[Phanidhar Koganti] Does this mean non-FGL RBridges cannot act as transit nodes? Why can't the transit nodes just rely on TRILL SA/DA to forward. Agree there will be issues for multicast in terms of the optimal pruned forwarding as a non-FGL RB will not have access to the inner IP header or VLAN (FGL based). However isn't this an optimization for multicast pruning? The transit RBs can forward based on the non-pruned multicast tree.


> And we're assuming that old edge RBs that only do VL will know to drop
> something tagged with FGL?
A VL RBridge should, in my opinion, drop an FGL frame based on RFC
6325. However, if it did not, it would presumably mean it was ignoring
the 0x893B value where it should be requiring 0x8100. As a result, it
would believe the FGL frame was in some VLAN and might egress it to
the wrong end-stations, violating security policy.

We need to make the spec clear on this aspect; i.e. FGL or non-FGL
RBridges must discard a received frame if the inner tag (FGL or VLAN
depending on what mode the port is operating in) is absent.

Anoop