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

[Donald Eastlake <[e-mail]>]

Hi Olen,

On Mon, Nov 26, 2012 at 10:09 AM, Olen Stokes
<[e-mail]> wrote:
> From Donald below:
>
> "If an RBridge has been modified from existing legacy VL RBridge so that you can safely use it as a transit node, then it *is* an FGL RBridge (even if it is a limited FGL RBridge that can't do FGL ingress and egress). If it has not been so modified, then it remains a VL RBridge and will likely mishandle or discard and FGL frames it receives."
>
> We seem to be moving in the direction where RBridges with differing capabilities are all considered to be FGL RBridges.  Do we need to consider advertising the differences in capabilities in the ISIS extensions for FGL?

I don't think so in this case.

It seems to me that there isn't a need to distinguish a limited FGL
TRILL switch (FGL transit only) from a full FGL TRILL switch (FGL
ingress, transit, and egress) in the link state. A port doesn't
ingress to FGL unless it is configured to do so and you can't
configure a port of a limited FGL TRILL switch that way. And an FGL
TRILL Data frame can't be egressed at a port unless the port is
labeled with the same FGL label as the frame which can't be done with
a limited FLG TRILL switch.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Cheers,
> Olen
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Donald Eastlake
> Sent: Friday, November 23, 2012 2:39 PM
> To: Phanidhar Koganti
> Cc: Anoop Ghanwani; [e-mail]
> Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt
>
> Hi Phanidhar,
>
> On Tue, Nov 20, 2012 at 2:29 PM, Phanidhar Koganti <[e-mail]> wrote:
>> 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]>
>   wrote:
>>
>> Hi Radia,
>>
>> On Mon, Nov 19, 2012 at 11:13 PM, Radia Perlman
>  <[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?  >
>>
>> <Donald> 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.)
>>
>> <Anoop> 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 RBridges being reachable from the same
>> RBridge port, otherwise it would be challenging to implement this
>> control for multicast frames.
>
> I am not sure what you mean by "disallow" but if some physical topology is trivially realizable by someone plugging in the wrong cables, you have to take it into account and say what happens. In this case, where FGL and non-FGL RBridges are on the same link, the FGL RBridges just refuse to report any adjacencies on the link, thus excommunicating the link for TRILL Data traffic.
>
>> [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.
>
> If an RBridge has been modified from existing legacy VL RBridge so that you can safely use it as a transit node, then it *is* an FGL RBridge (even if it is a limited FGL RBridge that can't do FGL ingress and egress). If it has not been so modified, then it remains a VL RBridge and will likely mishandle or discard and FGL frames it receives.
>
>>> <Radia> And we're assuming that old edge RBs that only do VL will
>>> know to drop something tagged with FGL?
>
> I believe they should but it does not seem wise to depend on that.
>
>> <Donald> 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.
>>
>> <Anoop> 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.
>
> In the draft, ports have an FGL/VL configuration "mode" for ingressing/egressing native frames but that don't have any "mode" for TRILL Data frames. If they are a VL RBridge, they can only handle VL TRILL Data frames. If they are an FGL RBridge, the can handle both VL and FGL TRILL Data frames.
>
>> Anoop
>
> Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA  [e-mail] _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill