Re: [mpls] Concerns about draft-kompella-mpls-special-purpose-labels-02

Curtis Villamizar <curtis@occnc.com> Tue, 26 March 2013 04:06 UTC

Return-Path: <curtis@occnc.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CC521F88E8 for <mpls@ietfa.amsl.com>; Mon, 25 Mar 2013 21:06:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.068
X-Spam-Level:
X-Spam-Status: No, score=0.068 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0IMX7db96-V for <mpls@ietfa.amsl.com>; Mon, 25 Mar 2013 21:06:17 -0700 (PDT)
Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 01CE121F88CC for <mpls@ietf.org>; Mon, 25 Mar 2013 21:06:16 -0700 (PDT)
Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r2Q4507N021858; Tue, 26 Mar 2013 00:05:00 -0400 (EDT) (envelope-from curtis@occnc.com)
Message-Id: <201303260405.r2Q4507N021858@gateway1.orleans.occnc.com>
To: erosen@cisco.com
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Mon, 25 Mar 2013 10:55:43 EDT." <22045.1364223343@erosen-linux>
Date: Tue, 26 Mar 2013 00:05:00 -0400
Cc: mpls@ietf.org, draft-kompella-mpls-special-purpose-labels-02@tools.ietf.org
Subject: Re: [mpls] Concerns about draft-kompella-mpls-special-purpose-labels-02
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@occnc.com
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2013 04:06:17 -0000

In message <22045.1364223343@erosen-linux>
Eric Rosen writes:
 
>  
> Loa> However there is one (maybe two) things in the draft that is a little
> Loa> more urgent than the extension of the special purpose label space.
>  
> Loa> 1. the renaming of "reserved labels" to "special purpose labels", to
> Loa>    align with how IANA uses the word "reserved".
>  
> Loa> 2. The procedures to deprecate and retire special purpose labels.
>  
> What is the urgency?
>  
> Loa> if you find a special purpose label that you don't recognize you should
> Loa> silently drop that packet. So a packet with an unrecognized extension
> Loa> label should not get into the hashing at all.
>  
> If an unrecognized label rises to the top of the label stack, the packet
> should be dropped.  However, I don't think there's any requirement for a
> router to drop a packet just because there's an unrecognized special purpose
> label somewhere in the stack.  So if hashing is done on the entire stack, I
> think Pablo is right that labels from the extended special purpose label
> space will get into the hash.
>  
> Whether that really makes any difference is another matter.  
>  
> Pablo> This will have the effect that current implementations will add
> Pablo> unintended entropy when it sees these labels.
>  
> Are there specific scenarios in which packets that should stay in order can get
> different special purpose labels pushed on their stacks, but cannot get
> different dynamically assigned labels pushed on their stacks?
>  
> Loa> I'd really would like to allocate 0-1023 after 15 for the extended
> Loa> special purpose
>  
> How about 0-63?  Or 0-255?  
>  
> If the WG were to decide that Pablo's point is valid, one could deal with it
> by treating several of the currently unused special purpose labels (I think
> there are nine available) as extension labels, each identifying a new 4-bit
> extended special purpose label space.  That scheme would satisfy Pablo's
> criteria, but would not require more than two label stack entries to
> represent any of the special purpose labels.  (I guess each such label space
> would have to assign 7 as the entropy label.)
>  
> I'm not advocating this scheme, but I do think it is better than using the
> cardinality of a sequence of 15's to identify a particular special purpose
> label space ;-)

No one is proposing to use the cardinality of a sequence of 15's and
in fact most of us are trying to get two 15s in a row to be an error
and I'm pushing for 0-15 following 15 to be an error.

> With regard to Jeff's suggestion to just expand the special purpose label
> space by several bits, I think the problem is the following.  There are
> bound to be routers in the network that do not know that 17, say, is now a
> special purpose label.  Such routers may bind dynamically 17 to a FEC or
> tunnel.  This will add an exciting bit of unpredictability to the handling
> of packets carrying that label.

17 would have no special meaning unless it directly follows 15.

> Jeff> Plenty of routers exist that are unwilling to look at a label stack
> Jeff> deeper than 3..5 labels.
>  
> I'm guessing that "unwilling to look at" means that the high speed memory
> used to hold the packet header cannot hold more than 3 to 5 labels.  This
> would only be a problem for a P router if it had to interpret (in the fast
> path) an extended special purpose label and 2-4 regular labels (or a couple
> of special purpose labels) in order to dispatch the packet properly.  It
> might be interesting to examine such scenarios, if someone can present them
> without getting overly emotional about it ;-)

By unwilling to look at, Jeff means unwilling to use them in the
multipath hash.

In PWE order (bottom to top).

PWE3 flow label
PWE3 PW label
EL
ELI
LDP
EL
ELI
RSVP-TE

OK.  That is 8.  Wedge 15 and new improved special label in there
(somewhere).  OTOH, only the top three (TE, ELI, EL) need to be looked
at if the gadget support EL.

Curtis