The Inter-Domain Routing (idr) WG in the Routing Area of the IETF is
undergoing rechartering. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list
([email protected]) by 2026-06-22.

Inter-Domain Routing (idr)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Sue Hares <[email protected]>
  Keyur Patel <[email protected]>
  Jeffrey Haas <[email protected]>

Secretaries:
  Jie Dong <[email protected]>

Assigned Area Director:
  Ketan Talaulikar <[email protected]>

Routing Area Directors:
  Jim Guichard <[email protected]>
  Gunter Van de Velde <[email protected]>
  Ketan Talaulikar <[email protected]>

Mailing list:
  Address: [email protected]
  To subscribe: https://www.ietf.org/mailman/listinfo/idr
  Archive: https://mailarchive.ietf.org/arch/browse/idr/

Group page: https://datatracker.ietf.org/group/idr/

Charter: https://datatracker.ietf.org/doc/charter-ietf-idr/

The Border Gateway Protocol (BGP) (version 4) [RFC4271] was originally
developed to support inter-domain IP routing over the Internet and other
IP-based networks. The introduction of multiprotocol extensions [RFC4760]
enabled BGP to support multiple address families, significantly broadening
its applicability to a wide range of routing features and deployment
scenarios.

The primary objective (and priority) of the Inter-Domain Routing (IDR)
Working Group (WG) is to develop and maintain BGP as the standard
inter-domain routing protocol deployed for IPv4 and IPv6 routing over the
Internet.

Aligned with this priority, the IDR WG will develop and maintain BGP
features, extensions, and mechanisms that are address-family independent and
are considered core to the protocol’s operation. These are:

- Protocol-level aspects such as message encoding and processing (PDUs),
support for different transports specific to BGP, session management,
neighbor finite state machine (FSM), path selection, and associated
procedures. - BGP attributes used to convey information relevant to Network
Layer Reachability Information (NLRIs), next-hop resolution, metrics, and
other data integral to BGP operation. - Capability advertisement mechanisms
[RFC5492] used during session establishment to signal support for optional
protocol features. - Extended Communities [RFC4360], including support for
Large and Wide Communities, for carrying metadata and policy-related
information. - Outbound Route Filtering (ORF) mechanisms [RFC5291][RFC5292]
for policy-based control of route advertisement. - Route constraint
mechanisms such as Route Target Constraints [RFC4684] for limiting route
propagation. - Advertisement of tunnel encapsulation information [RFC9012] to
support data plane flexibility. - Advertisement of Segment Routing
information via Prefix SID Attribute [RFC8669]. - Operation and optimization
of Route Reflectors [RFC4456] and Confederations [RFC5065] for scalable iBGP
deployments. - Graceful Restart procedures [RFC4724] [RFC9494] for improving
BGP session resiliency and convergence during restarts or failures. - BGPSec
[RFC8205] and BGP security related extensions other than the Resource Public
Key Infrastructure (RPKI) related work undertaken in SIDROPS WG.

In addition, the WG will develop and maintain BGP features, extensions, and
mechanisms for the following BGP address families for their respective
deployments within operator networks (including but not limited to service
provider, enterprise, and data center environments):

Track 1) Infrastructure (Underlay) Routing: These address families support
the routing of infrastructure prefixes, commonly referred to as underlay
routing:

- IPv4 and IPv6 unicast address families for networks outside of the public
Internet. - MPLS Labeled Unicast address family [RFC8277]. - Address families
related to intent-aware underlay routing specified by the WG.

Track 2) Routing-Adjacent Information Dissemination: These address families
enable BGP to carry information related to, or adjacent to, routing
functionality:

- Dissemination of Flow Specification rules [RFC8955] and Flow Specification
Version 2 [draft-ietf-idr-fsv2-ip-basic]. - Advertisement of link-state and
other topology information using BGP-LS [RFC9552]. - Advertisement of Segment
Routing (SR) Policies [RFC9830]. - Distribution of routing policies
[draft-ietf-idr-rpd]. - Signaling for SD-WAN tunnel discovery
[draft-ietf-idr-sdwan-edge-discovery]. - Advertisement of IPv4/IPv6 mappings
[draft-ietf-idr-mpbgp-extension-4map6].

The IDR WG charter lists work areas as opposed to specific deliverables,
reflecting the ongoing work, the extensible nature of the BGP, and the WG’s
operational model. Milestones are added for specific deliverables as
corresponding documents are adopted by the working group. These are tracked
as they progress through WGLC. The working group maintains a long-standing
policy that any protocol specification (excluding YANG modules) must have at
least two independent implementations prior to advancing to publication.

