2.6.4 Inter-Domain Routing (idr)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-20

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

Internet-Drafts:

  • 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-12.txt
  • draft-ietf-idr-bgp-ext-communities-09.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-07.txt
  • draft-ietf-idr-bgp-identifier-06.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-05.txt
  • draft-ietf-idr-bgp-mibagent-survey-02.txt
  • draft-ietf-idr-bgp-implementation-02.txt
  • draft-ietf-idr-rfc2796bis-02.txt
  • draft-ietf-idr-bgp-multisession-01.txt
  • draft-ietf-idr-avoid-transition-02.txt
  • draft-ietf-idr-bgp-prefix-orf-02.txt

    Request For Comments:

    RFCStatusTitle
    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
    RFC4223 I Reclassification of RFC 1863 to Historic

    Current Meeting Report

    IDR IETF 64
    
    Minutes taken by Larry Blunk and Dave Ward
    -------------
    0. Doc Status (Sue Hares, Yakov Rekhter)
    
    a. new draft to be reissued for 4-octet AS
    b. AS Confeds - implementation report submitted and spec will go as DS
    c. GR - post AD comments to PS
    d. RR - have IESG comments, revised draft sub. and back to editor
    e. 1863 went to historic
    f. ton of stuff on editor queue (all to be pub'ed as package vs individual
    docs)
    g. MPBGP, Cease notify at editor
    h. a lot no progress (see slides) due to lack of implementation report
    
    Enke Chen: agreed to produce implementation report for outbound route filtering
     
    
    Pekka Savola: what is status of BGP MIB v2
    Sue Hares: need two implementations
    Yakov Rekhter: no implemenation report ... no progress
    
    -------------
    1. 4-octet AS extended commmunity - Yakov Rekhter
    (no slides) 
    
    Extended community needs to be able to support 4 byte ASN ext comm
    
    Existing extended communities documnet removed text on 4 octet AS
    extended communities, as there are no implementations.
    
    New doc published for support (to not get in way of extended community
    doc)
    
    New doc produced via cut and paste protocol
    
    It is currently an individual submission
    
    Could be WG doc but, it will sit until any implementations
    
    Geoff Huston: It should be a WG draft
    
    Resulution: will send to mailing list and see if there is support
    to making it a WG document
    
    
    1A. YR request from Tony Li to make AS hop count a WG document
    sent to list and only got few replies asked room ... no concensus ... not WG
    doc yet
    
    -------------
    2. ORF groups  Sue Hares
    
    See slides  for structure of UPDATE
    
    See slides for usage scenarios
    
    Geoff Huston: You have small parts of a boolean language ... why
    not go all the way?
    
    Sue: We were told during the last two meetings that we should shrink
    back the functionality
    
    Geoff Huston: Just add groups in groups and go for full boolean
    logic
    
    We have had a lot of arguments/discussion on this topic and request
    more input.
    
    Geoff Huston: Can't determine beforehand how complex someone may
    want to get
    
    Vach Kompella: What about other operands? E.g. "Not"
    
    Need to see what you want or we are going full bore ...
    
    Enke Chen: If goal is to simplify config .. .but, ORF originally
    was not to simplify config but, to improve performance. It is unclear
    how the config is simplified.
    
    Sue Hares: It is an effort to expand power of config
    
    Kireeti Kompella: The language is not boolean complete
    
    Rudiger: The language helps the pain w/ config
    
    
    Resolution: Will take back comments about missing functionality and
    update draft and bring to WG.
    
    
    -------------
    3. Context AF - David Ward
    
    See slides
    
    Yakov: Clarification if we need to have larger work in IETF
    
    David Ward: It is not dependent on that work and can work with existing
    technology. A document will be written that associates diffserv architecture
    to this work.
    
    Sue - this looks like old IDR QOS revisited.   Dave - what's new
    is always old.  Divergent from QOS bit.  Semantic free and opaque.
    Service 42 is available but no meaning to semantics.  Sue - are you
    mixing QOS pieces?
    
    Sue - timeliness issue.  How do you ensure announcement is there
    in time.
    
    Chandra - could be useful to an application to group together
    prefix/service - don't need to go to IANA.
    
    Yakov - will you have different SAFI values for different AFI's?
    
    Dave - could negotiate to RD's are all the way down to RT's, but
    less flexible.
    
    Yakov - bigger picture does not belong in IDR, only BGP changes.
    Should the bigger picture come first ?
    
    Sue - is all you are asking for is a different AFI?   Dave - Yes.
    Add path and aggregate. withdraw would help, but not truly necessary.
    
    Sue - AD's what is process for new AFI?   Bill - it says nothing,
    would be sent to IESG which would send to back IDR.
    
    Yakov - would IESG like to see big picture?  Alex Zinin - not ready
    to answer that question, would like to see discussion on list. Dave
    - propose MAVs BOF to discuss QOS things not related to BGP. Dave
    - this is indepedent.  Alex - if working group discusses and believes
    it can be used for other technologies and there is strong support.
    Dave - I don't believe there are dependencies between outcome of
    MAVs BOF and this proposal. Alex - sounds like discussion and
    consensus is needed. Bruce Davie from Cisco - feels work does stand
    alone if you assume there is a diffserv architecture; can look at
    diffserv architecture for big picture context. Yakov - can someone
    write document about how this fits into diffserv ?  Bruce will find
    someone to do that.
    
    
    -------------
    4. Enke Chen - Extended Open Parameters
    
    See slides
    Problem ... we are running out of capability space
    
    NAME? How does it work w/ ORF
    
    Enke: It should work just fine. I don't understand.
    
    Sue - were state machine changes included?   John promised to do
    it. Needed to move forward.
    
    Enke - should this become a WG item?  Don't need it today, but could
    be important tomorrow.  Only 4 or so have read.
    
    Yakov: need more people to read before progressing. Work will not
    be done if no interest.
    
    
    -------------
    5. Chandra Appanna - Aggregate Withdraw
    
    See slides
    
    Ron Bonica - is there mechanism to ensure that you only withdraw
    routes that you announce?  Chandra - routes are only for a particular
    session.  Current draft is not transitive, but it could be so.
    
    Yakov - time-to-withdraw could be used without agg. withdraw.
    Chandra - yes.
    
    Pekka - if we are using Secure BGP or SOBGP will it require special
    processing?  Chandra - no, but haven't thought about it.
    
    Sue - how does this relate to withdraw bags of routes, not sure.
    Will take offline.
    
    Dave - with agg. withdraw you match on attributes unlike bags. Could
    be ASPATH, Origin, etc.  Chandra - designed to be general.
    
    Yakov - could mark and organize by extended communities instead.
    If you use communities, it will be easily transitive. Do we need
    the others? Dave - if it's too much flexilibility, that's okay.
    Dave - WG could determine that only communities are needed.
    
    Yakov - not clear how to propagate agg. withdraw if applied to
    things other than communities.   Will take this offline.
    
    WG needs to decide if it wants to propagate agg. withdraw.
    
    
    -------------
    6. Gargi Nalawade - Tunneling applications
    
    
    see slides
    
    Yakov: Connector attribute carries a shortand for the tunnel, not just the
    endpoint
    
    Gargi: Yes
    
    Yakov: It is even more than shortand but, a list of preferences for a set of
    tunnels
    
    Gargi: Yes, there is nothing in the draft that prevents this from happening
    
    Yakov: Most work going on in L3VPN but, IDR will oversee
    
    
    -------------
    7. Gargi Nalawade - Multicast signaling using BGP
    
    see slides
    
    No comments
    
    

    Slides

    IDR WG Document Status Update
    BGP for Interdomain Service Routing (aka Context AFI)
    BGP Aggregate Withdraw
    Extended Optional Parameters for the BGP OPEN Message
    Group Cooperative Route Filtering Capability for BGP-4
    BGP Connector Attribute
    Multicast Signaling using BGP