As contributor and/or authors of all three drafts/RFCs, I think moving the BSID text into draft-sidor-pce-lsp-state-reporting-extensions is doable and clearer.
Thanks, Cheng From: Samuel Sidor (ssidor) <ssi...@cisco.com> Sent: Thursday, November 28, 2024 11:19 AM To: Andrew Stone (Nokia) <andrew.st...@nokia.com>; draft-ietf-pce-segment-routing-policy...@ietf.org Cc: draft-sidor-pce-lsp-state-reporting-extensi...@ietf.org; pce@ietf.org; Samuel Sidor (ssidor) <ssidor=40cisco....@dmarc.ietf.org> Subject: RE: Explicit BSID handling for PCE initiated LSPs Thanks, Andrew. I know that WGLC for "draft-ietf-pce-segment-routing-policy-cp" was already done, but it will be definitely cleaner to just drop that "specified BSID only" extension completely - update section 3 (we can include some statement indicating that there is no change to BSID behavior), remove S flag from 5.1 and remove sections 5.5 and 6.4. By the way - current version is really even conflicting with RFC9604 for PCE initiated policies as it is saying "If the binding SID cannot be allocated or programmed for some reason, then the LSP must stay down.". Authors and WG please let me know your opinion, I can prepare that updated version for you if we agree to proceed. For "draft-sidor-pce-lsp-state-reporting-extensions" - agreed. If we will see that major part of the draft is really related to BSID, then I can imagine splitting draft into 2 (BSID extensions vs lsp-path-type) or just renaming it (and keep slightly unrelated extension). Thanks, Samuel From: Andrew Stone (Nokia) <andrew.st...@nokia.com<mailto:andrew.st...@nokia.com>> Sent: Monday, November 25, 2024 6:54 PM To: Samuel Sidor (ssidor) <ssidor=40cisco....@dmarc.ietf.org<mailto:ssidor=40cisco....@dmarc.ietf.org>>; pce@ietf.org<mailto:pce@ietf.org> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>; draft-sidor-pce-lsp-state-reporting-extensi...@ietf.org<mailto:draft-sidor-pce-lsp-state-reporting-extensi...@ietf.org> Subject: Re: Explicit BSID handling for PCE initiated LSPs Hi Samuel, PCE WG Thanks for bringing this to attention to the WG. I agree with your assessment that RFC9604 is effectively 'specified-bsid-only' inheritly today. Therefore yes, agree that the S bit being proposed in https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp#name-specified-bsid-only is looking redundant in PCEP since that's the implicit behavior by default, and to cover the options described by RFC9256 you would actually want an inverse kind of flag to permit relaxation. Since RFC9604 is quite clear in its rejection behavior, I agree it would make sense to make a targeted update to permit relaxation, independent of SR Policy (since, RFC9604 is not really tunnel-type specific). I do think draft-ietf-pce-segment-routing-policy-cp will probably still need to remark that BSID behavior and semantics are specified(and limited) by RFC9604 and that it introduces no new controls. While I think my preference would be for this to be in a dedicated document, I can appreciate the motivation to not spread updates in multiple docs since draft-sidor-pce-lsp-state-reporting-extensions is also bringing in Transit Eligible. So think it's okay to keep it there for now as the document progresses but it might be worth popping out if a lot more text gets added on this topic. Another really minor consideration: not sure if accepting PcUpd/PcInit invalid BSID value would be considered a 'Reporting Extension' as opposed to something like a pce-binding-label-sid-extension :) But again, we can keep as is for progression for now. In summary: agree with your points below. Thanks! Andrew From: Samuel Sidor (ssidor) <ssidor=40cisco....@dmarc.ietf.org<mailto:ssidor=40cisco....@dmarc.ietf.org>> Date: Thursday, November 21, 2024 at 5:12 AM To: pce@ietf.org<mailto:pce@ietf.org> <pce@ietf.org<mailto:pce@ietf.org>> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org> <draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>>, draft-sidor-pce-lsp-state-reporting-extensi...@ietf.org<mailto:draft-sidor-pce-lsp-state-reporting-extensi...@ietf.org> <draft-sidor-pce-lsp-state-reporting-extensi...@ietf.org<mailto:draft-sidor-pce-lsp-state-reporting-extensi...@ietf.org>> Subject: [Pce] Explicit BSID handling for PCE initiated LSPs CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi PCE WG, In IETF 121, I presented extension for BSID handling from: https://www.ietf.org/archive/id/draft-sidor-pce-lsp-state-reporting-extensions-00.html#name-binding-label-sid-dynamic-f I also mentioned during that presentation that RFC9604 is describing possibility to specify explicit BSID for PCE initiated LSPs, but it is also saying that PCC must reject complete request if such BSID cannot be allocated on headend. That seems to be a bit misaligned (not violating) with description in SR policy architecture, which is suggesting to just generate alert message (we can consider PCError as "alert"), but we are also rejecting complete request as well: https://www.rfc-editor.org/rfc/rfc9256.html#name-bsid-of-an-sr-policy When the specified BSID is not available (optionally is not in the SRLB), an alert message MUST be generated via mechanisms like syslog. In the cases (as described above) where SR Policy does not have a BSID available, the SR Policy MAY dynamically bind a BSID to itself. Dynamically bound BSIDs SHOULD use an available SID outside the SRLB. RFC9604 (PCEP BSID) in reality is more aligned with alternate (not described in main section for BSID, but only as option, which may be supported) behavior described in: https://www.rfc-editor.org/rfc/rfc9256.html#name-specified-bsid-only Then we have policy-cp draft, which is actually introducing "specified BSID only" behavior in PCEP: https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp#name-specified-bsid-only Which is finally enabled by default anyway (at least for PCE initiated LSPs), so that option has low added value (possible added value is only to report what behavior is enabled by local policy for PCC configured policy). So I was thinking whether it would not be better to drop "specified BSID only" extension from policy-cp draft (as that is useless) and introduce possibility to create policy with explicit BSID even if BSID is not available on headend in "draft-sidor-pce-lsp-state-reporting-extensions" and either keep policy down or allow fallback to dynamic BSID (behavior can be controlled by flag in PCEP or by local policy) to align options with SR policy architecture. That way BSID related extensions will not be spread across multiple drafts and we will not have "useless" specified BSID only extension in PCEP. Any opinions? Thanks, Samuel
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
