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

From: Radia Perlman <[email-masked]>
Date: Fri, 25 Jan 2013 11:00:24 -0800

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.

---

From: Haoweiguo <[email-masked]>
Date: Tue, 29 Jan 2013 06:59:17 +0000

Hi Radia,

In option3:

why FGL switches 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? If two FGL switches can only transmit data through VL switch, the method will disconnect data channel between FGL switches. I think VL switch is safe as transit node to tranmit unicast FGL data packet.

thanks

weiguo

________________________________

发件人: Radia Perlman [[email-masked]]
发送时间: 2013年1月26日 3:00
到: [email-masked]
主题: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)

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.

---

From: Radia Perlman <[email-masked]>
Date: Tue, 29 Jan 2013 02:59:10 -0800

Hi Weiguo,

 If we knew that it was already safe to transit FGL frames through VL
nodes, that would be great.  We could basically just start sending FGL
frames, not worry about ostrasizing VL RBridges, not worry about
calculating two forwarding databases.

 But,  I was assuming that there were implementations of VL that might do
bad things if they saw an FGL packet.  For instance, for unicast, they
might drop the packet, or they might decapsulate it onto a link that should
not receive packets for that FGL.  For multicast, they might falsely filter
the packet.  If that assumption is true, then the safe thing is to avoid VL
RBridges for FGL packets, which means calculating paths that do not include
VL RBridges.
.
Thanks,

Radia

On Mon, Jan 28, 2013 at 10:59 PM, Haoweiguo <[email-masked]> wrote:

>  Hi Radia,
>
> In option3:
>
> why FGL switches 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? If two FGL switches can only transmit data through VL
> switch, the method will disconnect data channel between FGL switches. I
> think VL switch is safe as transit node to tranmit unicast FGL data packet.
>
> thanks
>
> weiguo
>
> ------------------------------
>
>  *发件人:* Radia Perlman [[email-masked]]
> *发送时间:* 2013年1月26日 3:00
> *到:* [email-masked]
> *主题:* [trill] Explaining three options for upgrading to FGL
> (fine-grained-labeling)
>
>   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 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
>  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.
>

---

From: Haoweiguo <[email-masked]>
Date: Tue, 29 Jan 2013 13:23:13 +0000

Hi Radia,

For unicast, I think TRILL switch don't care about inner VLAN or FGL and they forward the unicast data frame just by egress nickname. So I think VL switch can support unicast FGL data frame forwarding and have no problem.

For multicast, VL switch can't perform distribution tree pruning by FGL and VL switch has following possible behaviors:

1,VL switch drops FGL multicast data frame because VL switch cares about inner ethtype.The VL switch only support inner ethtype of 0x8100.

2,VL switch don't implement VLAN pruning and forward multicast data frame by broadcast distribution tree.The forwarding key of the broadcast distribution tree is nickname of DST root.The VL switch don't care about inner VLAN or FGL also.Multicast FGL data frame can be forwarded by this kind of VL switch.

3,VL switch implements VLAN pruning and forward multicast data frame by VLAN pruning tree. The forwarding key of the pruning tree is root nickname+inner VLAN.  If the switch cares about accurate inner ethtype(0x8100),FGL data frame will be dropped. If the switch allows random or multiple ethtype,then FGL data frame can be forwarded higher 12 bit of FGL.

thanks

weiguo

发件人: Radia Perlman [[email-masked]]
发送时间: 2013年1月29日 18:59
到: Haoweiguo
Cc: [email-masked]
主题: Re: 答复: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)

Hi Weiguo,

 If we knew that it was already safe to transit FGL frames through VL nodes, that would be great.  We could basically just start sending FGL frames, not worry about ostrasizing VL RBridges, not worry about calculating two forwarding databases.

 But,  I was assuming that there were implementations of VL that might do bad things if they saw an FGL packet.  For instance, for unicast, they might drop the packet, or they might decapsulate it onto a link that should not receive packets for that FGL.  For multicast, they might falsely filter the packet.  If that assumption is true, then the safe thing is to avoid VL RBridges for FGL packets, which means calculating paths that do not include VL RBridges.
