Minutes IETF124: bess: Mon 22:00
minutes-124-bess-202511032200-01

IETF BESS Working Group – Meeting Minutes
Date: 03 November 2025
Location: IETF 124 – Montreal
Session Duration: 17:00–18:30
Chairs: Stéphane, Jeffrey, Jorge

1. Working Group Update (Chairs – 17:00–17:15)

1.1 Administrative
- Session opened; reminder on use of Meetecho/onsite sign-in for attendance
tracking. - Krishna volunteered as note taker.

1.2 Document Status
- One new RFC published since last IETF:
  • Multicast Source Redundancy EVPN.
- No additional documents currently in RFC Editor queue.

1.3 Ongoing Drafts in AD/IESG Review
- EVPN–IPVPN Interworking (draft-ietf-bess-evpn-ipvpn-interworking-15):
  • Large AD review from Gunter (approx. 120 pages).
  • Authors are working through comments; response targeted “this week”.
- MVPN/EVPN SR P2MP (draft-ietf-bess-mvpn-evpn-sr-p2mp-17):
  • Multiple DISCUSS positions under resolution.
  • One open issue around field naming (currently “MPLS Label” but used also
  for SRv6 SIDs); may require source RFC update.
- EVPN Unequal Cost Load Balancing (draft-ietf-bess-evpn-unequal-lb-29):
  • WG/IESG discussion largely closed.
  • Waiting for further AD/IESG comments.

1.4 Shepherded Documents
- VPLS Multihoming (draft-ietf-bess-vpls-multihoming-06):
  • Very old draft.
  • Author confirmed commitment to respond to questions and perform another
  shepherd review, then follow through with RFC Editor.
- EVPN Geneve:
  • Lacking recent refresh from editor.
  • Chairs may appoint a new editor if progress cannot be resumed.
- EVPN BFD (draft-ietf-bess-evpn-bfd-12):
  • Good technical discussion ongoing.
  • Main open issue: port number and potential packet confusion scenarios;
  expectation that a new port will be required.

1.5 Potential WG Last Calls
- BGP Multicast Controller/Chair drafts
(draft-ietf-bess-bgp-multicast-controller-16):
  • Author (Sue) reported several months of personal outage; plans to resume
  work after IETF.
- EVPN–MVPN Seamless Interop:
  • Authors need to confirm reviewers are satisfied with latest changes.
- EVPN Aware Bundling (draft-ietf-bess-evpn-ac-aware-bundling-05):
  • Outstanding issues with co-authors still being closed; further offline
  discussion planned.

1.6 Milestones and YANG Models
- Milestones are broadly on track.
- Some EVPN-related YANG models (device models, L2VPN/EVPN YANG) remain parked:
  • Other WGs (e.g., NVO3) depend on these models.
  • With the document backlog reduced, editors are encouraged to resume work if
  interested.

2. Working Group Draft Updates

2.1 draft-ietf-bess-ebgp-dmz-08 (Stephane – 17:15–17:25)
- Purpose:
  • Companion to IDR BGP Link Bandwidth draft, focused on EBGP DMZ and data
  center use cases.
- Recent Updates:
  • Cleaned up text to sync with changes in IDR link bandwidth draft.
  • Removed now-incorrect assumptions about link bandwidth community
  propagation. • Reorganized structure to separate:
    - Use cases (e.g., DC aggregation, WCMP load balancing).
    - Behaviors (e.g., automatic bandwidth setting, accumulation).
- Technical Points:
  • Automatic population of BGP link bandwidth from interface bandwidth.
  • Introduction of “contributing bandwidth”:
    - Remote bandwidth (from BGP attribute).
    - Local interface bandwidth.
    - Contributing bandwidth = configured function of the two (e.g.,
    min(remote, local)).
  • Accumulation use case: sum bandwidth across multiple paths and advertise an
  aggregated value downstream.
- Process/Ownership:
  • Draft changed back to Standards Track.
  • Discussion with IDR: proposal to move draft to IDR, as it is tightly
  coupled with the BGP Link Bandwidth draft. • BESS and IDR will continue
  co-ordination regardless of formal WG ownership.

2.2 draft-ietf-bess-v4-v6-pe-all-safi (Gyan Mishra – 17:25–17:30)
- Scope:
  • IPv4/IPv6 PE-PE interop using RFC 8950 next-hop encoding over SRv6/MPLS
  data planes.
- Interop Status:
  • Nokia–Juniper:
    - Interop at MPLS World Congress revealed next-hop encoding issue on
    Juniper side. - Issue fixed in later Juniper code; re-testing successful.
  • Cisco:
    - Cisco-to-Cisco testing in progress (XRd, NCS, 9000 platforms).
    - Some IPv4 over SRv6 and MPLS use cases already validated.
    - Multi-vendor interop with Cisco planned by end of year.
  • EANTC:
    - Targeting further multi-vendor testing in the next cycle.

3. Individual Drafts – New (Rev 0)

3.1 draft-zzhang-bess-evpn-multi-active-multihoming-00 (Jeffrey – 17:30–17:40)
- Goal:
  • Introduce a “multi-active” mode between all-active and single-active
  multihoming for EVPN ES.
