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

[Phanidhar Koganti <[e-mail]>]

Hi Donald,

Please see below inline

-----Original Message-----
From: Donald Eastlake [mailto:[e-mail]] 
Sent: Saturday, November 24, 2012 1:09 AM
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.
[Phanidhar Koganti] Understand and my concern is to strictly state that a VL only RBridge will never become a transit RB. There can be deployments where customers might want to reuse their older hardware for transit only where table sizes or VLAN aware might not be necessary. The transit VL-RBs need not have any non-TRILL ports. 

>> <Radia> And we're assuming that old edge RBs that only do VL will 
>> know to drop something tagged with FGL?
[Phanidhar Koganti] Yes or there are no non-TRILL ports so the VL-RB is only a pure transit RB.

I believe they should but it does not seem wise to depend on that.
[Phanidhar Koganti] True we cannot generalize and make such assumptions but on the goal to fit into existing VL-RB environments, should we not give some room for VL only RB hardwares that are potentially capable of such selective drops? 

> <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]