.
Thanks,

Radia

On Mon, Jan 28, 2013 at 10:59 PM, Haoweiguo <[email-masked]<mailto:[email-masked]>> wrote:

Hi Radia,

In option3:

thanks

weiguo

发件人: Radia Perlman [[email-masked]<mailto:[email-masked]>]
发送时间: 2013年1月26日 3:00
到: [email-masked]<mailto:[email-masked]>
主题: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 29 Jan 2013 06:42:44 -0800

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 <[email-masked]> wrote:
> 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.
>
> 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
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 29 Jan 2013 10:09:02 -0500

Hi Anoop,

> - Can the FGL-safe campus have both VLAN & FGL frames going around?

Yes.

That is part of the migration idea. There may be FGL-safe TRILL
switches (probably former VL switches with a software upgrade) that
cannot ingress or egress FGL. For an end station attached to such an
FGL-safe TRILL switch to communicate with an end station attached to
some new Full FGL switch, it needs to use VL frames. Or you could have
two end stations attached to RB1 and RB99 that were communicating fine
in a VL campus but you are now adding new FGL switches and upgrading
the core to FGL. Until you actually introduce FGL traffic by
configuring FGL ports, these end stations can continue to communicate
using VL frames through their VL TRILL switches and then through this
new FGL core. As soon as you want to actually introduce FGL traffic
(including multi-destination which can get distributed to every switch
with data connectivity to the campus) you would have to upgrade RB1
and RB99 to be FGL-safe, but the end stations can continue to talk to
each other with VL frames.

>   concluded that process and it see RB3 which happens to be VL.

Well, if you are migrating to FGL, you should upgrade all your VL
TRILL switches to be at least FGL-safe, possibly add new full FGL
switches, and then introduce FGL traffic. It obviously takes a little
time for information to propagate as each VL TRILL switch is upgrade
to be FGL-safe and later that there is a source of true FGL frames at
a TRILL switch in the campus. But all TRILL switches should agree
pretty quickly converge to the same link state database.

> Option 3 seems to introduce more complexity to solve this problem than

I agree.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 29 Jan 2013 11:38:17 -0500

Hi Weiguo,

On Tue, Jan 29, 2013 at 8:23 AM, Haoweiguo <[email-masked]>
wrote:
> Hi Radia,
>
> For unicast, I think TRILL switch don't care about inner VLAN or FGL
> and they forward the unicast data frame just by egress nickname. So
> I think VL switch can support unicast FGL data frame forwarding and
> have no problem.

It is true that the case for unicast is better than the case for
multi-destination. But a VL TRILL switch might (a) drop an FGL frame
as malformed because it does not have 0x8100 after the inner MAC
addresses or (b) do incorrect flow classification for ECMP, resulting
in persistent re-ordering, because it is trying to look deeper into
the frame past the data label and gets confused by an FGL. If it does
either (a) or (b) it is not FGL-safe (although (b) is not as bad as
(a)) and you have to route FGL frames around such VL switches.

> For multicast, VL switch can't perform distribution tree pruning by
> FGL and VL switch has following possible behaviors:
>
> 1,VL switch drops FGL multicast data frame because VL switch cares
> about inner ethtype. The VL switch only support inner ethtype of
> 0x8100.

If it does this, it is not FGL-safe and you have to route FGL traffic
around VL switches.

> 2,VL switch don't implement VLAN pruning and forward multicast data
> frame by broadcast distribution tree. The forwarding key of the
> broadcast distribution tree is nickname of DST root. The VL switch
> don't care about inner VLAN or FGL also Multicast FGL data frame can
> be forwarded by this kind of VL switch.

As far as I know, all TRILL products with silicon fast path support do
implement pruning.

> 3,VL switch implements VLAN pruning and forward multicast data frame
> by VLAN pruning tree. The forwarding key of the pruning tree is root
> nickname+inner VLAN.  If the switch cares about accurate inner
> ethtype(0x8100), FGL data frame will be dropped. If the switch
> allows random or multiple ethtype, then FGL data frame can be
> forwarded higher 12 bit of FGL.