- Concept:
  • On a given ES:
    - A subset of PEs is “preferred” (active for unicast).
    - Remaining PEs are “non-preferred” and stay inactive until needed.
  • Preference value is configured per PE on the ES and signaled via DF
  Election Extended Community.
- Operation:
  • Preferred PEs:
    - Operate in all-active mode for unicast.
    - Signal P-bit = 1 in Layer 2 Attributes EC.
  • Non-preferred PEs:
    - Operate in single-active mode.
    - Signal P-bit = 0, B-bit = 0.
  • Ingress PEs:
    - Load-balance unicast only across PEs with P-bit = 1.
- Strict vs Loose Mode:
  • Strict:
    - Only PEs with highest preference are active.
    - When primary fails, next-highest-preference PE becomes active.
  • Loose:
    - Multiple PEs with sufficiently high preference can be active
    simultaneously.
- DF Election:
  • Preference value is carried in DF Election community.
  • For capability “AC-influenced DF”:
    - PEs with P-bit=0 are ineligible to become DF.
- Discussion:
  • Need clearer use cases (operational drivers) in the draft.
  • Some concern about interaction with existing active/standby semantics and
  transitions.

3.2 draft-zl-bess-evpn-srv6-oam-00 (Xiaoqiu – 17:40–17:50)
- Problem:
  • MPLS-based EVPN has standardized OAM (RFC 9489 / EVPN Ping).
  • For EVPN over SRv6, there is no clearly specified OAM ping mechanism
  targeting the EVPN service.
- Proposal:
  • Define an EVPN SRv6 Ping, reusing MPLS echo request/reply structure.
  • Two encapsulation formats:
    1) Two-layer Ethernet/IPv6:
       - Outer Ethernet + IPv6 + SRH.
       - Inner Ethernet with virtual MAC + inner IPv6 loopback address.
       - UDP (destination port 3503, MPLS echo port).
       - MPLS echo request/reply payload.
    2) One-layer Ethernet/IPv6:
       - Single Ethernet/IPv6/SRH/UDP/MPLS-echo stack.
- Pros/Cons:
  • Two-layer:
    - Double isolation between forwarding path and virtual endpoints.
    - Better for multi-tenant visibility.
    - Larger overhead, more processing.
  • One-layer:
    - More compact, better performance/latency.
    - Less explicit virtual network identification; harder for troubleshooting.
- Feedback:
  • Zafar: SRv6 OAM should rely on IPv6 OAM (ICMPv6); design may need to start
  from 6man/SPRING. • Greg: Unclear what is being standardized beyond what
  ICMPv6 and existing SRv6 mechanisms already provide. • Agreement to continue
  discussion on mailing list; possible re-scoping.

3.3 draft-rabsaj-bess-evpn-vxlan-ir-bum-00 (Jorge Rabadan – 17:50–17:55)
- Issue:
  • With all-active ES and ingress replication for BUM:
    - Packet duplication can occur on multi-homed CEs when unknown unicast is
    flooded. - RFC 8365 recommended VXLAN-GPE B-flag use, but VXLAN (RFC 7348)
    lacked the flag registry.
- Proposal:
  • Define a B-bit in the upcoming VXLAN Flags Registry (7348bis).
  • B-bit indicates “packet is a BUM frame generated via ingress replication”.
- Use Cases:
  • Scenario 1: Remote PE unknown-unicast flood to all-active ES:
    - Non-DF PE discards packet when B-bit set.
    - Avoids duplication to multihomed CE.
  • Scenario 2: MAC known remotely but aged-out on ES PEs:
    - Ingress PE sends packet with B-bit = 0 when unicasting to an ES PE.
    - Receiving PE can safely forward to CE even if MAC is not currently
    present in FIB, based on non-BUM semantics.
- Discussion:
  • Overall agreement that a B-bit is useful.
  • Minor text clarification needed around “MUST treat B=0 as non-BUM” and
  pre-existing implementations.

4. Individual Draft Updates

4.1 draft-rabadan-bess-evpn-inter-domain-opt-b-07 (Jorge Rabadan – 17:55–18:05)
- Background:
  • Document analyzes EVPN behavior across inter-domain option-B boundaries
  (L2, L3, and PBB-EVPN). • Previous versions were informational, providing
  deployment guidance and describing problems with next-hop rewriting.
- Key Issue:
  • AD-per-ES route lacks a unique, stable identifier other than next-hop.
  • In option B, border routers rewrite next-hop → ingress PEs lose correlation
  between:
    - AD-per-ES routes.
    - MAC/IP routes.
  • Breaks:
    - per-ES mass withdraw,
    - aliasing/back-up path correctness,
    - AC-influenced DF election,
    - egress filtering for BUM from leaf nodes.
