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

From: Haoweiguo <[email-masked]>
Date: Fri, 1 Feb 2013 09:11:48 +0000

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 [[email-masked]]
发送时间: 2013年2月1日 4:24
到: Tissa Senevirathne (tsenevir)
Cc: Anoop Ghanwani; Ayan Banerjee; Sam Aldrin; [email-masked]; 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 edge, 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

---

From: Radia Perlman <[email-masked]>
Date: Fri, 1 Feb 2013 02:45:30 -0800

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 <[email-masked]> wrote:

> 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 [[email-masked]]
> *发送时间:* 2013年2月1日 4:24
>
> *到:* Tissa Senevirathne (tsenevir)
> *Cc:* Anoop Ghanwani; Ayan Banerjee; Sam Aldrin; [email-masked]; Donald
> Eastlake; Jon Hudson
> *主题:* Re: [trill] Explaining three options for upgrading to FGL
> (fine-grained-labeling)
>
>   Tissa said:
> "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
>
> 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:
>
> 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.
>
> >>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
>
>
>

---

From: Haoweiguo <[email-masked]>
Date: Sat, 2 Feb 2013 13:50:31 +0000

OK. I understand. I agree with your definition of "safe FGL".

thanks

weiguo

________________________________
发件人: Radia Perlman [[email-masked]]
发送时间: 2013年2月1日 18:45
到: Haoweiguo
Cc: Tissa Senevirathne (tsenevir); Anoop Ghanwani; Ayan Banerjee; Sam Aldrin; [email-masked]; Donald Eastlake; Jon Hudson
主题: Re: 答复: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)

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.

Radia

On Fri, Feb 1, 2013 at 1:11 AM, Haoweiguo <[email-masked]<mailto:[email-masked]>> wrote:

Hi Radia,

[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 [[email-masked]<mailto:[email-masked]>]
发送时间: 2013年2月1日 4:24

到: Tissa Senevirathne (tsenevir)
Cc: Anoop Ghanwani; Ayan Banerjee; Sam Aldrin; [email-masked]<mailto:[email-masked]>; Donald Eastlake; Jon Hudson
主题: Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)

---------

----

Radia

---

From: Jon Hudson <[email-masked]>
Date: Sun, 3 Feb 2013 02:35:37 -0800

Well one can certainly hope that FGLs end up in the core and VLs at the edge. However even when included in a design guide or offered as "best practice" this will not always be true. The best rule for users is "If it can be done, they will do it"

So in the end what we are really impacting here is volume of support calls for anyone currently shipping non FGL aware switches. 

On Jan 31, 2013, at 7:18 AM, "Tissa Senevirathne (tsenevir)" <[email-masked]> wrote:

