[Pce] Re: WG Adoption of draft-xpbs-pce-topology-filter-05

["Samuel Sidor (ssidor)" <[e-mail]>]

Hi Quan,

Thanks a lot for your responses and for handling those comments.

Please find <S2> inline.

Regards,
Samuel

From: [e-mail] <[e-mail]>
Date: Monday, 27 April 2026 at 10:47
To: Samuel Sidor (ssidor) <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Pce] Re: WG Adoption of draft-xpbs-pce-topology-filter-05



Hi Samuel,


Many thanks for your detailed review and comments! That will help a lot for this document.


Please see inline with Quan->. Thanks!


1. The draft does not define a capability advertisement mechanism to indicate which topology filters a PCC or PCE supports. This may be even more important in the future if additional TLVs/sub-TLVs will be introduced and implementations may not support the complete set. The statement in Section 6 - "A PCEP implementation MAY allow the capability of supporting the PCEP extensions introduced in this document" - is difficult to read. Does it refer to a configuration knob to enable/disable support, or is it intended to say something else?

Quan->Thanks for your remind. I agree that a T flag in topology-filter-capability TLV in OPEN object will be better for PCE/PCC to advertise the topology filter capability. And "A PCEP implementation MAY allow the capability of supporting the PCEP extensions introduced in this document" will be clarified to "A PCE or PCC implementation MAY allow the topology filter capability advertisement supporting the PCEP extensions introduced in this document." That will be revised in next version. Thanks!

<S2> By T-flag, do you mean jus single capability for all filters introduced in this document or something more granular?

 2. The draft references RFC 8231 (Stateful) but only defines behavior for stateless PCReq/PCRep messages. I don’t see anything described for stateful messages (PCRpt, PCUpd per RFC 8231) or PCE-initiated LSPs (PCInitiate per RFC 8281). Consider intended behavior for those.

Quan->Thanks for your suggestion. The proceduces of stateful messages will be added in section 3.2 like "In stateful mode, a PCE may carry an TOPOLOGY-FILTER object as part of  PCInitiate, PCUpd messages, then it MUST also include this object in PCRpt message.  If a PCE receives an TOPOLOGY-FILTER object  in PCRpt, then it MUST include the object in  PCUpd message in case of an unsuccessful path computation based on rules described in Section 7.11 of [RFC5440]."

<S2> That text is not ideal. “then it MUST also include this object in PCRpt message” -> “then PCC MUST …"?


Even if I sonsider simple case with PCC initiated policy delegated to PCE:

  *   PCC delegated policy to PCE using PCRpt with TOPOLOGY-FILTER

  *   PCE MUST reflect object only if path-computation failed (so it is valid to omit it in case of success)

  *   PCC MUST reflect what PCE sent -> TOPOLOGY-FILTER will be reported only if path-computation failed

May be better to split it and specify what PCC/PCE MUST do for PCE-initiated and PCC initiated policies.

Also 7.11 of RFC5440 is talking about LSPA object:

https://datatracker.ietf.org/doc/html/rfc5440#section-7.11

Is that correct reference? If yes, maybe at least modify that statement to indicate that same rules as for LSPA object are supposed to be applied.

3. Please clarify whether multiple TOPOLOGY-FILTER objects may be included in a single message, and if so, what the is expected result (e.g., AND, OR).

Quan->Thanks for your suggestion.  The TOPOLOGY-FILTER object must be presented once and other TOPOLOGY-FILTER objects MUST be ignored if multiple TOPOLOGY-FILTER objects appreared.


4. Section 3.1.1 explicitly states that each TLV type may only appear once and that all present TLVs are applied. Does same apply in Sections 3.1.2, 3.1.3,… or it is not allowed to include multiple instances for those. Please clarify.

Quan->Thanks for your suggestion.  It also applies with other sections. Will add the clarification.


5. Section 3.2 states the PCE MUST consider the TOPOLOGY-FILTER object. RFC 5440 defines the P flag in the PCEP object header: when P=0, a PCEP speaker is allowed to ignore the object. Please clarify the interaction.

