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

Pablo Frank <pabloisnot@gmail.com> Fri, 22 March 2013 21:13 UTC

Return-Path: <pabloisnot@gmail.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 DABBE21F89B2 for <mpls@ietfa.amsl.com>; Fri, 22 Mar 2013 14:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level:
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-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 0IhO38nTY43I for <mpls@ietfa.amsl.com>; Fri, 22 Mar 2013 14:13:33 -0700 (PDT)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id E22BB21F8496 for <mpls@ietf.org>; Fri, 22 Mar 2013 14:13:32 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hf12so3435340vcb.20 for <mpls@ietf.org>; Fri, 22 Mar 2013 14:13:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=dqL3QZeyv/1IlA+e2HkNTYsM0l5zeZz7RJSzQL8c+z4=; b=j2aJIK9tVG809JOMyZnGfCEntZV6gbHRUNMPhkeaGuHLRWjMp/MsSeICv2WJ+v42EF heg53uFQ8MjYE48ZTCngrAEbFeWnTwMF2An+bHnvSQ5Y+Yxu2jeplJh3ultCPy6IUX09 fCDHuoWFuU/XTS+4ipc1ispYk+mpYuneIuVXzcdC6usE9aaInJP/0w58WUL7jchZLVRP VlbA6eLFQzbyeOq9baMX2e/GMifFZd374dh68MOYOo4vKTGIcncOeiqMFWY50AwxXVgp gWmJVxDosSrbegwfsbv2HQ2Q9KPfZdp5kV8vvoSByulUICkzVuaUKkJM0b/ZckHIJo58 hz9g==
MIME-Version: 1.0
X-Received: by 10.58.85.134 with SMTP id h6mr4340498vez.18.1363986812354; Fri, 22 Mar 2013 14:13:32 -0700 (PDT)
Received: by 10.52.97.97 with HTTP; Fri, 22 Mar 2013 14:13:32 -0700 (PDT)
Date: Fri, 22 Mar 2013 17:13:32 -0400
Message-ID: <CAGEmCZzFSaTN=hKbBTmFakiF2H9EbEB4211K+oEXtCoMWox3zg@mail.gmail.com>
From: Pablo Frank <pabloisnot@gmail.com>
To: draft-kompella-mpls-special-purpose-labels-02@tools.ietf.org, mpls@ietf.org
Content-Type: multipart/alternative; boundary="047d7b6d93406dc4c104d889ed3b"
Subject: [mpls] Concerns about draft-kompella-mpls-special-purpose-labels-02
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Fri, 22 Mar 2013 21:13:34 -0000

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.  :-)

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 but because these labels can be outside the 0-15 range, existing
implementations will include them in their hash.  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.

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?

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.

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