The following work areas define the scope of activities for the WG, limited
to the context of the BGP address families and core protocol extensions
outlined above:

- Advancement of BGP specifications, including but not limited to [RFC4271],
toward Internet Standard status, where appropriate. - Resolution of protocol
issues and incorporation of improvements based on operational experience and
feedback from the operator community. This includes enhancements related to
security, performance, scalability, protocol correctness, robustness, and
operational simplicity. - Development of YANG data models scoped to the WG's
chartered BGP features and extensions to support the management of BGP
features standardized by the WG, with a focus on device models and capturing
operational considerations, as appropriate. - Definition of BGP protocol
extensions to meet new requirements and use cases originating in other IETF
working groups. - Enhancements to BGP’s path selection and forwarding
behavior to support advanced load-balancing capabilities beyond Equal-Cost
Multi-Path (ECMP), including unequal and weighted load-balancing based on
parameters such as bandwidth. - Protocol improvements and extensions to
support BGP deployments in IPv6 networks, including IPv6-only environments
and mechanisms that facilitate the transition from IPv4 to IPv6.

The primary focus of the WG will remain on the development of Standards Track
BGP specifications. Adoption of experimental specifications may be done as an
exception in consultation with the Responsible AD. The WG will not seek to
publish documents focused on use cases, frameworks, or architectural
definitions. As an exception, the WG may produce Informational documents
capturing deployment experience or best practices for BGP features developed
within the WG with the exception of those related to global Internet routing
and BGP security that are covered by the GROW and SIDROPS WG charters.

As listed in the work areas, the WG may take up work on BGP protocol
extensions to support the work happening in other IETF WGs following
consultation with the relevant WG Chairs and Responsible ADs without the need
for a recharter. The WG shall coordinate closely with the originating WG(s)
that is responsible for the overall framework, architecture, and
requirements. Progression of such work in IDR WG shall follow the maturity
(specifically the adoption and WGLC milestones) of the corresponding base
work in those WGs. Relevant WGs include, but are not limited to, SPRING,
TEAS, CATS, SAVNET, and, in the context of BGP-LS, LSR.

The IDR WG may consider adopting work related to new BGP address families,
feature extensions, or work areas not explicitly listed above. However,
adoption of such work will require demonstrated interest and sufficient
expertise within the WG, and will be subject to a rechartering process (i.e.,
IDR will not become the WG that automatically adopts any BGP work).

Given the broad use of BGP across various WGs in the IETF, the IDR WG will
provide advice and collaborate closely with other WGs developing or relying
on BGP extensions and their BGP-related YANG models. This includes BESS (VPN
service-related BGP features), LSVR (BGP-SPF extensions), GROW (operational
practices and monitoring via BMP), and SIDROPS (RPKI related). The IDR WG
will seek input from GROW and SIDROPS as appropriate, particularly with
respect to operational and security considerations during the development of
new BGP specifications. Likewise, the WG will seek review from V6OPS and 6MAN
for IPv6-related extensions and from SRV6OPS for Segment Routing operational
aspects.

The IDR WG is expected to review BGP-related work in other WGs that is
specifically impacting core BGP protocol aspects and provide timely feedback
during (but not limited to) WG adoption and last calls in those respective
WGs. This feedback has no additional standing beyond any other community
review.

