Hi Dhrub, With what Aijun described and what you wrote.. I think your suggestions makes more sense to me now.
//Zahed On Fri, Aug 23, 2024 at 8:48 AM Dhruv Dhody <d...@dhruvdhody.com> wrote: > Hi Aijun, Zahed, > > On Fri, Aug 23, 2024 at 11:42 AM Aijun Wang <wangai...@tsinghua.org.cn> > wrote: > >> Hi, Zaheduzzaman: >> >> Thanks for your review and comments. >> Some detailed responses are inline below. >> If you agree or have other suggestions, please let me know. I will update >> the document accordingly later to reflect our consensus. >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> >> -----邮件原件----- >> 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] >> 代表 Zaheduzzaman Sarker via Datatracker >> 发送时间: 2024年8月22日 20:11 >> 收件人: The IESG <i...@ietf.org> >> 抄送: draft-ietf-pce-pcep-extension-native...@ietf.org; pce-cha...@ietf.org; >> pce@ietf.org >> 主题: [Pce] Zaheduzzaman Sarker's No Objection on >> draft-ietf-pce-pcep-extension-native-ip-35: (with COMMENT) >> >> Zaheduzzaman Sarker has entered the following ballot position for >> draft-ietf-pce-pcep-extension-native-ip-35: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for working on this document. I have not comments from transport >> protocol points of view. >> >> I have following comment/question though - >> >> - In section 6.1 it says - >> >> "The PCInitiate message SHOULD be sent to PCC which is >> acting as >> BGP router and/or RR." >> >> In Section 6.2 it says - >> >> "The PCInitiate message SHOULD be sent to every router on >> the >> path." >> >> To me it seems like there is not way to bypass those SHOULDs and get >> the >> route and session establishment procedure done. If that understanding >> is >> correct then what are the exceptionsthiking about to let the >> implementers >> skip that part? Also, if this understand is not true, then I would >> expect >> this document to give warnings on the effects of skiping the PCInitiate >> messages. >> 【WAJ】：For “SHOULD” in section 6.1 that you mentioned, the original >> considerations are that such PCInitiate message may be sent to PCCs only(in >> no-RR scenario); or be sent to PCC and RR(in RR scenario). If we use MUST, >> it will be not appropriate for the no-RR scenario. Then, we select the word >> "SHOULD". Or we change the text as below: >> "The PCInitiate message MUST be sent to PCCs which are acting as BGP peer >> routers and exchange routes directly, or MUST be sent to PCC and RR >> respectively when two PCCs exchange the routes via the RR" >> >> > Dhruv: Note that all routers including RR are acting as PCC. The use of > "PCC and RR" gives an impression that RR is not a PCC. > > IMHO the use of normative text in this section is not helping. In version > -34 this was lowercase should. > > My suggestion would be to change this to - > > "The PCInitiate message is sent to the BGP router and/or RR (which are > acting as PCC)." > > > >> For "SHOULD" in section 6.2, actually there are some situations that such >> PCInitiate messages doesn't need to be sent to every router. For example, >> if the links between two router are not congest, it is not necessary to >> control the forward path explicitly via the PCIniitiate message that >> includes EPR objects. The traffic can depend solely on the default path >> that calculated by the IGP algorithm to forward the traffic. This is the >> reason that we use the word "SHOULD", instead of "MUST". >> >> > This could be changed to - > > "For the purpose of explicit route addition, the PCInitiate message ought > to be sent to every router on the explicit path." > > Do folks agree with this text change instead? > > Regards, > Dhruv > > > > >> Should we add such explanation into the context then? >> >> >> >> _______________________________________________ >> Pce mailing list -- pce@ietf.org >> To unsubscribe send an email to pce-le...@ietf.org >> >>
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
