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

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 <aldrin.ietf@gmail.com> 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 <d3e3e3@gmail.com> wrote:
> 
>> Hi Anoop,
>> 
>> On Tue, Jan 29, 2013 at 7:03 PM, Anoop Ghanwani <anoop@alumni.duke.edu> wrote:
>>> On Tue, Jan 29, 2013 at 12:49 PM, Donald Eastlake <d3e3e3@gmail.com> 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
>> d3e3e3@gmail.com
>> 
>>> Anoop
>> _______________________________________________
>> trill mailing list
>> trill@ietf.org
>> https://www.ietf.org/mailman/listinfo/trill
> 
> _______________________________________________
> trill mailing list
> trill@ietf.org
> https://www.ietf.org/mailman/listinfo/trill