Hi authors,
I have the following comments on your draft:
1. Support for multiple candidate-paths, segment-list, etc.
The procedures defined here are not aligned to those in
“draft-barth-pce-segment-routing-policy-cp” for unicast SR policies– for
example:
1. Ability to instantiate multiple candidate path, or
2. Using SR Candidate Path Association Group to associate the multiple
candidate-path(s) for the same SR policy, or
3. Ability of having multiple Segment-list(s) per endpoint (with
equal/unequal weights)
What are your plans to align to draft-barth-pce-segment-routing-policy-cp?
2. Path selection when instantiating using different protocols (e.g. BGP SRTE,
PCEP, or NETCONG/config)
For unicast SR policies, it is possible have multiple candidate paths (for the
same SR policy) instantiated via BGP, PCEP, or NETCONG/config. In such case, a
preference-based selection and tie-breaking criteria to select from amongst the
candidate path(s) was defined, but those cannot be applied using approach
defined in this ID.
Any plans to address this?
3. SR-IPV4-P2MP-LSP-IDENTIFIER TLV, LSP-ID and P2MP-ID
If 1) and 2) above are sorted out, I believe LSP-ID would not be needed and can
be removed.
I prefer to completely replace P2MP-ID by “color” to 1) aligned to the ‘color’
for used in unicast SR Policies, and 2) avoid the confusion since P2MP ID is
set by the ingress in RSVP-TE – noting `color` is usually carried in service
routes as ext-com so that the ingress can use it as a service selector.
4. New SR-P2MP-CCI Object:
I understand you are inheriting this object from
“draft-ietf-pce-pcep-extension-for-pce-controller-00”, however, it is not clear
to me how one can program a P2MP Tree-SID (e.g. having an In-label
cross-connected to multiple next-hops – where each next-hop having its own
label stack)?
If the assumption is multiple CCI Objects (Type MPLS Label) will be downloaded
for each out-label in the stack? If so, what defines the position in the label
of the stack? How can I specify an out-label stack with repeated same label,
e.g. next-hop=NH, and out-label-stack-{L1, L1, L1}? Noting, could downloading
the same SR-P2MP-CCI with same outgoing label multiple times be interpreted as
redundant?
5. Programing new/reopt p2mp SR LSP
When setting up the LSPs, a sequential order of visiting nodes starting from
egress back ingress is desirable (for example see Figure 2: Basic PCECC LSP
setup in draft-ietf-pce-pcep-extension-for-pce-controller).. I did not see it
explicitly highlighted in your draft.
Regards,
Tarek
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
