Hi Boris, 1) Preference is actually optional in the SR Policy Architecture [https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/], it defaults to the value "100". So, we are just following the same data model. Even though in CLI, preference may be a key for a Candidate Path, in the data model it's actually a non-key value that can change.
2) Yes, in the current proposal there is the "State" field in the TLV, which encodes the PCC's state, i.e., if it's dropping traffic or not. We could use this field to signal other "forwarding states" as well. 3) Yes, the wording is not clear about how many LSPs (report/update/initiate) can be put into a PCEP message. It's perfectly valid to send multiple, but there's currently no reason to do it (except saving 4-bytes of PCEP message header). I will clarify the wording. 4) Hmmm yeah that's a great idea. Because currently if first label resolution fails at the PCC, then the LSP would just be down, but there would be no "invalidation reason" sent back to the PCE. We can indeed provide some indication, probably per-SL, about first-hop label resolution status. Perhaps the INVALIDATION TLV can be re-used in the PATH-ATTRIB object to encode per-SL invalidation reason (1-st SID unresolved)? Thanks, Mike. From: Boris Khasanov <[email protected]> Sent: Friday, November 12, 2021 10:36 AM To: Mike Koldychev (mkoldych) <[email protected]> Cc: [email protected] Subject: Additional questions for draft-ietf-pce-segment-routing-policy-cp Hi Mike, Few more questions which I did not mention on the mike (and repeat one which is absent in the Notes): 1) I probably missed previous discussions ( I tried to search on mailarchive but no success) , pls remind - what is the logic why SRPOLICY-CPATH-PREFERENCE TLV is optional? IMO it is quite important to define CPATH preference into same SR Policy. 2) Could INVALIDATION TLV usage be extended also for PCC -> PCE (i.e. add this TLV to ASSOCIATION obj in PCRpt) case, to include some additional information to signal PCE what something goes wrong with LSP? What do you think? 3) s.7.4 currently says: " PCE sends a separate PCInitiate message for every candidate path that it wants to create, or it sends multiple LSP objects within a single PCInitiate message. " IMO, it needs to be re-phrased (as I said verbally too) to some more concrete like : "PCE SHOIULD send a separate PCInitiate message for every candidate path that it wants to create, or it MAY send multiple LSP objects within a single PCInitiate message." (or MAY for both cases if we want it to be relaxed) 4) Can we extend section 8.3 PCEP Errors to include some more detailed Error types, for example, SL or CPATH instantiation failure (i.e. when 1st label in SL is invalid) etc.? Idea is to provide PCE more detailed info about forwarding plane issues. Thank you. SY, Boris
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
