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

Lou Berger <> Fri, 27 October 2017 21:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1F0413875A for <>; Fri, 27 Oct 2017 14:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (768-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7B6nmktmldo9 for <>; Fri, 27 Oct 2017 14:51:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 291C813A034 for <>; Fri, 27 Oct 2017 14:51:43 -0700 (PDT)
Received: from cmgw3 (unknown []) by (Postfix) with ESMTP id A2FF21790EC for <>; Fri, 27 Oct 2017 15:43:47 -0600 (MDT)
Received: from ([]) by cmgw3 with id Sljj1w00z2SSUrH01ljmo2; Fri, 27 Oct 2017 15:43:47 -0600
X-Authority-Analysis: v=2.2 cv=H76r+6Qi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=02M-m0pO-4AA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=VHR9UauA4humKzEhH1gA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nbgI91m7JhhjyePZGvEYxw78mucHT6QA+vUyco2+2ak=; b=rKxkktBnUwEm8qS56ME/Xj6cUX g3oX40Ftj/IwVC39ADMdjsJ/Nk1MoXV95Kz/EYOgDsJq4VG8CeviPLWY0+wg/2N1ZCECVeDglyqKC 86yDkCr2b7qFqEX36f8ZxN+bh;
Received: from ([]:48748 by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <>) id 1e8CPn-00342w-QS; Fri, 27 Oct 2017 15:43:43 -0600
To: Vishnu Pavan Beeram <>
Cc: Loa Andersson <>, "" <>, "<>" <>, "" <>, "" <>
References: <> <> <>
From: Lou Berger <>
Message-ID: <>
Date: Fri, 27 Oct 2017 17:43:40 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Exim-ID: 1e8CPn-00342w-QS
X-Source-Sender: ( []:48748
X-Email-Count: 15
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
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: Fri, 27 Oct 2017 21:51:45 -0000

Hi Pavan,
	Sorry about the delayed response.  See below.

On 10/23/2017 09:20 AM, Vishnu Pavan Beeram wrote:
> Lou, Hi!
> Thanks for reviewing this. Please see inline (prefixed VPB) for responses.
> Regards,
> -Pavan
> 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.

I think sharing in the middle of the network, and potentially onto other
hierarchical labels, is a bid different -- this said I think your first
couple of sentences above are right on the mark.

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

How about just avoiding the well established verb altogether? Perhaps
"interface label", "TE link label" or even "shared label"?

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

isn't this just a "label"?

> 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.
I think we can circle back to this after resolving pop-label.  I do
think your title is clear and perhaps there's something that can serve
as a short hand of that, maybe "Shared Forwarding TE-Tunnel" or "Segment
Routing TE Tunnel"?

> Pop-and-forward data plane:   A forwarding plane where every
> participating LSR uses pop-labels on every LSP. 
> **
I have the same basic comment here as the previous one.

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

I think the draft needs to document how the defined operations fit into
3031 or how they extend / update 3031.


>> 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