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

[Donald Eastlake <[e-mail]>]

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?

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.)

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

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

> Radia
>
> On Mon, Nov 19, 2012 at 7:24 PM, Donald Eastlake <[e-mail]> wrote:
>>
>> Hi Thomas,
>>
>> I guess the draft is not as clear as I thought it was.
>>
>> On Mon, Nov 19, 2012 at 8:40 PM, Thomas Narten <[e-mail]> wrote:
>> > Hi.
>> >
>> > Donald Eastlake <[e-mail]> writes:
>> >
>> >> Yes, an FGL RBridge must support Fine Grained Labeling (FGL) and
>> >> support VLAN Labeling (VL) as the inner data label. In other words, an
>> >> FGL RBridge must be able to ingress a native frame to an FGL TRILL
>> >> data frame, handle an FGL TRILL data frame as a transit switch, and
>> >> egress an FGL TRILL data frame to a native frame. In addition, an FGL
>> >> RBridge must be able to ingress a native frame to a VL TRILL data
>> >> frame, handle a VL TRILL data frame as a transit switch, and egress a
>> >> VL TRILL data frame as a native frame, all this VL stuff as described
>> >> in the TRILL base protocol RFC 6325.
>> >
>> > I'm still a bit confused by this discussion.
>> >
>> > My understanding (from reading the draft earlier today) was that an RB
>> > either operates in FGL mode or VL mode. It doesn't mix and
>> > match. I.e., you don't have an RB with some ports understanding FGL
>> > and others VL.  (To do that, you'd an RB would have to convert between
>> > the the two formats which could result in loss of information...)
>>
>> So what exactly did you think text like the following meant:
>>    "An FGL RBridge MAY be configured, on one or more ports, to ingress
>>    native frames as FGL. Any ports not so configured that accepts a
>>    native frame perform the previously specified VL ingress processing
>>    on native frames [RFC6325]."
>>
>> I also can't see why you would think that the ability to ingress,
>> transit, and egress both VL and FGL frames implies having to "convert"
>> between those formats. The whole idea of data labeling is
>> separation/isolation. Why would you convert between them anymore than
>> you would convert between a random pair of different VLANs?
>>
>> Anyway, the intent is that ports operate in either VL or FGL mode. And
>> all the ports of a VL RBridge are VL ports. But an FGL RBridge is
>> required to support an arbitrary mix of VL and FGL ports. VL and FGL
>> frames are ships in the night just like VL frames for different VLANs
>> for FGL frames for different FGLs.
>>
>> > And the way to look at VL mode, is that it is the fallback for the
>> > case where not all of the RBs in the compus are FGL capable.
>>
>> The word "mode" does not occur anywhere in the body of the draft. FGL
>> RBridges are supersets. FGL RBridges can handle VL frames fine. It is
>> just that VL RBridges can't handle FGL frames and it is very hard to
>> guarantee that an FGL frame will never be routed to a VL RBridge
>> without either multi-topology (which is not yet fully specified for
>> TRILL) or stopping all data flow between VL and FGL RBridges (whcih is
>> what this draft does).
>>
>> > Is my understanding correct?
>>
>> See above.
>>
>> > Skimming the document again, this could perhaps be clearer.
>>
>> I guess so.
>>
>> > I.e., what is supposed o happen in a campus where some RBs say they do
>> > FGL and others do not? Is the intention that one TRILL campus gets
>> > formed with all nodes falling back to VL mode?
>>
>> As stated in the draft, the assumption in that case is that you wanted
>> a completely FGL campus and whatever VL RBridges are present are
>> isolated misconfigurations. So the provisions are that all the
>> RBridges peer for control but VL and FGL RBridges do not peer for
>> data. You don't want the attachment of one RBridge misconfigured to be
>> a VL RBridge to kill your whole FGL campus. You can't "fall back" a
>> port configured for FGL without violating security policy.
>>
>> Maybe clarifying text should be added and the "FGL RBridges" should be
>> referred to as "FGLVL RBridges".
>>
>> Thanks,
>> Donald
>> =============================
>>  Donald E. Eastlake 3rd   [phone] (cell)
>>  155 Beaver Street, Milford, MA 01757 USA
>>  [e-mail]
>>
>> > Thomas
>> >
>>
>> _______________________________________________
>> trill mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trill
>
>