Re: [Idr] At a slight tangent to Re: Delta Status 5/23/2023

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 26 May 2023 11:42 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBC5C151092 for <idr@ietfa.amsl.com>; Fri, 26 May 2023 04:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBucDidlvLmn for <idr@ietfa.amsl.com>; Fri, 26 May 2023 04:42:16 -0700 (PDT)
Received: from mail-m121145.qiye.163.com (mail-m121145.qiye.163.com [115.236.121.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9622C15106E for <idr@ietf.org>; Fri, 26 May 2023 04:42:14 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPV6:240e:47d:620:dfd7:598f:3ce4:e17b:6050]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id 672768003E7; Fri, 26 May 2023 19:42:08 +0800 (CST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Fri, 26 May 2023 19:41:57 +0800
Message-Id: <4544FF78-7ABD-4C13-BA60-0EDA3AD59C2A@tsinghua.org.cn>
References: <20230526184151.6AED7900117@mail-m121149.qiye.163.com>
Cc: Susan Hares <shares@ndzh.com>, idr@ietf.org
In-Reply-To: <20230526184151.6AED7900117@mail-m121149.qiye.163.com>
To: tom petch <ietfc@btconnect.com>
X-Mailer: iPhone Mail (20E252)
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFITzdXWS1ZQUlXWQ8JGhUIEh9ZQVlCTEtPVh5NTEJNTh5ISR1CTVUTARMWGhIXJBQOD1 lXWRgSC1lBWUlPSx5BT0wfQU1JS0EfHR9MQU5CQx1BSBgeT0EeSkwZQU1LTktZV1kWGg8SFR0UWU FZT0tIVUpOTElKSVVKS0tVSkJZBg++
X-HM-Tid: 0a8857ddb82bb03akuuu672768003e7
X-HM-MType: 1
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NDo6Hgw4Kz0QFUoDSjkfKjE0 HAsKCTpVSlVKTUNOSktKSElCS0hMVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJT0seQU9MH0FNSUtBHx0fTEFOQkMdQUgYHk9BHkpMGUFNS05LWVdZCAFZQU5CSE03Bg++
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/H2CKpUa76C3iwAFCEMVEENtuPQY>
Subject: Re: [Idr] At a slight tangent to Re: Delta Status 5/23/2023
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 May 2023 11:42:18 -0000

Hi, Tom:

Let’s image the possible scenario:
We should know that every PCC should be controlled only by one PCE. 
So if the PCE send the BPI object embedded PCInitiate message to one pair of PCCs devices that be instructed to establish the BGP session, it can set the waiting threshold for the BGP successful establishment one enough large value(if PCE cannot receive any successful establishment PCRpt during this period, it can determine the failure for this set of instructions and try another round), what’s the interoperability issue that you concern then?

I think it is similar with the host send the http request to the http server—-the client can determine itself that when it should initiate the next request.

Aijun Wang
China Telecom

> On May 26, 2023, at 18:41, tom petch <ietfc@btconnect.com> wrote:
> 
> From: Aijun Wang <wangaijun@tsinghua.org.cn>
> Sent: 26 May 2023 07:24
> 
> Hi, Tom:
> 
> Aijun Wang
> China Telecom
> 
> On May 25, 2023, at 19:41, tom petch <ietfc@btconnect.com> wrote:
> 
> From: Aijun Wang <wangaijun@tsinghua.org.cn>
> Sent: 25 May 2023 08:41
> 
> Hi, Tom and Sue:
> 
> Let me make some clarification first.
> Maybe the sentence in the document “ The example below shows two IBGP clients interacting with one RR, but it may have up to 100s of clients.” lead some confusion——-Actually, in such situation, only the two edge routers and RR need to be configured the new BGP session via the PCE, all other RR clients need not be configured again. The BGP prefixes advised by PPA(Peer Prefix Advertisement) Object via the PCInitiate message will be advertised via the existing BGP sessions between RR and its other clients.
> If we take the scenario illustrated in Figure 1 as the example, we can notice that the PCInitiate message is sent only to R1/R7/R3(RR), not to the R5 and R6.
> 
> For the two phase approaches, I think it is acceptable. How about the following updates:
> 
> 1) PCE sends the BPI object with PCInitiate message, then PCC  replies with “Ack, start BGP session”.
> 2) PCC reports the successful results to PCE after the BGP session is established successfully. In case of any failure during the process, PCC can report the error information accordingly.
> 
> The above proposed changes may be more friendly to the BGP session establishment.
> 
> <tp>
> I did start out by saying that I do not understand this I-D!
> 
> Session setup was one such where I see attempts failing  until all peers are configured and no knowing when that will be suggesting to me a need for guidance to implementers as to how long to wait, how often to retry and so on before declaring failure (or achieving success).
> 
> [WAJ] As indicated at https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip#name-bgp-considerations-2, we exchange only the key information for BGP session setup. Other values, for example, the BGP related timers should use the default values of each device. So each PCC can determine itself when it should send the PCRpt message to indicate the failure or successful of BGP session establishment.
> The PCE can also determine what’s its strategy to try again. All these are implemented dependent.
> 
> <tp>
> The BGP timers are irrelevant.  This is about PCEP related timers for configuring BGP and then activating a session.  If every implementation has its own idea of what the timers should be then I can see interoperability failing.
> 
> Tom Petch
> 
> Route Reflectors is another,  The I-D says they are 'required' (n.b. lower case) for IBGP but with no indication why.  Obviating the need to configure the hundreds of clients seems plausible but I think that that needs explaining.
> 
> [WAJ] Using RR to facilitate the full mesh like BGP sessions among all IBGP peers is the traditional design choice. There is no special reason.
> Will try add more explanations for the limited/selected configurations of BGP sessions among the RR clients.
> 
> I did wonder about using IPV4 to advertise IPv6 and vice versa, which some routing protocols now do, but that seems some way off.
> [WAJ] Yes, It’s possible but we don’t want to complex the solution. There is no urgent reason to do so.
> 
> Tom Petch
> 
> Aijun Wang
> China Telecom
> 
> On May 25, 2023, at 01:18, Susan Hares <shares@ndzh.com> wrote:
> 
> 
> Tom:
> 
> Thank you for letting me know.  I’ll send comments to PCE.
> 
> Sue
> 
> From: tom petch <ietfc@btconnect.com>
> Sent: Wednesday, May 24, 2023 5:47 AM
> To: Susan Hares <shares@ndzh.com>; idr@ietf