pce

Summary

The PCE working group session covered the status of existing documents, including several approaching Working Group Last Call (WGLC) or awaiting AD review. Key discussions revolved around the specifics of new proposals: PCE extensions for Circuit Style SR Policies, PCE Extensions to Redundancy Policy, and PCE Extensions for SID Verification for SR Policies. The working group addressed open technical issues, clarified use cases, and emphasized the need for better cross-document coordination and continued mailing list discussions.

Key Discussion Points

Working Group Document Status:
- One document is in the RFC Editor queue, awaiting a reference to another document.
- Three documents are with the ADs for publication: "extended flags" and "stateful GMPLS extensions".
- Several IPR disclosures were announced, including one for the Flow Spec RFC, one for a multipath draft, and one for IFIT. Discussion on the mailing list is encouraged.
- Four documents have received IANA early allocation code points. Chairs will assist authors in triggering the early allocation policy if needed for new specifications.
Individual Document Updates & Discussions:
- Local Protection Enforcement (draft-ietf-pce-local-protection-enforcement): WGLC completed. Currently awaiting Shepherd review (Julian). Updates addressed Yang Doctor review comments, including moving repetitive content to an appendix, clarifying relationship with PSEPMIP, renaming leaves, collapsing single-use groupings, adding stateful GMPLS capability to the Yang model, and validating examples. Considered ready for WGLC.
- SRv6 (draft-ietf-pce-srv6-inst-info): Received two updates, including an IANA allocation and enhanced security considerations. Mostly editorial changes. Recommended for prioritization for WGLC.
- Native IP and Flex Grid (draft-ietf-pce-native-ip-only, draft-ietf-pce-flex-grid): No recent updates. Working group members are encouraged to review these documents.
- Enhanced Errors (draft-ietf-pce-enhanced-errors): No progress or feedback received. The working group needs to decide on the future of this document.
- Path Segment (draft-ietf-pce-path-segment): No change. An open issue was highlighted regarding the two mechanisms for path segment allocation (via TLV or PCC mechanism). The chairs sought working group consensus on supporting both or focusing on a single one. Authors confirmed current intent to support both, open to mailing list discussion.
- Bi-directional SR Path (draft-ietf-pce-bidirectional-sr-paths): No change, considered ready for WGLC. Authors confirmed readiness for WGLC.
- SR Policy (draft-ietf-pce-sr-policy): An update added an invalidation TLV for traffic steering (for down/invalid LSPs).
- PCC SR (draft-ietf-pce-pcc-sr): An update added text for anycast SID allocation.
- Multipath (draft-ietf-pce-multipath): Multiple updates, including multipath opposite direction path TLV, an implementation status section (listing three existing implementations), and early IANA allocation.
- State Sync between PCEs (draft-ietf-pce-state-sync): Two updates, adding implementation status and manageability considerations. An open issue is how primary/secondary PCE selection priority is advertised, as it's currently out of scope (assumed via configuration/Yang or future capability). Feedback from the working group is requested.
- Optional (draft-ietf-pce-optional-processing): Implementation status added, but no known implementations listed. Implementers were urged to reach out to chairs/authors.
- Algorithm SID Algo (draft-ietf-pce-algorithm-sid-algo): Adopted in February, but comments received during adoption are still pending. Authors noted conflicting opinions and plan partial updates, with a suggestion to use editor's notes for disagreements.
- Path MTU (draft-ietf-pce-sr-path-mtu): A companion document in Spring has been produced and presented. Text has moved from the PCE document to the Spring document. Updates included clarifying RFC 5440 for metric bounds (min vs. max for MTU) and adding a multipath section.
PCE Extensions for Circuit Style SR Policies (draft-ietf-pce-cs-sr-policy-ext-01):
- Purpose: Extends PCE to meet requirements for connection-oriented transport services using SR policies (circuit style SR policies), focusing on path persistency and by-hop behavior (adj-SIDs/prefix-SIDs).
- Changes: Simplified a new TLV for blocking path computation/optimization (removed flags, renamed, moved from LSP to LSPA object, though a recent comment suggests moving it back). Introduced new flags for allowing/blocking path modification (if original path invalid) and for explicit operator requests. Generalized the state path definition.
- Discussion:
  - Delegation without Re-computation: A primary point of discussion was the use case for delegating a path to the PCE but restricting its re-optimization capabilities. Examples provided included maintaining established resource usage and controlled teardowns based on bandwidth awareness by the PCE. Clarifying text for this scenario will be added to the document.
  - Spring vs. PCE Document Content: A suggestion was made to keep the Spring document for circuit-style SR policies as general as possible, moving PCE-specific text and mechanisms (like delegation) to the PCE document. This would allow the Spring document to be technology-agnostic.
  - Policy Framework: A broader discussion point raised whether "circuit style" policies should be handled as a specific, new flag/TLV or integrated into a more general "well-known path profile" or policy framework. Authors stated the flags are designed to be reusable beyond just circuit style policies.
