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

Lou Berger <lberger@labn.net> Fri, 27 October 2017 21:51 UTC

Return-Path: <lberger@labn.net>
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 B1F0413875A for <mpls@ietfa.amsl.com>; Fri, 27 Oct 2017 14:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 7B6nmktmldo9 for <mpls@ietfa.amsl.com>; Fri, 27 Oct 2017 14:51:43 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291C813A034 for <mpls@ietf.org>; Fri, 27 Oct 2017 14:51:43 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id A2FF21790EC for <mpls@ietf.org>; Fri, 27 Oct 2017 15:43:47 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) 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; d=labn.net; 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 pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:48748 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1e8CPn-00342w-QS; Fri, 27 Oct 2017 15:43:43 -0600
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
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>
References: <1872ff72-845f-4b85-11a5-f00123223fb5@pi.nu> <2d0dd3b5-1fb9-1435-a1f7-0d04ff98ad49@labn.net> <CA+YzgTutss04yaM2XQ7kti1ja0cwwmKkhZXaCOnFgkvWkYaeNg@mail.gmail.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <a95540be-9e15-a5dd-a4e6-e6316fc008c2@labn.net>
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: <CA+YzgTutss04yaM2XQ7kti1ja0cwwmKkhZXaCOnFgkvWkYaeNg@mail.gmail.com>
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 - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1e8CPn-00342w-QS
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:48748
X-Source-Auth: lberger@labn.net
X-Email-Count: 15
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/K9DQkwbTQIks31Mc1fdFvs8xELI>
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: 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 <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.

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

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