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) < [email protected]> 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. > > - 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 > ca**ses 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 <[email protected]> on behalf of [email protected] < > [email protected]> > *Sent:* Friday, January 17, 2020 5:12 AM > *To:* [email protected] <[email protected]> > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
