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

[Xuxiaohu <[e-mail]>]

发件人: Xuxiaohu
发送时间: 2012年11月22日 10:10
收件人: 'Radia Perlman'; Rajeev Manur
抄送: Thomas Narten; Donald Eastlake; [e-mail]
主题: re: [trill] WG Last Call: draft-ietf-trill-fine-labeling-02.txt



发件人: [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?

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]<mailto:[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]> [mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:

>Hi Donald.
>
>Donald Eastlake <[e-mail]<mailto:[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]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/trill

_______________________________________________
trill mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/trill


_______________________________________________
trill mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/trill