pce

Summary

The pce working group session covered updates on existing documents, including those in the RFC editor queue, those awaiting AD review, and several nearing Working Group Last Call (WGLC) or requiring further chairs' decisions. Several new or significantly updated drafts were presented, requesting feedback and working group adoption. Key discussions revolved around PCEP extensions for multi-path signaling, support for SR policy candidate paths, path MTU, in-situ OAM (IFIT), and ingress protection. Authors were encouraged to engage the mailing list for significant changes and clarify relationships between overlapping drafts.

Key Discussion Points

Administrative Updates
- Reminders on IPR rules, conduct guidelines, and online meeting etiquette were provided.
- Harry is acting as secretary, using notes.ietf.org / CodeMD for minutes.
- Emphasis on using the mailing list for discussions, polls, and creating new threads.
- Reminder about the wiki for relevant information and the process for early IANA code point allocation.
- The agenda for both PCE sessions was presented without objections.
Document Status Updates
- No new RFCs since the last IETF.
- L2 VPN Flow Spec (RFC editor queue): A blocking part (L2 VPN flow spec) was stripped into a separate ID. Authors asked for quick adoption of the new ID given prior consensus. This question remains open.
- Binding SID: Updated to address AD comments; awaiting AD review.
- Errata (RBNF Ordering): Rejected with reasoning provided on the mailing list. A new ID for this issue is proposed for discussion in the Friday session.
- Early IANA Code Points: Three documents received early allocation; expiry dates noted, requiring extensions if publication is delayed.
- Stateful GMPLS: Authors confirmed it is ready for Working Group Last Call (WGLC).
- Enhanced ERR: Low interest in previous polls. Chairs are considering marking it experimental or "waiting for implementation" in the data tracker, or publishing alongside related work. A decision will be made after IETF 112.
- PCEP YANG: Updated, needs Yang Doctor review and WGLC. Dependencies (i.e., ietf-tls-client, ietf-tls-server, ietf-te-yang) are nearing WGLC, clearing the path.
- Native IP: Feedback is being sought from the IDR WG, with an agenda slot in their upcoming session. Cross-posting for WGLC in both WGs is planned.
- Flex-Grid: No recent changes; authors to confirm readiness.
- SRv6: Stable, nearing WGLC.
- VN Association: Authors confirmed it is ready for WGLC.
- SR Path Segment & SR Bi-directional: Updated with mainly editorial changes to sync with published documents, no open issues, nearing WGLC.
- Local Protection Enforcement: Updated, has IANA allocation, two implementations; authors encouraged to prepare for WGLC.
- PCC SR: Updated to align with RFC 1950.
- Stateful Inter-Domain: No update this time.
- Extended Flags: New version posted, comments from adoption call handled.
- Multipath: Updated, comments from adoption call handled.
- Optional Objects: Updated, comments from adoption call handled.
- Adoption Poll Queue: An ongoing poll for sr-pcep-to-mp-policy. A reshuffling of the adoption queue is planned after IETF 112 based on feedback.
PCEP Extensions for Signaling Multi-Path Information (draft-ietf-pce-pcep-multipath-07)
- Presented by Mike (Cisco). Allows the PCE to return multiple forward and reverse paths for a computation request, independent of the data plane (e.g., SR policy, RSVP-TE). Applicable to stateful and stateless PCEP.
- Introduced an Opposite Direction Path TLV within the Path Attributes Object to specify reverse paths. This relationship is not necessarily mutual.
- Demonstrated with an example of circuit-style SR policies, where each policy head-end needs to know both forward and corresponding reverse paths.
- Discussion with Cheng (Huawei) about the relationship with sr-bi-directional draft. The presenter clarified this draft supports multiple segment lists within a candidate path, complementing the candidate path association in sr-bi-directional.
- Chairs requested authors to discuss significant changes on the mailing list for wider WG feedback and to add text clarifying the relationship/differences with sr-bi-directional.
- Authors noted no current implementation status, requested IANA code points.
- Boris (Huawei) requested implementation status to be added to the next version.
- Rakesh (Cisco) stated sr-bi-directional draft includes text on its relationship with this draft.
- The AD (John) mentioned concerns raised in Spring WG regarding backup segment lists in SR policy architecture.
- Lou (Juniper) suggested an opportunity to merge the multi-path and sr-bi-directional drafts, or at least add text linking them. Authors maintain they address different use cases.
PCEP Extensions to Support Segment Routing Policy Candidate Paths (draft-ietf-pce-sr-policy-candidate-paths-05)
- Presented by Mike (Cisco). Proposes PCEP extensions to support generic tunnel mechanisms from the SR policy architecture draft, applicable to SR-TE, RSVP-TE, and future tunnels.
- Introduced Invalidation TLV to specify actions (redirect to IGP or drop) if a path becomes invalid.
- Proposed a bit in the Path Binding TLV to indicate if a B-SID is mandatory for programming if the PCE is unavailable.
- Suggested making the SR Policy Candidate Path ID TLV optional in PC Initiate messages.
- Reported Cisco and Juniper have production implementations (via vendor TLVs) and successful interop testing.
- Boris (Huawei) requested clarification on PCE Initiate message content and acknowledged the production status.
- Chairs questioned the inclusion of generic mechanisms in an SR-specific document, suggesting authors clarify that while rooted in SR policy, the encodings are generic, or add a paragraph stating their broader applicability.
- Authors requested IANA code points for new TLVs.
Support of Path MTU in PCEP Protocol (draft-ietf-pce-pcep-path-mtu-05)
- Presented by Lou (MTN). Motivates the need for path MTU signaling in SR tunnels to avoid packet drops due to fragmentation.
- Updates addressed terminology clarification, path adjustment for protection (TI-LFA), relationship with maximum SID depth, and multi-path support.
- Requested working group adoption.
PCEP Extensions to Enable In-Situ OAM (IFIT) (draft-ietf-pce-pcep-ifit-03)
- Presented by Giuseppe (Ericsson). Defines PCEP extensions to signal IFIT (In-situ OAM, on-path telemetry, alternate marking) capabilities and attributes.
- Latest changes focused on application in controlled domains for security reasons.
- Defines IFIT Capability TLV (in Open Object, with flags for IOM types and alternate marking) and IFIT Status TLV (in LSPA Object, for configurable features).
- Noted IFIT methods are maturing for SR-MPLS.
- Requested working group adoption. Authors will consider registry for flags.
PCEP for Ingress Protection (draft-ietf-pce-ingress-protection-00)
- Presented by Hwu-mei (Huawei). This is a merged draft providing ingress protection for SR and B-RTE paths, offering a foundation for protecting different path types.
- Updated Ingress Protection Capability Sub-TLV and Ingress Protection Sub-TLV to include path type indicators (SR, B-RTE flags).
- Chairs questioned the necessity of differentiating so much by path type when the PCEP procedures might be generic, suggesting it could be a common generic draft.
- Jeffrey (ZTE) asked if it was discussed in Spring or BIER WGs; it has not yet been, but it was suggested it should be.
- Mike (Cisco) asked for clarification on communication with CE devices (acknowledged by author) and applicable overlay types (e.g., L3VPN).
- Chairs requested authors to address past comments and the generic vs. path-specific differentiation.
- Requested working group adoption.

