Hi Rakesh, Thanks for the speedy reply. One follow up comment below.
Cheers Andrew From: Rakesh Gandhi <rgandhi.i...@gmail.com> Date: Monday, January 20, 2020 at 9:49 AM To: "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.st...@nokia.com> Cc: "pce@ietf.org" <pce@ietf.org> Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Hi Andrew, Thank you for your review comments. Please see some comments inline with <RG>. On Sun, Jan 19, 2020 at 5:57 PM Stone, Andrew (Nokia - CA/Ottawa) <andrew.st...@nokia.com<mailto:andrew.st...@nokia.com>> wrote: Hi PCE WG and Authors, It's possible some of these items have been discussed prior to me following the WG, so apologies in advance if that's the case. Some questions/comments regarding the document: * Agree, PCEP definition/support for SR Bi-dir associated LSPs is needed feature set and work to be covered by the WG <RG> Great, thanks. * For bidirectional associating two LSPs, does PCC/PCE need an additional way to distinguish whether it's an SR or an RSVP bidirectional association? Would that not be implicit based on the path setup type of the LSPs which have been associated together? In other words, do we actually need double-sided bidirectional SR association group object defined? draft-li-pce-sr-bidir-path-06 seems to imply the behavior is basically the same as MPLS-TE (minus the RSVP signalling of course) and the object encoding is the same, so does yet-another object need to be defined? From a PCEP message encoding p.o.v within an association object structure, are 2 SR LSPs that different than associating 2 RSVP LSPs? <RG> Main difference is that in case of RSVP-TE, the egress node learns the reverse LSP via RSVP signaling whereas in case of SR, the egress node learns the reverse LSP via PCE. <Andrew> Yes, I realize that, however the association structure is about informing PCE to associate two LSPs together, is it not? It’s not related to how 2 LSPs learn each opposite reverse path. To be specific, my comment is regarding section 3.1. To instruct PCE “make these 2 bidirectional” is a separate task than how the LSPs learn of each other’s reverse LSP and path in my opinion. So to inform PCE “these 2 LSPs are bidirectional, make them so” is the same instruction irrelevant of how each LSP learns of each others path. For SR, yes there is the added process where PCE may need to tell the PCC the opposite path, but that decision is a behaviour post-association being provided, which can be determined as necessary by the LSP path setup type of the associated LSPs. So if the goal of to instruct PCE “these 2 LSPs are bidirectional”, that instruction is common between LSPs whether they are RSVP or SR. Essentially defining 'Double-sided Bidirectional SR Path Association Group' is not required (unless there’s something else in that object we foresee being specific to SR in the future). * While I can appreciate the need for textual clarity, and perhaps I'm missing something, but for some reason I find sections 1, 3, and 4 quite verbose to essentially say at it's core: "use the objects defined in draft-ietf-pce-association-bidir, except use this new value type double-sided-bidirectional-sr instead. You can also use path segment". * In Section 5 I would prefer the document would say "there are use cases which require the PCC to be aware of the reverse direction SR path. A PCE MAY inform the reverse SR Paths to the ingress PCCs and vice versa in order to provide functionality for those use cases". Associating two LSPs together and never informing them of each others reverse path is a valid, simple use case. Therefore having PCC informed of the reverse path to achieve further use cases is truly "OPTIONAL" in my opinion. <RG> Agree. * Related to previous point, my preference would be for references to pce-sr-path-segment be considered as a MAY, as there isn't a need for path-segment in a basic case of associating bi-directional LSPs for PCE to manage/compute bi-directional paths for. <RG> Agree. * Section 5 I think needs a bit more discussion: * I agree the PCC should not instantiate the reverse path, but it's not stated how to make this decision. I assume this is easy enough to decide with the reverse (r) bit in the association object? Might be worth mention. <RG> Ok. * indicates PCE needs to allocate a PLSP-ID for the reverse path to tell the ingress PCC, due to potential PLSPID space collision. RFC 8231 & RFC8281 has PCC owning the PLSP-ID. At first I was confused, then remembered about PCE Controlled ID space draft. I suppose this text is a carry over from path segment integration, but li-pce-controlled-id-space is not referenced directly, more transitively via path-segment which is only SHOULD as an inclusion. My question is, is there actually a need to use PCE Controlled ID space to achieve notifying the PCC about the reverse path? Would the indication of "PCE-init + R bit" be enough to let PCC generate the PLSP-ID and report it back, while also not instantiating the path? * Possibly depending on the outcome of previous comment, I would recommend the diagrams in 5.1 and 5.2 include example PLSP-IDs. <RG> I will let Dhruv and other co-authors comment on this. Thanks for your support. Thanks, Rakesh * In general this document appears to be a good base to work from to achieve bi-dir sr association. Support adoption. Thanks Andrew ________________________________ From: Pce <pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>> on behalf of julien.meu...@orange.com<mailto:julien.meu...@orange.com> <julien.meu...@orange.com<mailto:julien.meu...@orange.com>> Sent: Friday, January 17, 2020 5:12 AM To: pce@ietf.org<mailto:pce@ietf.org> <pce@ietf.org<mailto:pce@ietf.org>> Subject: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? Hi all, It is time to share your thoughts about draft-li-pce-sr-bidir-path-06. Do you believe the I-D is a right foundation for a PCE WG item? Please use the PCE mailing list to express your comments, support or disagreement, including applicable rationale, especially for the latter. Thanks, Dhruv & Julien _______________________________________________ Pce mailing list Pce@ietf.org<mailto:Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
