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

[[e-mail]]

Hi Samuel,

Thanks for your response!

Yes, some update will be in next version.

Clarification will be added for whether both - include-all and include-any after the discussion with co-authors.

 IANA section TBD8 for filtering rules will be removed (the TLV has been removed , thanks for pointing it).

For the unsuccessful case, I agree with you. I think there will be two cases. First is that the PCE can not find the corresponding filter and can not constract the topology, for example, it can not find the Domain ID with ID=2. In this case, the PCE may send back the PCErr with "PCE can not find the domain". Second is that PCE can construct the topology successfully but path computation failed. The PCRep message may contain a NO-PATH object, and the TOPOLOGY-FILTER object  is used to carry all the set of topology filter constriants.


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年05月11日 20:09
Subject: Re: [Pce] Re: WG Adoption of draft-xpbs-pce-topology-filter-05

Hi Quan,
 
Thanks for submitting it. It looks better, but there is still a lot of work remaining (which can be handled in future versions).
 
E.g. more work will be needed in section 3.1.3.2 (resolution for whether both - include-all and include-any really makes sense - most likely not), IANA section (e.g. TBD8 assigned to 2 different TLVs, inconsistent format for defining new registry values (compare section 5.1 vs 5.2), …
 
Also don’t forget to explain when this statement is really applicable:
 
The TOPOLOGY-FILTER object can be carried within a PCRep message in case of unsuccessful path computation. In this unsuccessful case, the PCRep message also contains a NO-PATH object, and the TOPOLOGY-FILTER object is used to indicate the set of topology filter constriants that could not be satisfied
 
How PCE is supposed to figure out which filter is causing that path-computation to fail as discussed in the mail thread (most likely PCE will not know whether path-computation failed, because of filter, some other constraint or anything else - it just won’t be able to find the path).
 
Regards,
Samuel
 
From: [e-mail] <[e-mail]> 
Date: Thursday, 7 May 2026 at 10:23
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,
 
I have submitted a version-01 and hope that can help with all your comments.. Thanks!
 
A new version of Internet-Draft draft-ietf-pce-topology-filter-01.txt has been
successfully submitted by Quan Xiong and posted to the
IETF repository.
 
Name:     draft-ietf-pce-topology-filter
Revision: 01
Title:    Path Computation Element Communication Protocol (PCEP) Extensions for Topology Filter
Date:     2026-05-07
Group:    pce
Pages:    23
URL:      https://www.ietf.org/archive/id/draft-ietf-pce-topology-filter-01..txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-pce-topology-filter/
HTML:     https://www.ietf.org/archive/id/draft-ietf-pce-topology-filter-01..html
HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-topology-filter
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-topology-filter-01
 
Abstract:
 
   A topology filter is a data construct that is used to filter network
   topologies.  The Path Computation Element (PCE) MUST take into
   account the topology related constraints during the path computation.
   This document proposes a set of extensions for Path Computation
   Element Communication Protocol (PCEP) to support the topology filter.
 
 
Best Regards,
Quan
 
 
 
 
Original
From: SamuelSidor(ssidor) <[e-mail]> 
To: 熊泉00091065;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <draft-xpbs-pce-topology-filter@ietf..org>;[e-mail] <[e-mail]>;
Date: 2026年05月06日 17:29
Subject: Re: [Pce] Re: WG Adoption of draft-xpbs-pce-topology-filter-05
Thanks a lot for response and for handling my comments, Quan.
 
I’ll check version 01 when it will be submitted.
 
Regards,
Samuel
 
From: [e-mail] <[e-mail]> 
Date: Wednesday, 6 May 2026 at 10:14
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,
 
Thanks! Sorry for the delay due to the holiday!
 
Please see inline with Q4->. And all of your comments will reflect in WG version -01. Thanks!
 
Best Regards,
Quan
 
 
 
From: SamuelSidor(ssidor) <[e-mail]> 
To: 熊泉00091065;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <draft-xpbs-pce-topology-filter@ietf..org>;[e-mail] <[e-mail]>;
Date: 2026年04月30日 20:04
Subject: Re: [Pce] Re: WG Adoption of draft-xpbs-pce-topology-filter-05
Thanks Quan,
 
I think that last one open is:
 
 
Q3->From the  [draft-ietf-teas-yang-topology-filter], the 'include-any', 'include-all' and 'exclude' containers carry the  info-source list as following   shown.
 
+--rw info-source* [source-id instance-id division-id]
 
+--rw source-id      tet:te-info-source
 
 +--rw instance-id    uint32
 
+--rw division-id    uint32
 
So I will define a sub-TLV to contain Protocol-ID, Instance-ID and domain-ID and Include-Any/Include-All/Exclude Information Source TLV will carry a   list of the sub-TLVs. What is your suggestion for this format? Thanks!
 
 
<S4> In yang model, 3 different fields are mentioned (source-id instance-id division-id), but  your original Source Protocol sub-TLV contains protocol-ID (is  this different representation of source-ID?) and instance-ID. Is there any reason for that discrepancy?
 
 
Also do you want to support partial match - e.g. what if only instance-ID is specified in the TLV - should that match even if other fields (e.g. division-ID/protocol-ID/…  are  not matching)?
 
 
If you just want to support exact match, then this should work (potentially update fields in Info-Source based on what you really want to include  - whether you want to match Yang model or just use your original  fields:
 
 
Exclude-Any Information Source TLV:
 
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Type=TBDx             |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//          List of Info-Source sub-TLVs (see below)           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Q4->Yes, what I mean is exactly the same with this TLV.
 
Info-Source sub-TLV:
 
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Type=TBDy             |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol-ID  |                  Reserved                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Instance-ID                          |
|                           (64 bits)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
If you want to support partial match, then you may need to support something like this (again - depends on fields, which you want to include - added Division-ID for illustration as well):
 
0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Type=TBDy             |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol-ID  |    Flags    |I|D|        Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Instance-ID (64 bits, present if I=1)          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Division-ID (32 bits, present if D=1)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
Where I=1 means Instance-ID field is present, D=1 means Division-ID field is present and Protocol-ID is mandatory (you can still select different fields)
 
Q4-> Yes, I mean to define a sub-TLV to carry the Protocol-ID, Instance- ID and Domain-ID (which is Division-ID in the scope of PCEP). And thanks for the suggestion of the I and D flag. That is good point.
 
Also for having include-all/include-any/exclude-any - for info-source I still don’t big added value in supporting both - what is practical difference between include-all/include-any - does include-all mean that you want to include only nodes/links which belongs   to multiple instances in the same time?
 
Q4->This format is to align with the [draft-ietf-teas-yang-topology-filter] and the 'include-any', 'include-all' and 'exclude' containers  all carry the  info-source list. I will talk to the co-authors who are also the authors of [draft-ietf-teas-yang-topology-filter]. Thanks for your concerns.
 
One last thing - in draft-ietf-teas-yang-topology-filter instance-ID is defined as uint32, but you are pointing to RFC9552, which is using 64b value. Are both referring to same field (I don’t see Yang model  referring that RFC) -  if yes, it potentially makes sense to reach to authors of draft-ietf-teas-yang-topology-filter to fix that.
 
Q4-> Thanks! In my view,  the instance-ID is 64bits during PCE computation using the information from BGP-LS RFC9552. I am not sure about the yang model from controller view. I will talk to the co-authors to make sure that. Thanks!
 
Regards,
Samuel
 
From: [e-mail] <[e-mail]> 
Date: Thursday, 30 April 2026 at 11:26
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,
 
 
Thanks again for your detailed responses!
 
 
Please see inline with Q3->. Thanks!
 
 
Regards,
 
Quan
 
 
From: SamuelSidor(ssidor) <[e-mail]> 
To: 熊泉00091065;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <draft-xpbs-pce-topology-filter@ietf..org>;[e-mail] <[e-mail]>;
Date: 2026年04月29日 18:18
Subject: Re: [Pce] Re: WG Adoption of draft-xpbs-pce-topology-filter-05
Hi Quan,
 
Thanks for your responses.
 
Please see inline <S3>.
 
Regards,
Samuel
 
From: [e-mail] <[e-mail]> 
Date: Wednesday, 29 April 2026 at 11:31
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,
 
 
Thanks for your further suggestions!
 
 
Please see inline with Q2->. 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?
 
Q2->Yes, an optional TLV called TOPOLOGY-FILTER-CAPABILITY TLV and with T flag to indicate all filters as a whole  topology filter capability. What is your suggestion? Do you suggest more flags for each filter? Some of the filters capability have been  defined   in other TLV.
 
<S3> I was thinking about more granular flags (e.g. one per TLV in TOPOLOGY-FILTER-CAPABILITY TLV) as not all vendors have to implement all filters from the beginning and even   from long-term. E.g. I personally consider extended admin group as useful (gap in existing PCEP constraints), but filtering using TE Topology Identifier as not that useful (but that is my point of view). If some vendor would implement support for some TLVs,   then it may be difficult to figure out from PCC/PCE POV which of them other peer can support - at least some PCError may need to be defined in the draft to reject those or specify if some existing one should be used (note in PCEP by default unrecognized TLVs   are silently ignored, which may be dangerous in this case since PCE would compute path without considering all filters specified).
 
Q3->Yes, I agree that maybe some part of filters are implemented. The filters constraints are optional and can be used seperately except that the Protocol ID TLV is mandatory. It may be better to define seperate flags for these newly defined capabilities and add PCError when Protocol ID TLV is absent with other TLVs presenting as IGP domain identifiers.
 
 
 
 
 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.
 
Q2-> Thanks for your remind! I understand what your mean and the procedures are revised as following shown.
 
"The TOPOLOGY-FILTER object can be carried within a PCReq message,
 
or a PCRep message in case of unsuccessful path computation. In this
 
unsuccessful case, the PCRep message also contains a NO-PATH object,
 
and the TOPOLOGY-FILTER object is used to indicate the set of topology
 
filter constriants that could not be satisfied.
 
In stateful mode, a PCE may carry an TOPOLOGY-FILTER object as part of
 
PCInitiate, then the PCC MUST also include this object in PCRpt message.
 
If a PCE receives an TOPOLOGY-FILTER object in PCRpt, then
 
it MUST include this object in PCUpd message.”
 
<S3> For stateful, consider something like this maybe:
 
"In stateful mode, the following procedures apply:
 
For PCC-initiated LSPs: A PCC MAY include a TOPOLOGY-FILTER object in a PCRpt message when delegating an LSP to the PCE, to indicate the topology constraints that MUST be applied during path computation. The PCE SHOULD include the TOPOLOGY-FILTER object in   a PCUpd message only when path computation cannot be completed because the referenced topology or domain is not known to the PCE; in that case the PCUpd MUST also include a empty ERO to indicate the failure. If path computation succeeds, the PCE MAY omit  the  TOPOLOGY-FILTER object from PCUpd.
 
For PCE-initiated LSPs: A PCE MAY include a TOPOLOGY-FILTER object in a PCInitiate message. The PCC MUST reflect the TOPOLOGY-FILTER object in the corresponding PCRpt message and in all subsequent PCRpt messages for the same LSP." 
 
Q3->Thanks for the proposed texts and it looks much clear.
 
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)