Subject: [nvo3] The implications of locally significant VN ID and globally significant VN ID//re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)

From: Xuxiaohu <[email-masked]>
Date: Thu, 8 Nov 2012 14:43:58 +0000

Hi all,

I think it might be helpful to add some detailed discussions about the implications of locally significant VN ID and globally significant VN ID from multiple perspectives into the NVo3 data plane requirement draft.

Best regards,
Xiaohu

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Xuxiaohu [[email-masked]]
发送时间: 2012年11月8日 1:59
到: [email-masked]
主题: Re: [nvo3] [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)

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-masked] [[email-masked]] 代表 Shahram Davari [[email-masked]]
发送时间: 2012年11月7日 5:40
到: Eric Gray; [email-masked]; [email-masked]
Cc: [email-masked]; 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-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Tuesday, November 06, 2012 12:16 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; 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-masked] [mailto:[email-masked]] On Behalf Of Eric Rosen
Sent: Friday, November 02, 2012 1:46 PM
To: [email-masked]
Cc: [email-masked]; '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-masked]
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3