Hi Andrew, Thank you for your comment. Yes, the point of using PST (SR/RSVP) was discussed during the early stage of the draft and was converged to define a new association type, specifically due to the extra requirements related to the reverse LSP for SR. I will let other co-authors comments further.
Thanks, Rakesh On Mon, Jan 20, 2020 at 10:41 AM Stone, Andrew (Nokia - CA/Ottawa) < [email protected]> wrote: > Hi Rakesh, > > > > Thanks for the speedy reply. One follow up comment below. > > > > Cheers > > Andrew > > > > *From: *Rakesh Gandhi <[email protected]> > *Date: *Monday, January 20, 2020 at 9:49 AM > *To: *"Stone, Andrew (Nokia - CA/Ottawa)" <[email protected]> > *Cc: *"[email protected]" <[email protected]> > *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) < > [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. > > > > <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 <[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
