Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction
Susan Hares <shares@ndzh.com> Tue, 27 July 2021 21:58 UTC
Return-Path: <shares@ndzh.com>
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 55EA03A0A88; Tue, 27 Jul 2021 14:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.348
X-Spam-Level: *
X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 mzvWeNzQPBP8; Tue, 27 Jul 2021 14:58:26 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 79EF33A0A8D; Tue, 27 Jul 2021 14:58:25 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.107.119.54;
From: Susan Hares <shares@ndzh.com>
To: 'Aijun Wang' <wangaijun@tsinghua.org.cn>, pce@ietf.org
Cc: 'idr-chairs' <idr-chairs@ietf.org>, 'pce-chairs' <pce-chairs@ietf.org>
References: <074701d782b7$b0d19430$1274bc90$@tsinghua.org.cn>
In-Reply-To: <074701d782b7$b0d19430$1274bc90$@tsinghua.org.cn>
Date: Tue, 27 Jul 2021 17:58:10 -0400
Message-ID: <002d01d78332$7d7df850$7879e8f0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01D78310.F6730F10"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGxQOSLCGDTVg9cnNOeUKjAO7FkS6uj3bdQ
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/1nPOE_rL_nFr-icBkeyTuYavMzM>
Subject: Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction
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, 27 Jul 2021 21:58:31 -0000
Aijun: Thank you for your quick response. I¡¯ve answered questions below. Would you let me know when you update your draft? I¡¯ll re-read the sections that changed and make additional suggestions. If you think it would be useful to add 2 (or more) next hops per EPR, please let me know. I¡¯m glad to keep reviewing your changes. Cheers, Sue From: Aijun Wang [mailto:wangaijun@tsinghua.org.cn] Sent: Tuesday, July 27, 2021 3:19 AM To: 'Susan Hares'; pce@ietf.org Cc: 'idr-chairs'; 'pce-chairs' Subject: RE: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt---with HyperLink Correction Hi, Susan and all: Update one hyperlink on the contents, please refer to this mail for comments responses. From: pce-bounces@ietf.org <pce-bounces@ietf.org> On Behalf Of Aijun Wang Sent: Tuesday, July 27, 2021 12:04 PM To: 'Susan Hares' <shares@ndzh.com>; pce@ietf.org Cc: 'idr-chairs' <idr-chairs@ietf.org>; 'pce-chairs' <pce-chairs@ietf.org> Subject: Re: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt Hi, Susan: Thanks for your reviews, let me first address your current questions and wait for the further discussions on the overall solution. Best Regards Aijun Wang China Telecom From: pce-bounces@ietf.org <pce-bounces@ietf.org> On Behalf Of Susan Hares Sent: Tuesday, July 27, 2021 7:19 AM To: pce@ietf.org Cc: 'idr-chairs' <idr-chairs@ietf.org>; 'pce-chairs' <pce-chairs@ietf.org> Subject: [Pce] draft-ietf-pce-pcep-extension-native-ip-14.txt Greetings: Thank you for your work on draft-ietf-pce-pcep-extension-native-ip-14.txt. This comment should be consider feedback from me as a WG member of IDR and PCE. I have posted this information also on the This draft takes a step toward auto-configuration of BGP peers. IDR has created a set of requirements for BGP auto-configuration for Data Centers at: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-autoconf-considerations/ [WAJ] Yes, I have also reviewed this document and attended some discussions on it. The autoconf document tries to build the BGP from scratch without 3rd party(for example, PCE) assistance. It considers mainly the direct connected BGP peer setup process automatically and does not involve the prefix advertisement and explicit route setup. I think the aim of these two drafts is different but we can refer to some designed considerations from it. [Sue] You have understood that the bgp auto-configuration works on peer set-up. I simply wanted you to know that your PCE work linked that that work in BGP. I¡¯ve put a copy of these comments at: https://trac.ietf.org/trac/idr/wiki/pce-pcep-extension-native-ip%20Hares%20c omments Cheers, Sue Comments on draft-ietf-pce-pcep-extension-native-ip-14 ================================================= Overview of errors 1) section 6 description of BGP routers needs clarification (sections 6.1, 6.2, and 6.3) for RR and RR Clients [WAJ] Please see the replies inline below. 2) BGP Session Establish Procedures ¨C are these restrict to RR and RR Clients? [WAJ] Yes. The BGP session is established between RR and its clients in large network. It can also be established between two nodes directly.(as described in https://datatracker.ietf.org/doc/html/rfc8821#section-3) The point ¨Cto-point (P2P) Peering was clear in RFC8821. [Sue] It would be useful to revise the draft to clearly define this is a single AS, RR location, and RR client locations. 3) Explicit routes [section 6.2] ¨C Is ECMP support as well as 1 prefix/1 next Hop? [WAJ] Yes, ECMP is supported. PCE needs to send two EPR(Explicit Peer Route) objects, with the same ¡°Destination Adress¡± and ¡°Route Priority¡±, but different ¡°Next Hop Address¡± [Sue] ¨C it is possible to be more effective in the EPR by including 2 (or more) Next Hops. Have you consider this choice in PCE? 4) IPv4/IPv6 restrictions [section 6.3] ¨C are you restricting the peer session or the AFI/SAFI supported by the Peer session? [WAJ] AFI/SAFI supported by the peer session. [Sue] Again ¨C it would be helpful to clearly state AFI/SAFI. 5) Sections 7, 9, and 10 ¨C may need to change based on your answers to questions 1-4? Detailed questions --------------------- 1. Section 6 ¨C sub sections 6.1, 6.2 and 6.3. Problem: The text that describe the BGP peers and the diagram needs clarification on the BGP peering between BGP peers: R1, R7, and R3. If R1 and R7 are Route Reflector clients (RR clients) are attached to the R3 then it is important to indicate this point. [WAJ] Yes, R1 and R7 is RR clients. [Sue] Please make this fact clear in your next revision. If you are using classic route reflection, then R1, R3 and R7 would need to be in the same Autonomous system. [WAJ] Yes, certainly. [Sue] Please make that clear in your document. The RR (R3) determines what routes are sent to the RR clients. This problem impacts the text in section 6.1, 6.2, and 6.3 2.) Text change for Section 6.1 ¨C if R1 and R7 are RR clients. Here¡¯s a change if R1 and R7 are Router Reflector Clients. Current text: / The PCInitiate message should be sent to PCC which acts as BGP router and route reflector(RR). In the example in Figure 1, it should be sent to R1(M1), R3(M2 & M3) and R7(M4), when R3 acts as RR./ Improved text: / The PCInitiate message should be sent to PCC which acts as BGP router reflector or a route reflector client. In the example in Figure 1, it should be sent to the route reflector clients R1(M1) and R7 (M4), and the route reflector R3 (M1 or M4). / [WAJ] Has updated the draft with the following contents(almost same as your suggestions): The PCInitiate message should be sent to PCC which acts as BGP router and/or route reflector (RR). In the example in Figure 1, it should be sent to route reflector clients R1(M1) and R7(M4), and the route reflector R3(M2 & M3) when R3 acts as RR. PCInitiate message creates an auto-configuration function for these BGP peers providing the indicated Peer AS and the Local/Peer IP Address. [Sue] Thank you. Did you submit your updated draft? 3) Section 6.1 ¨C BGP Session Establishment Procedure Question: Does the PCEInitiate (message and report) require the RR and RR client structure? [WAJ] No. not necessary. The BGP session setup procedures is same between RR and its clients. [Sue]: If you use the PCEInitiate message with another structure, it would be useful To include an example in your document of multiple peers. If so, the PCInitiate should have a parameter indicate what type of BGP peer (RR or RR client) each receiving BGP peer should be. 4) Section 6.2 ¨C Explicit Route Establishment Procedure Problem: It is unclear what the impact to the routing system of the setting of explicit route. Basic Details: (1 Route with 1 Next Hop) If R1 and R7 are RR clients and the Explicit route operates as static route installed by the PCIntiate, then BGP peer will reflected these static routes R3. [WAJ] No, the explicit route is only installed on the aimed PCC nodes and such information will not be advertised via the BGP session between RR and its clients. [R1 (explicit route [static route]) ¨¤ R3] [R1 (explicit route [static route]) ¨¤ R7] [note my error] [Sue] If a route is installed in the RR clients, why is it not updated to the BGP Peer web (R1-RR-R7). I thought the purpose of adding it to the RR client. If it is not the purpose, why is this included in the BGP section? Setting or clearing the Explicit route seem to map to a setting/clear a static route on the node. If this is true, then this section needs to be rework to clear describe the process. [WAJ] Yes, it is similar with the static route on the node. The purpose of these explicit routes are to influence the final recursive forwarding path for prefixes advertised by BGP peer. [Sue] Then is the purpose to send it from 1 RR client (for example R1), and Have it redistribute to R3 (RR) and R7 (RR client). Your setting the route on the pathway hop by hop is similar to netconf/restconf setting routes in a pathway. [WAJ] Yes, it is similar. [Sue] Thank you. At least I got one detail correct [smile]. ECMP Details: (1 Route with multiple Next Hop) If the explicit route is a ECMP route with multiple next hop paths, the next hop for a route installed in could be R5 or R2. [WAJ] Yes. For ECMP routes, the PCE needs to send two EPR objects to PCC(in Figure2, on R1), with the ¡°Destination Address¡± are both set to R7, but the ¡°Nexthop Address¡± is set differently(for example, R2, R5 as you mentioned.). The ¡°Route Priority¡± field in EPR object should also be the same. [Sue] Thank you for the explanation. Do you think it is useful to allow 2 Next-Hops In the same EPR object. If ECMP is allowed, then you need to decide if: a) adding this route allows the route to be installed if only some of the next hops are valid (for example R5 is valid, but R2 is not) b) delete routing allows the route to be deleted if both next hops were not installed. [WAJ] Adding the description ¡°The PCC should verify that the next hop address is reachable.¡± before the sentence ¡°Upon the error occurs, the PCC SHOULD send the corresponding error via PCErr message, with an error information¡ ¡¡£ [Sue]: This is a wonderful addition. 5) Section 6.3 Problem: You do not clear indicate the status of BGP peer routers. If R1 and R7 are BGP route reflector clients, then R1 and R7 will send the route to R3 which will reflect the route to other RR clients (if policy allows). [WAJ] The propagation of BGP prefixes is the same as the traditional BGP procedures. The ¡°Peer Address¡± in PPA objects indicates which peer the prefixes will be sent to. [Sue] If you have trio of 2 RR clients and RR, then simply indicate you follow RR-RRclient rules. 6.) Section 6.3 Problem: It is unclear why there is a restriction for IPv4 prefix to be sent only via a IPv4 BGP section, and the IPv6 prefix only via a IPV6 section. Details: I think the author is trying to describe the peers support for a particular set of AFI/SAFIS for NLRI sent rather than the peering. However, it is unclear. [WAJ] What we want to express is that the IPv4 BGP Peer session will advertise/receive only IPv4 prefixes(AFI/SAFI is 1/1 ), and IPv6 BGP Peer session will advertise/receive IPv6 prefixes(AFI/SAFI is 2/1). [Sue]: Why did you make this restriction? Is it from PCE requirements? 7.) Sections 7.2 and 7.3 All of these issues on the intent of the protocol need to be answered before I can provide additional feedback on the PCEP objects. The initial shape of the PCE discussion are reasonable, but working through the details requires clarity in sections 6.1 to 6.3. For example, support for ECMP in the explicit routes may cause sections 7.3 and 7.4 to be rewritten. 8.) Section 9 ¨C The error handling must consider the RR to RR client distribution of routes. [WAJ] The route distribution process between the RR and RR clients is unchanged. Also, if one PCE overwrites another multiple route are sent from a RR client to the RR. The policy in the RR must be set-up to handle errors. [WAJ] The information from EPR object is not advertised by the RR client back to the RR. [Sue] What prevents the EPR object from being sent to the RR via BGP. Is the EPR object not installed in the BGP RIBs to be sent? I think I am missing something simple here. This section needs a bit of rethinking. 8.) Section 10 - BGP Considerations - The content of the BGP consideration sections seems reasonable, but it should be reviewed again after all the remainder of the document has been clarified. [WAJ] Wish to receive your more through considerations for the current solution. [Sue] Thank you for the discussion. Could you provide updates
- Re: [Pce] draft-ietf-pce-pcep-extension-native-ip… Aijun Wang
- Re: [Pce] draft-ietf-pce-pcep-extension-native-ip… Susan Hares
- Re: [Pce] draft-ietf-pce-pcep-extension-native-ip… Aijun Wang
- Re: [Pce] draft-ietf-pce-pcep-extension-native-ip… Susan Hares
- Re: [Pce] draft-ietf-pce-pcep-extension-native-ip… Aijun Wang
- Re: [Pce] draft-ietf-pce-pcep-extension-native-ip… Susan Hares
- Re: [Pce] draft-ietf-pce-pcep-extension-native-ip… Aijun Wang
- Re: [Pce] draft-ietf-pce-pcep-extension-native-ip… Susan Hares
- Re: [Pce] draft-ietf-pce-pcep-extension-native-ip… Susan Hares
- Re: [Pce] draft-ietf-pce-pcep-extension-native-ip… Aijun Wang