Decisions and Action Items

Chairs:
- Take action on Working Group Last Call for stateful-gmpls.
- Make a decision on the future of enhanced-err (experimental, waiting for implementation, or co-publication).
- Initiate Yang Doctor review and Working Group Last Call for pcep-yang.
- Discuss working group adoption requests for pcep-path-mtu, pcep-ifit, and pcep-ingress-protection.
- Reshuffle the working group adoption queue after IETF 112 based on feedback.
John (AD): Review comments on the binding-sid document.
Mike (Author, pcep-multipath):
- Engage the mailing list for discussion on recent changes, particularly reverse path signaling.
- Add text to the draft clarifying its relationship with sr-bi-directional.
- Add implementation status to the next version.
Mike (Author, sr-policy-candidate-paths):
- Clarify the generic applicability of mechanisms in the draft (e.g., a paragraph explaining their use beyond SR policy).
- Request IANA code points for the new TLVs.
Giuseppe (Author, pcep-ifit): Consider the suggestion of a registry for flags.
Hwu-mei (Author, pcep-ingress-protection):
- Clarify the generic vs. path-specific differentiation in the document; consider if path type indicators can be removed from Ingress Protection Sub-TLV.
- Discuss the use case in Spring and BIER working groups.
- Elaborate on the need for communication with CE devices in the draft.
- Mention which overlay types (e.g., L3VPN) the solution applies to.
- Address older comments received on the document.
Working Group Participants: Provide feedback on the ongoing sr-pcep-to-mp-policy adoption call and other adoption queue items.