- New Solution in v7:
  • Define a new sub-TLV in BGP Tunnel Encapsulation Attribute:
    - “Egress PE Identifier Sub-TLV”.
    - Similar format to “Tunnel Egress Endpoint” Sub-TLV in RFC 9012 but
    different code point and semantics.
  • Procedures:
    - Egress PE encodes its own ID in the sub-TLV in AD-per-ES, MAC/IP, and IP
    Prefix routes. - First border router can add sub-TLV if missing (deriving
    from original next-hop). - Subsequent border routers MUST NOT alter the
    Egress PE Identifier.
  • Ingress PEs:
    - Use Egress PE Identifier to correlate AD-per-ES and service routes across
    domains and apply all EVPN procedures correctly.
- Process:
  • Document status changed to Standards Track.
  • Chairs asked WG to review and move toward adoption.

4.2 draft-rbickhart-evpn-ip-mac-proxy-adv-04 (Wen Lin – 18:05–18:15)
- Problem:
  • In all-active multihoming, MAC+IP bindings may only be learned by a subset
  (often just one) of the ES PEs. • On node or egress link failure, MAC+IP
  bindings can be lost before they are relearned:
    - Causes temporary black holes.
    - Triggers unnecessary flooding.
    - Can interfere with ARP/ND suppression logic.
- Goal:
  • Avoid race conditions between:
    - MAC/IP retention (aging) timers.
    - Time required to relearn MAC/IP after failure.
- Proposal: Proxy MAC/IP Advertisement
  • When one PE on ES learns MAC+IP via data plane:
    - It advertises a normal (non-proxy) Type-2 route to all PEs.
  • Other multihomed PEs on same ES:
    - Re-advertise a proxy MAC/IP Type-2 route (with a “proxy” bit set).
    - Indicates: “I did not learn this locally; I am proxying someone else’s
    knowledge.”
  • Remote PEs (not on ES):
    - Ignore proxy bit; treat proxy and non-proxy the same for forwarding.
- Failure Handling:
  • On failure of the sole “true” owner PE:
    - That PE withdraws its non-proxy MAC/IP route.
  • Remaining multihomed PEs:
    - Detect that no non-proxy routes exist for that MAC/IP on the ES.
    - Trigger local ARP/ND (GARP, NS) to relearn MAC/IP.
    - Continue advertising proxy routes while attempting to relearn.
  • If relearn succeeds:
    - That PE becomes new “true” owner.
    - Remote PEs never saw a complete withdrawal, so no flooding/blackholing.
  • If relearn fails:
    - Proxy MAC/IP routes age out and are withdrawn.
    - Remote PEs then clean up and revert to unknown-unicast flooding.
- Advantages:
  • Localizes convergence to ES PEs.
  • Remote PEs do not need to churn state or rely on control-plane refresh in
  large-scale networks.
- Discussion:
  • Krishna: Asked for clearer description of how multihomed PEs handle proxy
  vs non-proxy routes. • Some concerns on corner cases (e.g., links bouncing
  and possible loops). • Agreement to clarify behaviors in the draft; further
  discussion on mailing list. • Implementation and field deployment already
  exist (multi-vendor and open-source FRR).

4.3 draft-liu-bess-srv6-anycast-vpn-service (Changwang – 18:15–18:20)
- Problem:
  • In multihomed SRv6 deployments, PEs may advertise SIDs for the same service
  from multiple locations. • Need to distinguish:
    - Anycast SIDs (for load balancing / redundancy).
    - Unicast SIDs (for specific node).
- Proposal:
  • Define “anycast” flavor for SRv6 endpoint behaviors used by VPN/EVPN.
  • New behaviors (examples):
    - End.DT4 with anycast flavor.
    - End.DT6 with anycast flavor.
    - Similar variants for DT46, etc.
  • PEs may advertise:
    - Anycast SID (shared among multiple PEs).
    - Unicast SID (per-PE).
  • Ingress PEs can distinguish anycast vs unicast SIDs and use them
  appropriately.
- Status:
  • Solution is structurally simple; no time for questions due to schedule.
  • Feedback requested on mailing list.
  • Author requested WG adoption consideration.

4.4 draft-wang-bess-l3-accessible-evpn (Aijun – 18:20–18:30)
- Objective:
  • Provide “L3-accessible” EVPN bundle service where sites behind different L3
  MAN networks are bound together and identified as belonging to the same
  customer “bundle”.
- Approach:
  • Introduce a new L3 Service Identifier (LSI) carried in VXLAN-like
  encapsulation and signaled via EVPN. • New ES type and control-plane
  signaling to bind LSI with existing EVPN mechanisms.
- Discussion and Feedback:
  • Several experts (Ali, Jeffrey, Sasha) argued:
    - Existing EVPN mechanisms already cover the described requirements.
    - Alternative compositions (e.g., current EVPN bundle service, VLAN/VNI
    mapping, VPWS/EVPN combinations) can be used. - The proposed requirement of
    an explicit “bundle identifier” is new and not clearly justified
    operationally.
  • Authors and reviewers disagree on whether a real gap exists.
  • Chairs noted:
    - Multiple rounds of discussion (meetings + mailing list) have not produced
    WG consensus. - Current conclusion: draft does not have enough support or a
    clear problem statement to proceed to WG adoption.