Zhan, and all, Please see some comments inline below. Regards, Sasha
Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: zhan.shuangp...@zte.com.cn [mailto:zhan.shuangp...@zte.com.cn] Sent: Wednesday, March 14, 2018 9:39 AM To: mach.c...@huawei.com Cc: Alexander Vainshtein <alexander.vainsht...@ecitele.com>; spring@ietf.org; Shell Nakash <shell.nak...@ecitele.com>; Michael Gorokhovsky <michael.gorokhov...@ecitele.com>; Dmitry Valdman <dmitry.vald...@ecitele.com>; stewart.bry...@gmail.com; Ron Sdayoor <ron.sday...@ecitele.com>; Hemmy Yona <hemmy.y...@ecitele.com>; draft-cheng-spring-mpls-path-segm...@ietf.org; hu.fang...@zte.com.cn; tang.chu...@zte.com.cn Subject: 答复: RE: Comments on draft-cheng-spring-mpls-path-segment-01 Hi everyone, I read the discussion in the mail and want to mention some of my own opinions. 1. The point that Sasha mentioned path segment can not identify the LSP at the transit node. it is indeed the case. The path segment mainly solves the identity of the tail node. Actuanlly the transit node identity LSP is generally applicable to node-by-node performance statistics. [[Sasha]] My collection of use cases stems from the combination of MPLS-TP with SR-MPLS as discussed in draft-hu-spring-sr-tp-use-case. In particular, there are requirements in RFC 5654 for the transit node to be aware of pairing between the two directions of a bi-directional (both co-routed bi-directional and associated bi-directional) if both cross the same transit node (they always do that for co-routed bi-directional LSPs). There are already some other solutions to address this problem, such as draft-ietf-mpls-flow-ident-07, which defines the flow ID to identify a specific object. Flow ID can be used for per LSR, per LSP, per Flow etc. It is more general and more flexiable. Path segment can combine with Flow ID to meet the needs of different scenarios. [[Sasha]] Please see above. 2. Regarding the distribution path segment, I rather agree with Mach's opinion that BGP may be a better choice. First, the BGP peer-to-peer model is more conform with the path segment application scenario. Actually the path segment does not need to be flooded within the IGP domain. In addition, BGP can solve the path segment distribution of SR tunnels across IGP domains. [[Sasha]] I would prefer to differentiate between the mechanisms for distribution of Path SIDs and their actual usage. From my POV, ability to distribute Path Segment IDs (complete with some relevant information, e.g., identification of paired LSP reverse direction LSP) should be defined both for IGP and BGP, and it will be up to the user which ones would be actually deployed in specific scenarios. Best regards, Zhan 原始邮件 发件人：MachChen <mach.c...@huawei.com<mailto:mach.c...@huawei.com>> 收件人：Alexander Vainshtein <alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>> 抄送人：spring@ietf.org<mailto:spring@ietf.org> <spring@ietf.org<mailto:spring@ietf.org>>Shell Nakash <shell.nak...@ecitele.com<mailto:shell.nak...@ecitele.com>>Michael Gorokhovsky <michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>Dmitry Valdman <dmitry.vald...@ecitele.com<mailto:dmitry.vald...@ecitele.com>>Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>RonSdayoor <ron.sday...@ecitele.com<mailto:ron.sday...@ecitele.com>>Hemmy Yona <hemmy.y...@ecitele.com<mailto:hemmy.y...@ecitele.com>>draft-cheng-spring-mpls-path-segm...@ietf.org<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org> <draft-cheng-spring-mpls-path-segm...@ietf.org<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org>> 日 期 ：2018年03月14日 11:07 主 题 ：RE: Comments on draft-cheng-spring-mpls-path-segment-01 Hi Sasha, Thanks for your prompt response! Section 2.1.1 discusses some potential directions for Path segment ID assignment and distribution, there are several ways that can be used. IGP based solution is good for the case where more nodes within the domain needs to learn the Path Segment ID. For the use cases as mentioned in Section 3, the nodes that need to learn the Path Segment ID are mainly the ingress LSR. For a centralized model, the centralized controller may also need to learn the Path Segment ID. So, for these use case, a point-2-point model (e.g., BGP) or request/reply model (e.g., PCEP) seems more suitable. How do you think? Best regards, Mach > -----Original Message----- > From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com] > Sent: Tuesday, March 13, 2018 7:30 PM > To: Mach Chen <mach.c...@huawei.com<mailto:mach.c...@huawei.com>> > Cc: spring@ietf.org<mailto:spring@ietf.org>; Shell Nakash > <shell.nak...@ecitele.com<mailto:shell.nak...@ecitele.com>>; Michael > Gorokhovsky > <michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; > Dmitry Valdman > <dmitry.vald...@ecitele.com<mailto:dmitry.vald...@ecitele.com>>; Stewart > Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>; > Ron Sdayoor <ron.sday...@ecitele.com<mailto:ron.sday...@ecitele.com>>; Hemmy > Yona > <hemmy.y...@ecitele.com<mailto:hemmy.y...@ecitele.com>>; > draft-cheng-spring-mpls-path-segm...@ietf.org<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org> > Subject: RE: Comments on draft-cheng-spring-mpls-path-segment-01 > > Mach, > Lots of thanks for a prompt and very encouraging response! > One more question: > > Do you and your colleagues plan to define the mechanism for distribution of > the Path Segment ID in IGP? > (Usually such mechanisms are defined in dedicated drafts separately for OSPF > and ISIS, but, at least, it should be nice to mention the fact in the draft). > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: > alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com> > > -----Original Message----- > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Mach Chen > Sent: Tuesday, March 13, 2018 1:22 PM > To: Alexander Vainshtein > <alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; > draft-cheng- > spring-mpls-path-segm...@ietf.org<mailto:spring-mpls-path-segm...@ietf.org> > Cc: spring@ietf.org<mailto:spring@ietf.org>; Shell Nakash > <shell.nak...@ecitele.com<mailto:shell.nak...@ecitele.com>>; Michael > Gorokhovsky > <michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; > Dmitry Valdman > <dmitry.vald...@ecitele.com<mailto:dmitry.vald...@ecitele.com>>; Stewart > Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>; > Ron Sdayoor <ron.sday...@ecitele.com<mailto:ron.sday...@ecitele.com>>; Hemmy > Yona > <hemmy.y...@ecitele.com<mailto:hemmy.y...@ecitele.com>> > Subject: Re: [spring] Comments on draft-cheng-spring-mpls-path-segment-01 > > Hi Sasha, > > Many thanks for your valuable comments! > > Please see my responses inline... > > > > > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander > > Vainshtein > > Sent: Sunday, March 11, 2018 9:44 PM > > To: > > draft-cheng-spring-mpls-path-segm...@ietf.org<mailto:draft-cheng-spring-mpls-path-segm...@ietf.org> > > Cc: spring@ietf.org<mailto:spring@ietf.org>; Shell Nakash > > <shell.nak...@ecitele.com<mailto:shell.nak...@ecitele.com>>; Michael > > Gorokhovsky > > <michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; > > Dmitry Valdman > > <dmitry.vald...@ecitele.com<mailto:dmitry.vald...@ecitele.com>>; Stewart > > Bryant > > <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>; Ron Sdayoor > > <ron.sday...@ecitele.com<mailto:ron.sday...@ecitele.com>>; > > Hemmy Yona <hemmy.y...@ecitele.com<mailto:hemmy.y...@ecitele.com>> > > Subject: [spring] Comments on draft-cheng-spring-mpls-path-segment-01 > > > > Dear authors of draft-cheng-spring-mpls-path-segment-01, and I have a > > few comments. > > > > 1. From my POV, the draft addresses the problem of identifying an > > incoming SR LSP at the tail-end node. > > a. This problem is real because SR LSPs, by their very nature, are > > MP2P > > (merging) LSPs. > > b. The draft does not try to solve the problem of SR LSP > > identification in transit nodes. > > Yes, that's the intention. > > > 2. The draft proposes two solutions (one-label and two-label) for the > > above- mentioned problem, and the authors expect the WG to discuss > > these solutions and to select the preferred one. As I see it: > > a. Both uses cases discussed in Section 3 of the draft can be > > addressed with any of these solutions b. IMHO and FWIW, as long as > > SR-MPLS leaves multicast out of scope (as mentioned in Section 6 of > > the SR Architecture draft), any future issue with identification of SR > > LSPs that can be addressed with the two-label solution can also be > > addressed with the one-label solution c. The two-label solution > > requires support of upstream-allocated labels and context-specific > > label spaces, i.e., adds substantial implementation complexity. The > > one-label solution can be implemented using just per platform label space of > downstream-allocated labels. > > d. Based on these considerations, my preference (FWIW) is for > > one-label solution. > > I also have the same preference as yours. > > > 3. The draft lists both the already mentioned SR Architecture draft > > and the SR- MPLS draft as Informative references, but the SRV6 Routing > > Header draft appears as a Normative reference. From my POV, the first > > two documents MUST be Normative references and the last one - an > > Informative reference, because the draft only deals with SR-MPLS. > > Agree, will update it in the next revision. > > > > > Hopefully, these notes can be useful. > > Very useful, as always! > > Thanks, > Mach > > > > > Regards, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: > > alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com> > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org<mailto:spring@ietf.org> > https://www.ietf.org/mailman/listinfo/spring > > ________________________________________________________________ > ___________ > > 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. ___________________________________________________________________________
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