Next Steps

Chairs will follow up on identified WGLC candidates and adoption requests.
Authors will address comments, clarify relationships between drafts, and engage the mailing list for broader feedback.
The working group will continue discussions on the mailing list, particularly concerning the pcep-multipath and pcep-ingress-protection drafts.
Another session is scheduled for Friday to continue with the remaining agenda items.

Session Date/Time: 12 Nov 2021 16:00

pce

Summary

The pce working group session covered several key PCEP extension drafts. A significant discussion revolved around relaxing the strict object ordering requirements in RFC 5440 to improve flexibility and interop. Other presentations included PCEP extensions for topology filtering, support for Virtual Transport Networks (VTN) and its relation to Network Resource Partitions (NRP), updates on PCEP Link-State (LS) capabilities, PCEP extensions for Multicast/BEER, VLAN-based traffic forwarding, and an RSVP Color attribute. Several drafts are seeking working group adoption, and there's a strong emphasis on aligning terminology and architecture with other IETF working groups like TEAS and BEER.

Key Discussion Points

PCEP Object Ordering (Draft: draft-dhody-pce-object-ordering-00)
- Problem: RFC 5440's strict "MUST" requirement for object ordering in PCEP messages has led to errata and interop issues, as new extensions frequently cause conflicts.
- Proposal: Update RFC 5440 to change "MUST" to "SHOULD" for message reception, allowing implementations to be more liberal in accepting out-of-order objects when unambiguous. Sending messages should still respect ordering.
- Compatibility: Acknowledged potential backward compatibility issues with legacy strict implementations, though many existing implementations are already liberal on receive. RFC 5440 currently lacks an error code for out-of-order objects.
- Discussion:
  - Andrew: Raised concerns about negative impact on interop with existing strict implementations.
  - Joe: Questioned the purpose of strict sending if receiving is liberal. The presenter clarified this is a common standard philosophy.
  - Oscar: Suggested a complete revisit of PCEP grammar, whether adopting a fully strict or relaxed approach, as a sudden change could be problematic.
  - Boris: Supported the approach and suggested signaling the relaxing capability via a PCEP capability TLV.
  - Mike: Supported liberal receiving, suggested specifying relative ordering between specific objects rather than a global strict order.
PCEP Extensions for Topology Filter (Draft: draft-cheng-pce-topology-filter-00)
- Purpose: Defines PCEP extensions to support topology filters (as defined in a related YANG draft) during path computation.
- Mechanism: Introduced TLVs within a new Topology object to identify topology references (e.g., IGP domain, instance ID, multi-topology ID, area ID). Proposed extensions for IRO/XRO objects for include/exclude filtering rules.
- Discussion:
  - Joe: Asked for clarification on consistency with other drafts (e.g., slicing/NRP ID, TE Topology) and the operational procedure (controller to device or device to controller).
  - Robin: Questioned the division of work into multiple drafts and the necessity of certain constraints.
  - Chairs: Emphasized the need for alignment with TEAS documents.
PCEP Support for VTN (Virtual Transport Network) (Draft: draft-wang-pce-pcep-vtn-00)
- Purpose: Describes PCEP extensions to carry VTN information for VTN-specific path computation requests, responses, reports, and initiation.
- Mechanism: Defined a VTN_ID_TLV (32-bit global identifier) to be carried in the LSPA object. A PCEP capability bit was introduced for PCC to indicate support for data plane VTN ID encapsulation. Applicable to PCReq, PCRep, PCReport, and PCInitiate messages.
- Discussion:
  - Eric: Raised concerns about potential duplication with the Network Resource Partition (NRP) ID term being discussed in TEAS, and suggested collaboration to avoid standardizing two IDs.
  - Jimmy: Noted an ongoing mailing list discussion about the relationship between enhanced VPN (HSB) and network slicing, suggesting feedback there to clarify scope and potential convergence of terms.
  - Pavan (Co-Chair): Clarified that while the TEAS framework draft uses "Network Resource Partition", there's no formal consensus call on the term, and the editor is leading its definition.
  - Adrian (TEAS Editor): Confirmed no formal consensus on terminology in TEAS framework, and that the framework aims to provide a common base for mapping, rather than forcing document rewrites.
