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

[Radia Perlman <[e-mail]>]

Hi Olen,

Re your first comment:  I was not intending to differentiate pruning based
on IP multicast vs FGL...I should have said "multidestination" instead of
"multicast".  So we are not disagreeing on anything here...you just
interpreted my word "multicast" differently than I intended.  Sorry for the
confusion.

Re your second comment:

[OLS]: Just to double check...  Following step #4 above, FGL-safe RBridges
on the edge should still be able to send/receive VL frames.  This allows
migration for devices on the edge that can be made FGL-safe but cannot
ingress/egress FGL frames.  ****

[/OLS]



Yes...that is true.  It is fine for an FGL-safe guy not to be quite smart
enough to ingress/egress FGL.  All it has to do is to be able to follow all
the rules for "FGL-safe".  But....see the new thread...there's a proposed
tweak to option 2 that even allows a VL-guy to coexist, so long as FGL guys
do a bit more work....see the description in the "tweak" thread.



Radia




On Thu, Jan 31, 2013 at 2:00 PM, Olen Stokes <[e-mail]>wrote:

>  Thanks for consolidating these topics.  Please see two [OLS] comments in
> line…****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Radia Perlman
> *Sent:* Thursday, January 31, 2013 3:24 PM
> *To:* Tissa Senevirathne (tsenevir)
> *Cc:* Anoop Ghanwani; Ayan Banerjee; Sam Aldrin; [e-mail]; Donald
> Eastlake; Jon Hudson
>
> *Subject:* 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****
>
> ** **
>
> [OLS]: I believe that there is still FGL-based pruning and multicast
> pruning.  It should be OK to do FGL-based pruning and not do multicast
> pruning.  For FGL-based pruning, I agree that a FGL-safe node cannot look
> at the first 12 bits of FGL and just “pretend it’s the same as VL”.
> However, it should be possible for the control plane to determine all FGL’s
> that have the same first 12 bits of FGL.  Such a control plane should be
> able to set up FGL-based pruning for each leg of a D-Tree based on the
> existence of listeners downstream belonging to the collection of FGL’s with
> the same first 12 bits.  ****
>
> [/OLS]****
>
> ** **
>
> 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.****
>
> ** **
>
> [OLS]: Just to double check...  Following step #4 above, FGL-safe RBridges
> on the edge should still be able to send/receive VL frames.  This allows
> migration for devices on the edge that can be made FGL-safe but cannot
> ingress/egress FGL frames.  ****
>
> [/OLS]****
>
> ** **
>
> ----****
>
> 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****
>
> ** **
>
> ** **
>