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

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

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.

I did wonder about using IPV4 to advertise IPv6 and vice versa, which some routing protocols now do, but that seems some way off.

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.org
Subject: At a slight tangent to Re: Delta Status 5/23/2023

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> on behalf of Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>

Sent: 23 May 2023 20:44

To: idr@ietf.org<mailto:idr@ietf.org>

Subject: [Idr] Delta Status 5/23/2023

<tp>

There is also a PCE I-D in WGLC which was flagged to the IDR WG a week ago as it involves PCE being used to configure and initiate a BGP session. (draft-ietf-pce-pcep-extension-native-ip)

I do not understand how it works.  The configuration information is supplied in a PCInitiate message to each peer that needs configuring.  The I-D mentions the requirement for Route Reflectors with potentially hundreds of clients).  The bit that puzzles me is Section 6.1 which says, once configured, the BGP session operates in a normal fashion.  Well, only when all have been configured.  If the first to be configured tries to establish a session, it will fail until its peers are configured.  I would expect a two phase approach, first configure and when that has been confirmed as successful, then activate the session.  For  a less significant protocol, a single phase might be appropriate but it does not seem so to me for BGP.

Tom Petch

Below is the short delta status.

A full status is at:

https://wiki.ietf.org/en/group/idr/idr-draft-status

Allocations can be found at:

https://wiki.ietf.org/group/idr/Early-Allocation-Status

WG LC

1. draft-ietf-idr-bgp-model-16

Shepherd: Jie Dong

Awaiting IPR from authors: (Keyur Patel, Mahesh Jethanandani)

Awaiting IPR from contributors (Alex Zhdankin, Rob Shakir, Kevin D’Souza, Deepak Bansal)

Next up for WG LC (in pre-WG LC reviews)

1. draft-ietf-idr-sdwan-edge-discovery-08

2. draft-ietf-idr-ct – currently in github review

3. draft-ietf-idr-car – currently in github review

Awaiting implementation report and/or draft revision for WG LC:

1. draft- ietf-idr-sr-policy-ifit-03,

2. draft-ietf-idr-bgp-ifit-capabilities-02,

3. draft-ietf-idr-flowspec-redirect-ip-03

Adoption (in Chairs Review) – next up date on 5/26/2023

1. draft-zzhang-idr-tunnel-encapsulation-label-stack

(shepherd: Keyur Patel)

2. draft-dong-idr-sr-policy-nrp-01 –

(shepherd: Susan Hares)

Adoptions in progress:

1. draft-chen-idr-tcp-user-timeout-01 – (5/5 to 5/26)

Lacks enough interest at this point.

Upcoming adoptions:

1. draft-zhang-idr-sr-policy-metric-04

2. draft-misra-idr-v4-island-v6-core-4pe-02

3. draft-peng-idr-segment-routing-te-policy-attrib

4. draft-ssangli-idr-bgp-generic-metric-aigp

5. draft-xie-idr-mpbgp-extension-4map6

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr