Yes, I agree. Better move the BSID handling to Samuel's draft to be more
accurate.
Thanks,
Mike.
On Wednesday, December 4th, 2024 at 11:48 AM, Cheng Li
<c.l=40huawei....@dmarc.ietf.org> wrote:
> 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>
> Sent: Monday, November 25, 2024 6:54 PM
> To: Samuel Sidor (ssidor) <ssidor=40cisco....@dmarc.ietf.org>; pce@ietf.org
> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org;
> 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>
> Date: Thursday, November 21, 2024 at 5:12 AM
> To: pce@ietf.org <pce@ietf.org>
> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org
> <draft-ietf-pce-segment-routing-policy...@ietf.org>,
> draft-sidor-pce-lsp-state-reporting-extensi...@ietf.org
> <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
