2.5.4 Inter-Domain Routing (idr)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-09-30

Chair(s):
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/working-groups/idr/current/
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 internets. 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 document.

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 draft-ietf-idr-route-filter-03.txt.

- 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 standards track.

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

- 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
Jan 03  Submit BGP4 document to IESG.
Jan 03  Submit updated base BGP4 MIB to IESG.
Jan 03  Submit BGP Security Vulnerabilities Analysis to IESG
Mar 03  Submit BGP Graceful Restart to IESG
Mar 03  Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG
Mar 03  Submit BGP MIB v2 to IESG
Mar 03  Submit Extended Communities draft to IESG.
May 03  Submit 4-byte AS ID to IESG
May 03  Submit Outbound Route Filter, Prefix and ASpath ORF draft to IESG
May 03  Submit Subcodes for BGP Cease Notification Message to IESG
May 03  Submit AS-wide Unique BGP Identifier for BGP-4 to IESG
May 03  Submit Dynamic Capability for BGP-4 to IESG
Internet-Drafts:
  • - draft-ietf-idr-bgp4-22.txt
  • - draft-ietf-idr-bgp4-mib-13.txt
  • - draft-ietf-idr-route-filter-09.txt
  • - draft-ietf-idr-restart-08.txt
  • - draft-ietf-idr-as4bytes-07.txt
  • - draft-ietf-idr-bgp-ext-communities-06.txt
  • - draft-ietf-idr-aspath-orf-05.txt
  • - draft-ietf-idr-dynamic-cap-04.txt
  • - draft-ietf-idr-cease-subcode-04.txt
  • - draft-ietf-idr-bgp-gr-survey-00.txt
  • - draft-ietf-idr-bgp-analysis-04.txt
  • - draft-ietf-idr-bgp-issues-01.txt
  • - draft-ietf-idr-bgp-vuln-00.txt
  • - draft-ietf-idr-bgp4-experience-protocol-03.txt
  • - draft-ietf-idr-rfc3065bis-01.txt
  • Request For Comments:
    RFCStatusTitle
    RFC1105 E Border Gateway Protocol BGP
    RFC1164 H Application of the Border Gateway Protocol in the Internet
    RFC1163 H A Border Gateway Protocol (BGP)
    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)
    RFC1266 I Experience with the BGP Protocol
    RFC1265 I BGP Protocol Analysis
    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
    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
    RFC1654 PS A Border Gateway Protocol 4 (BGP-4)
    RFC1655 PS Application of the Border Gateway Protocol in the Internet
    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
    RFC1930BCPGuidelines 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
    RFC1998 I An Application of the BGP Community Attribute in Multi-home Routing
    RFC1997 PS BGP Communities Attribute
    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
    RFC2842StandardCapabilities 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

    
    ----------------------------------------
    -------------------------
    
    
    1. IDR Documents status update
       Y. Rekhter
       =======================
       See slides
    
    
       IDR Charter Update
       Y. Rekhter
       ===========================
       See Slides
    
    
    2. draft-chavali-bgp-prefixlimit-00
       Sue Hares
       ================================
    
    
       The intent of this proposal is to provide a mechanism by which both 
    peers can become aware of a prefix limit.  If the number of prefixes 
    approaches the known limit, both peers can provide warning to their 
    respective operators, and even if the limit is reached, both devices can 
    behave in a manner to preserve network stability until the operators can 
    address the cause of the excessive prefix condition. In addition, the 
    option to terminate the session is retained in order to protect the BGP 
    receiver, if the BGP sender ignores the limit.
    
    
    
       The basic function proposed here is for a BGP receiver which 
    implements a limit on the number of prefixes which it will accept (a 
    "maximum prefix limit") to send an advertisement of that limit to its peer 
    BGP sender, at the time the peering session is initiated.  That is, a BGP 
    receiver configured with a maximum-prefix limit notifies its peer BGP 
    sender of the limit, so that the sender should automatically restrict the 
    number of prefixes it announces, in order to comply with the limit.
    
    
       Three level response:
          90% generates warning
          at 100%, BGP speaker stops sending
          at 110%, BGP listener drops session
    
    
    
    John Scudder: Three functions could support this feature now. These are: 
    remote logging, ORF, inform. You might want to collapse these 
    functions into existing proposals (ORF, inform).
    
    
    Hares: Inform is not widely deployed.
    
    
    Binam(?): I am surprised that providers do not maintain explicit import 
    policies that prevent them from accepting every route that a customer 
    might advertise.
    
    
    Hares: VPN providers may not maintain such policies. (Note that a 
    service provider is among the authors.)
    
    
    Enke Chen: Dropping after prefix limit is exceeded is a bad idea. It is 
    better to disable AFI. Current implementations only have warning and 
    action level. Draft should also have 2 levels.
    
    
    Scudder: You only need one number. A limit.
    
    
    Ash: We need this.
    
    
    Bonica: We need three numbers; warning, speaker stops sending and 
    listener drops session.
    
    
    3. draft-chen-bgp-avoid-collision-00
       Enke Chen
       ===================================
    
    
       To simplify the BGP session bringup logic, in this document we 
    propose a revision that allows a BGP speaker to play only the active or the 
    passive role in establishing a BGP connection with another BGP speaker.  A 
    BGP speaker determines whether it will play the active or passive role 
    based on the AS numbers and/or the peering addresses involved.
    
    
       Backward compatiblility required.
       Gracefull restart required.
    
    
    Yakov: According to the spec, you must send an notification if you close due 
    to collision
    
    
    Enke: All implementations don't do that
    
    
    Rajeesh Kumar: If server detects connection is gone, it has to wait for 
    client to re-establish.
    
    
    Hares: could be misconfigured?
    
    
    Enke: No, larger AS number is active
    
    
    Gargi: Proabability of connection collision first time is high.
    
    
    Hakkivori: ?????
    
    
    Jeff Pickering: problem with tie breaker using remote access. you may not 
    know your source address
    
    
    Enke: disagress
    
    
    Jeff Pickering: you don't know that peers source will be what you send
    
    
    Alex Zinin: we will have to support the old code for years
    
    
    Enke: do randomn backoff
    
    
    Alex Zinin: are you assuming that you won't have to support the old code?
    
    
    Dan Indrieden: Active passive decision should be configured, not 
    determined
    
    
    Raj: does this make a difference, since there are only a few 
    implementations of BGP
    
    
    Scudder: this is backward compatible.
    
    
    4. draft-py-idr-redisfilter-00
       Michel Py
       =========
    
    
       What this draft is:
    
    
       A mechanism to distribute filtering information. Bogon filtering is only 
    one example of filtering information. The objective is to 
    standardize the mechanism.
    
    
       Idea: re-use ORF mechanisms. The ORF specifications are not 
    modified; what is required is a syntax enhancement that is mostly a 
    matter of implementation.
    
    
    
    Scudder: 1)may be you want to publish this and do it. There isn't any new 
    protocol to standardize. 2) Have you looked at Pedro Marques flowspec 
    document? 3) Is the single server a single point of failure, target for 
    malicious attack
    
    
    5. draft-nalawade-bgp-soft-notify-00
       Gargi Nalawade, Keyur Patel, John Scudder, David Ward
       
    ======================================================
    
    
       Currently there is no mechanism available for two BGP Speakers to 
    communicate the occurrence of an error-condition other than through a BGP 
    NOTIFICATION Message. The problem is that a NOTIFICATION message resets the 
    peering session and terminates the connection. If a peer wants to 
    gracefully recover from an error or wants to warn its peer about the 
    occurrence of a BGP-related event, there is no mechanism currently 
    available to do that.
    
    
       The proposed BGP SOFT-NOTIFICATION message is a mechanism to notify a 
    remote peer of an error-condition or an event without resetting or 
    terminating the BGP session. The purpose of this message is to provide the 
    ability to soft-reset a particular AFI/SAFI without disrupting other BGP 
    AFI/SAFIs or sections.
    
    
       - New Soft noticication message and soft notification ACK
    
    
       - Inform is for logging only; soft notification can also take an 
    action
    
    
    6. draft-nalawade-bgp-update-v2-00
       Gargi Nalawade, Himanshu Shah
       ============
       The current version of the BGP UPDATE Message has evolved from its 
    original definition for IPv4 Unicast AFI/SAFI. The use of new 
    AFI/SAFIs in BGP has caused the MP_REACH and MP_UNREACH attributes to be 
    defined. But the attributes such as NEXTHOP still continued to apply only to 
    IPv4 Unicast. It is only defined to carry an IPv4 address. This has 
    forced several workarounds over the years such as carrying the Nexthop 
    corresponding to the AFI/SAFI inside the MP_REACH/MP_UNREACH 
    attribute.
    
    
       Carrying non-IPv4 NLRIs in the MP_REACH/MP_UNREACH attribute itself is a 
    workaround to the fact that the NLRI section only applies to IPv4 
    Unicast routes.
    
    
       Also, the current BGP UPDATE Message starts out as being generic such 
    that it could apply to any AFI/SAFI - until an 
    MP_REACH/MP_UNREACH section is encountered. Only then can it be decided 
    whether to use the NEXTHOP attribute or the NEXTHOP encoded in the 
    MP_REACH attribute as the applicable NEXTHOP.
    
    
       The MP_REACH/MP_UNREACH attribute needs to be successfully parsed to 
    identify the AFI/SAFI to which the UPDATE Message applies. Thus, if there is 
    an error in the section preceding the MP_REACH attribute, the whole BGP 
    session and other AFI/SAFIs running on the same saession are impacted. This 
    does not protect one AFI/SAFI from being impacted by the other 
    AFI/SAFIs on the same session - in case of AFI/SAFI specific errors that 
    make it impossible to parse the MP_REACH/ MP_UNREACH section.
    
    
    
       The proposed BGP UPDATE-v2 message proposes solving all of the 
    above-mentioned problems. BGP UPDATE-v2 will enable separation of 
    updates belonging to different AFI/SAFI and an error in attribute can be 
    isolated to a particular AFI/SAFI.
    
    
    7. draft-scudder-bgp-multisession
       John Scudder
       =============
       This specification augments "Multiprotocol Extensions for BGP-4" by 
    proposing a mechanism to allow multiple sessions to be used between a 
    given pair of BGP speakers.  Each session is used to transport routes for 
    one or more AFI/SAFI.  This provides an alternative to the current MP-BGP 
    approach of multiplexing routes for all AFI/SAFI onto a single 
    connection.
    
    
       Use of this approach is expected to increase the robustness of the BGP 
    protocol as it is used to support more and more diverse AFI/SAFI.
    
    
    
    Discussion on (5), (6), and (7).
    ================================
    
    
    Parantap: frightened by multiple afi/safis. frightened by amount of 
    change to BGP.
    
    
    Parantap: perhaps we could use reliable UDP, instead of making all these 
    changes to BGP.
    
    
    Yakov: Would you be frightened by reliable UDP ?
    
    
    Parantap: Then perhaps we could use unreliable UDP.
    
    
    Yakov: Would you be frightened to use unreliable transport for 
    delivering incremental updates ?
    
    
    Yakov: If folks are frightened by changes in BGP then we should 
    immediately stop the WG meeting, close the WG, and go to the bar. That was 
    greeted by a round of applause.
    
    
    Scudder: design goal is to minimize number of changes to BGP
    
    
    Gargi: If changing the BGP transport is thought to minimize the changes to 
    the BGP protocol, that assumption is not right. That in fact would 
    involve lot of changes to the BGP protocol, Spec & FSM.
    
    
    Rahul: please compare and contrast the drafts? 2) Would like to see 
    discussion on percieved problem with multiple loopbacks. Why not?
    
    
    Chavali: 3 comments in the soft notify draft:
       1. The Cease codes are peer event related and not AFI/SAFI 
    specific. The draft sets out to address AFI/SAFI events. Peer event 
    related codes are already handled by existing/proposed mechanisms.
       2. Each Update code causes persistent resets of AFI/SAFI per code. The 
    root cause here is that the peer's implementation code that causes bad 
    Atttributes. That needs to be fixed rather than adding more 
    processing in the protocol.
       3. Light weighted non-fatal warning mechanism per AFI/SAFI in this 
    draft would be useful.
    
    
    Acee: Too many ways to group. Do we really need all of this 
    flexibility?
    
    
    Alex: if the length field is incorrect, can you trust the next PDU?
    
    
    Yakov: if the legth field is incorrect, then Gargi's proposal results in 
    terminating BGP session for all the AFI/SAFI carried in the session, thus 
    failing to provide isolation among multiple AFI/SAFIs, and therefore 
    failing to provide isolation among different applications that use BGP. In 
    contrast, Scudder proposal does not have this problem as different 
    AFI/SAFI need not share the same BGP session.
    
    
    Andrew Lang: ????
    
    
    Enke: Passive active simplfies multiple session
    
    
    Scudder: already simple, but wouldn make it 

    Slides

    Agenda
    Peer Prefix Limits Exchange in BGP
    BGP Connection Collision Avoidance
    Redistribution of Cooperative Filtering Information
    BGP Soft-Notification
    BGP UPDATE-v2
    Multisession BGP