Quan->This document proposed the TOPOLOGY-FILTER object in section 3.1 is optional and conforms the P flag in RFC5440. The procedures will be revised to "SHOULD" like "A PCC MAY insert a TOPOLOGY-FILTER object in PCReq message to   indicate the specific topology that SHOULD be considered by the PCE   during path computation."

<S2> It may be better to keep original statement, but explicitly specify that PCE MAY ignore the object in case of P=0. Otherwise PCE would be allowed to ignore even in case of P=1, which is probably not intended.

6. A motivation/use case section describing specific scenarios where each filter type is applicable would help to understand how such filter was intended to be used.

Quan->Section 2 specified the background for topology filter and each filter type is aglined with the topology filter as defined in draft-ietf-teas-yang-topology-filter.

<S2> draft-ietf-teas-yang-topology-filter is also not saying much about motivation. Also one part is to specify filter in Yang model and other part is whether it make sense to support such filters in path-computation, so at least some short section may be useful.

7. Please clarify whether this extension is applicable to specific LSP setup types only (e.g., RSVP-TE, SR-TE, SRv6) or is intended to be setup-type agnostic.

Quan->Thanks, it is intended to be setup-type agnostic and will clarify it in the newly added OPEN object extension.


8. Section 3.1.1.3 (Algorithm ID TLV): The draft states the Algorithm ID TLV provides "Flex-algo plane information" but does not define what is considered. Specifically, does the PCE filter based on: (a) Flex-algo participation only, (b) participation plus constraints from FAD, or (c) anything else (e.g. per-link Flex-algo ASLA link attributes)?

Quan->From my view, the Algorithm ID is a filter constraint for IGP domain iderntifier and it will based on the Flex-algo participation only.

<S2> Makes sense to me, but better to clarify that in the draft as well. Also specify whether it is still valid to do path-computation for different algorithms (using SR-Algorithm TLV) - I assume that topology filter is independent from SID-algo constraint, but it may be better to be clear.


9,The sub-TLVs (Figures 8, 9, 10) use a non-standard encoding with 1-byte Type + 1-byte Length. RFC 5440 Section 7.1 defines the standard PCEP TLV format as 2-byte Type + 2-byte Length. Is there any specific reason for using different format?

Quan->Thanks for your remind. Will revise to 2-byte Type + 2-byte Length.

10. The IANA Considerations section does not identify the specific IANA registries from which TBD1/TBD2 (Object-Class and Object-Type) and TBD3–TBD11 should be allocated, and does not specify the allocation policy. See RFC 8231 Section 8.3 for an example of the expected format.

Quan->Many thanks! Will revise it in next version.


11. The Filtering Rules TLV (Section 3.1.4) replicates Exclude-any, Include-any, and Include-all fields that already exist in the LSPA object (RFC 5440 Section 7.11). Why it is not sufficient to include LSPA object on top of TOPOLOGY-FILTER (with other filters)? It seems that both are doing same thing, so duplication is not really needed (otherwise we can replicate all constraints into this object, e.g. SRLG).

Quan->This document applies the topology filter construct as defined in draft-ietf-teas-yang-topology-filter. The IGP domain identifier and TE topology identifier belongs to topology reference container and they do not need  Exclude-any, Include-any, and Include-all fields. And the sub-TLVs in Filtering Rules TLV need the  Exclude-any, Include-any, and Include-all procedures.

<S2> I’m not sure if I understand this part. So are you saying that “Exclude-any, Include-any, and Include-all” is not defining bitfield for affinity, but it is an operation for subTLV, so it can be used for “Source Protocol” as well? Can you please provide example of how such filter would be encoded? (since for example Include-all filter is 32b value, but those subTLVs have more complicated values)

12. Section 3.1.4.1 (Link ID sub-TLV): Please describe the intended use case. The Link-ID from RFC 5307 / RFC 3630 is a locally scoped 32-bit identifier - it requires a Router ID to be uniquely resolvable in a topology, but that is not included in the sub-TLV. Unnumbered link constraints are already handled by the Unnumbered Interface ID subobject for ERO/XRO/IRO, those are correctly encoding the {Router ID, Interface ID} pair. At least my understanding was that TOPOLOGY-FILTER is trying to limit the scope for path-computation, so PCE can prune the topology before actual path-computation is done, but this specific “filter” sounds like regular constraint.