If the VL switch drops frames without the 0x8100, they it is not
FGL-safe and you have to steer FGL traffic around VL switches. If the
VL switch pruning is based on believing that the top 12 bits of the
FGL are a VLAN ID, it will prune incorrect and will not be FGL-safe,
so you have to route FGL traffic around such a VL switch.

And then there is a fourth behavior:

4, VL switch ignores the Ethertype and uses the top 12 bits of the FGL
as a VLAN ID. As a result, it egresses multi-destination frames out
wrong ports in the wrong VLAN and violates security considerations.
This may be the worst of the possible behaviors. Since you cannot tell
if a VL TRILL switch might do this, you cannot trust VL switches to
properly handle FGL traffic.

However, as far as I know, existing silicon based VL TRILL switches
can be upgraded with software changes to be FGL-safe.

Thanks,
Donald

>  If we knew that it was already safe to transit FGL frames through VL nodes,
> that would be great.  We could basically just start sending FGL frames, not
> worry about ostrasizing VL RBridges, not worry about calculating two
> forwarding databases.
>
> bad things if they saw an FGL packet.  For instance, for unicast, they might
> drop the packet, or they might decapsulate it onto a link that should not
> receive packets for that FGL.  For multicast, they might falsely filter the
> packet.  If that assumption is true, then the safe thing is to avoid VL
>> 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.
>>

---

From: Ayan Banerjee <[email-masked]>
Date: Tue, 29 Jan 2013 11:45:02 -0800

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.

Thanks,
Ayan

On Tue, Jan 29, 2013 at 6:42 AM, Anoop Ghanwani <[email-masked]>wrote:

> The
> option
> RBridge
> options 1
> let's

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 29 Jan 2013 15:49:58 -0500

Hi Ayan,

On Tue, Jan 29, 2013 at 2:45 PM, Ayan Banerjee <[email-masked]> 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

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

---

From: Ayan Banerjee <[email-masked]>
Date: Tue, 29 Jan 2013 13:15:31 -0800

Donald,

Yes, realize that would be way to do it - not sure if these options are
being captured in a document, if so it would be great if this also added
there.

Thanks,
Ayan

On Tue, Jan 29, 2013 at 12:49 PM, Donald Eastlake <[email-masked]> wrote:

> then
> >> On Fri, Jan 25, 2013 at 11:00 AM, Radia Perlman <[email-masked]
> >
> >> wrote:
> the
> >> > tradeoffs, to help people have informed opinions about the
> implications
> >> > of
> >> > the three approaches.  There are infinite variations, of course, but
> as
> >> > I
> >> > do the right thing with them, and 2) ostrasize VL guys...meaning that
> an
> >> > FGL
> >> > of actually starting to use FGL frames, in other words). This option
> is
> >> > more
> >> > advertise FGL capability in their LSP), when calculating paths to
> other
> >> > FGL
> >> > when calculating an FGL-friendly tree, R1 calculates a tree through
> only
> >> > FGL
> >> > coexistence with VL guys.  For instance, you could forever keep some
> VL
> >> > edge
> >> > there forever, and still be able to communicate through the core to
> all
> >> > the

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 29 Jan 2013 16:03:18 -0800

> switches while still being able to handle VL traffic between VL ports

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
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?

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?

Anoop

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 29 Jan 2013 19:14:28 -0500

Ayan,

Yes, it would probably be good to have a brief informational section
describing the intended VL to FGL migration scenario.

Thanks,
Donald

On Tue, Jan 29, 2013 at 4:15 PM, Ayan Banerjee <[email-masked]> wrote:
>> >>   FGL-safe and starts announcing attachment to FGL links, but RB2
>> >> hadn't
>> >> yet
>> >> On Fri, Jan 25, 2013 at 11:00 AM, Radia Perlman
>> >> <[email-masked]>
>> >> wrote:
>> >> > type is "FGL".  FGL guys need to do two things: 1) understand FGL
>> >> > tags
>> >> > and
>> >> > the RBridges have been upgraded to be FGL-safe, then edge RBridges
>> >> > can
>> >> > start