PCE Extensions to Redundancy Policy (draft-li-pce-redundancy-policy-extension-00):
- Purpose: Introduces PCE extensions for a generalized redundancy protection mechanism (packet replication, multiple disjoint paths, first-accurate merging). This builds on related drafts defining redundancy SIDs, SR policies, and BGP extensions.
- Proposed Extensions: New TLVs in the Request Parameters Object to request redundancy path computation and protection method. Also, a TLV to distribute a new redundancy flag attribute for candidate paths within the SR Policy Association Group.
- Discussion:
  - SR-MPLS Coverage: Concern was raised that the existing Spring redundancy protection document is SRv6-specific. The authors confirmed the intent to support both SR-MPLS and SRv6, acknowledging a gap for SR-MPLS data plane specifications that needs addressing.
  - Coordination with Thatnet: A suggestion was made to coordinate with the Thatnet working group, as redundancy functions originate from their work.
  - Protection Type Definition: Further clarification is needed on how this "redundancy protection" differs from existing PCE protection mechanisms (e.g., diversity) and how they would interact if both are encoded. Discussion is needed on whether a new T-S-A is necessary or if existing mechanisms can be extended.
PCE Extensions for SID Verification for SR Policies (draft-ietf-pce-sr-state-verification-01):
- Purpose: Defines a mechanism for a PCC to explicitly request the PCE to verify a Segment ID (SID) state.
- Mechanism: Introduces a new 'V' flag in the SR ERO sub-object for indicating the explicit verification request. An SRRO sub-object for reporting verification failures is also defined.
- Status: Updates have been made based on AD comments. The document is considered ready for a call for adoption. It received support for adoption from a working group member.
Cross-Document Coordination: A new wiki page was introduced to help track dependencies and coordinate work across multiple working groups (PCE, Spring, BGP, I2RS) to prevent issues like missed bit flags or inconsistent definitions. Authors are encouraged to update this wiki.

Decisions and Action Items

Decisions

Local Protection Enforcement: The document is considered ready for Shepherd review.
SRv6: The document is recommended for prioritization for Working Group Last Call.
Path Segment: Authors will proceed with supporting both path segment allocation mechanisms (TLV and PCC), with further discussion on the mailing list if comments arise.
Bi-directional SR Path: The document is considered ready for Working Group Last Call.
PCE Extensions for SID Verification for SR Policies: The document is ready for a call for adoption.

Action Items

Authors of draft-ietf-pce-local-protection-enforcement: Await and address Shepherd review comments.
Authors of draft-ietf-pce-srv6-inst-info: Push for Working Group Last Call.
Working Group Members: Review draft-ietf-pce-native-ip-only and draft-ietf-pce-flex-grid and provide feedback.
Working Group Members: Provide feedback on the future direction of draft-ietf-pce-enhanced-errors.
Working Group Members and Authors of draft-ietf-pce-path-segment: Continue discussion on the mailing list regarding the two path segment allocation mechanisms.
Working Group Members: Provide feedback on the handling of primary/secondary PCE priority advertisement in draft-ietf-pce-state-sync.
Working Group Implementers: Contact chairs/authors if implementing draft-ietf-pce-optional-processing to update its implementation status.
Authors of draft-ietf-pce-algorithm-sid-algo: Address pending adoption comments, consider making partial updates, and use editor's notes in the document for areas of disagreement.
Authors of draft-ietf-pce-cs-sr-policy-ext: Add clarifying text to the document regarding the use cases for "delegation without re-optimization."
Authors of draft-ietf-pce-cs-sr-policy-ext and draft-li-pce-redundancy-policy-extension: Coordinate content distribution between their respective PCE and Spring documents to ensure PCE-specific text resides in PCE documents.
Authors of draft-li-pce-redundancy-policy-extension: Ensure the document adequately covers SR-MPLS in addition to SRv6, and coordinate with the Thatnet working group as appropriate.
Authors of draft-li-pce-redundancy-policy-extension: Clarify the differences between "redundancy protection" and existing PCE protection types, and describe their interaction.
Working Group Members: Provide feedback on draft-ietf-pce-sr-state-verification to support its adoption.
Authors of all Working Group documents: Update the new wiki page for cross-document coordination, especially concerning bit flags and inter-WG dependencies.

