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 >
- [mpls] working group adoption poll on draft-sitar… Loa Andersson
- Re: [mpls] working group adoption poll on draft-s… Stewart Bryant
- Re: [mpls] working group adoption poll on draft-s… Adrian Farrel
- Re: [mpls] working group adoption poll on draft-s… Ravi Torvi
- Re: [mpls] working group adoption poll on draft-s… Vishnu Pavan Beeram
- Re: [mpls] working group adoption poll on draft-s… Harish Sitaraman
- Re: [mpls] working group adoption poll on draft-s… Chandrasekar Ramachandran
- Re: [mpls] [E] working group adoption poll on dra… Parikh, Tejal
- Re: [mpls] working group adoption poll on draft-s… Ambrose Kwong
- Re: [mpls] working group adoption poll on draft-s… Lou Berger
- Re: [mpls] working group adoption poll on draft-s… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-s… Vishnu Pavan Beeram
- Re: [mpls] working group adoption poll on draft-s… Vishnu Pavan Beeram
- Re: [mpls] working group adoption poll on draft-s… Lou Berger
- Re: [mpls] working group adoption poll on draft-s… Vishnu Pavan Beeram
- Re: [mpls] working group adoption poll on draft-s… Tarek Saad (tsaad)
- Re: [mpls] working group adoption poll on draft-s… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-s… Vishnu Pavan Beeram
- [mpls] Closed --- Re: working group adoption poll… Loa Andersson