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

Vishnu Pavan Beeram <> Tue, 31 October 2017 20:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CB2913F686; Tue, 31 Oct 2017 13:20:57 -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 lkkM_4XMjy7q; Tue, 31 Oct 2017 13:20:54 -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 AC54E1397F3; Tue, 31 Oct 2017 13:20:54 -0700 (PDT)
Received: by with SMTP id b79so157377pfk.5; Tue, 31 Oct 2017 13:20:54 -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=OIhXQs9yiFpMTCTp6mwWEFDv/LI/6l4tlHkpYdFP6Zg=; b=JvMAvq2VkMQpBt4dzogdwjcEcvyDMyY00WeB/mpaW2KG7Tl+9G1g8nwVGr29hG/CFS GFR5Mkt9v8RK2DUT7gX7L1Vha7Q6ngggHtP/+XKbdy66le1IxPhCqoEAVxvwzQkPLXsi Q/d5s9X2brk7uvzS4jmqTob3Em9HjliwlBJzSqMkdPWtuoAQPveJ0vM27ePAOnv9scFF jSO4m/E2z7eXpp2TB3TwUh9XjQ6Uedmyo2euUW9Pjzf0Mx+cl91sHddAZDgrxRfBQQTJ aQmhYXxhB5bVJtcaakZ8V36rlk662l90AB2TL3NFwHyRgq6XLVRbpyoctv6hEClOcuYi krBw==
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=OIhXQs9yiFpMTCTp6mwWEFDv/LI/6l4tlHkpYdFP6Zg=; b=CKa80vv7QVA9kIMC3Mus9hcnCsFaCoKoovS9K1zKOynlCUl6Tn2agyz096gstrGyMA +UKdoh+MhZkBF1qLLX8RZllNjsAJ3Az/Q8fFxFyjUNnIaGxX3pDgcJAEwlO6W01CysC1 IEdlQlYJys06u9qO2QCrXkgda9ig/cpz2BvnRNlulJx7ETgaVCkws5bTzKYdFDa4xx62 gZGw3c4TPqRvKNyJ0w7eILk/y5aWEhotEiLC/fH4Y+99mT2K489yrD3/01yy2CmVd9LI CE249gVuU84fdDNUp33MYgfklg1JgTVynnSbOLbh1+5PF8BQt+LfxjKufOW9Ie7YM7wI B8oA==
X-Gm-Message-State: AMCzsaUWmCoXzR8q4m9bEaYs/N8g4bN5IbH888lnT2rRXrh6etrnCzm0 MGmNjeBhtn0AkwVBTZ0vlf3psm0E7FX8+Z4m1x5cBA==
X-Google-Smtp-Source: ABhQp+SxTe9wv2PKKgZOvKWxZHJ6n0YUvEqOckGNs2P8+vzfteCLFmflIV9wsUTqVUHySL/JFU+Xju1iUqwPmpwj1uE=
X-Received: by with SMTP id w4mr3058115pgs.335.1509481254112; Tue, 31 Oct 2017 13:20:54 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 31 Oct 2017 13:20:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Vishnu Pavan Beeram <>
Date: Tue, 31 Oct 2017 16:20:53 -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: Tue, 31 Oct 2017 20:20:57 -0000

Lou, Hi!

Thanks for the feedback!
Please see inline.


On Fri, Oct 27, 2017 at 5:43 PM, Lou Berger <> wrote:
> 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.

[Pavan] Ack. We'll add relevant text to the next version as indicated.

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

[Pavan] We (the authors) aren't too particular about the terms that
are currently being used in the document. We will be ok with whatever
terms the WG agrees upon. Personally, I think the terms pop-label and
swap-label make the operational intent explicit and help make the
document a better read. That said, I would be ok with "TE link 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"?

[Pavan] Yes, this is just the traditional swap-label. There are
several places in the document where we refer to this type of label --
so it seemed useful to define a "term" for this at the beginning and
use it in the rest of the document.

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