Milestones:

  Done     - Submit to BGP Capability Advertisement to the IESG

  Done     - Submit BGP Security Vulnerabilities Analysis to IESG as an
  Informational

  Done     - Submit BGP4 MIB to IESG as a Proposed Standard

  Done     - Submit BGP4 document to IESG as a Draft Standard

  Done     - Submit BGP Graceful Restart to IESG as a Proposed Standard

  Done     - Submit Extended Communities draft to IESG as a Proposed Standard

  Done     - Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG
  as a Draft Standard

  Done     - Submit Subcodes for BGP Cease Notification Message to IESG as a
  Proposed Standard

  Done     - Submit 4-byte AS ID to IESG as a Proposed Standard

  Done     - Submit Outbound Route Filter draft to IESG as a Proposed Standard

  Done     - Prefix ORF draft to IESG as a Proposed Standard

  Done     - Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a
  Proposed Standard

  Done     - Submit BGP Support for Four-octet AS Number Space (revised
  version) to IESG as a Proposed Standard

  Done     - Submit Revisions to the BGP 'Minimum Route Advertisement
  Interval' to IESG as a Proposed Standard

  Done     - Submit The Accumulated IGP Metric Attribute for BGP to IESG as a
  Proposed Standard

  Done     - Submit Error Handling for Optional Transitive BGP Attributes to
  IESG as a Proposed Standard

  Done     - Submit Advertisement of Multiple Paths in BGP to IESG as a
  Proposed Standard

  Done     - Submit BGP Link Bandwidth Extended Community to IESG as a
  Proposed Standard

  Jul 2026 - Submit Yang BGP Modules to IESG as Proposed Standard

  Jul 2026 - Submit BGP Extended Communities Attribute rfc4360bis to IESG as
  a Proposed Standard

  Jul 2026 - Complete WGLC for Link-Local Next Hop Capability for BGP as a
  Proposed Standard

  Jul 2026 - Complete WGLC for Extended Communities Derived from Route
  Targets as a Proposed Standard

  Jul 2026 - Complete WGLC for BGP-LS Extension for Inter-AS Topology
  Retrieval as a Proposed Standard

  Jul 2026 - Complete WGLC for BGP SR Policy Extensions for Segment List
  Identifier as a Proposed Standard

  Nov 2026 - Complete WGLC for BGP Community Container Attribute as a
  Proposed Standard

  Nov 2026 - Complete WGLC for Registered Wide BGP Community Values as a
  Proposed Standard

  Nov 2026 - Complete WGLC for BGP-LS SR EPE over L2 Bundle Members as a
  Proposed Standard

  Nov 2026 - Complete WGLC for BGP FlowSpec Extensions for SRv6 Policy as a
  Proposed Standard

  Nov 2026 - Complete WGLC for BGP FlowSpec Extensions for Path Redirection
  as a Proposed Standard

  Nov 2026 - Complete WGLC for BGP FlowSpec Extensions for Indirection to
  Interface-set as a Proposed Standard

  Nov 2026 - Complete WGLC for BGP FlowSpec Extensions for SRv6 as a Proposed
  Standard

  Nov 2026 - Complete WGLC for BGP SR Policy Extensions for Metric as a
  Proposed Standard

  Dec 2026 - Complete WGLC for Dynamic Capability for BGP-4

  Dec 2026 - Complete WGLC for BGP BFD Strict-Mode as a Proposed Standard

  Dec 2026 - Complete WGLC for BGP Flow Specification Version 2 - for Basic
  IP as a Proposed Standard

  Dec 2026 - Complete WGLC for IANA Registrations for the BGP FSM as a
  Proposed Standard

  Dec 2026 - Complete WGLC for BGP-LS Extensions for SR Policy Path Segment
  as a Proposed Standard

  Dec 2026 - Complete WGLC for BGP SR Policy Extensions for Path Segment as a
  Proposed Standard

  Dec 2026 - Complete WGLC for BGP SR Policy Extensions for Advertising SID
  Algorithm as Experimental

  Mar 2027 - Complete WGLC for ASpath ORF as a Proposed Standard

  May 2027 - Submit Base BGP specification (RFC 4271) to IESG as an Internet
  Standard

  Jul 2027 - Complete WGLC for BGP Extension for 5G Edge Service Metadata as
  a Proposed Standard

  Jul 2027 - Complete WGLC for BGP for SD-WAN Edge Discovery as a Proposed
  Standard

  Jul 2027 - Complete WGLC for BGP-LS Extensions for SR Policy NRP as a
  Proposed Standard

  Jul 2027 - Complete WGLC for BGP-LS Extensions for IS-IS Flood Reflection
  as a Proposed Standard

  Jul 2027 - Complete WGLC for BGP SR Policy Extensions for Path MTU as a
  Proposed Standard

  Jul 2027 - Complete WGLC for BGP SR Policy Extensions for Entropy Label
  Position as a Proposed Standard

  Nov 2027 - Complete WGLC on Multisession BGP as a Proposed Standard

  Dec 2027 - Complete WGLC for MP-BGP Extension for IPv4/IPv6 Mapping
  Advertisement as a Proposed Standard

  Dec 2027 - Complete WGLC for BGP Extensions for Routing Policy Distribution
  as a Proposed Standard

  Dec 2027 - Complete WGLC for Advertising SR P2MP Policies in BGP as a
  Proposed Standard

  Dec 2027 - Complete WGLC for BGP CT Adaptation for SRv6 as an Experimental



_______________________________________________
IETF-Announce mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to