**Session Date/Time:** 20 May 2024 14:00

# [IDR](../wg/idr.html)

## Summary

This IDR interim meeting focused on pre-adoption discussions for five drafts related to BGP-LS, SR policy extensions, SR segment types, L2 bundle members, and SR policy templates. The chairs emphasized catching up on shepherding work and conducting more thorough reviews before adoption calls. Key discussions revolved around technical alignment with existing Segment Routing work in the Spring WG, clarification of protocol mechanisms, and IETF process for new segment type allocations and broader architectural concepts like templates.

## Key Discussion Points

*   **WG Status and Note Well**: The meeting opened with the IETF Note Well reminder. Chairs provided an update on ongoing shepherding work and planned status updates. Upcoming interims for Flowspec V2 (minimal set focus) and draft-00 presentations were announced for June.
*   **draft-chen-idr-bgpls-sr-policy-nrp-sr-policy-extensions-00**
    *   This draft proposes extensions to BGP-LS SR Policy to carry an NRP (Network Resource Partition) ID attribute.
    *   **Discussion**: Several participants, including Joel M. and Kon T., questioned the relationship between the proposed NRP ID mechanism and existing or in-progress work in the Spring WG (e.g., `draft-ietf-spring-resource-aware-segments`) and 6MAN WG (`draft-ietf-6man-nrp-gaps`). Concerns were raised about how the NRP ID relates to Resource SIDs and its applicability to SRv6 and SR-MPLS.
    *   Kon also asked for clarification on how the NRP ID would be removed or decapsulated at the tail-end of an SR policy path, particularly for encapsulation mode.
    *   The authors noted that consistency verification is a key function, especially if policies are configured via NETCONF.
*   **draft-yao-idr-bgpls-sr-segtypes-extensions-00**
    *   This draft defines new segment sub-TLVs for SR-MPLS Adjacency SIDs with an optional Algorithm field, for use in BGP-LS SR policy advertisements.
    *   **Discussion**: The primary discussion revolved around the process for allocating new segment types. Joel M. and Alvaro R. clarified that new segment types can be requested and defined within this draft, but explicit mention of the allocation request and review by the Spring WG is necessary for coordination and consistency with the SR architecture. The practice of "squatting" on letters for TBDs was also noted, with a preference for early allocation once the definition is stable.
*   **draft-wang-idr-bgpls-sr-policy-headend-behavior-00**
    *   This draft proposes BGP-LS extensions for SR Policy to specify head-end behaviors for L3 and L2 traffic, such as `End.Encaps` and `End.Encaps.Reduced`.
    *   **Discussion**: Kon T. questioned the motivation and need for these TLVs, suggesting that L2/L3 behavior is determined by the steered traffic type rather than explicit signaling within the policy. Joel M. suggested the value might be in distinguishing between `reduced` and `non-reduced` encapsulation modes. The authors clarified that in the current version, the main function is to control the use of the `reduced` option.
    *   It was confirmed that the behaviors cited (e.g., `End.Encaps`) are already defined in RFCs, so prior Spring WG review is not strictly necessary for those specific behaviors.
*   **draft-wang-idr-bgpls-sr-l2-bundle-members-00**
    *   This draft describes how to support Segment Routing BGP EPE for L2 bundle members, proposing updates to RFC 9185 and RFC 9186 to allow L2 bundle member attributes and P-Adj-SID TLVs.
    *   **Discussion**: Kon T. raised a specific technical comment regarding the handling of BUM (Broadcast, Unknown Unicast, Multicast) traffic and the prevention of loops in scenarios involving MC-LAG or similar L2 bundle setups when steering traffic onto specific links via SR policies. Alvaro R.'s previous review comments regarding formal updates to existing RFCs were also acknowledged.
*   **draft-kang-idr-bgpls-sr-policy-template-extension-00**
    *   This draft introduces an SR Policy template mechanism, where a `Template ID` is carried in BGP-LS, referencing a locally configured set of features (e.g., BFD, OAM parameters) at the head-end.
    *   **Discussion**: Kon T. suggested aligning the "template ID" concept with the "profile ID" used in PCEP (e.g., `draft-ietf-pce-sr-vtn-rsc`). Alvaro R. and Sue H. (chair) expressed concern that this draft focuses only on carrying the `Template ID` via BGP-LS, but a broader architectural discussion on the template/profile concept (its scope, nesting, behavior when not found, etc.) is needed, likely within the Spring WG. Nadir A. also asked about the behavior of active SR policies when a referenced template is modified.

## Decisions and Action Items

*   **draft-chen-idr-bgpls-sr-policy-nrp-sr-policy-extensions-00**
    *   **Action**: Authors to provide a clearer explanation of the relationship between their proposed NRP ID mechanism and existing `draft-ietf-spring-resource-aware-segments` and `draft-ietf-6man-nrp-gaps` in the document.
    *   **Action**: Authors to address how the NRP ID is removed/decapsulated at the tail-end of an SR policy.
    *   **Action**: Further discussion on these points to occur on the mailing list.
*   **draft-yao-idr-bgpls-sr-segtypes-extensions-00**
    *   **Decision**: To proceed with adoption, the draft needs to explicitly include the request for allocation of the new segment types.
    *   **Action**: Authors to add explicit segment type allocation requests into the draft.
    *   **Action**: Authors to send the updated draft to both IDR and Spring WG chairs for review.
    *   **Action**: Spring WG chairs will be asked to review and confirm no issues with the allocations, after which IDR will proceed with an adoption call.
*   **draft-wang-idr-bgpls-sr-policy-headend-behavior-00**
    *   **Action**: Authors to clarify the specific purpose and value proposition of the TLVs in the draft, especially regarding the `reduced` vs. `non-reduced` option.
    *   **Action**: Authors to send the updated draft to the chairs for an adoption call.
*   **draft-wang-idr-bgpls-sr-l2-bundle-members-00**
    *   **Action**: Authors to address comments regarding BUM traffic handling and loop prevention in L2 bundle scenarios.
    *   **Action**: Authors to review Alvaro R.'s comments on formal updates to existing RFCs.
    *   **Action**: Once updated, the draft will move towards the adoption process; no Spring WG pre-review is required for this.
*   **draft-kang-idr-bgpls-sr-policy-template-extension-00**
    *   **Action**: Authors to initiate a discussion within the Spring WG on the overall "template approach" or "profile ID architecture" for SR policies, considering its relationship to PCE/PCEP (e.g., `draft-ietf-pce-sr-vtn-rsc`).
    *   **Action**: Authors to clarify the relationship between this draft and existing PCE/PCEP work, potentially aligning on naming (e.g., "profile ID").
    *   **Action**: Authors to address comments regarding template modification behavior for active SR policies and precedence.
    *   **Action**: After initial Spring WG feedback and revisions, the updated draft should be sent to Spring WG for review first, before IDR considers adoption.

## Next Steps

*   Authors of all drafts are requested to revise their documents based on the feedback and action items identified.
*   Specific drafts requiring Spring WG review for architectural concepts or new allocations (`draft-chen-idr-bgpls-sr-policy-nrp-sr-policy-extensions-00`, `draft-yao-idr-bgpls-sr-segtypes-extensions-00`, `draft-kang-idr-bgpls-sr-policy-template-extension-00`) will coordinate with both IDR and Spring WG chairs.
*   The IDR chairs will follow up on the status of these drafts and initiate adoption calls once the necessary pre-adoption work and reviews are completed.