Hi all, The informatin contained in the forwarded email may be interesting to those people who want to know the advantages of locally significant VN ID over globally significant VN ID on the data plane of NVo3.
For example, in order to support 16M tenant/VPN instances in the whole data center network scope, by using globally significant VN IDs, each NVE device must perform 24 bit lookup on per tunnelled packet so as to determine which tenant/VPN instance that packet belongs to, even if only a few tenant/VPN instances (e.g., no more than 1024) would be installed on that NVE device (e.g., ToR). In contrast, by using locally significant VN IDs, those NVE devices on which no more than 1024 tenant/VPN instances would be installed only need to perform 10 bit lookup on per tunnelled packet so as to determine which tenant/VPN instance that packet belongs to (even in the case where the 20 bit MPLS label is used as the VN ID). Best regards, Xiaohu ________________________________________ 发件人: [email protected] [[email protected]] 代表 Shahram Davari [[email protected]] 发送时间: 2012年11月7日 5:40 到: Eric Gray; [email protected]; [email protected] Cc: [email protected]; Vivek Kumar 主题: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) Hi Eric (Gray). Let me explain this from chip perspective. As you probably know 20-bit lookup is expensive since it either requires a Hash table or a TCAM. Also note that any chip has a limitation on the number of MPLS labels that can be looked up per-packet (let's call this N). Now let's discuss the special labels. Special Labels as described in this draft adds one Label to the Label stack depth. This means if you want to use the existing 20-bit lookup you will consume one of the Label lookups and therefore you can now only support (N-1) forwarding labels. The solution that Eric Rosen has proposed solves this problem. Since looking at the first 14-bit is easy, just do a HW comparison with zero and then have a small direct index table (64 entries) to do the special label lookup. Such table is cheap. You could even implement it in Registers. Hope this helps. Regards, Shahram -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Eric Gray Sent: Tuesday, November 06, 2012 12:16 PM To: [email protected]; [email protected] Cc: [email protected]; Vivek Kumar Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) Eric (Rosen), I am having some trouble understanding how what you describe is not simply an isomorphism of a "20-bit look-up." If you examine the first 16 bits (to see if they are all zeros), and then look at the last 4 bits, you have examined all 20 bits. It is easy enough to imagine an implementation that does exactly what you've described, but difficult to see why such an implementation might be considered to be "definitive." If it is possible that you will do a 20-bit look-up in at least some non-null subset of all cases, then the hardware needs to support this. Having it also explicitly support a "special case" handling mechanism for the case where the first 16 bits are all zeros may be considered by at least some implementers as more complex than supporting the basic 20-bit look-up with the results associated with the "special case" labels simply "hard-wired" in. The part I'm having the most trouble with is the notion that an implementation would be optimized for the (hopefully) unusual case of "special case" labels, rather than being optimized for the (probable) common case where the label has meaning assigned for the purpose of forwarding packets. The process you describe gets a result after two (presumed) separate lookup operations: a first one that determines if the first 16 bits are all zero, followed by a second step where either the last 4 bits are used to pick a special cases result, or the entire 20 bit label is examined (with the first 16 bits presumably being examined yet a second time). This would seem to be sub-optimal. If the implementation does not - in fact - do this as 2 separate lookups, than it is performing steps that are logically identical to a 20-bit lookup in a single step. -- Eric (Gray) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Eric Rosen Sent: Friday, November 02, 2012 1:46 PM To: [email protected] Cc: [email protected]; 'Vivek Kumar' Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel) Adrian> I prefer that we keep the label as 20 bits (which is what the Adrian> hardware will expect to process) This is not correct; to interpret a "special purpose label", hardware has never had to do a 20-bit lookup. We should not require that implementations of this draft need to do a 20-bit lookup in order to process the extended special purpose labels. Adrian> If we restrict it to 6 bits, it will imply the other bits are Adrian> available to be "squatted". Unless you expect the WG to be assigning a million or so codepoints for special purpose labels, any 20-bit scheme will leave plenty of unassigned values that can be misappropriated. Allocation policies don't really provide disincentive to "squatting" unless there is a real likelihood of "codepoint clash". _______________________________________________ mpls mailing list [email protected] https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list [email protected] https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list [email protected] https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
