2.5.3 Inter-Domain Routing (idr)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-13


Susan Hares <skh@nexthop.com>
Yakov Rekhter <yakov@juniper.net>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Bill Fenner <fenner@research.att.com>

Technical Advisor(s):

Randall Atkinson <rja@extremenetworks.com>
Sharon Chisholm <schishol@nortelnetworks.com>

Mailing Lists:

General Discussion: idr@ietf.org
To Subscribe: idr-request@ietf.org
In Body: subscribe idr-post
Archive: http://www.ietf.org/mail-archive/web/idr/index.html

Description of Working Group:

The Inter-Domain Routing Working Group is chartered to standardize
and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
1771] capable of supporting policy based routing for TCP/IP
The objective is to promote the use of BGP-4 to support IP version
4 and IP version 6. The working group will continue to work on
improving the scalability of BGP.

The current tasks of the WG are limited to:

- Revise and clarify the base BGP4 document (RFC 1771). Note that
RFC 1771 no longer documents existing practice and one goal of the
update is document existing practice. Determine whether the document
can be advanced as full Standard or needs to recycle at Proposed
or Draft Standard.

- Submit updated base BGP4 MIB to accompany the revised base BGP4

Once these tasks are finished (means WG consensus, WG Last Call,
AD Review, IETF Last Call, and IESG approval for publication), work
will progress on the following:

- Review and Evaluate Existing RFCs on AS Confederations and Route
Reflection. If changes are needed, create and advance revisions.

- Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
as Draft Standard.

- Progress BGP Extended Communities along standards track.

- Extend BGP to support a 4-byte AS number, develop plan for
transitioning to usage of 4-byte AS numbers. Advance support for a
4-byte AS numbers along standards track.

- Produce BGP MIB v2 that includes support for AS Confederations,
Route Reflection, Communities, Multi-Protocol BGP, BGP Extended
Communities, support for 4-byte AS numbers.

- Progress along the IETF standards track a BGP-based mechanism
that allows a BGP speaker to send to its BGP peer a set of route
filters that the peer would use to constrain/filter its outbound
routing updates to the speaker. Currently defined in

- Progress along standards track an Outbound Router Filter (ORF)
type for BGP, that can be used to perform aspath based route
filtering. The ORF-type will support aspath based route filtering
as well as regular expression based matching for address groups.
Currently defined in draft-ietf-idr-aspath-orf-00.txt.

- Progress a BGP Graceful Restart mechanism along standards track.

- Progress Subcodes for BGP Cease Notification Message along

- Progress AS-wide Unique BGP Identifier for BGP-4 along standards

- Progress Dynamic Capability for BGP-4 along standards track.

Tasks for this working group are limited to those listed above;
new items to be added to the charter must be approved by the IESG.