---

From: Ayan Banerjee <[email-masked]>
Date: Tue, 29 Jan 2013 16:22:42 -0800

Thanks much Donald. I think that I would vote for approach 2.
Ayan

On Tue, Jan 29, 2013 at 4:14 PM, Donald Eastlake <[email-masked]> wrote:

> >> > On Tue, Jan 29, 2013 at 6:42 AM, Anoop Ghanwani <
> [email-masked]>
> >> > wrote:
> >> >>
> >> >> > 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.,
> >> >> > guy refuses to form an adjacency with a VL guy.  This option is
> very
> >> >> > simple
> >> >> > 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
> >> >> > with VL RBridges...it's just not safe to inject FGL frames yet.
>  Once
> >> >> > all
> >> >> > announcing they are connected to an FGL link, and can start
> injecting
> >> >> > FGL
> >> >> > packets.  It is considered a misconfiguration if you start
> injecting
> >> >> > FGL
> >> >> > unicast paths to FGL edge guys that avoid any VL guys, and
> calculate
> >> >> > at
> >> >> > have to calculate Dijkstra in two different ways, one for reaching
> VL
> >> >> > guys,

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 29 Jan 2013 19:37:02 -0500

Hi Anoop,

> 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.

> (with the assumption that there was some kind of race condition?

Yes. (This could just be due to some misconfiguration.)

> 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

---

From: Haoweiguo <[email-masked]>
Date: Wed, 30 Jan 2013 01:21:46 +0000

Hi Donald,
OK, I agree with your comments for both unicast and multicast forwarding process!
thanks
weiguo

________________________________________
发件人: Donald Eastlake [[email-masked]]
发送时间: 2013年1月30日 0:38
到: Haoweiguo
Cc: Radia Perlman; [email-masked]
主题: Re: [trill] 答复: 答复: Explaining three options for upgrading to FGL (fine-grained-labeling)

Hi Weiguo,

Thanks,
Donald

---

From: Yizhou Li <[email-masked]>
Date: Wed, 30 Jan 2013 12:25:35 +0800

With option 2, once RB starts to injecting FGL frame, isolated pure VL RB
will no longer able to exchange VL-tagged frame with FGL-safe RB and vice
versa. Such scenario may be caused by mis-configuration, flaky link, newly
connected cable, etc. Option 3 gives better handlings for such corner cases.
However comparing the complexity， I would still vote for option 2. The most
possible smooth migration path would be gradually replacing VL RB with FGL
safe RB. 
I think the administrator should roughly know the overall equipments
distribution and be responsible to decide when is the right time to actually
enable the injecting of FGL frame. 

Yizhou

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anoop Ghanwani
Sent: Wednesday, January 30, 2013 8:03 AM
To: Donald Eastlake
Cc: Radia Perlman; Ayan Banerjee; [email-masked]
Subject: Re: [trill] Explaining three options for upgrading to FGL
(fine-grained-labeling)

Anoop

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 30 Jan 2013 06:59:02 +0200

I would go with option 2, as it seems to offer a fairly smooth migration process, as well as a relatively simple software upgrade to turn VL nodes into FGL-safe nodes.

Tal.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Friday, January 25, 2013 9:00 PM
To: [email-masked]
Subject: [trill] Explaining three options for upgrading to FGL (fine-grained-labeling)

---

From: [email-masked]
Date: Wed, 30 Jan 2013 14:27:01 +0800

Support option 2

It provides a smooth migration process by a simple software upgrade from 
VL node to FGL-Safe node.

Radia Perlman <[email-masked]> 
发件人:  [email-masked]
2013-01-26 03:00

收件人
[email-masked]
抄送

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

 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
[email-masked]
https://www.ietf.org/mailman/listinfo/trill

---

From: [email-masked]
Date: Wed, 30 Jan 2013 16:11:39 +0800

In the process of an current TRILL campus migrates smoothly to FGL campus, 
it is possible that the core RBriges are first changed to FGL-RBriges (or 
FGL-safe Rbridges), then some edge Rbridges are changed to FGL. 

During the process of that migration, VL traffic and FGL traffic will exit 
in the TRILL campus simultaneously. Option 3 provides a way for the two 
types of traffic being forwarded in that TRILL campus safely. 

Furthermore, I am not sure that a VL-RBridge can be changed to FGL-safe 
just by updating its software.

So I prefer Option 3, although it seems more complex than Option 2.

Best Regards,
Zhai Hongjun
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
 Protocol Development Dept.VI, Central R&D Institute, ZTE Corporation
 No. 68, Zijinghua Road, Yuhuatai District, Nanjing, P.R.China, 210012
 
 Zhai Hongjun
 
 Tel: +86-25-52877345
 Email: [email-masked]
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

收件人
[email-masked]
抄送

主题

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 30 Jan 2013 11:55:35 -0800

[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

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 30 Jan 2013 20:17:47 +0000

I think Option 2 is better.

Linda Dunbar

---

From: Jon Hudson <[email-masked]>
Date: Thu, 31 Jan 2013 04:40:43 +0800

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.

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 30 Jan 2013 15:25:32 -0800

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

---

From: Jon Hudson <[email-masked]>
Date: Thu, 31 Jan 2013 16:16:01 +0900

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)

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 30 Jan 2013 23:31:43 -0800

Jon,

There are only couple of vendors who have actual deployments, and that includes you. As long as you and other vendors who deployed give nod, it is fairly ok to go ahead with model being chosen. For new deployments, which most other vendors likely to have, backward compatibility will not be an issue, w.r.t FGL.

True that it is difficult to get users to be on ietf lists. Atleast if those concerns are echoed, indirectly through channels like you, would help immensely.

Cheers
Sam

Sent from my iPad

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Thu, 31 Jan 2013 15:18:44 +0000

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)

