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

[tom petch <[e-mail]>]

From: Aijun Wang <[e-mail]>
Sent: 26 May 2023 07:24

Hi, Tom:

Aijun Wang
China Telecom

On May 25, 2023, at 19:41, tom petch <[e-mail]> wrote:

From: Aijun Wang <[e-mail]>
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 <[e-mail]> wrote:


Tom:

Thank you for letting me know.  I’ll send comments to PCE.

Sue

From: tom petch <[e-mail]>
Sent: Wednesday, May 24, 2023 5:47 AM
To: Susan Hares <[e-mail]>; idr@ietf