Hi, Tom: I think two phases approach may be more appropriate. As I replied you also in the IDR list, we propose the following update later:
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. Regarding to your worry about the “hundreds of clients” configuration, I think there may be some misunderstandings, or we should describe more clearly in the documentation to avoid such worry: 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 tolerance of BGP session establish duration, I think it should be determined by the PCE itself, because there is no guarantee way to assure the underlying establishment time lapse. The PCE can determine when it should retry, and when it will give up and determine the failure itself if it can’t still receive the responses from the PCC. Aijun Wang China Telecom > On May 24, 2023, at 23:45, tom petch <ie...@btconnect.com> wrote: > From: Aijun Wang <wangai...@tsinghua.org.cn> > Sent: 24 May 2023 15:47 > > Hi, Tom: > > As I explained in previous mail, the procedure of PCEP described in this > draft and the establishment of underlying BGP sessions that initiated by the > BPI object that included in the PCInitiate message is asynchronous. > The PCC will report the successful information only after the specific BGP > session has been established. We think it’s unnecessary to expose the details > BGP FSM states to the PCE—-If there is no successful report from the PCC, the > PCE can consider the BGP session is still undergoing. > > Does the above considerations solve your concerns? If necessary, we can > consider add some extra state reports from the PCC. > > <tp> > > Not really. The BGP session setup will fail until the peer is configured so > how long does the PCE wait for that, how often does it retry, when does it > give up and declare a failure? If one PCE is impatient, another leisurely, > then we may not have interoperability. I would expect some guidance on this. > > The I-D talks of RR with hundreds of clients which makes me wonder what else > might happen, such as a DoS attack. > > Tom Petch > > Aijun Wang > China Telecom > >> On May 24, 2023, at 17:24, tom petch <ie...@btconnect.com> wrote: >> >> Adding a new concern about session setup >> >> From: Pce <pce-boun...@ietf.org> on behalf of tom petch <ie...@btconnect.com> >> Sent: 22 May 2023 12:35 >> From: Pce <pce-boun...@ietf.org> on behalf of Dhruv Dhody >> <d...@dhruvdhody.com> >> Sent: 16 May 2023 23:15 >> >> <tp2> >> I do not understand how this operates. I would expect there to be two >> phases. first the boxes are configured with the information needed by BGP >> and then one or more is instructed to initiate the BGP session. Here I see >> PCInitiate providing the configuration information and s.6.1 then says that >> the BGP session the operates in a normal fashion; but if the PCE immediately >> attempts to initiate a session, it will likely fail because the peer is not >> yet configured. I assume it must then back off, wait and try again later >> and then report success or failure (after an extended period of time). Such >> behaviour could be found in a number of protocols. >> >> None of this seems to be catered for. >> >> Tom Petch >> >> >> This email starts a 2-weeks working group last call for >> draft-ietf-pce-pcep-extension-native-ip-20 [1]. >> >> <tp> >> I had a look and decided that it is mostly beyond me - I am not up to speed >> with all the 15 Normative References, in particular with RFC8821. I would >> prefer that this I-D provided a better bridge to the material in RFC8821. >> >> I note that RFC8821 is an as yet unapproved downref which reinforces that >> view. >> >> I note too that the Abstract references this and 8735 as anchors which >> Abstracts must not do. >> >> The I-D uses the word 'draft' in many places. These must be changed. >> >> The I-D has a large number of TBDnnn with no note requesting that they are >> replaced; I find these easy to miss. >> >> p.9 2) >> seems to end mid-sentence. >> >> The English is not quite in several places and could be confusing. Thus p.5 >> "Further only one >> of BPI, EPR, or PPA object MUST be present. " >> I can interpret in two ways although subsequent text makes one the preferred >> one. >> >> I suspect that there are many potential interactions with BGP, especially >> when things are not going quite right, and that the I-D does not cover them >> all. The language used is not that of BGP (e.g. Established, speaker). The >> timing too of BGP can be quite slow, in setup and in shutdown and I wonder >> how a PCC copes with that. >> >> As I say, largely beyond me but the English needs some attention; using the >> terminology of BGP would help. >> >> Tom Petch >> >> >> Please indicate your support or concern for this draft. If you are opposed >> to the progression of the draft to RFC, please articulate your concern. If >> you support it, please indicate that you have read the latest version and it >> is ready for publication in your opinion. As always, review comments and >> nits are most welcome. >> >> The WG LC will end on Wednesday 31st May 2023. We will also notify the IDR >> WG about this WGLC. >> >> A general reminder to the WG to be more vocal during the last-call/adoption >> and help us unclog our queues :) >> >> Thanks, >> Dhruv & Julien >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
