Re: [mpls] working group adoption poll on draft-sitaraman-mpls-rsvp-shared-labels

Vishnu Pavan Beeram <> Mon, 23 October 2017 13:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C782C138A38; Mon, 23 Oct 2017 06:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kreIHic43rQR; Mon, 23 Oct 2017 06:20:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C31B313F6DC; Mon, 23 Oct 2017 06:20:34 -0700 (PDT)
Received: by with SMTP id n14so17088666pfh.8; Mon, 23 Oct 2017 06:20:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jPmT9mrC9/Fuj7bZ+lAgUB1zlyAjfsugUuk3W7Ttu98=; b=hHXL2ba9HZSnJEBNIhH0J84tZe/7+53tU1xscczEyNDMyBo/ULZqJDPZ1e7IIsK6dP tGimr6yEu8JoMz7+++eT9P06/ImVqvPoha2G3Cd5tFdQh7oY1fWSgCAEhFMoJ9qBOyjO uROpp7pStGnDZah0tO5nV6S/0h0Nx/u7DC9w5nVAg3iEbGWPhAP7vS+24IwnvK9Kgqsl HnOiO9YLu2jHYvm+6XB3zNmDUrRSK6z0/FS4qPRGEI+Ycu+aNTZ9tYTrO8xtSTk5Lvz1 srJKLyitUn1sbzC/zy5hnktiXQjWm466FdjzaquA1FFHgeWj60KYC9c1mT05wBrxYMwQ 2zlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jPmT9mrC9/Fuj7bZ+lAgUB1zlyAjfsugUuk3W7Ttu98=; b=DQ7nUx0k1jkOmcND5rK7aAcVIWKp+kENb0krdEiCea9yYgcPaWOt0vdWU1izkIoWjq 8wMOr2uVqGWb1+xgiL4VpPzsMv4vfHxveuzLQAXyDeDO7X91MC7sZeXHnwUBpObHngV8 rJ0nKL8LtKC0yuRiZ6IgeeM0QNXyQ1fQwwl37LFZvul3ahw+C5PxMAOy4OLmTQ9/6spt v6PcSFwdumwb73oG/j5GgQQ6iHOe7ixarsTvzl8kV2fJ3kq5poOZAVLRZcdjBCoxOGMz Zz+P7fSBA1OyBRySuOgmSi5aWVLSistf4ZL5uewhVM9Kjmtq6+zh+aUEavAQBDI7KrEQ kixA==
X-Gm-Message-State: AMCzsaV0fdmf/L8Q9jXLdKYZUZuWgEi9vZfyPFI3p0E32wXj+VG78yfw fNMvhNFb8uW15SoNtYQCZhyb3uhugdE4FRzX4WU=
X-Google-Smtp-Source: ABhQp+QLNYvad3RnjZPPbgv3+Z7w7onFpX1CUwNOq4IY+U+axmABsLOF1QFFHPP/Lqd38ygfBIT2/JZbjd3ejWqTxIw=
X-Received: by with SMTP id w26mr12128514pge.11.1508764834196; Mon, 23 Oct 2017 06:20:34 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 23 Oct 2017 06:20:33 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Vishnu Pavan Beeram <>
Date: Mon, 23 Oct 2017 09:20:33 -0400
Message-ID: <>
To: Lou Berger <>
Cc: Loa Andersson <>, "" <>, "<>" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [mpls] working group adoption poll on draft-sitaraman-mpls-rsvp-shared-labels
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Oct 2017 13:20:40 -0000

Lou, Hi!

Thanks for reviewing this. Please see inline (prefixed VPB) for responses.


On Mon, Oct 16, 2017 at 1:41 PM, Lou Berger <> wrote:
> Hi Loa,
>     I have some technical concerns about this document that IMO need to
> be addressed. I think addressing them before adoption would be best but
> is certainly not the only option:
> - The document is completely silent on the impact of shared labels on TE
> bandwidth/tspec/rspec related processing.  Clearly there is some no
> inconsequential impact and this needs to be covered.

[VPB] We will add some text in the next version explaining the mapping
between a shared label and the corresponding bandwidth-reservations.
Implementations that maintain per-label bandwidth accounting at each
hop must aggregate the reservations made for all the LSPs using the
shared-label. Note that using a shared pop-label (albeit a special
label) along the path of an MPLS RSVP LSP is nothing new. Signaling
for PHP LSPs (we can signal 1-hop PHP LSPs as well) is done today
without any special changes to the tspec/flowspec processing at the
penultimate hop. The only difference now (with the changes proposes in
the draft) is that a pop-label can be used at any given hop along the
path of the LSP.

> - The definition of ' pop and forward tunnel' is a circular at best  (it
> references  'pop and forward labels' which are not defined at all.)  --
> I think I understand what the draft is trying to do, but how do I really
> know that my interpretation is right without a formal definition.  On an
> aside, I think the use of 'pop label' is a poor choice as we'll have an
> architecture that allows for a node to 'pop labels' (i.e., the operation
> defined in RCF3031) and a new RFC that adds 'pop labels' which are
> labels whose value indicates that the node should pop the label and
> forwarded out the interface indicated in the label. BTW this functions
> seems similar to egress control discussed in rfc4003.

[VPB] Please see if the following tweaks to the terminology section
(remove the “verb” vs “noun” ambiguity) address the above concerns.
We’ll fix all occurrences of these terms in the rest of the document.

A pop-label:   An incoming label at an LSR that will be popped by the
LSR with the packet being forwarded over a specific outgoing TE link
to a neighbor.

A swap-label:   An incoming label at a LSR that will be swapped to an
outgoing label with the packet being forwarded over a specific
outgoing TE link to a neighbor.

RSVP-TE pop-and-forward tunnel:   An MPLS RSVP-TE tunnel that requests
the use of a pop-label on every hop of the LSP.

Pop-and-forward data plane:   A forwarding plane where every
participating LSR uses pop-labels on every LSP.

> - In writing this mail, it occurs to me that the addition of this
> function is really an update to RFC3031 defined function and those
> changes should be explicitly and formally described.

[VPB] I believe what you are saying is that the “forward” aspect in
“pop-and-forward” is not discussed in RFC3031. And hence, the need to
formally update RFC3031. We (the authors) would be ok with whatever
the WG deems fit in this regard.

> Lou
> On 10/14/2017 11:20 AM, Loa Andersson wrote:
>> Working Group,
>> This is to start a two week poll on adopting
>> draft-sitaraman-mpls-rsvp-shared-labels-02 as a MPLS working group document.
>> Please send your comments (support/not support) to the mpls working
>> group mailing list ( Please give a technical
>> motivation for your support/not support, especially if you think that
>> the document should not be adopted as a working group document.
>> There are three IPR disclosures (though one disclosure seems to be an
>> update) against this document.
>> All the authors have stated on the MPLS wg mailing list that they are
>> unaware of any other IPRs that those that has been disclosed
>> The working group adoption poll ends October 29, 2017.
>> /Loa
>> mpls wg co-chair
> _______________________________________________
> mpls mailing list