Next Steps

The chairs will consider initiating Working Group Last Calls for draft-ietf-pce-local-protection-enforcement, draft-ietf-pce-srv6-inst-info, and draft-ietf-pce-bidirectional-sr-paths.
The chairs will consider a call for adoption for draft-ietf-pce-sr-state-verification.
Discussions on various open issues (e.g., Path Segment mechanisms, PCE state sync priority advertisement, "circuit style" SR policy framework, redundancy policy specifics, Algorithm SID Algo comments) will continue on the mailing list.
The second PCE session is scheduled for tomorrow.

Session Date/Time: 28 Jul 2022 21:30

pce

Summary

The pce working group session covered several key areas: clarifications for the PCEP protocol, an update on PCEP extensions for In-situ Flow Information Telemetry (IFIT), two early-stage proposals for PCEP extensions to support Deterministic Networking (DetNet) bounded latency, and a proposal for PCEP extensions for Network Resource Partition (NRP) ID. Discussions included the structuring of clarification documents, alignment with other working groups' efforts (DetNet, ICN, IETF-NS), and coordination between similar PCEP extension drafts.

Key Discussion Points

PCEP Operational Clarifications (draft-ietf-pce-pcep-operational-clarifications)
- Optional PCReq/PCReply: Proposed making PCRequest and PCReply messages optional to reduce signaling (from three messages to one for tunnel setup), reflecting current vendor practices.
- Terminology: Clarified "PCEP tunnel" (identified by PSPID symbolic name) versus "PCEP LSP" (an instance of a tunnel for make-before-break, identified by LSP identifiers TLV).
- Associations: Clarified that PCEP associations contain LSPs, not tunnels.
- LSP Operations: Provided examples of various LSP operations to address observed interop issues.
- Object Absence: Explicitly stated that the absence of an object (if it lacks an explicit removal flag) implies the removal of the constraint it represents.
- SR RRO Discouragement: Discouraged the use of SR RRO due to its RCPT concept origin and confusion it caused with SR paths.
- Draft Structure Discussion: Raised the question of whether to keep informative and normative content in a single draft (clearly separated) or split into two separate drafts.
  - Andrew Stone, Adrian Farrell: Expressed a mild preference for a single draft, clearly distinguishing informative/normative sections.
  - Dhruv Dhody: Preferred two separate drafts for clarity, noting the difficulty in separating content within a single document for reviewers. Suggested making normative changes explicit upfront, followed by examples.
  - Julian Lucek: Suggested taking the discussion on draft structure to the mailing list to reach consensus between options 1 (single draft with clear separation) and 2 (two separate drafts).
PCEP Extension for IFIT (draft-ietf-pce-pcep-ifit)
- Draft Status: The draft was recently adopted by the working group.
- IFIT Scope: The extensions define IFIT capabilities and attributes as TLVs within the LSP Attributes (LSPA) object, applicable to various path types (not just SR).
- Capabilities: An IFIT Capability TLV (optional) in the OPEN object advertises support for ION (in-situ OAM) and Alternate Marking via five flags.
- Attributes: An IFIT Attribute TLV provides configurable knobs (five sub-objects for ION/Alternate Marking) carried in the LSPA object.
- Addressing Comments: Upcoming 01 version will address comments including:
  - Clarification on head-end support for IFIT capability (at least two nodes required).
  - IPv6 examples for extension headers.
  - Relationship between PCEP and BGP-SR Policy IFIT mechanisms.
  - Clarification of IFIT terminology and framework.
  - Editorial comments.
- Adrian Farrell: Questioned the lack of reference to the IFIT framework draft from the ops area, which stalled.
- Dhruv Dhody: Suggested clarifying the IFIT term (by reference or description) and tracking the scope for SR-MPLS, as discussions are ongoing in the MPLS WG. Emphasized coordination with related IDR drafts.
PCEP Extension for DetNet Bounded Latency (draft-tran-pce-pcep-detnet-bonded-latency)
- Motivation: To support DetNet requirements for bounded latency (min/max end-to-end latency, jitter) in path selection and establishment, considering queuing delay bounds.
- Proposed Extensions:
  - Two new metrics in the Metric object: End-to-end Bounded Latency and End-to-end Bounded Jitter.
  - A 'D' bit in the LSP Extended Flag TLV.
  - Extension of queue information structure (possibly new sub-objects) in ERO/SERO/SRv6ERO.
