|RFC1105|| E ||Border Gateway Protocol BGP |
|RFC1163|| H ||A Border Gateway Protocol (BGP) |
|RFC1164|| H ||Application of the Border Gateway Protocol in the
|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
|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
|RFC1656|| I ||BGP-4 Protocol Document Roadmap and Implementation
|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
|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
|RFC2283|| PS ||Multiprotocol Extensions for BGP-4 |
|RFC2385|| PS ||Protection of BGP Sessions via the TCP MD5 Signature
|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 |
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
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
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
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
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
We have had a lot of arguments/discussion on this topic and request
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
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
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
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
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
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
Yakov: Connector attribute carries a shortand for the tunnel, not just the
Yakov: It is even more than shortand but, a list of preferences for a set of
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