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
