Hi Marina, I fully agree with your 3rd point. Path ID is not a routing object, it is more like an SR path attribute, so It is better to add sub-TLV to the LSP object. This is proposed in https://tools.ietf.org/html/draft-li-pce-sr-path-segment-01. In this way, the SR-ERO is not affected by path segment. The path segment can be added into the SID list based on the policy. I appreciate your idea very much.
Also, just like you said, the reverse ID can be carried within an LSP object, we did think about this at the beginning. However, we found that we need the detailed information of the reverse SR path in some scenarios, such as for directing the reverse path for BFD https://tools.ietf.org/html/draft-ietf-mpls-bfd-directed-09. But it is not suitable to carry the reverse SR path information within a LSP object. Also, it is a little bit weird to carry information another SR path within the LSP object. But if we use the association group object like using the association group (https://tools.ietf.org/html/draft-ietf-pce-association-bidir-01) to associate two MPLS LSPs into a bidirectional LSP, problem solved. Therefore, we defined a new association group called “Double-sided Bidirectional SR Path Association Group” for associating two unidirectional SR path into a bidirectional SR path in https://tools.ietf.org/html/draft-li-pce-sr-bidir-path-00. In this way, two unidirectional SR path can be associated as a unidirectional SR path in a general way without affecting SR-ERO list. Those drafts have been presented in IETF 102, and your comments are very welcome! BTW, there was a discussion among the authors of draft path segment about PCEP extensions for Path segment, and there was an agreement to follow the way defined in draft-li-pce-sr-path-segment-01 and draft-li-pce-sr-bidir-path-00. Last but not least, your comments and contributions are very welcome! Thanks, Cheng From: Pce [mailto:[email protected]] On Behalf Of Marina Fizgeer Sent: Wednesday, August 22, 2018 2:07 PM To: [email protected] Cc: Alexander Vainshtein <[email protected]>; [email protected]; Alexander Ferdman <[email protected]>; Ron Sdayoor <[email protected]>; [email protected]; [email protected]; Michael Gorokhovsky <[email protected]>; Rotem Cohen <[email protected]> Subject: Re: [Pce] PCEP extensions for SR-TP Hi, Xiong Quan, Thank you for reply. Some comments: 1. R bit shall be 1 for reverse direction (and not 0) 2. As I understand, we don’t have egress ERO for reverse direction. My suggestion was to add the second (reverse) path ID to the ingress ERO of LSP. 3. One remark: path ID is not routing object, may be make sense to add two sub-TLVs to the LSP object (one for forward path ID and one with R bit for reverse path ID). It means that LSP will have two additional attributes – forward path ID and reverse path ID Best regards, Marina From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Wednesday, August 22, 2018 6:28 AM To: Marina Fizgeer <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Michael Gorokhovsky <[email protected]<mailto:[email protected]>>; Alexander Ferdman <[email protected]<mailto:[email protected]>>; Ron Sdayoor <[email protected]<mailto:[email protected]>>; Alexander Vainshtein <[email protected]<mailto:[email protected]>>; Rotem Cohen <[email protected]<mailto:[email protected]>> Subject: 答复: PCEP extensions for SR-TP Hi Marina, Thanks for your attention and comments! I think you have proposed a good question. The "path label " which my draft defined is inserted into ERO list and uniquely identifies a uni-directional path. So one label can be added to the Ingress ERO list for the forwarding direction and another label with the R bit set to 0 can be added to the egress ERO list for the reverse direction. The two path labels can be the same or diffrent and can be binded to indentify a bi-directional path. I will update the draft soon and provide more details. More comments are welcome! Quan 熊泉 xiongquan 软件工程师 Software Engineer 预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R＆D Institute/Wireline Product Operation [cid:[email protected]] [cid:[email protected]] 武汉市东湖高新技术开发区华师园路6号中兴通讯 2/F, R&D Building, ZTE Corporation, Huashi Park Road 6th, Hi-tech Donghu District, Wuhan, P.R.China, 430022 T: +86 27 13871144372 E: [email protected]<mailto:[email protected]> www.zte.com.cn<http://www.zte.com.cn/> 原始邮件 发件人：MarinaFizgeer <[email protected]<mailto:[email protected]>> 收件人：[email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> 抄送人：熊泉00091065;胡方伟10075772;詹双平10034653;Michael Gorokhovsky <[email protected]<mailto:[email protected]>>Alexander Ferdman <[email protected]<mailto:[email protected]>>Ron Sdayoor <[email protected]<mailto:[email protected]>>Alexander Vainshtein <[email protected]<mailto:[email protected]>>Rotem Cohen <[email protected]<mailto:[email protected]>> 日 期 ：2018年08月20日 20:31 主 题 ：PCEP extensions for SR-TP Dear authors of draft-xiong-pce-pcep-extension-sr-tp, My colleagues and I are interested in some clarifications: According to this draft, Path label can be added as the last label in the LSP SR-ERO list. Each endpoint element needs 2 labels – one for forward path ID and one for incoming path ID Our question is – if 2 path labels can be added to the LSP SR-ERO list (one with “R” bit) per LSP? Path label with “R” bit set will not be added to outgoing label stack, but will be configured in the data plane as an incoming label. Using this approach one SR-ERO list will contain outgoing Path label as well as incoming Path label PCE path example: Best regards, Marina Email: [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
