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

[Radia Perlman <[e-mail]>]

I'd think it ought to be possible to have a really simple transit-only RB
R that doesn't bother looking beyond the TRILL header...so doesn't care
what VLAN or FGL it is...R won't do any filtering, but filtering is only an
optimization, except at the edges, where it is mandatory.

Anyway...back to two tags vs a single 24-bit tag...we really have to pick
one and go with it.  Either one works, and although one tag might be a bit
more elegant, I've informally asked some implementers and some of them said
they don't care, and others say they prefer two 12-bit pieces in two tags,
so I vote that we stick with that.

As for the spec...yeah, as people pointed out, there are places where the
spec could be clarified, and we should do that.

Of the combinations possible, which should be described in the spec?

I think FGL+VL, and VL definitely.  And the base spec already describes
VL-only.

We might also want to mention neither FGL nor VL (transit only, no
filtering).

We might also want to mention eventually dropping support for VL, and
allowing a mixture of FGL+VL and FGL-only.  But for simplicity, I think we
should not describe that variant at that point, and only describe (in this
document), FGL+VL and its interoperability with VL-only.

Does anyone have any strong opinions?

Radia

On Wed, Nov 21, 2012 at 11:24 AM, Rajeev Manur <[e-mail]> wrote:

>
> My understanding is we have only 2 modes, VL-mode and FGL-mode (superset
> mode supporting both VL and FGL). I feel it would be useful to add more
> text to clarify the processing/compliance requirements for ingress /
> transit / egress RB contexts separately for each of these two modes. This
> will help implementations they may want to support transit only functions
> and still be compliant.
>
> For example, it is not clear to me when an RB wants to operate as
> transit-only RB, VL/FGL capability can be configured per port or all ports
> on that RB must be configured to operate in the same mode? I am assuming it
> is the latter.
>
> Thanks!
> --Rajeev
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Olen Stokes
> Sent: Tuesday, November 20, 2012 9:08 PM
> To: Thomas Narten; Donald Eastlake
> Cc: [e-mail]
> Subject: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt
>
>
> Trying NOT to add anything more in lineŠ
>
> It seems that multiple different people have multiple different migration
> scenarios in mind.  I think that several of us could benefit from
> something that better spells out what scenario(s) the authors have in
> mind.  Donald's scenarios described in his response to my previous email
> would have helped the draft.  We can then discuss if there are others that
> need to be considered.
>
> We seem to be discussing three types of nodes:
>
> 1) VL-only capable RBridges
> 2) VL and FGL capable RBridges
> 3) FGL-only capable Rbridges
>
> For the third (FGL-only) type, remember that at some point people will
> want to drop support for the VL RBridges.  There may also be silicon out
> that that can operate in VL mode or in FGL mode but not both at the same
> time.  Note, I am not a silicon person.
>
> If these three types are intended, a more clear statement of the
> requirements for each time might be of benefit.  The requirements should
> describe ingress, egress, transit, and transit plus egress RBridges. If
> one of these types is not intended, then a clear statement that it is not
> supported may be in order.  It could then be debated.
>
> I believe that Donald has described that the second type above (VL and FGL
> capable RBridge) is a requirement.  To me, the best case for that
> requirement is in a multi-topolgy environment.  Stating that use case
> would have made the document and that requirement more clear to me.  I
> leave it to others to figure out how to reference something that might be
> defined in another draft (at some point in the future).  Note that to me,
> a "VL and FGL capable" node acting only as a VL node is just a VL RBridge.
>
> Cheers,
> Olen
>
>
> On 11/20/12 7:35 AM, "Thomas Narten" <[e-mail]> wrote:
>
> >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
> >
> >_______________________________________________
> >trill mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/trill
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>