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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Tue, 31 October 2017 20:20 UTC

Return-Path: <vishnupavan@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 2CB2913F686; Tue, 31 Oct 2017 13:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkkM_4XMjy7q; Tue, 31 Oct 2017 13:20:54 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC54E1397F3; Tue, 31 Oct 2017 13:20:54 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id b79so157377pfk.5; Tue, 31 Oct 2017 13:20:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.101.86.196 with SMTP id w4mr3058115pgs.335.1509481254112; Tue, 31 Oct 2017 13:20:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.8 with HTTP; Tue, 31 Oct 2017 13:20:53 -0700 (PDT)
In-Reply-To: <a95540be-9e15-a5dd-a4e6-e6316fc008c2@labn.net>
References: <1872ff72-845f-4b85-11a5-f00123223fb5@pi.nu> <2d0dd3b5-1fb9-1435-a1f7-0d04ff98ad49@labn.net> <CA+YzgTutss04yaM2XQ7kti1ja0cwwmKkhZXaCOnFgkvWkYaeNg@mail.gmail.com> <a95540be-9e15-a5dd-a4e6-e6316fc008c2@labn.net>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Tue, 31 Oct 2017 16:20:53 -0400
Message-ID: <CA+YzgTvczagArspbWKcSZdj6fymZMSmkitffBpwfKOchHn3-Cg@mail.gmail.com>
To: Lou Berger <lberger@labn.net>
Cc: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "draft-sitaraman-mpls-rsvp-shared-labels@ietf.org" <draft-sitaraman-mpls-rsvp-shared-labels@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/CXMUQqGUR0YVsO-D44z3QeRXnqQ>
Subject: Re: [mpls] working group adoption poll on draft-sitaraman-mpls-rsvp-shared-labels
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 31 Oct 2017 20:20:57 -0000

Lou, Hi!

Thanks for the feedback!
Please see inline.

Regards,
-Pavan

On Fri, Oct 27, 2017 at 5:43 PM, Lou Berger <lberger@labn.net> 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 <lberger@labn.net> 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 (mpls@ietf.org). 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
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls
>>
>