Re-,
I think that we are converging. Thanks for accommodating.
Please see inline.
Cheers,
Med
> -----Message d'origine-----
> De : Samuel Sidor (ssidor) <ssi...@cisco.com>
> Envoyé : mercredi 26 mars 2025 13:08
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>
> Cc : draft-ietf-pce-segment-routing-policy...@ietf.org; pce-
> cha...@ietf.org; The IESG <i...@ietf.org>; pce@ietf.org;
> d...@dhruvdhody.com
> Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-pce-segment-
> routing-policy-cp-22: (with DISCUSS and COMMENT)
>
>
> Hi Med,
>
> Thanks for your response, please check inline <S2>.
>
> Regards,
> Samuel
>
> -----Original Message-----
> From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>
> Sent: Wednesday, March 26, 2025 7:41 AM
> To: Samuel Sidor (ssidor) <ssi...@cisco.com>
> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce-
> cha...@ietf.org; The IESG <i...@ietf.org>; pce@ietf.org;
> d...@dhruvdhody.com
> Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-pce-segment-
> routing-policy-cp-22: (with DISCUSS and COMMENT)
>
> Hi Samuel,
>
> Thank you for the follow-up.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Samuel Sidor (ssidor) <ssi...@cisco.com> Envoyé : mardi 25 mars
> > 2025 14:06 À : BOUCADAIR Mohamed INNOV/NET
> > <mohamed.boucad...@orange.com> Cc :
> > draft-ietf-pce-segment-routing-policy...@ietf.org; pce-
> > cha...@ietf.org; The IESG <i...@ietf.org>; pce@ietf.org;
> > d...@dhruvdhody.com Objet : RE: Mohamed Boucadair's Discuss on
> > draft-ietf-pce-segment-
> > routing-policy-cp-22: (with DISCUSS and COMMENT)
> >
> >
> > Hi Med,
> >
> > Thanks a lot for your review and comments. I'll need some time to go
> > over comments in attached document, but please see inline responses
> > <S> at least.
> >
> > Regards,
> > Samuel
> >
> > -----Original Message-----
> > From: Mohamed Boucadair via Datatracker <nore...@ietf.org>
> > Sent: Monday, March 24, 2025 12:35 PM
> > To: The IESG <i...@ietf.org>
> > Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce-
> > cha...@ietf.org; pce@ietf.org; d...@dhruvdhody.com; d...@dhruvdhody.com
> > Subject: Mohamed Boucadair's Discuss on draft-ietf-pce-segment-
> > routing-policy-cp-22: (with DISCUSS and COMMENT)
> >
> > Mohamed Boucadair has entered the following ballot position for
> > draft-ietf-pce-segment-routing-policy-cp-22: Discuss
> >
> > When responding, please keep the subject line intact and reply to
> all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > --------------------------------------------------------------------
> > DISCUSS:
> > --------------------------------------------------------------------
> >
> > Hi Mike, Siva, Samuel, Colby, Shuping, and Hooman,
> >
> > Many thanks for the effort put into this specification.
> >
> > Thanks also to Xiao for the opsdir review and to the authors for
> > promptly addressing his comments.
> >
> > Please find below some few DISCUSS points, with a focus to ensure
> that
> > this spec is consistent with the other various pieces of work that
> > covers this same topic.
> >
> > ## Section 3
> >
> > CURRENT
> >
> > This document does not propose any extension for the use of BSID
> > with
> > SR Policy; the existing behavior is documented in [RFC9604].
> >
> > Are there additional considerations to take into account when used
> > with the new objects on this document? For example, the base spec
> says
> > "Candidate paths of different SR Policies MUST NOT have the same
> > BSID", while such checks are not (at least I failed to find where)
> > defined in 9604.
> >
> > <S> Specific case, which you described should be already covered
> with
> > following statement from Section 5 of RFC 9604:
> >
> > If the
> > binding value is valid but the PCC is unable to allocate the
> > binding
> > value, it MUST send a PCErr message with Error-Type = 32
> ("Binding
> > label/SID failure") and Error-value = 2 ("Unable to allocate the
> > specified binding value").
> >
>
> [Med] Thank you for pointing this excerpt, but I still don't see how
> this can be trivially linked to checking that "different SR Policies
> MUST NOT have the same BSID". Unless I'm missing something, having a
> statement that echoes that required check would be a simple fix here.
> Thanks.
>
> <S2> I still consider this more like generic BSID conflict handling
> (same way like there can be conflict between BSID of SR-policy with
> BSID of RSVP-TE tunnel for example), but there is no harm for adding
> something like:
> "If Binding SID allocation failed, because of conflict with Binding
> SID used by another policy, then PCEP peer MUST send a PCErr message
> with Error-Type = 32 ("Binding label/SID failure") and Error-value = 2
> ("Unable to allocate the specified binding value")."
>
> Is that acceptable for you?
>
[Med] Looks good to me. Thanks.
> > ## Section 4.2.1
> >
> > The SR policy BGP extension includes: "It is RECOMMENDED that the
> size
> > of the symbolic name for the SR Policy is limited to 255 bytes.
> > Implementations MAY choose to truncate long names to 255 bytes when
> > signaling via BGP"
> >
> > I guess we should be consistent and align the various pieces, unless
> > there are specifics to a given signaling mechanism.
> >
> > This is even important given that some computed paths will be passed
> > between the two signaling channels:
> >
> > "Typically, but not limited to, an SR Policy is computed by a
> > controller or a path computation engine (PCE) and originated by a
> BGP
> > speaker on its behalf."
> >
> > <S> In BGP, recommendation to limit length to 255 was introduced,
> > because of PDU limit, in PCEP we don't have any such limitation.
>
> [Med] hmm, draft-ietf-idr-sr-policy-safi has actually the following:
>
> The Policy Name sub-TLV may exceed 255 bytes in length due to a
> long
> policy name. A 2-octet length is thus required. According to
> section 2 of [RFC9012], the sub-TLV type defines the size of the
> length field. Therefore, for the Policy Name sub-TLV a code point
> of
> 128 or higher is used.
>
> It is RECOMMENDED that the size of the symbolic name for the SR
> Policy is limited to 255 bytes. Implementations MAY choose to
> truncate long names to 255 bytes when signaling via BGP.
>
> We
>
> <S2> I assume that it is not ideal to go into details of encoding of
> Policy or CP name in BGP in PCEP draft, so what about just
> recommending size of 255 and just specifying that it can help with
> mapping/interoperability with other protocols? So something like this:
>
> "It is RECOMMENDED that the size of the symbolic name for the SR
> Policy is limited to 255 bytes. Implementations MAY choose to
> truncate long names to 255 bytes to simplify interoperability with
> other protocols."
[Med] Works for me.
>
> > can still add statement to indicate that if PCE-Initiated LSPs are
> > reported to BGP-LS, then limit/recommendation of 255 as specified in
> > draft-ietf-idr-sr-policy-safi may be applied by implementations.
>
> [Med] Thanks. Adding such a reco is an enhancement. I think that we
> can avoid the "if" part and follows the same reasoning as the text I
> quoted above.
>
> >
> > ## Section 4.2.2: SR Policy Candidate Path Name
> >
> > The BGP extension has the following "It is RECOMMENDED that the size
> > of the symbolic name for the candidate path is limited to 255 bytes.
> > Implementations MAY choose to truncate long names to 255 bytes when
> > signaling via BGP"
> >
> > I guess we should be consistent.
> >
> > <S> Same as above.
>
> [Med] Idem as above :-)
>
> >
> >
> > --------------------------------------------------------------------
> --
> > COMMENT:
> > --------------------------------------------------------------------
> --
> >
> >
> > ## Section 3.1
> >
> > Who assigns the id? Who ensures unicity?
> >
> > <S> For ensuring unicity - we can update existing statement to
> > indicate that receiving PCEP peer MUST check it - "... the
> receiving
> > PCEP speaker MUST send a PCErr message ...".
> > For assignment - it is implicitly indicated already on a few places
> > that PCEP peer originating that LSP in PCEP (e.g. PCE for PCE-
> > Initiated) is assigning it, but we can add statemen to specify it
> > explicitly as well.
> >
>
> [Med] Looks good to me. Thanks.
>
> > ## Section 4.1
> >
> > (1)
> >
> > CURRENT:
> > * Extended Association ID TLV: Mandatory TLV of the ASSOCIATION
> > object.
> >
> > As that TLV is optional in rfc8697, I think the wording should be
> > clear this is for SR policy context.
> >
> > <S> Ack.
>
> [Med] Thanks.
>
> >
> > (2)
> >
> > CURRENT: "Any others MUST be ignored"
> >
> > Should we log this as well?
> >
> > <S> I would say that behavior should be consistent with existing
> > behavior for ignored (including unrecongnized) TLVs by PCEP speaker
> >
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c13ac10a8de4bee4f
> 3408dd6c5ed93c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387858768
> 24403463%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s
> data=UcLxiHjKzS6rmhvPDN1xkwXUtq3YsXzLMlKTYRTkgL0%3D&reserved=0
> > atracker.ietf.org%2Fdoc%2Fhtml%2Frfc5440%23section-
> >
> 7.1&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C63ab4ffdc36c4e73a8
> >
> 6408dd6b9dddc2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387850481
> >
> 74772355%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM
> >
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s
> > data=1ctJEweHOsq%2B4TxQGVuOV35obzRzsCXDGtLLUvMWbU0%3D&reserved=0).
> Is
> > there any reason define different behavior for this specific case or
> > re-state existing behavior from RFC5440?
>
> [Med] I think that since 5440, we accumulated a lot of extensions.
> Providing means to help with troubleshooting and assist network
> observability are becoming key.
>
> <S2> I agree with that part, but I'm not sure if it really makes sense
> to specify individually for various error conditions, which can happen
> that error should be logged. Especially since this specific one does
> not seem to sever enough when compared with regular error conditions
> resulting in PCErr (which may not be logged at all).
>
> I can imagine some other future PCEP extension may need to introduce
> another instance of same TLV - with current behavior, such extension
> can be done in backward compatible way without having to introduce new
> set of capabilities, but if we will start enforcing logging
> error/warning messages, then older implementations may be spammed with
> those even in valid cases. If we think that original behavior
> described in RFC5440 is not good enough, then I would prefer to
> improve it generically with separate draft (which can change behavior
> for existing documents in consistent way) rather than trying to "fix"
> it in each draft separately, possibly introducing inconsistencies in
> handling of such behaviors.
[Med] This is fair. Let's consider this one closed.
>
> >
> > ## Section 4.2.1
> >
> > (1) Should we remind that padding is not included in the Length
> field?
> >
> > CURRENT:
> > The TLV MUST be zero-padded so
> > that the TLV is 4-octet aligned.
> >
> > <S> Ack, I'll mention it explicitly.
>
> [Med] Thanks.
>
> >
> > (2) "a string of printable ASCII characters": We may cite STD80
> here.
> >
> > <S> At least RFC9256 is already referring to [RFC0020] as reference
> > for ASCII characters:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%
> 2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c13ac10a8de4bee4f3
> 408dd6c5ed93c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63878587682
> 4416958%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd
> ata=KRLhcSZTpvYCVSFP%2BIrEAUUaRpKKDWFv9tOjLHQCp7Y%3D&reserved=0.
> > rfc-editor.org%2Frfc%2Frfc9256.html%23name-identification-of-an-sr-
> >
> pol&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C63ab4ffdc36c4e73a8
> >
> 6408dd6b9dddc2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387850481
> >
> 74780985%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM
> >
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s
> > data=55dVXxbqajuLMtVcTJl2BmHFBBCdn8Tbev6mlzZlC7g%3D&reserved=0
> > And we are already specifying that definition for the name is in
> that
> > RFC, but we can add it explicitly again.
>
> [Med] Thanks.
>
> >
> > ## Section 5
> >
> > A more explicit title would be helpful.
> >
> > BTW, the flow of the document would be better if we first introduce
> > the capabilities/session establishment and then dive into SRPA
> > signaling.
> >
> > <S> It is combination of various extensions, which are applicable to
> > SR policy, so maybe something like "SR Policy Signaling Extensions",
> > but I'll think about alternative names.
>
> [Med] I'm sure you are will be inspired :-)
>
> >
> > ## Section 5.1
> >
> > (1) Shouldn't the following be conditioned by the activation to use
> > the feature?
> >
> > CURRENT:
> > Implementations that support SR Policy MUST
> > include SRPOLICY-CAPABILITY TLV in the OPEN object.
> >
> > <S> Ack.
>
> [Med] Thanks.
>
> >
> > (2) I guess that we should log the error as well. Please update.
> >
> > CURRENT:
> > If a PCEP speaker receives SRPA but the SRPOLICY-CAPABILITY TLV
> is
> > not exchanged, then the PCEP speaker MUST send a PCErr message
> with
> > Error- Type = 10 ("Reception of an invalid object") and Error-
> Value
> > =
> > TBD ("Missing SRPOLICY-CAPABILITY TLV") and MUST then close the
> > PCEP
> > session.
> >
> > Also, consider updating similar constructs in the spec.
> >
> > <S> PCEP implementation should already log error events as specified
> > in:
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> %2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c13ac10a8de4bee4f
> 3408dd6c5ed93c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387858768
> 24425023%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s
> data=gJAtPuXyUIbJrd2ObAgVBUZTACCENoci7C4a5jI10Nk%3D&reserved=0
> > tracker.ietf.org%2Fdoc%2Fhtml%2Frfc5440%23section-
> >
> 8.4&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C63ab4ffdc36c4e73a8
> >
> 6408dd6b9dddc2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387850481
> >
> 74789382%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM
> >
> DAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&s
> > data=XH4k%2BxOWBXzyTr58hPlrw2zPG745TFqrvPzsTO4AHfc%3D&reserved=0
> > Is there any reason to explicitly repeat it for this specific error?
>
> [Med] We simply need to point to those. You may consider adding:
>
> NEW:
> Section 8.4 of [RFC5440] describes generic considerations to verify
> PCEP operations. Such considerations are not repeated here.
>
> <S2> Thanks, I can add something generic like that.
[Med] Thanks.
>
> >
> > (3) Figure 6: Any reason non contiguous bits were used for these
> > flags?
> >
> > <S> Backward compatibility with existing implementations as S flag
> > (which was originally used for Specified-BSID-only) was removed in
> > late phase of the draft.
>
> [Med] Thanks for the context. BTW, please add in Section 5.1 a
> description of the "Flags" field right after Length and then list the
> assigned bits. Also, indicate that future flags are assigned per the
> procedure in Section 6.7.
>
> <S2> Thanks. I'll add it.
[Med] ACK.
>
> >
> > (4) The use of "PCEP speaker" is confusing in some part of the text.
> > Please make it clear whether this is about receiving or sending.
> >
> > <S> Sure, I'll try to update it.
>
> [Med] Thanks.
>
> >
> > ## Section 5.3
> >
> > CURRENT:
> > Note that Explicit
> > Null is currently only defined for SR MPLS and not for SRv6.
> >
> > Does it make sense for SRv6 at the first place?
> >
> > Anyway, I would align the description with draft-ietf-idr-segment-
> > routing-te-policy.
> >
> > <S> I don't see any explicit statement in draft-ietf-idr-segment-
> > routing-te-policy indicating what implementation should do if it is
> > received for SRv6 policy.
>
> [Med] Sorry, I meant draft-ietf-idr-sr-policy-safi
>
>
> Isn't it actually better to specify what
> > MUST be done instead just assuming that nobody will do it? I'll
> check
> > whether we can align some parts of the description at least.
>
> [Med] Thanks.
>
> >
> > ## Section 5.4
> >
> > CURRENT:
> > Oper: encodes the current state of the LSP, i.e., whether it is
> > actively dropping traffic right now.
> >
> > A better description is needed to reflect the use of the oper
> status.
> > You may consider deleting text till "i.e.,".
>
> [Med] Please fix this one.
>
> >
> > ## Section 6.1
> >
> > The registry url should be provided instead of RFC8697.
> >
> > <S> Ack, I'll add it.
> [Med] Thanks.
>
> >
> > ## Section 6.5
> >
> > Given that draft-ietf-idr-bgp-ls-sr-policy is in the RFC editor
> queue,
> > may be it is time to delete this request.
> >
> > <S> Already deleted in version 23.
>
> [Med] ACK
>
> >
> > ## Section 9.6
> >
> > First, thanks to you and the PCE WG to always supply a manageability
> > section.
> > That's helpful.
> >
> > There are bunch of extensions that are defined out there for SR
> policy
> > purposes (BGP, for example). Should we consider including
> > considerations about co-existence and interactions between those?
> >
> > It is tempting to have a mapping between the various SR policy
> objects
> > to make sure that feature parity (or no) is supported. I'm not
> asking
> > to make any change to cover this mapping, but I would be happy If
> you
> > consider so.
> >
> > <S> I personally consider this to be out of scope of this draft and
> > I'm thinking if such mapping will be done in any specific document,
> > whether it is not better to have it in spring WG, so it can map
> > interactions between extensions which are not even available in
> PCEP.
>
> [Med] This is fair. This is exactly what I'm not asking for any change
> here, but hope that someone will be INSPIRED to help the community
> having that view ;-)
>
> >
> > ## References
> >
> > I don't think that I-D.ietf-idr-sr-policy-safi is normative. Please
> > consider moving the entry to be listed as Informative given that the
> > only citation is:
> >
> > The values of this field are
> > specified in IANA registry "SR Policy ENLP Values" under "Segment
> > Routing" registry group, which was introduced in Section 6.10 of
> > [I-D.ietf-idr-sr-policy-safi].
> >
> > You may replace delete "which was introduced in Section 6.10 of
> > [I-D.ietf-idr-sr-policy-safi]." and replace it with a pointer to
> >
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww%
> 2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9c13ac10a8de4bee4f3
> 408dd6c5ed93c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63878587682
> 4432820%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd
> ata=MpAmHSImhc2z1F%2ButZ4rx3A0IH%2FQS3uiqZOzxPNyZfY%3D&reserved=0.
> > iana.org%2Fassignments%2Fsegment-routing%2Fsegment-
> routing.xhtml%23sr-
> > policy-enlp-
> >
> values&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C63ab4ffdc36c4e7
> >
> 3a86408dd6b9dddc2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6387850
> >
> 48174797860%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj
> >
> AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7
> >
> C&sdata=LWudcX%2F%2FcSPJCqBNm%2FGq9dQGTBqH3gpjpq1AgaXVw6g%3D&reserved=
> > 0.
> >
> > <S> Ack, I'll update it.
>
> [Med] Thanks
>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
