Last Modified: 2004-01-22
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.
|Done||Submit to BGP Capability Advertisement to the IESG|
|Jan 04||Submit BGP Security Vulnerabilities Analysis to IESG as an Informational|
|Jan 04||Submit BGP4 MIB to IESG as a Proposed Standard|
|Jan 04||Submit BGP4 document to IESG as a Draft Standard|
|Mar 04||Submit BGP Graceful Restart to IESG as a Proposed Standard|
|Mar 04||Submit Extended Communities draft to IESG as a Proposed Standard|
|Mar 04||Submit BGP MIB v2 to IESG as a Proposed Standard|
|Mar 04||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 Subcodes for BGP Cease Notification Message 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|
|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|
|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|
|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|
|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|
Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 ================================== CHAIRS: Sue Hares (firstname.lastname@example.org) Yakov Rekhter (email@example.com) AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases? Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistancy issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current edployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behaviour. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implimentation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistant throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behaviour is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI  and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation? bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the the base specification, we will be opening the charter. This section of the meeting will discuss what items will be added to the charter.