Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02

Eric Rosen <erosen@cisco.com> Tue, 19 March 2013 17:03 UTC

Return-Path: <erosen@cisco.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 7142C21F8C7D for <mpls@ietfa.amsl.com>; Tue, 19 Mar 2013 10:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 XEVTgQX3Qw4z for <mpls@ietfa.amsl.com>; Tue, 19 Mar 2013 10:03:04 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 597B121F8CDF for <mpls@ietf.org>; Tue, 19 Mar 2013 10:03:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2050; q=dns/txt; s=iport; t=1363712584; x=1364922184; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=bA3GkWKhgyliNP9K42HpghOLnH6QReJXIdKIkJTsmRI=; b=DALSUzkzMGESuKRoDWYy4ipR7OTP7pGU08Kz1DlvxmnxLeI3rQLhjtLh csATxovB6sWhcL+U83J7FY9LrL+WbvRHEA6SCt1aFjehfXaFwlnbXDuHg hCvafFzjdEu/Z/sv0VzJqx6ldV3RKQRdHJpdBYBhwiffvhPcaWDLxcc1w g=;
X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="73474334"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 19 Mar 2013 17:03:04 +0000
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2JH33Mq026094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Mar 2013 17:03:03 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r2JH32SU031964; Tue, 19 Mar 2013 13:03:02 -0400
To: "William Ivory (wivory)" <wivory@cisco.com>
In-reply-to: Your message of Mon, 18 Mar 2013 17:25:04 -0400. <D2FD2FE4B21AEB41A13FAA7498B10761E0C1C3@xmb-aln-x03.cisco.com>
Date: Tue, 19 Mar 2013 13:03:02 -0400
Message-ID: <31963.1363712582@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
Cc: MPLS <mpls@ietf.org>
Subject: Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: erosen@cisco.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, 19 Mar 2013 17:03:05 -0000

> Using extended labels increases packet size.  This could cause unexpected
> issues with MTU at pinch points in a network,

Suppose one has a choice between (a) reusing a deprecated codepoint from the
special purpose label space, and (b) using a new codepoint from the extended
special purpose label space.  The risk of (a) is that you later find that
you have a customer with a legacy system that still uses the deprecated
codepoint.  The risk of (b) is that the label stack is 32 bits longer for
each occurrence of the label, and this is the factor that pushes some
packets over the MTU.

IMHO, (b) is the much more cost-effective strategy.  Lower risk, and lower
cost to work around it if it happens.

> and could also possibly lead to faster exhaustion of hardware resources as
> the extra labels will need to be programmed in hardware.

Even if we deprecated and reused every special purpose label from the
non-extended space, that would only be 16 labels.  I hope that 16 labels in
the extended space will not exhaust the hardware resources.

With regard to the issue of allowing an arbitrary number of "extension
labels":

> Isn't it better to allow for an arbitrary number now, rather than only
> allow one now, then have to extend in future

There will never be a need for an arbitrary number of extension labels,
because the semantics of an arbitrary number of extension labels (according
to the draft) is the same as the semantics of a single extension label.

I wonder if there is a terminological issue here.  An extended special
purpose label is represented by a pair of contiguous label stack entries.
The topmost entry of the pair is the "extension label" (label value 15), and
the bottommost entry of the pair is a label from the extended special
purpose registry.  It should be possible to have an arbitrary number of such
pairs in the label stack.  But I don't see the value of having an arbitrary
number of contiguous "15"s followed by a label from the extended special
purpose registry.