Quan->I agree with you. I also think about it and it would be better to remove the link ID sub-TLV and just use the Admin Group sub-TLV to indicate the link-affinity. Will revise it in next version.


13. Section 3.1.4.2 (Admin Group sub-TLV): RFC 7308 requires the EAG value to be a multiple of 4 octets - consider mentioning in the draft that length of payload must be aligned to 4. The 1-byte Length field limits the sub-TLV payload to 255 bytes. OSPF TE sub-TLVs use a 2-byte length field, so topology information from OSPF may carry bigger EAG values that cannot be fit into this TLV.

Quan->Thanks for your remind, will revise it to align with RFC7308.

<S2> Please make sure that 4 octet alignment will be also specified.

14. Section 3.2 states that the TOPOLOGY-FILTER object is included in a PCRep with NO-PATH "to indicate the set of topology constraints that could not be satisfied.” Can you specify how the PCE determines this. E.g. I will use filter with domain ID, so I will restrict path-computation to single domain. How PCE would know that it would succeed if that filter were not specified?

Quan->Multiple TLVs will be presented in TOPOLOGY-FILTER object and if one of them can be not satisfied, the path can not be computed. If the domain ID is carried as a topology filter and the path computation will be within this domain. If the PCE can not find the domain, then it will be not satisfied. If the filtering rules are not carried, the PCE will just compute the path within the scope of  this domain ID.

<S2> So domain ID filter will be considered as not satisfied only if such domain does not exist at all? So if I will have topology with domain 1, where valid path exist to LSP destination and domain 2, where valid path does not exist and filter is set to domain 2, then domain filter is not considered as not satisfied filter? If that is the case, please specify that in the draft clearly.

Hope the reply will help with your suggestions and comments and they will be revised in next version. Thanks!


Best Regards,

Quan



Original
From: SamuelSidor(ssidor) <[e-mail]>
To: 熊泉00091065;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2026年04月24日 19:38
Subject: Re: [Pce] Re: WG Adoption of draft-xpbs-pce-topology-filter-05
Hi Quan,

A few comments from my side:


  1.
The draft does not define a capability advertisement mechanism to indicate which topology filters a PCC or PCE supports. This may be even more important in the future if additional TLVs/sub-TLVs will be introduced and implementations may not support the complete set. The statement in Section 6 - "A PCEP implementation MAY allow the capability of supporting the PCEP extensions introduced in this document" - is difficult to read. Does it refer to a configuration knob to enable/disable support, or is it intended to say something else?
  2.
The draft references RFC 8231 (Stateful) but only defines behavior for stateless PCReq/PCRep messages. I don’t see anything described for stateful messages (PCRpt, PCUpd per RFC 8231) or PCE-initiated LSPs (PCInitiate per RFC 8281). Consider intended behavior for those.
  3.
Please clarify whether multiple TOPOLOGY-FILTER objects may be included in a single message, and if so, what the is expected result (e.g., AND, OR).
  4.
Section 3.1.1 explicitly states that each TLV type may only appear once and that all present TLVs are applied. Does same apply in Sections 3.1.2, 3.1.3,… or it is not allowed to include multiple instances for those. Please clarify.
  5.
Section 3.2 states the PCE MUST consider the TOPOLOGY-FILTER object. RFC 5440 defines the P flag in the PCEP object header: when P=0, a PCEP speaker is allowed to ignore the object. Please clarify the interaction.
  6.
A motivation/use case section describing specific scenarios where each filter type is applicable would help to understand how such filter was intended to be used.
  7.
Please clarify whether this extension is applicable to specific LSP setup types only (e.g., RSVP-TE, SR-TE, SRv6) or is intended to be setup-type agnostic.
  8.
Section 3.1.1.3 (Algorithm ID TLV): The draft states the Algorithm ID TLV provides "Flex-algo plane information" but does not define what is considered. Specifically, does the PCE filter based on: (a) Flex-algo participation only, (b) participation plus constraints from FAD, or (c) anything else (e.g. per-link Flex-algo ASLA link attributes)?
  9.