Goals and 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
Mar 04  Submit BGP MIB v2 to IESG as a Proposed Standard
Done  Submit Extended Communities draft to IESG as a Proposed Standard
Done  Submit BGP Graceful Restart to IESG as a Proposed Standard
Done  Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard
May 04  Submit 4-byte AS ID to IESG as a Proposed Standard
May 04  Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as a Proposed Standard
May 04  Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard
May 04  Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard
Done  Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard


  • draft-ietf-idr-bgp4-26.txt
  • draft-ietf-idr-bgp4-mib-15.txt
  • draft-ietf-idr-restart-10.txt
  • draft-ietf-idr-bgp-ext-communities-07.txt
  • draft-ietf-idr-dynamic-cap-06.txt
  • draft-ietf-idr-cease-subcode-05.txt
  • draft-ietf-idr-rfc2858bis-06.txt
  • draft-ietf-idr-bgp-identifier-04.txt
  • draft-ietf-idr-bgp-analysis-06.txt
  • draft-ietf-idr-bgp-vuln-01.txt
  • draft-ietf-idr-bgp4-experience-protocol-05.txt
  • draft-ietf-idr-rfc3065bis-02.txt
  • draft-ietf-idr-bgp-mibagent-survey-01.txt
  • draft-ietf-idr-bgp-implementation-01.txt
  • draft-ietf-idr-rfc2796bis-01.txt
  • draft-ietf-idr-bgp-multisession-00.txt
  • draft-ietf-idr-avoid-transition-00.txt
  • draft-ietf-idr-bgp-prefix-orf-00.txt

    Request For Comments:

    RFC1105 E Border Gateway Protocol BGP
    RFC1163 H A Border Gateway Protocol (BGP)
    RFC1164 H Application of the Border Gateway Protocol in the Internet
    RFC1265 I BGP Protocol Analysis
    RFC1266 I Experience with the BGP Protocol
    RFC1267 H A Border Gateway Protocol 3 (BGP-3)
    RFC1268 H Application of the Border Gateway Protocol in the Internet
    RFC1269 PS Definitions of Managed Objects for the Border Gateway Protocol (Version 3)
    RFC1364 PS BGP OSPF Interaction
    RFC1397 PS Default Route Advertisement In BGP2 And BGP3 Versions Of The Border Gateway Protocol
    RFC1403 PS BGP OSPF Interaction
    RFC1654 PS A Border Gateway Protocol 4 (BGP-4)
    RFC1655 PS Application of the Border Gateway Protocol in the Internet
    RFC1656 I BGP-4 Protocol Document Roadmap and Implementation Experience
    RFC1657 DS Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2
    RFC1745 PS BGP4/IDRP for IP---OSPF Interaction
    RFC1771 DS A Border Gateway Protocol 4 (BGP-4)
    RFC1773 I Experience with the BGP-4 protocol
    RFC1774 I BGP-4 Protocol Analysis
    RFC1863 E A BGP/IDRP Route Server alternative to a full mesh routing
    RFC1930 BCP Guidelines for creation, selection, and registration of an Autonomous System (AS)
    RFC1965 E Autonomous System Confederations for BGP
    RFC1966 E BGP Route Reflection An alternative to full mesh IBGP
    RFC1997 PS BGP Communities Attribute
    RFC1998 I An Application of the BGP Community Attribute in Multi-home Routing
    RFC2270 I Using a Dedicated AS for Sites Homed to a Single Provider
    RFC2283 PS Multiprotocol Extensions for BGP-4
    RFC2385 PS Protection of BGP Sessions via the TCP MD5 Signature Option
    RFC2439 PS BGP Route Flap Damping
    RFC2519 I A Framework for Inter-Domain Route Aggregation
    RFC2545 PS Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
    RFC2796 PS BGP Route Reflection An alternative to full mesh IBGP
    RFC2842 Standard Capabilities Advertisement with BGP-4
    RFC2858 PS Multiprotocol Extensions for BGP-4
    RFC2918 PS Route Refresh Capability for BGP-4
    RFC3065 PS Autonomous System Confederations for BGP
    RFC3345 I Border Gateway Protocol (BGP) Persistent Route Oscillation Condition
    RFC3392 DS Capabilities Advertisement with BGP-4
    RFC3562 I Security Requirements for Keys used with the TCP MD5 Signature Option

    Current Meeting Report


    Sue Hares and Yakov Rekhter co-chaired the meeting. Yakov issued an initial OPEN, but a transmission failure of the microphone system caused his transport entity to time out. He retransmitted the OPEN and successfully peered with the attendees.

    Old Business

    Sue reviewed the status of the core BGP documents under revision:

    - Border Gateway Protocol 4 (BGP-4)
    - Definitions of Managed Objects for the Fourth Version of
    Border Gateway Protocol (BGP-4)
    - BGP-4 Protocol Analysis
    - BGP Security Vulnerabilities Analysis
    - Experience with the BGP-4 Protocol
    - BGP MIB V1 implementation survey
    - BGP 4 Implementation Report

    There is no new internal WG progress or action required; these are awaiting IESG review.

    Also in the approval process are Graceful Restart and Extended Communities, both as Proposed Standards, and Cease Subcodes, to be a Draft Standard.

    The IESG is waiting for an implementation report on confederations.

    There was nothing to report on cooperative route filtering, 4-octet AS numbers, AS-based ORF, MIB 2, and AS-wide identifiers.

    New Business
    Equal Cost Multipath (Manav Bhatia, Joel Halpern)

    This was a working report on differences, not a final. The problem that the ECMP proposal intends to solve is defining a mechanism by which an implementation that installs equal cost multipath routes, but only advertises one route, can readvertise the multiple routes without breaking policies. Its basic approach is to create synthetic AS-SETS in the readvertisements.

    Potential benefits of the technique include avoiding certain cases of route reflector oscillation. The technique is consistent with multiprotocol extensions, using the AFI/SAFI relevant to the routes it is advertising: conventional IPv4 or VPN. It is not intended for load splitting across different AS.

    The consensus was that not enough WG members had read it for consensus.

    IPv6 over IPv4 MPLS (Francis LeFaucheur, presenter)
    The draft presents a technique, which will be coordinated with V6OPS through the ADs, for providing IPv6 service over an existing IPv4 MPLS cloud, without the cloud needing to be V6-aware. The proposed solution is intended to require no protocll extensions (see draft-ietf-l3vpn-bgp-ipv6). It carris labels in MP-BGP. The requiriemens are stated in


    Draft 04 is underway, and will clarify some MUST/SHOULD terminology, expand on the inter-AS cases, and add additional detail on security. Publication of this specification will involve coordinated documents between V6OPS and IDR, consistent where possible and different where necessary. For example, the V6OPS document will carry label SAFI/AFI while the IDR document will carry VPN SAFI/AFI.

    After the editorial changes are complete, the document will go out for last call and implementation survey.

    AS Edge Confederations (Sue Hares)
    This was a discussion item; the I-D did not make the cutoff. The technique described is a method for using dynamic capabilities at the edge of AS confederations, with the confederation-AS typically in a ring topology. The example was given of a confederation of satellite-based confederation AS being accessed by an earth station. While the technique both is ad hoc and involves mobility, it is different in applicability from MANET and mobile IP, since its quantum of mobility is the AS, not either subnet or host.

    This would typically be used in a low-bandwidth applkication where the edge (i.e., non-confederation) AS lose connectivity with one AS in the ring, but transfer connectivity to a differfent confederation-AS, using dynamic capabilities exchange. As operational requirements dictate, the non-confederation AS might switch back to the original upstream AS. Additional security may be required for this application.

    Discussion followed.

    John Scudder (): If you expect this change, why wait for dynamic capabilities? Why not configure immediately?

    Sue: We don't want to drop the associated peers

    Peter Lothberg: Why not use an IGP? Sue answered that an IGP gives insufficient policy control.

    John Scudder: Pointed out that you cannot nest confederations, limitiing applicability. Sue reitierated this is neither MANET nor mobile IP.

    Chandra -- is confederation AS too small a level of granularity? He asked why there could be additional security requirements, and Sue pointed out that TCP neither encrypts nor authenticates, and regular BGP security may be insufficient for some tactical applications.

    Peter Lothberg: Is the policy for inter-AS links, AS, or AS confederation? WHat is the requirement? Sue replied the policy was for the confederation.

    Russ White: Suggested avoided the security cookie. He felt it might be too ad hoc, and a general solution would be better.

    John Scudder: agrees ad hoc may not be desirable -- worried about cloned AS.

    Parantep (MCI): "neither confirm or deny IGP is aware", agreed to by Sue. Application may involve multiple IGP.

    Peter Lothberg: Asked Sue to confirm this proposal is to solve a real problem, not just to demonstrate what could be done.


    Sue suggested there be WG list discussion of updates.


    Advertising Equal Cost Multi-Path (ECMP) Routes in BGP
    draft-ck-bgp-atm- nlri-00.txt
    Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)
    AS Confederations Edge
    IDR WG Document Status Update