- Discussion:
  - Janusz Wojcik: Noted that the proposal is ahead of the DetNet WG's consensus on requirements and solutions. Suggested leveraging existing flow information RFCs and waiting for DetNet work to mature for queuing parts.
  - Andrew Stone: Asked how PCEP learns processing delays; clarified by author that IGP advertisement for load delay would provide this. Suggested referencing such documents.
  - Greg Mirsky: Encouraged informing or contributing to the DetNet controller plane framework document.
  - Dhruv Dhody: Recommended clear references to DetNet requirements documents and consistent terminology.
PCEP Extension for Enhanced DetNet (draft-shao-pce-pcep-enhanced-detnet)
- Motivation: To transmit bounded latency information between PCC and PCE to guarantee bounded latency transmission in the control plane for Enhanced DetNet (RFC 8655, RFC 9440, SR Enhanced DetNet).
- Proposed Extensions:
  - OPEN Object: Bounded Latency Capability TLV to negotiate feature support.
  - RP Object: BR Type TLV to specify desired BR type/format.
  - PCRequest: Traffic Model object to specify flow features for path computation.
  - PCReply: BR Object (Bounded Latency Information) to indicate requirements and resource allocation. Two types: BRList TLV (different values per node) and Shared BR TLV (same value for all nodes).
  - SR Policy: Extensions to carry BRList or Shared BR TLV.
- Discussion:
  - Dhruv Dhody: Reiterated comments from the previous DetNet draft regarding clear requirements and terminology alignment, noting a potential mismatch in the current TLV structure (one BLI per hop vs. multiple BLIs needed per hop as mentioned in DetNet WG).
PCEP Extension for NR-P ID (draft-shuaiwang-pce-pcep-nrpid)
- Motivation: To support Network Resource Partition (NRP) ID as a constraint for network slicing during path computation, replacing earlier t-constraints drafts.
- NRP ID Definition: Defines NRP ID based on IETF-NS and IETF-MPLS-RP terminology, as a globally unique identifier within an RP domain.
- Proposed Extensions:
  - NRP ID TLV to identify slices and network resources.
  - Carried in PCReport, PCInitiate, and PCUpdate messages.
- Next Steps:
  - Add NRP capability in OPEN message.
  - Clarify path computation with NRP ID constraint.
  - Add reference to IETF-NS NRP extensions.
- Hongwei Li: Noted a similar draft (draft-ietf-pce-pcep-slicing) exists. Emphasized coordination among control plane drafts (IGP, BGP, PCEP) for network slicing and aligning with IETF-NS WG terminology.
- Shuaiwang Li: Agreed to discuss and collaborate on unifying this work.
- Dhruv Dhody: Urged authors of similar drafts to work together for a single, unified document.

Decisions and Action Items

draft-ietf-pce-pcep-ifit: Adopted by the working group. Authors to publish a 01 version addressing comments.
draft-ietf-pce-pcep-operational-clarifications: Working Group adoption requested.
- Action Item: The chairs will initiate a discussion on the mailing list to achieve consensus on the draft's structure (single document with clear separation of informative/normative content vs. two separate documents).
DetNet PCEP Extension Drafts:
- Action Item (Authors): Align proposals with DetNet working group requirements and terminology. Reference relevant DetNet documents and the DetNet controller plane framework.
NRP ID PCEP Extension Drafts:
- Action Item (Authors): The authors of draft-shuaiwang-pce-pcep-nrpid and draft-ietf-pce-pcep-slicing (and potentially others) are urged to collaborate and consolidate their work into a single document for the working group.

Next Steps

Continue discussions on the pce mailing list for all drafts, especially regarding the structure of the pcep-operational-clarifications draft and the coordination of DetNet and NRP ID related work.
Authors of draft-ietf-pce-pcep-ifit to publish a new version addressing comments.
Authors of DetNet PCEP drafts to engage with the DetNet WG to ensure alignment.
Authors of NRP ID PCEP drafts to coordinate for a unified specification.
The working group will continue to review and provide feedback on these and other ongoing drafts.