[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
- Re: [mpls] Concerns about draft-kompella-mpls-spe… Jeff Wheeler
- [mpls] Concerns about draft-kompella-mpls-special… Pablo Frank
- Re: [mpls] Concerns about draft-kompella-mpls-spe… Loa Andersson
- Re: [mpls] Concerns about draft-kompella-mpls-spe… Eric Rosen
- Re: [mpls] Concerns about draft-kompella-mpls-spe… Loa@mail01.huawei.com
- Re: [mpls] Concerns about draft-kompella-mpls-spe… Curtis Villamizar
- Re: [mpls] Concerns about draft-kompella-mpls-spe… Curtis Villamizar
- Re: [mpls] Concerns about draft-kompella-mpls-spe… Pablo Frank
- Re: [mpls] Concerns about draft-kompella-mpls-spe… Adrian Farrel
- Re: [mpls] Concerns about draft-kompella-mpls-spe… Loa Andersson
- Re: [mpls] Concerns about draft-kompella-mpls-spe… Eric Rosen