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

[Donald Eastlake <[e-mail]>]

Hi Ayan,

On Tue, Jan 29, 2013 at 2:45 PM, Ayan Banerjee <[e-mail]> wrote:
> I agree with Anoop here.
>
> I think that we are describing a network that is FGL-safe and ready and then
> switch to FGL-mode. However, we need some statements to account for a
> VL-node coming-in/leaving-the network due to a flaky link.

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.

After you have unleashed FGL traffic, it would certainly be possible
that a VL switch could be attached to the network or come and go due
to a flakey link, but this would have almost no effect. With FGL
traffic being handled, VL switches are isolated.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> Thanks,
> Ayan
>
>
>
> On Tue, Jan 29, 2013 at 6:42 AM, Anoop Ghanwani <[e-mail]>
> wrote:
>>
>> At noted, option 1 looks dangerous so that should be ruled out.
>>
>> Option 2 seems reasonable.  It might be useful to clarify a couple of
>> things:
>> - Can the FGL-safe campus have both VLAN & FGL frames going around?
>> - Do all RBridges need to agree on when the campus is FGL-safe?  I would
>>   hope not.  But the problem I'm thinking about is where RB1 thinks
>> the campus is
>>   FGL-safe and starts announcing attachment to FGL links, but RB2 hadn't
>> yet
>>   concluded that process and it see RB3 which happens to be VL.
>>
>> Option 3 seems to introduce more complexity to solve this problem than
>> is necessary.
>>
>> Anoop
>>
>> On Fri, Jan 25, 2013 at 11:00 AM, Radia Perlman <[e-mail]>
>> wrote:
>> > I'm going to summarize three options for phasing-in FGL, and explain the
>> > tradeoffs, to help people have informed opinions about the implications
>> > of
>> > the three approaches.  There are infinite variations, of course, but as
>> > I
>> > said, I'll describe three main ones.
>> >
>> > Option 1:  Original draft, no changes.  There are two types of RBridges.
>> > The
>> > first type is "VL" which only understands VLAN tags, and have unknown
>> > and
>> > possibly dangerous behavior when they receive an FGL-labeled packet.
>> > (e.g.,
>> > decapsulate a packet onto a link where it is not allowed, or mistakenly
>> > prune a multicast so it does not reach everywhere it should). The second
>> > type is "FGL".  FGL guys need to do two things: 1) understand FGL tags
>> > and
>> > do the right thing with them, and 2) ostrasize VL guys...meaning that an
>> > FGL
>> > guy refuses to form an adjacency with a VL guy.  This option is very
>> > simple
>> > for implementers of FGL, but the implication is that you have to upgrade
>> > your entire campus to FGL at once.  There is no coexistence.
>> >
>> > Option 2: Two types of RBridges, but the 2nd type is different from
>> > option
>> > 1.  VL guys of course are the same as in option 1...they cannot be
>> > trusted
>> > with FGL frames. The second type I will call "FGL-safe". An FGL-safe
>> > RBridge
>> > must advertise in its LSP that it is FGL-safe, and it must not "do
>> > anything
>> > bad" with FGL frames, meaning that it is allowed to ignore pruning of
>> > FGL
>> > (or even VL frames) entirely...it just can't falsely drop FGL frames.
>> > And
>> > it must not decapsulate an FGL frame onto a link for which that FGL
>> > frame
>> > doesn't belong. In this option, all RBridges must be upgraded to
>> > FGL-safe,
>> > but it need not happen instantaneously...it's fine to mix FGL-safe
>> > RBridges
>> > with VL RBridges...it's just not safe to inject FGL frames yet.  Once
>> > all
>> > the RBridges have been upgraded to be FGL-safe, then edge RBridges can
>> > start
>> > announcing they are connected to an FGL link, and can start injecting
>> > FGL
>> > packets.  It is considered a misconfiguration if you start injecting FGL
>> > frames before all the RBridges are upgraded to FGL-safe, so an
>> > additional
>> > chore for an FGL-safe RBridge R1 is to examine LSPs, and if any RBridge
>> > claims to be attached to an FGL link, then R1 must ostrasize any VL
>> > neighbors.  (don't start ostrasizing VL guys until it is necessary
>> > because
>> > of actually starting to use FGL frames, in other words). This option is
>> > more
>> > work for the upgraded RBridges than option 1, and there still isn't good
>> > coexistence with VL guys long-term (as option 3 will), but it does allow
>> > upgrading RBridges one by one in a working campus without causing
>> > disruption.
>> >
>> > Option 3: Two types of RBridges.  VL, of course, is the same as in
>> > options 1
>> > and 2.  This option makes FGL guys do more work, but allows maximal long
>> > term coexistence of VL and FGL guys. In this option, FGL guys calculate
>> > unicast paths to FGL edge guys that avoid any VL guys, and calculate at
>> > least one FGL-friendly multicast tree that also avoids any VL guys. So
>> > let's
>> > say R1 is an FGL guy.  R1 discards all LSPs from VL guys (ones that
>> > don't
>> > advertise FGL capability in their LSP), when calculating paths to other
>> > FGL
>> > RBridges. Then R1 calculates paths to the VL guys using all LSPs.
>> > Likewise,
>> > when calculating an FGL-friendly tree, R1 calculates a tree through only
>> > FGL
>> > guys.   This option is more work for the upgraded RBridges (because they
>> > have to calculate Dijkstra in two different ways, one for reaching VL
>> > guys,
>> > and one for reaching FGL guys).  However, it does allow having long-term
>> > coexistence with VL guys.  For instance, you could forever keep some VL
>> > edge
>> > RBridges that communicate just fine through an FGL core.  They can stay
>> > there forever, and still be able to communicate through the core to all
>> > the
>> > links attaching to their VLAN.
>> >
>> > _______________________________________________
>> > trill mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/trill
>> >
>> _______________________________________________
>> trill mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trill
>
>
>
> _______________________________________________
> trill mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trill
>