On Jan 31, 2013, at 8:25 AM, Sam Aldrin <[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.
>>>> 
>>>>> 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
>>>> 155 Beaver Street, Milford, MA 01757 USA [email-masked]
>>>> 
>>>>> Anoop

---

From: Radia Perlman <[email-masked]>
Date: Thu, 31 Jan 2013 12:24:20 -0800

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

---

From: Olen Stokes <[email-masked]>
Date: Thu, 31 Jan 2013 14:00:22 -0800

Thanks for consolidating these topics.  Please see two [OLS] comments in line...

From: [email-masked] [mailto:[email-masked]] On Behalf Of Radia Perlman
Sent: Thursday, January 31, 2013 3:24 PM
To: Tissa Senevirathne (tsenevir)
Cc: Anoop Ghanwani; Ayan Banerjee; Sam Aldrin; [email-masked]; 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.

[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 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: Thu, 31 Jan 2013 14:27:11 -0800

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

>  Thanks for consolidating these topics.  Please see two [OLS] comments in
> line…****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Radia Perlman
> *Sent:* Thursday, January 31, 2013 3:24 PM
> *To:* Tissa Senevirathne (tsenevir)
> *Cc:* Anoop Ghanwani; Ayan Banerjee; Sam Aldrin; [email-masked]; Donald
> Eastlake; Jon Hudson
>
> *Subject:* Re: [trill] Explaining three options for upgrading to FGL
> (fine-grained-labeling)****
>
> ** **
>
> Tissa said:****
>
> 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:****
>
> ** **
>
> (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****
>
> ** **
>
> assume you are VL ("FGL-unsafe")****
>
> ** **
>
> ---------****
>
> Also, TIssa said:****
>
> will be at the edge of the network ?****
>
> ** **
>
> The only kinds of coexistence in option 2 are:****
>
> ** **
>
> a) VL and FGL-safe RBridge, but no actual FGL links yet.****
>
> 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:****
>
> ****
> ** **
> *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
> 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),****
>
> ** **
>
> are ostrasized, *even if they are just at the edge.*****
>
> ** **
>
> 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
> VL guys at the edge for a long time.****
>
> ** **
>
> Radia****
>
> ** **
>
> ** **
>