Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

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) <
andrew.stone@nokia.com> wrote:

> Hi Rakesh,
>
>
>
> Thanks for the speedy reply. One follow up comment below.
>
>
>
> Cheers
>
> Andrew
>
>
>
> *From: *Rakesh Gandhi <rgandhi.ietf@gmail.com>
> *Date: *Monday, January 20, 2020 at 9:49 AM
> *To: *"Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@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.stone@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-bounces@ietf.org> on behalf of julien.meuric@orange.com <
> julien.meuric@orange.com>
> *Sent:* Friday, January 17, 2020 5:12 AM
> *To:* pce@ietf.org <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
> https://www.ietf.org/mailman/listinfo/pce
>
>