> Jon
> 
> You brought up the most import element. Questions Sam asked are extremely valid. What do you mean by "safe FGL", how can you make sure all of the so called "Safe FGL" have consistent behavior, 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 ? We are not talking about control plane we are talking about Hardware.
> 
> Based on your point and with the analogy (though not the exact numbers :) ), we are looking at a limited install base here. For that Do you agree if we say, FGL will always be core of the network, and VL will be at the edge of the network ?
> 
> Thanks
> Tissa
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon Hudson
> Sent: Wednesday, January 30, 2013 11:16 PM
> To: Sam Aldrin
> Cc: Donald Eastlake; Anoop Ghanwani; Radia Perlman; Ayan Banerjee; [email-masked]
> Subject: Re: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)
> 
> Well most of my customers and bound by 3yr depreciation schedules. So any non-FGL devices they have when Full FGl devices ship will not be available for swap-pout. If they have been in service for 2hrs then maybe, but 2.5-3yrs ideal.
> 
> So we expect most scenarios to be the addition of net new full FGL rbridges. Then (hopefully) a software update to the existing non FGLs to some quasi FGL mode ( just so you can take some advantage of the new functionality. Then when the older rbridges run out on the books, then they can be replaced with shiny new full FGL rbridges and now have a full FGL compliant environment.
> 
> But that is just for the small number of customers already running non FGL compliant hardware. (~1000 for Brocade, and then probably more, but lets say 2,000for Cisco)
> 
> For a large majority it will be green field installs all net new. 
> 
> We just don't want to punish those ~3000ish early adopters 
> 
> I have had MUCH difficultly getting customers involved in mail list discussions. So getting someone who is today and operator (as apposed to a recovering operator like myself) isn't super easy.  Needless to say the volume of emails and tone of emails scares a lot of folks away. ( not just a TRILL WG thing, an IETF in general thing)
> 
> 
> On Jan 31, 2013, at 8:25 AM, Sam Aldrin <[email-masked]> wrote:
> 
>> Here is what I meant.
>> 
>> Deployment scenarios could be  upgrading to FGL RBridges via 1) new device insertion OR 2) replacing older devices with FGL supported RBridges OR 3) the so called upgrade to existing hardware to be FGL safe.
>> In each of those cases, the way to do it could differ for the reasons highlighted in various emails.
>> At the end of the day, by moving towards FGL based network, we cannot afford to disrupt existing TRILL network or force to forklift upgrade of non-FGL aware hardware.
>> 
>> Lastly, it would be good to hear from the actual user to understand the pain points in doing one way or the other.
>> 
>> -sam
>> 
>> On Jan 30, 2013, at 12:40 PM, Jon Hudson <[email-masked]> wrote:
>> 
>>> Can you clarify on what you mean by deploy?
>>> 
>>> I ask because I have many customers waiting for this functionality. Everyone of the ~1000 installs we have, that also have multitenancy environments plan to deploy this as soon as possible. 
>>> 
>>> But with no one have I gone through and done a Visio of how their Rbridges are wired up today and how FGL rbridges would be integrated gracefully into the environment.
>>> 
>>> On Jan 31, 2013, at 3:55 AM, Sam Aldrin <[email-masked]> wrote:
>>> 
>>>> [still catching up on email, so the delay]
>>>> 
>>>> When everyone says, upgrade RBridges, what is the upgrade model they have in mind?
>>>> How can one do software upgrade when hardware/silicon cannot support?
>>>> Secondly, any actual users, not vendors, commented on how they plan to deploy FGL?
>>>> 
>>>> -sam
>>>> 
>>>> On Jan 29, 2013, at 4:37 PM, Donald Eastlake <[email-masked]> wrote:
>>>> 
>>>>> Hi Anoop,
>>>>> 
>>>>> On Tue, Jan 29, 2013 at 7:03 PM, Anoop Ghanwani <[email-masked]> wrote:
>>>>>> On Tue, Jan 29, 2013 at 12:49 PM, Donald Eastlake <[email-masked]> wrote:
>>>>>> 
>>>>>>> The general assumption is that you are migrating from VL to FGL. 
>>>>>>> First you migrate to FGL-safe. Then you unleash the FGL traffic, 
>>>>>>> by configuring FGL ports, which isolates any remaining 
>>>>>>> (FGL-unsafe) VL switches while still being able to handle VL 
>>>>>>> traffic between VL ports on FGL-safe switches.
>>>>>> 
>>>>>> Based on what is written so far, it looks like as long as there is 
>>>>>> even one VL RBridge in it's database, an RBridge would not be able 
>>>>>> to start sourcing FGL traffic.  It may start doing so only when 
>>>>>> all RBridges in
>>>>> 
>>>>> Well, it can start sourcing FGL traffic but their are consequences 
>>>>> as you note below.
>>>>> 
>>>>>> its database are FGL-safe.  If we ever get into a condition where 
>>>>>> an RBridge has started advertising FGL information, at that point, 
>>>>>> does any other RBridge in the campus simply isolate any VL RBridge 
>>>>>> (with the assumption that there was some kind of race condition?
>>>>> 
>>>>> Yes. (This could just be due to some misconfiguration.)
>>>>> 
>>>>>> The case I'm concerned about is we have 2 FGL RBridges, RB1 and RB2.
>>>>>> RB1 is connected to a campus of n RBs that are still VL only.  The 
>>>>>> VL link Breaks, and RB1 starts advertising FGL information to RB2, 
>>>>>> but then the link to the VL campus comes back up.  Does this mean 
>>>>>> RB1 and RB2 remain isolated from the campus (and operate as they 
>>>>>> own mini-campus) until all the other RBridges are converted over to FGL-safe?
>>>>> 
>>>>> Yes. But I don't think this as much of a problem given that I 
>>>>> believe existing TRILL switches can be software upgraded to be 
>>>>> FGL-safe. I view the configuration of FGL ports on RB1/RB2 and the 
>>>>> consequent routing of actual FGL traffic to be an active network 
>>>>> management decision, not something that might just happen because 
>>>>> there appear to be no more VL TRILL switches in the topology.
>>>>> 
>>>>> Thanks,
>>>>> Donald
>>>>> =============================
>>>>> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>>>> 155 Beaver Street, Milford, MA 01757 USA [email-masked]
>>>>> 
>>>>>> Anoop
>>>>> _______________________________________________
>>>>> trill mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/trill
>>>> 
>>>> _______________________________________________
>>>> trill mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/trill
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill