2.5.4 Inter-Domain Routing (idr)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-01


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@nortel.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
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
Done  Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard
Oct 05  Submit BGP MIB v2 to IESG as a Proposed Standard
Oct 05  Submit 4-byte AS ID to IESG as a Proposed Standard
Oct 05  Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG as a Proposed Standard
Oct 05  Submit AS-wide Unique BGP Identifier for BGP-4 to IESG as a Proposed Standard
Oct 05  Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard


  • draft-ietf-idr-bgp4-26.txt
  • draft-ietf-idr-bgp4-mib-15.txt
  • draft-ietf-idr-route-filter-12.txt
  • draft-ietf-idr-restart-10.txt
  • draft-ietf-idr-as4bytes-10.txt
  • draft-ietf-idr-bgp-ext-communities-09.txt
  • draft-ietf-idr-aspath-orf-07.txt
  • draft-ietf-idr-bgp4-mibv2-05.txt
  • draft-ietf-idr-dynamic-cap-07.txt
  • draft-ietf-idr-cease-subcode-06.txt
  • draft-ietf-idr-rfc2858bis-06.txt
  • draft-ietf-idr-bgp-identifier-05.txt
  • draft-ietf-idr-bgp-analysis-07.txt
  • draft-ietf-idr-bgp-vuln-01.txt
  • draft-ietf-idr-bgp4-experience-protocol-05.txt
  • draft-ietf-idr-rfc3065bis-04.txt
  • draft-ietf-idr-bgp-mibagent-survey-02.txt
  • draft-ietf-idr-bgp-implementation-02.txt
  • draft-ietf-idr-rfc2796bis-01.txt
  • draft-ietf-idr-avoid-transition-02.txt
  • draft-ietf-idr-rfc1863-historic-00.txt
  • draft-ietf-idr-bgp-prefix-orf-01.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

    IDR WG Minutes 2005.08.04

    Doc status
    see ppt for info

    Danny McPherson to finish Confed implementation report in one month.

    Geoff Houston to complete the implementation report for 4-octet AS number space.

    New MIB editor see draft

    Tony Li AS Hop count Attribute

    see ppt for info
    Essence: Add TTL to each prefix, decrement at AS boundary
    Drop route when TTL hits zero
    Transitive attribute

    Alt: Distribution Lists
    List contains ASs that can rx and cannot exclusion

    NOTE: NO_EXPORT and AS_HOPCOUNT can be combined

    Geoff Houston: is NO_EXPORT dropped or continued when combined?

    NOTE: Can scope 'anycast'

    Geoff Houston: when aspath prepending, is that expressed in the HOP_COUNT?
    Tony Li: Decremented by one always

    Sue Hares: Two more ASPATHS per route? How does scaling work?
    Tony Li: In the worst case, when setting up a list you can have an arbitrary number in incl or excl list?

    Sue Hares: Is order semantics true but,

    Yakov Rekhter: An ASPATH cannot carry all AS in the internet as it would exceed the maximum size of the BGP Update message.

    Tony Li: An avg ASPATH has ~4 AS' in it so, we are going to have on avg roughly two X

    Sue Hares: Why do you say proxy usage is diffficult in Dist List case?
    TTL is lighter but, why choose between two? Might have both.

    Tony Li: From an implementors POV, it is easier to do one and not two

    Yakov Rekhter: The increase in number of AS' per route is not a practical issue

    Geoff Houston: At the edge, it may work but, topology is dense and we nee

    Jason Schiller (UUNET): Scope - useful in subconfeds ... need a separate counter?

    Tony Li: Want to see draft first. Technically what is required is a separate attribute but, look almost identical

    Geoff Houston: When comparing the two mechanisms need to look at "what is going on." Distribution lists require complete knowledge of topology. Problem is that you cannot insure that they do not leak. HOPCOUNT does not have 'knowledge' problem but, focuses on accuracy.

    Sue Hares: Inclusion requires enumeration but exclusion does not

    Geoff Houston: HOPCOUNT allows more specifics w/ a boundary.
    Advocates HOPCOUNT

    Pedro Roque: No productive compare the two. Want to select upstream provider w/ targeted ext comms. HOPCOUNT might prevent this technique. Most common TE technique; customers preferring transit AS' per prefix. Not applicable for transit exit scenario. Two issues and solutions are orthogonal but, neither solution is devalued.

    Chris Morrow (UUNET): proxy means "I can add" and/or "I can delete"

    Tony Li: Yes and not violate

    Chris Morrow: Will it get used if provider ignores or removes

    Yakov Rekhter: Who is entity that benefits from this? Which SP.

    Tony Li: Table size reduction is goal. One SP adds does the work but, gets no benefits. Altruism or hope of it is a good reason.

    Geoff Houston: Zhang drafts in GROW show that altruism is bunk instead self-interest. Most UPDATEs come from lower tier points. Most computation happens at lower level of peering .. therefore, small folks get most thrash. If "I" do this, I help my problem ... therefore altruism is there for the folks that use it and tag it.

    David Ward: Affect Hop count?

    Tony Li: Not significantly as it would be longer prefixes.

    Enke Chen: Can we inject an AS numer as 'signature' of who adds attribute?

    May be added to draft. No comments

    Zhang Renhai Entire Route Reflect

    Comments held until after Walton's draft
    see ppt for info

    Walton Add Paths
    Alvaro Retana (Cisco) presenter.
    see ppt for info

    NOTE: RFC 3107 must be updated

    Walton Oscillation Stop
    Alvaro Retana (Cisco) presenter
    info in same ppt as "Add Paths"

    George Swallow: What is frequency of oscillation?

    Alvaro Retana: dependent on update timer setting (MIN ADVERT INTERVAL)

    Combined questions for both draft authors:
    Danny (unaffiliated) - We are increasing and decreasing table size. Walton's draft is more general and flexible then Zhang's.

    Alvaro Retana: Most of increase of table size is internal to an AS (almost all)

    Zhang: I don't understand question.

    Zhang: Walton's draft is more general.

    Alvaro Retana: NLRI will be bigger but, no impact on packing.

    Gargi (Cisco): Zhang's draft - must specify that you explicitly WD when a nexthop changes or how to announce new NH? How do you delete the first NH?

    Zhang: If NH changes, just add it. To solve the problem there will taken offline to email.

    Paul Jakma: If in ECMP case, what AS sequence? How to pass multiple paths to a legacy speaker?

    Alvaro Retana: Cap advert defines who can learn add_path. Other applications like EBGP ECMP and propagating multiple paths will have to be addressed.

    Alvaro Retana: Constrained scope.

    Pedro Roque: Although you say impact of deployment is localized. We need a better understanding of what impact will be. For each route prefix, path attrs in Adj RIB Out. Generally announcement, is only when Adj-RIB-Out changes. What is expectation of propagating changes when inbound updates would cause outbound content. What are consequences? Size of Adj-RIB-Out? What is key of Adj-RIB-Out? etc.

    Alvaro Retana: Spec says send on path. Change is that we would have tracking of two or more paths.

    Yakov Rekhter: We can have as many ad hoc solutions as we want or a more general solution. We, as a group, should decide on a more general solution. We should look at potential new functionality once we have more than one path being advertised.

    Suggestion is that the authors of three proposals should find common solution to all problems that WG would like to address. A mailing list will be set up to discuss this problem and solution. On the IDR mailing list please identify problems.

    Yakov Rekhter: Do we need requirements document?

    Ward: No, absolutely not.

    Dubois PM Reqmts

    see ppt for info

    Yakov Rekhter: Send note to list on whether or not we should take as a WG doc.

    Dubois: Earlier solution was not meeting requirements and there are many possible solutions. We need a solution that fits the requirements; we are not encouraging one solution over another:

    Ted Seely (Sprint): Why not weight traffic away from peer or interface? There are other techniques that don't require change to protocol.

    Ruediger Volk: I lose traffic when I do this technique.

    Ruediger Volk: The convergence problem I see is due to the previous issue of config change.

    Jason Schiller (UUNET): Is there a hard requirement that this does not require a config change ... taken to the list.

    Hares Dynamic Confed AS

    Not requested to be WG item.
    see ppt for info

    Roque: I would assume that you would want to do restoration in a seamless way. What is motivation to make failure restoration a visible outside the confederation?

    Sue Hares: Goal is to not drop the peering session. Therefore, the purpose is policy rerouting wants to 'hang by itself.' If I drop out of the AS confed, I would have had to drop the session.

    Roque: Why not just tunnel back?

    Sue Hares: No IGP connectivity and tunnels ran into problems.
    Sue Hares: will send scenarios to list

    Chandra Appanna (Cisco): I think you need a few more failsafes. Resend is a MUST, and some mechanisms is nec. that moved did not suddenly change. Need to resend routes due to policy change potential.

    Sue Hares: We have added failsafe. We delayed resend, it would be abnormal to send all routes if nothing changed. Will send scenario in email.

    Gargi (Cisco): Are there any mechanisms in mind for NO resend if ones moves from one confed to another?

    Multisession update - Chandra Appanna

    See ppt for info

    Added flexibility for any capability code to cause/create multiple sessions

    No comments

    Kapoor SSA - Gargi, Scott Wainner

    see ppt for info

    Kapoor Tunnel SAFI

    combined w/ SSA preso, same ppt

    Gargi did technical side and changes to docs:

    more TLVs to express encap:

    MPLS, IPsec, GRE in IPsec, L2TPv3 in IPsec

    added application scenarios: MPLS over IP tunnels

    Scott presented motivations

    Combined comments:

    Sue Hares: Can you explain status of this mechanism w/in each of these groups (on referenced drafts)? What is approved, required, etc. We need to see something from those chairs that the ref'ed drafts are "blessed."

    Scott Wainner: Walked through

    Gargi: We have chicken and egg to get this done. Encoding first or formats first?

    Intro work on L3VPN list.

    Yakov Rekhter: Very reasonable model where must have both WGs review dependent docs.

    Bill Fenner: Must work w/ other WG for encoding.

    Yakov Rekhter: Two possible models - first: semantics or encoding need to be done in L3VPN; second: L2/L3VPN WGs tell us semantics and IDR produces encoding.

    Rahul Aggarwal: there were two problems in the past: 1) Motivation wasn't clear 2) Authors of draft-raggarwa-ppvpn-tunnel-encap and authors of the drafts presented at this IDR meeting were unable to come up with a joint proposal. Suggested that since motivations are clearer now, this work should be discussed again in the L3VPN WG.

    Pedro Roque: Disagree w/ motivations. IGP can provide reachability. I think you use BGP as signaling protocol which is not a problem. But, presentation states that BGP needs to know this information. Please clarify the layering split.

    Yakov Rekhter: Can this move to L3VPN

    SOLUTION: Joint Last Call in IDR and L3VPN.

    SAFI Space Partition
    In reply to Jeff Haas email on list.

    Bill Fenner to send notes on how to alloc SAFI space.

    Proposal: take private use space and turn it into reserved and perhaps 16 or so as private use. Reserved is reserved so we can decide later on FCFS or otherwise managed.

    Are folks using private space? Do we need to skip some?

    Yakov Rekhter: How long will it take to use up first come first served?

    Bill Fenner: We should be able to straighten this out quickly and IANA is keeping up. 30 days deadline.

    Danny McPherson: Needs to be uniform across all WGs and Areas. Make it IETF aligned.

    Pedro Roque: I do not want to see vendor specific space go away altogether. There is much more usage than one case alluded to. Today is only practical alternative, cannot be locked out. Can it be shown to work before we assume 30 days?

    Bill Fenner: There are publications on these agreements and promises that it will be done in 30 days. FCFS is you get it now .... no draft, no wait.

    Chandra: Cannot get rid of vendor space. AF/SAFI has lost meaning and is a way to differentiate addrs between two peers. Just need opaque space that we can use between two peers.

    Gargi: Must have vendor space perhaps reduced is ok. Second, IANA is faster but, it seems to required Routing ADs having lunch w/ IANA.

    Yakov Rekhter: IANA must have strict 30 days max as rule.

    Bill Fenner: We are working on this and the stats show that 30 days is being met.


    IDR WG Document Status Update
    The AS_HOPCOUNT Attribute
    Entire Routes Reflecting capability
    BGP Persistent Route Oscillation Solution
    Requirements for planned maintenance of BGP sessions
    Dynamic AS renumbering
    Multisession BGP
    Tunnel SAFI SSA Attribute