The sub-TLVs (Figures 8, 9, 10) use a non-standard encoding with 1-byte Type + 1-byte Length. RFC 5440 Section 7.1 defines the standard PCEP TLV format as 2-byte Type + 2-byte Length. Is there any specific reason for using different format?
  10.
The IANA Considerations section does not identify the specific IANA registries from which TBD1/TBD2 (Object-Class and Object-Type) and TBD3–TBD11 should be allocated, and does not specify the allocation policy. See RFC 8231 Section 8.3 for an example of the expected format.
  11.
The Filtering Rules TLV (Section 3.1.4) replicates Exclude-any, Include-any, and Include-all fields that already exist in the LSPA object (RFC 5440 Section 7.11). Why it is not sufficient to include LSPA object on top of TOPOLOGY-FILTER (with other filters)? It seems that both are doing same thing, so duplication is not really needed (otherwise we can replicate all constraints into this object, e.g. SRLG).
  12.
Section 3.1.4.1 (Link ID sub-TLV): Please describe the intended use case. The Link-ID from RFC 5307 / RFC 3630 is a locally scoped 32-bit identifier - it requires a Router ID to be uniquely resolvable in a topology, but that is not included in the sub-TLV. Unnumbered link constraints are already handled by the Unnumbered Interface ID subobject for ERO/XRO/IRO, those are correctly encoding the {Router ID, Interface ID} pair. At least my understanding was that TOPOLOGY-FILTER is trying to limit the scope for path-computation, so PCE can prune the topology before actual path-computation is done, but this specific “filter” sounds like regular constraint.
  13.
Section 3.1.4.2 (Admin Group sub-TLV): RFC 7308 requires the EAG value to be a multiple of 4 octets - consider mentioning in the draft that length of payload must be aligned to 4. The 1-byte Length field limits the sub-TLV payload to 255 bytes. OSPF TE sub-TLVs use a 2-byte length field, so topology information from OSPF may carry bigger EAG values that cannot be fit into this TLV.
  14.
Section 3.2 states that the TOPOLOGY-FILTER object is included in a PCRep with NO-PATH "to indicate the set of topology constraints that could not be satisfied.” Can you specify how the PCE determines this. E.g. I will use filter with domain ID, so I will restrict path-computation to single domain. How PCE would know that it would succeed if that filter were not specified?

Thanks,
Samuel

From: [e-mail] <[e-mail]>
Date: Tuesday, 21 April 2026 at 10:43
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [Pce] Re: WG Adoption of draft-xpbs-pce-topology-filter-05



Dear All,


Many thanks for your support and suggestions during the call from Adrian, Aijun, Li Zhang, Ran Chen, Zhengxin, and Junfeng!


The authors submitted a new version with the following updates:

https://datatracker.ietf.org/doc/draft-xpbs-pce-topology-filter/06/


1, RFC7752 has been replaced to RFC9552 and modify some descriptions.

2, Requirements Language section has been updated to refer to the reference RFC8174

3, RFC9543 and draft-ietf-teas-ns-ip-mpls have been added to the reference for "NRP" and "NRP-ID".

4,Modify the description of the abstract.

5,NRP TLV has been mentioned and refered to draft-ietf-pce-pcep-nrp.

6, Add the section of operational considerations.

7,Add clarification in introduction covering the RFC8776.

8, Add clarification to "include-any”, “include-all”, and “exclude” fields and the format ia aligned with the RFC5440 and RFC3209.

9, Add operation clarfication for the TOPOLOGY-FILTER object  carried  within a PCReq message and PCRep message.

10, The informative and normative references have been provided.


Hope the new version could help to address your concerns! Thanks!


Best Regards,

Quan

From: DhruvDhody <[e-mail]>
To: [e-mail] <[e-mail]>;
Cc: pce-chairs <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2026年04月10日 19:52
Subject: WG Adoption of draft-xpbs-pce-topology-filter-05
Hi WG,

This email begins the WG adoption poll for draft-xpbs-pce-topology-filter-05

https://datatracker.ietf.org/doc/draft-xpbs-pce-topology-filter/

Should this draft be adopted by the PCE WG? Please state your reasons: Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list.

Please respond by Monday 27th Apr 2026.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien