Re: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04
Adrian Farrel <adrian@olddog.co.uk> Tue, 22 December 2020 13:37 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A20C3A10A0; Tue, 22 Dec 2020 05:37:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 3xzPt3zTNwkF; Tue, 22 Dec 2020 05:37:13 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 AA2BB3A109E; Tue, 22 Dec 2020 05:37:11 -0800 (PST)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0BMDb8GB032100; Tue, 22 Dec 2020 13:37:08 GMT
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B17D42203A; Tue, 22 Dec 2020 13:37:08 +0000 (GMT)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 9AC402203B; Tue, 22 Dec 2020 13:37:08 +0000 (GMT)
Received: from LAPTOPK7AS653V ([87.113.187.83]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 0BMDb7Am008246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Dec 2020 13:37:08 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Dhruv Dhody' <dd@dhruvdhody.com>, pce@ietf.org
Cc: 'pce-chairs' <pce-chairs@ietf.org>
References: <CAP7zK5a1wD1vs=FyY_CyErGN_j5bFMFywVqr5CBZbD9gvRLy2g@mail.gmail.com>
In-Reply-To: <CAP7zK5a1wD1vs=FyY_CyErGN_j5bFMFywVqr5CBZbD9gvRLy2g@mail.gmail.com>
Date: Tue, 22 Dec 2020 13:37:07 -0000
Organization: Old Dog Consulting
Message-ID: <01fe01d6d867$8b3b9fe0$a1b2dfa0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQDfNQTtHkc0Vv3uI3AT1EyKlv4vE6vyZEGQ
Content-Language: en-gb
X-Originating-IP: 87.113.187.83
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25864.007
X-TM-AS-Result: No--9.095-10.0-31-10
X-imss-scan-details: No--9.095-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25864.007
X-TMASE-Result: 10--9.095200-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbDjNGpWCIvfTaeMaKzvXUpkG2HMvWEJenjxj Zct4QfWdBIeNRE2SLuDj7fHVAl9C78ZjWS+/cngMZSNLxsgoyr9PnKxAOPp4WfAlhlr8vzcdYrw TiCibn+p5f8vYxjcXGqyL4Ypulxck81caAHAsVkVO8qlnOXFSzy45ojdE7FAWfkiy7TTogYa92h NfeDCUvVmrMOBHukCupg2oCxmKCK2DX2CAyOsKNt1+No0HEURttlX8GfOXuDjfUZT83lbkEG4RZ q5Bvfozq/IXFxavMC/PnN0YHsQkkn2IKB5eohESPSCQg3BaqhWAwt46EiEGhETqq9Xa45y5mfZS nQAU0rE4T3/lk4s8q8yJMr/7ikRyn79nCE5goDbgnTiQMgPq/oLsLasl5ROhVyfzU4GikKYOB59 clnD1iHoV3fjBEUHN99xKwcU+yRppL0rJpuS26zdfT4zyWoZSSuH+GfgmQGd0QT71c31VP8N8UY UrpTOB8cC4CbXf2cfKOPizB88C0QtgJ854eHwO0x8on4GtZ8d9twJClWWSlx05C+fzCc4umx64y hYBxccm82OIu9r5iK7TOcaMTTTjgtLf8kVzpVEdiUoeZWVlyPtEoNSP/uXB/ZlT98dhI5nwP6Eh SNhXwspIsmbP77qCvMiPJvFUb7zM/uM2mmZRNfUwiX15l0tvAeCR7YmppCzMyIQ0Dmiw9WjtEqy FPlQ/lMRNTezYhOmFIQGEErfD4cLko0U8v7J0ihCjnGX2dsSaR0BTe6y8q6lZmPwQ/ZxtXa2+zE 1cP+WBfd8xFsi9CtS1+cCqMAMdqcvngzkLMRCeAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg46HM5rqDwqt9cI5PNlf9MRSdm3Q6KKtjLcmg+kNKuDv4zK8JlaP1FMvlUP9HpMCkg==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/AvCIqphj4VDe-j2hHn2yHGZX4M0>
Subject: Re: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Dec 2020 13:37:15 -0000
Hi, I've reviewed this draft and I think it is ready for adoption because the functionality (i.e., stitching segments without inter-domain signaling which means that path-key cannot be used) is valuable. There are a number of editorial comments below. I think they do not need to be addressed before adoption, but I hope the authors will factor them into a new revision after adoption. Thanks, Adrian === Need to update Young Lee's coordinates --- Abstract I think that BRPC or H-PCE are methods to achieve inter-domain paths not methods to be combined with inter-domain paths. How about... OLD This document specifies how to combine a Backward Recursive or Hierarchical method with inter-domain paths in the context of stateful Path Computation Element (PCE). NEW This document specifies how to use a Backward Recursive or Hierarchical method to derive inter-domain paths in the context of stateful Path Computation Element (PCE). END --- Abstract "It relies on..." comes in the sentence immediately after "This document..." I think you need to be more precise. Probably s/It relies on/The mechanism relies on/ --- Abstract s/enables to operate them/enables them to be operated/ --- Abstract A new Stitching Label is defined, new Path Setup Types, a new Association Type and a new PCEP communication Protocol (PCEP) Capability are considered for that purpose. I can't parse this. Possibly... For this purpose, this document defines a new Stitching Label, new Path Setup Types, new Association Type, and a new PCEP communication Protocol (PCEP) Capability. --- The requirement language should be moved into section 1.2 --- Introduction There is a *lot* of text in the Introduction. I wonder whether we need so much. Does every PCE document have to start with the whole history of PCE? I tried to boil down what this document is really about: - PCE is used to compute paths from MPLS-TE, GMPLS, and SR - Various mechanisms can be used to enable PCEs to cooperate to compute inter-domain paths including BRPC and H-PCE - MPLS-TE and GMPLS depend on signaling using RSVP-TE to set up paths, but it is not common to allow signaling across administrative domain borders. - SR depends on a stack of segment identifiers, but in an inter-domain path, this stack may become large, and detailed control of a path within one domain by packets originating in another domain might not be supported. - This document describes a mechanism whereby the paths across each domain remain under the control of those domains, and the paths are stitched together at domain boundaries to form a single end-to-end path. - The mechanism relies on cooperating PCEs to determine the end-to-end path with each PCE responsible for computing and initiating the paths within its domain. The PCEs are assumed to be stateful active PCEs so that they can instruct their networks to set up the paths. - Signaling (for MPLS-TE and GMPLS) is used only within individual domains. - Specific labels/SIDs are used to indicate which path segments should be stitched together. - To enable this mechanism, this document defines a new Stitching Label, new Path Setup Types, new Association Type, and a new PCEP communication Protocol (PCEP) Capability. I think that can be converted into text that is a little easier to read than the current Introduction. --- 1.1 s/end-o-end/end-to-end/ --- I think it would be helpful to have a figure that shows the solution architecture in more detail than that currently in section 1.1. Nothing wrong with that figure, but we also need to see the LSPs/SR-paths and where the signaling stops and how the label/SID on the inter-domain link is used. Also, how the PCEs talk to the various nodes. Something like the figure below would allow the descriptive text that follows. -------------- -------------- -------------- |Domain-A | |Domain-B | |Domain-C | | | | | | | | PCE------+--PCEP---+---PCE--------+--PCEP---+---PCE | | / | | / | | / | | / | | / | | / | | Src=========BNA-------BNB1===========BNB2------BNC=========Dst | | | Inter- | | Inter- | | -------------- Domain -------------- Domain -------------- Link Link 1. The PCEs in Domain-A, Domain-B, and Domain-C communicate using PCEP either directly, as shown, using BRPC or with a parent PCE if using BRPC. 2. The PCE in Domain-A selects an end-to-end domain path. It tells the PCE in Domain-B that the path will be used, and that PCE passes the information on to the PCE in Domain-C. 3. Each of the PCEs use PCEP to instruct the segment head ends. a. In Domain-A, the PCE instructs the Source node with the path to use to reach Border Node, BNA. The instructions also include the label or SID to use on the inter-domain link to BNB1. b. In Domain-B, the PCE instructs the ingress Border Node, BNB1, with the path to reach the egress Border Node, BNB2. The instructions also tell BNB1 the incoming label or SID that will be stitched to the intra-domain path, and the label or SID to use on the inter-domain link to BNC. c. In Domain-C, the PCE instructs the ingress Border Node, BNC, with the path to reach the Destination. The instructions also tell BNC the incoming label or SID that will be stitched to the intra-domain path. -----Original Message----- From: Pce <pce-bounces@ietf.org> On Behalf Of Dhruv Dhody Sent: 18 December 2020 12:52 To: pce@ietf.org Cc: pce-chairs <pce-chairs@ietf.org> Subject: [Pce] WG adoption poll for draft-dugeon-pce-stateful-interdomain-04 Hi WG, This email begins the WG adoption poll for draft-dugeon-pce-stateful-interdomain-04. https://datatracker.ietf.org/doc/html/draft-dugeon-pce-stateful-interdomain- 04 Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list. To accommodate for the holiday season, this adoption poll will end on 11th Jan 2021 (Monday). Thanks! Dhruv _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
- [Pce] WG adoption poll for draft-dugeon-pce-state… Dhruv Dhody
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Young Lee
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Adrian Farrel
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Dhruv Dhody
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Dhruv Dhody
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… olivier.dugeon
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Jeff Tantsura
- [Pce] 答复: WG adoption poll for draft-dugeon-pce-s… Zhenghaomian
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Boris Khasanov
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… olivier.dugeon
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Dhruv Dhody
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Daniele Ceccarelli
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Gyan Mishra
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Luis M. Contreras
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… julien.meuric
- Re: [Pce] WG adoption poll for draft-dugeon-pce-s… Dhruv Dhody