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

Curtis Villamizar <curtis@occnc.com> Tue, 26 March 2013 03:56 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 CC3CD21F88E8 for <mpls@ietfa.amsl.com>; Mon, 25 Mar 2013 20:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.456
X-Spam-Level:
X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_37=0.6, 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 hjk7H3vZl1rP for <mpls@ietfa.amsl.com>; Mon, 25 Mar 2013 20:56:03 -0700 (PDT)
Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42D21F88D8 for <mpls@ietf.org>; Mon, 25 Mar 2013 20:56:03 -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 r2Q3rV7u021746; Mon, 25 Mar 2013 23:53:31 -0400 (EDT) (envelope-from curtis@occnc.com)
Message-Id: <201303260353.r2Q3rV7u021746@gateway1.orleans.occnc.com>
To: Loa Andersson <loa@pi.nu>
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Mon, 25 Mar 2013 10:56:14 BST." <51501F3E.2010400@pi.nu>
Date: Mon, 25 Mar 2013 23:53:31 -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 03:56:04 -0000

In message <51501F3E.2010400@pi.nu>
Loa Andersson writes:
> 
> Pablo,
>  
> tnx for comment - see inline please-

Loa,

A few comments inline.

Curtis


> On 2013-03-22 22:13, Pablo Frank wrote:
> > Hello draft-kompella-mpls-special-purpose-labels authors,
> >
> > I'll preface my comments by saying that while I think the intent of this
> > draft is certainly laudable, the matter of reserved-label exhaustion is
> > probably not urgent.  In other words, let's not be hasty on this one and
> > let's get it right.  :-)
>  
> The reason for this draft been posted now was that we wanted to address
> the issue before it becomes urgent, so yes I agree.
>  
> However there is one (maybe two) things in the draft that is a little
> more urgent than the extension of the special purpose label space.
>  
> 1. the renaming of "reserved labels" to "special purpose labels", to
>     align with how IANA useses the word "reerved".
> 2. The procedures to deprecate and retire special purpose labels.
>  
> If we find that the discussion on how to extend the special purpose
> label space drags out, then I guess we could break out those to items
> in a separate draft. But let keep in the draft for some time.
>  
> >
> > My first concern involves backwards compatibility with mpls multipath
> > solutions.  In particular, it's important that implementations that hash
> > label stacks for the purposes of ECMP or LAG should ignore reserved
> > labels.  I would think the same thing should apply to extended special
> > purpose labels
>  
> yes that is true
>   but because these labels can be outside the 0-15 range,
> > existing implementations will include them in their hash.
>  
> I don't think this is true - if you find a special purpose label that
> you don't recognize you should silently drop that packet. So a packet
> with an unrecognized extension label should no get into the hashing
> at all.

It is.  If the 15 is not on the top of the stack, then the LSR MUST
NOT drop the packet.  In doing the hash, an older LSR would skip over
the 15 but then incorrectly hash on the next label if it fell outside
of the 0-15 range.

> > This will
> > have the effect that current implementations will add unintended entropy
> > when it sees these labels.
> >That's probably a bad effect and I doubt it
> > was intended.  Conversely, this is exactly the desired behaviour of
> > ELI+Entropy which this proposal appears to be modeled on.
> >
> > My second concern involves the size of the extended special purpose
> > label range and how that will impact very high-speed hardware designs.
> >   As it currently stands, detecting a reserved label is trivially simple
> > and since the set of reserved labels is so small, the handling of said
> > labels can be either implemented in a very small lookup resource or even
> > hard-coded.  Since the proposed extended special purpose label space is
> > now 20-bits wide, this becomes a much more expensive lookup resource in
> > terms of chip area, lookup cycles, etc.  If jumping from 4-bits to
> > 20-bits is "free", I'd be less concerned.  But IMO, it's not free and
> > may very well be an overreaction given that the rate of reserved label
> > allocation does not appear to be growing exponentially.
>  
> I'd be fully open to discuss how many special purpose labels that is
> needed, I saw Curtis talking about 0-1023, would that address your
> concern?
>  
> >
> > The third concern is a relatively minor issue with how the draft appears
> > to allow arbitrarily long strings of label 15 and seems to mandate that
> > they should be treated as a single occurence of label 15.  I could see
> > some implementations being vulnerable to DOS attack if they parse the
> > label stack recursively.  Is there a particular motivation for this
> > requirement or am I reading it wrong?
>  
> In the last version of the document we said that 15 in the extended
> space is "reserved", my personal opinion is that 15,15 is not allowed
> and that it should have be taken out of the draft.

+1

> > A possible solution that addresses all of these concerns, that
> > admittedly is not very elegant, is to use each consecutive occurance of
> > label 15 to extend the reserved label space by another 15 labels.  In
> > other words:
> > - labels 0-14 are the original (classic) reserved labels if they are not
> > preceeded by label 15.
> > - Unless they are preceeded by label 15, in which case labels 0-14 are
> > really mapped to special purpose labels 16-30.
> > - Unless they are preceeded by two consecutive label 15s, in which case
> > labels 0-14 are really mapped to special purpose labels 32-46.
> > - etc.
> > To address my 3rd concern, an implementation would discard a string of
> > label 15s if they exceeded the range of labels that it supported.
>  
> I'd really would like to allocate 0-1023 after 15 for the extended
> special purpose, with some of the as listed in the draft, have a common
> interpretation in both spaces.

How about 16-1023 following 15?  With 0-15 following 15 being
considered an error.  Then 10 bits can be passed to the OAM gorp.

> /Loa
> >
> > Yeah, I know, yuck.  But it does work and has the virtue of being
> > backwards-compatible with existing mpls multipath techniques and
> > allowing a much more gradual ramp for the hardware lookup tables.
> >
> > It also assumes that the rate of reserved label allocation will remain
> > more or less linear over time.  It may, in fact, decrease given that
> > GACh channel-types can probably address many future needs.
> >
> > regards,
> > Pablo