Hello Dhruv & all
Thanks again for meeting today. Capturing some notes here to share with the
list.
As discussed, here’s some comments / items to consider for
draft-barth-pce-segment-routing-policy-cp:
1. Candidate path support for multiple SID Lists + weight of each SID list
* draft-barth-pce-segment-routing-policy-cp defines a PLSPSID per
candidate path, therefore 1 SID list (expressed as ERO) per candidate path.
Therefore, in this draft there's no way to express multiple SID lists (and
their weight) per candidate path.
* As discussed, one option may be to map one PLSPID for each SID list
and to tag these objects with something (such as Tunnel-ID) that binds them to
the same candidate path. A new TLV for weight is likely required. It's still
not clear to me where/how the attributes of the candidate path (such as
originator (see below)) would also be included in the messaging
2. PCREPORT should notify which candidate path is active under a given SR
Policy
* Status UP may be valid on multiple candidate paths, but only one of
them is active
* SRCPAG-INFO-TLV would therefore contain an active flag which would
need to be set true for all reports related to SID list (as per previous
bullet) whose parent candidate path is active
3. SR Policy null endpoint support + PCREQ?
* (theoretically) SR Policy definition could contain null endpoint
0.0.0.0 for steering purposes but wishes to have a dynamic candidate path and
use PCE to compute. draft-ietf-spring-segment-routing-policy points to
filsfils-spring-sr-policy-considerations for considerations regarding dynamic
path optimization objective, but it’s not explicitly stated regarding whether
the candidate path definition may contain a destination for local/PCE
calculation purposes.
* Therefore, in draft-barth-pce-segment-routing-policy it might be worth
mentioning/commenting on whether this is intentionally defined or not.
* Obviously, For PCE to compute it needs a real destination IP so I
assume SRCPAG-INFO-TLV would contain 0.0.0.0 and the END-POINTS object would
contain the intended-for-calculation-destination?
* For these reasons calling SRCPAG-INFO-TLV attribute “destination
end-point” may be confusing (even though it’s within the SRPOL ASSOCIATION
object). Perhaps calling it “sr-pol end-point” or something different may be a
good idea.
4. Protocol-origin attribute is missing and likely needed
* If the goal is for PCEP SR-Policy support is to also report state for
SR policies from other origins (such as statically configured) then the
candidate path protocol-origin should be advertised as well
5. Clarification / reference for BSID
* draft-sivabalan-pce-binding-label-sid describes a generic path binding
TLV for PCEP LSPs. I assume this draft would be referenced inside
draft-barth-pce-segment-routing-policy for messaging the candidate path BSID
Cheers
Andrew
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
