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

[Haoweiguo <[e-mail]>]

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