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

[Donald Eastlake <[e-mail]>]

On Wed, Nov 21, 2012 at 9:09 PM, Xuxiaohu <[e-mail]> wrote:
>
>
> 发件人: [e-mail] [mailto:[e-mail]] 代表 Radia Perlman
> 发送时间: 2012年11月22日 7:29
> 收件人: Rajeev Manur
> 抄送: Thomas Narten; Donald Eastlake; [e-mail]
> 主题: Re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt
>
>
> 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.
>
>
>
> Does it ought to have another type of transit RB which needs to do filtering
> but can’t do it based on the full FGL due to some reasons (e.g. the lack of
> enough hardware memory capability)? For example, it could do a
> coarse-grained filtering based on partial bits in the FGL. In other words,
> The transit RB could have a flexibility to determine how many bits (0~24) in
> the FGL would be used for filtering.
>
>
>
> 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.
>
>
>
> Since there is no need to worry about the backwards compatibility anymore,
> could you please explain why others prefer two 12-bit tags to a single
> 24-bit tag?

Already existing silicon.

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


> Best regards,
>
> Xiaohu
>
>
>
> 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
>
>