Re: [trill] 答复: Explaining three options for upgrading to FGL (fine-grained-labeling)

[Radia Perlman <[e-mail]>]

I think you were just misinterpreting what I wrote.  It is OK to let things
through that could be pruned.  It is *not* OK to falsely delete things.
The example I gave of interpreting the first FGL label as a VL label is
something that the RBridge MUST NOT do.

So we're not disagreeing.

Radia

On Fri, Feb 1, 2013 at 1:11 AM, Haoweiguo <[e-mail]> wrote:

>  Hi Radia,
>
> I agree with your definition of "Safe FGL",but I have a problem about the
> following point:
>
>
> b) multicast pruning: it's OK not to do pruning at all, or to actually
> look at all 24 bits of the FGL and prune as a proper FGL guy would do.  But
> an example of what you canNOT do is look at the first 12 bits of FGL,
> pretend it's the same as VL, and delete the multicast packet because nobody
> downstream is listening to that 12 bit VL value
>
> [weiguo]:If a switch performs pruning by first 12 bits of FGL, can the
> switch called "Safe FGL" switch? If downstream have one VL switch with VLAN
> is equal to first 12 bits of FGL,then the switch will forward multicast
> data frame to downstream VL switch.
> thanks
> weiguo
>  ------------------------------
> *发件人:* Radia Perlman [[e-mail]]
> *发送时间:* 2013年2月1日 4:24
>
> *到:* Tissa Senevirathne (tsenevir)
> *Cc:* Anoop Ghanwani; Ayan Banerjee; Sam Aldrin; [e-mail]; Donald
> Eastlake; Jon Hudson
> *主题:* Re: [trill] Explaining three options for upgrading to FGL
> (fine-grained-labeling)
>
>   Tissa said:
> >> how can you make sure all of the so called "Safe FGL" have consistent
> behavior
>
> "Safe FGL" need not all have the *same* behavior as each other...they
> just have to do "nothing bad" with an FGL frame.  It's worth summarizing
> (again) what it means to be "FGL-safe", which allows you to coexist safely
> with FGL frames.  To be FGL-safe you must do the following:
>
> a) unicast: you MUST NOT drop a packet because of seeing the unrecognized
> FGL tag.  You also MUST NOT get confused and do flow hashing improperly
> (choosing different paths for packets for the same flow).
>
> b) multicast pruning: it's OK not to do pruning at all, or to actually
> look at all 24 bits of the FGL and prune as a proper FGL guy would do.  But
> an example of what you canNOT do is look at the first 12 bits of FGL,
> pretend it's the same as VL, and delete the multicast packet because nobody
> downstream is listening to that 12 bit VL value
>
> c) egress of either unicast or multicast:  you MUST NOT egress an FGL
> frame onto a link that is not supposed to get that FGL value
>
> d) you have to advertise that you are FGL-safe...otherwise other RBs will
> assume you are VL ("FGL-unsafe")
>
> ---------
> Also, TIssa said:
> >>Do you agree if we say, FGL will always be core of the network, and VL
> will be at the edge of the network ?
>
> With option 2, a VL guy *cannot even be at the edge of a network with FGL
> links* unless it is upgraded to FGL-safe AND advertises that it is
> FGL-safe.  Option 2 says a VL guy is completely ostrasized once FGL-labeled
> links are introduced.  There is NO coexistence of VL guys and FGL-links.
> The only kinds of coexistence in option 2 are:
>
> a) VL and FGL-safe RBridge, but no actual FGL links yet.
> b) FGL-safe guys, even if some of them don't really understand FGL, but
> just don't do "anything bad" with it, and FGL frames.
>
> So...again...the migration phases in option 2 are
> 1) VL-only (today's deployment), then
> 2) A mixture of VL and FGL-safe, until
> 3) EVERYone upgraded to FGL-safe, then
> 4) FGL-links can be introduced.
>
>
> ----
> Also, Tissa said:
> >>what about some devices who are not "safe FGL" and so on, are we saying
> do not buy no safe FGL devices, if you do that you cannot get FGL interop ?
>
> *If* it's important to have VL guys as transit, and they cannot be
> upgraded to FGL-safe because upgrading requires a hardware change (it
> involves parsing data packets), then we are stuck with option 3.  In option
> 3, we can forever have VL guys at the edge speaking through an FGL-safe or
> full-FGL core.  In option 2, as I said, there is *no coexistence* of VL
> guys, *even at the edg*e, once FGL links are introduced.  In option 2, a
> VL guy, even at the edge, will be ostrasized completely once anyone
> advertises connectivity to an FGL link.
>
> I personally like option 2, because it's simple, but as Einstein said
> "make things as simple as possible, but no simpler".  We have to make sure
> that everyone understands the implications of option 2, and can live with
> them.  To summarize again (since there seems to be some confusion about
> what the implications of option 2 are),
>
> If we can upgrade all existing VL implementations to FGL-safe through
> software upgrade only, then option 2 provides smooth migration by changing
> ALL RBridges (edge as well as transit) to FGL-safe, and only after ALL of
> them are upgraded, then FGL-labeled links can be introduced.  If there are
> any remaining VL guys once FGL-labeled links are introduced, the VL guys
> are ostrasized, *even if they are just at the edge.*
>
> If we canNOT upgrade all existing VL to FGL-safe, AND if it's important to
> be able to mix VL guys into a network with FGL frames (say, having VL guys
> at the edge), then option 3 allows this.
>
> So hopefully everyone understands the implications of option 2 fully
> before voting.  As I said, I don't know about whether there are VL chips
> that would require a hardware upgrade to become FGL-safe.  Assuming there
> are none, then I'm quite happy with option 2.   And actually, it looks like
> people are converging on option 2 (though I hope it's based on fully
> understanding option 2).  Now is the time for people to speak up, that know
> of problems this would cause...for instance, needing to have non-upgradable
> VL guys at the edge for a long time.
>
> Radia
>
>
>