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

[Thomas Narten <[e-mail]>]

Hi Donald.

Donald Eastlake <[e-mail]> writes:


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

Personally, I thought the wording was somewhat odd, and made a note to
figure out what the real intention was. :-) Also, "MAY" means it's not
part of the spec, but not being disallowed either. That is not the
same thing as saying it is something that implementations would want
or need to do.

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

No disagreement. My assumption had been that if you have an RB that
understands both VL and FGL, that such a mode would only be useful if
one was converting from one format to the other, or if one fell back
from from FGL to VL mode if it didn't make sense to operate in FGL
mode. But I wasn't 100% sure what the draft's intention was...

But on rereading parts of the draft, it seems that a single TRILL
campus can actually consist of a mixture of both VL and FGL-capable
RBs. And that campus is effectively partitioned, where some of the
links/RBs operate in FGL mode (only) and the rest operate in VL mode
(only) with the data planes of the "two networks" operating likes
ships in the night.

You can even have a single RB supporting both modes (on some
links). E.g., you could have RB1 with links L1 and L2 operating in VL
mode and links L3 and L4 operating in FGL mode. Right? (This is
because it is the individual links that operate in a given mode, not
the RB per se.)

If so, let me push back on this model.  The document says:

   The usual DRB election operates on a link with mixed FLG and VL
   ports. If an FGL RBridge port is DRB, it MUST handle all native
   traffic or appoint only other FGL ports as forwarder for one or more
   VLANs, so that all end stations will get service to the FGL campus.
   If a VL RBridge port is DRB, it will not understand that FGL RBridge
   ports are different. To the extent that a VL DRB handles native
   frames or appoints other VL ports on a link to handle native frames
   for one or more VLANs, the end stations sending and receiving those
   native frames will be isolated from the FGL campus. To the extent
   that a VL DRB happens to appoint an FGL port as Appointed Forwarder
   for one or more VLANs, the end stations sending and receiving native
   frames in those VLANs will get service to the FGL campus. This
   somewhat odd corner case behavior is considered acceptable because it
   is assumed that VL TRILL switches in an FGL campus are infrequent
   misconfigurations.

I would not just call this a "corner case" that can be ignored. What
it seems to mean is that you can deply TRILL, but get disconnected
VLAN islands. That is, C-VID X at one edge is processed by FGL RBs
(say RB1), but elsewhere on the network, only VL RBs connect to C-VID
X (say via RB2). Because the VL and FGL networks are isolated from
each other, the result is that devices in VLAN X connected to RB1 will
be unable to communicated with devices in VLAN X connected to
RB2. Right?

I wouldn't consider that a "corner case" to be ignored. I'd consider
that an operational nightmare that can't be allowed to happen (by
default).

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

Why must FGL capable devices be required to support VL? I understand
that it is probably a good thing to do (so you can support either
mode, depending on what other RBs are capable of). But does the FGL
*protocol* require this in order to work correctly? Does proper
operation of FGL require being able to support VL as well? Or is the
real intent just to allow a graceful way to "fall back" into VL mode
to intereperate with non FGL-aware RBs? (I think that is a fine thing
to require, btw.)

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

IMO, this spec should not say anything about multi-topology (that is
future work) and should ensure that a standards compliant
implementation cannot and will not forward FGL packets to VL-only
RBs. Anything else will likely lead to operational problems...

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

I think this is an unreasonable assumption. You will get deployments
that have both. Accidents can happen, etc. I think we'd be better off
with very clear ways for the operator to specify what they want to
have happen in a mixed mode. We can have a default mode, but the
operator needs to be able to override the defaults.

I.e., if only one (or a small number of) switches supports FGL, you
want the default mode to be to have the entire TRILL campus to try to
use FGL? I'm not sure. 

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

I don't understand the "security policy" reference here.

> Maybe clarifying text should be added and the "FGL RBridges" should be
> referred to as "FGLVL RBridges".

No. The issue isn't terminology. The text needs to be clearer what the
intention is. For me, it's sometimes hard to pull out the overriding
intention from the specific rules that are layed out in the document.

Thomas