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
