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.

>
>    - 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 <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
>