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
* 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?
* 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.
* 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.
* 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.
* 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.
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