PCEP LS Update (Draft: draft-mishra-pce-pcep-ls-02)
- Purpose: An experimental ID to explore learning network state and topology via PCEP, explicitly stated as not a replacement for existing mechanisms.
- Use Cases: Primarily for PCC-PCECC (device to controller) and HPC (controller-controller) scenarios.
- Mechanism: Reuses existing PCEP sessions, introduces a new PCEP object/message, and reuses existing TLVs. The default mode (R=0) is local-only, but R=1 allows hybrid setups. Aims for single SBI for some PCECC use cases, and faster learning for certain information (e.g., optical extensions).
- Request: Seeking working group adoption as an experimental track.
- Discussion:
  - Chiang: Expressed strong support for adoption, viewing it as essential to complete PCEP capabilities alongside BGP-LS.
  - Robin: Agreed on the application scenario, particularly for simplifying controller/router implementations.
PCEP Extensions for Multicast/BEER (Draft: draft-li-pce-pcep-extension-for-multicast-beer-01)
- Purpose: PCEP extensions for multicast management signaling in SDN scenarios, focusing on BEER (Bit Indexed Explicit Replication).
- Process: Involves ingress source registration, egress receiver join/leave, controller path calculation, and receiver statistics synchronization.
- Updates: Refined objects by moving duplicate fields into TLVs, added a P flag for BEER multicast, allowing objects to be used in both BEER and non-BEER scenarios. Defined several new TLVs for multicast source/group addresses, VPN info, and VR info.
- Discussion:
  - Dhruv (Co-Chair): Noted previous discussion in BEER WG; stressed the need for clear requirements and architectural guidance from the BEER WG. Expressed concern about the document mixing BEER and non-BEER specific content.
  - Tony: Suggested an interim meeting between PCE and BEER WGs to establish clear requirements and align architecture for PCEP-based BEER solutions.
  - George: Agreed the document should focus solely on BEER, as existing RFC 6006 covers non-BEER point-to-multipoint PCEP extensions.
PCEP Extensions for VLAN-based Traffic Forwarding (Draft: draft-qin-pce-pcep-vlan-based-traffic-forwarding-01)
- Purpose: Defines PCEP extensions for VLAN-based traffic forwarding in native IP networks, building on RFC 9050 (NPR label switch paths).
- Mechanism: PCE calculates explicit SR routes, sending information to PCCs. PCCs then form VLAN forwarding tables (ingress forms a VLAN forwarding table, transit/egress form VLAN crossing tables). Packets are labeled with VLAN tags and forwarded.
- Advantages: Uses a new address space, compatible with IPv4/IPv6, leverages existing PCE technologies.
- Updates: Made updates to the CC object for specific interface indication and introduced an 'O' bit for differentiating in/out VLAN.
- Discussion:
  - Igen: Noted its alignment with SR PC solutions and support for IPv4/IPv6.
PCEP RSVP Color Draft (Draft: draft-sivabalan-pce-pcep-rsvp-color-02)
- Presenter: Pavan (due to Balaji's audio issues).
- Update: The single TLV was generalized to support various use cases, including those referenced in the PCE multipath draft.
- Request: Seeking working group adoption.
- Discussion:
  - Dhruv: Asked where the TLV would be carried. Pavan clarified it would be in the LSPA object, potentially under path attributes for multipath, and specific use cases would detail its placement for RSVP.

Decisions and Action Items

PCEP Object Ordering:
- Action Item: Discussion to continue on the mailing list.
- Action Item: Co-authors to perform a scan of existing PCEP extensions for text related to object ordering.
VTN / NRP ID:
- Action Item: Discussion on the relationship between VTN ID and Network Resource Partition ID to continue on the mailing list.
- Action Item: Chairs will seek guidance from the TEAS WG on terminology alignment.
PCEP LS:
- Action Item: Chairs will consider a working group adoption call based on the expressed interest.
Multicast / BEER:
- Action Item: An interim meeting between the PCE and BEER working groups is suggested to align requirements and architecture for PCEP-based BEER solutions.
- Guidance: Document authors are advised to focus the draft strictly on BEER-specific aspects to avoid confusion with generic multicast solutions.
PCEP RSVP Color:
- Action Item: Chairs will consider a working group adoption call.

Next Steps

Continue discussions on the PCE mailing list for the PCEP object ordering and VTN/NRP ID alignment.
PCE chairs to coordinate with TEAS and BEER WGs for terminology and architectural alignment.
Working group adoption calls are anticipated for the PCEP LS and PCEP RSVP Color drafts.