Last Modified: 2004-07-01
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 | |
| 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 | |
| Mar 04 | Submit BGP Graceful Restart 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 | |
| Done | Submit Extended Communities draft to IESG as a Proposed 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 |
| RFC | Status | Title |
|---|---|---|
| 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 |
|
IDR WG minutes.
Monday, August 2 at 1300-1500 ============================= CHAIRS: Susan Hares <skh@nexthop.com> Yakov Rekhter <yakov@juniper.net> SCRIBES: Ignas Bagdonas <Ignas.Bagdonas@sc.vu.lt> John Scudder <jgs@cisco.com> David Ward <dward@cisco.com> See proceedings (http://www.ietf.org/proceedings/04aug/index.html) for presentation slides. - ---- Document Status Update (5 mins) S. Hares, Y. Rekhter Presenter: Yakov Four new work items accepted since last IETF, good consensus. Other items proposed, not sufficient consensus, not accepted as WG items. IESG review of BGP base spec package is done, comments incorporated (BGP-4, MIB, etc). Will issue further revisions as needed. Submitted 6 docs to IESG to advance since last IETF (GR, extcomm, etc) Confeds -- need to be updated with comments from last call, need implementation report -- once done, to IESG. No new progress until >= 2 impls: - - ORF - - 4-octet ASN - - AS path ORF - - MIB - - AS wide unique identifier Questions/Comments: Susan Harris: Just to clarify - which document was reclassified to historic? Yakov: RFC 1863. - ---- Dynamic Capability for BGP-4 (10 mins) draft-ietf-idr-dynamic-cap-05.txt Enke Chen, Srihari R. Sangli Presenter: Enke Additions to support capabilities which affect Update encoding: - - Ack request - - Ack - - Sequence number What capabilities need ack? - - 4-byte AS - - Multipath - - Address Family (probably) Ack is optional so need not be used for capabilities that don't require it. Unfortunately ack is not backward compatible. Want to reuse current code point (fine if little/no deployment w/ prev spec version) or get ew code point? Questions/Comments: Yakov: Get a new code point, we have hundreds of 'em, no need to economize. Martin Djernaes: Why not increase capability number space to 16 bits, also length to 16 bits? Chandra Appanna: Agreed, increase sizes. Chandra: What impact on the state machine? Enke: Little or none, session is already established. Chandra: Really? What about when you send a capability which changes something you negotiated at OPEN time? Tony Li: Reserve one value "for future extensions" Enke: Does anyone really need more length than 255? Many: Yes. (Out of time, move to mailing list) - ---- Advertisement of the Group Best Paths in BGP (15 mins) draft-chen-bgp-group-path-update-01.txt E. Chen, N. Chen Presenter: Enke Why? Persistent oscillation issues -- RR or confederation. Observations: - - Full mesh is free of oscillations - - Route selection groups paths based on neighbor AS. Two approaches: - - Advertise group-best (i.e. best path from each neighbor AS) -- eliminates MED oscillation, still vulnerable to topology-based issues, still reduces info vs. full mesh. Paths adv'd == number of neighbor ASes. Topology issues means that IGP constraints still apply -- intra-cluster links must have smaller metrics than inter-cluster links. - - Advertise group multi-path -- adv all paths that survive MED comparison -- effectively makes RR advertisements independent of IGP metrics. However, virtually as much state as full mesh. Suggestions: accept MED, reduces number of routes that survive MED step ==> fewer routes advertised. Encoding: - - must be changed (pfx, neighbor_as) for group-best, (pfx, originator_id) for group-multipath - - no encoding change for reachable routes (because neighbor_as, orig_id already in update) - - need new encoding for w/draw - - therefore need new capability to indicate ability to parse new w/draw and all, also advertises which mode to be used (best only, group best, multi) Implementation/deployment: - - only RR/confed BR need to advertise multiple paths - - non-RR need only to Rx, not Tx -- Rx is easy recommendation: - - Use group-best, incremental deployment. group-multi solves more problems but too many paths Questions/Comments: Pedro Marques: We could use the route server doc we just moved to historical for this instead of using this encoding. One reason I would like to use a new path attribute is because some non RR might like to do this, in which case originator ID won't work. Since there's no backward compatibility anyway, why try to reuse existing semantics? Enke: I think Orig_ID is a good fit. Yakov: Neighbor AS hack won't work with AS set. Enke: When advertising, you must create AS sequence, this is in base specification. John Scudder: I agree w/ Pedro. If defining a capability, then use a new encoding. Most important contribution of this draft is not encoding, what is most important is ruleset of what to advert and when. Enke: <missed comment> Yakov: There is little value to send the same information in the same message twice. Pedro: What about non-RR? You have to have the exit point (external box) to be able to do this. The originator_id only works for RR server. John: If define a way to solve multi-path in BGP, please solve the general case and not just the oscillation case. Enke: There are a lot of issues if we generalize and I don't know any examples. (Out of time, move to mailing list) - ---- Graceful Shutdown of BGP Sessions (15 mins) draft-dubois-bgp-planned-maintenance-00.txt N. Dubois, B. Decraene, B. Fondeviole Presenter: Nicolas Why? - - Want no packet loss during maintenance - - Current is break paths and then inform peers - - Want make-before-break NOTE: not always useful for single IBGP session Observed behavior: - - in small network test, router shutdown goes from 20s traffic loss to 0s - - w/ 100k routes 20ms loss vs 4 sec loss - - timer should be between 30 and 60s draft was too conservative w/ 300s Questions/Comments: Tony Li: What happens if the router undergoing maintenance simply withdraws in an orderly fashion Nicolas: Yes, that is exactly what the draft proposes John Scudder: No changes to BGP? Can you do this with a route map? Nicolas: No changes to BGP state machine. Can be done w/ route-map -- did that for testing. But, too hard for ops people. - ---- Group Cooperative Route Filtering Capability for BGP-4 (10 mins) draft-muley-hares-idr-orf-order-00.txt Praveen Muley, Susan Hares, Keyur Patel Presenter: Sue Problem: There is a whole bunch of ORF types, may not have efficient policy together. Multiple policies but no grouping. Solution: Apply in order by putting a Group_id wrapper Process: Add group apply in grouping order Uses: VPN policies Global routing Questions/Comments: Enke Chen: Using this approach you can apply one policy before some other. Sue: This is to group them - ORF type or entry based Enke: Now tied to type and group as structure vs type and entry Enke: What does this accomplish? This is a location implementation problem. Currently you decide what order to send them in. Sue: Different ordering than base spec defines. Enke: Type based or entry based? If you have prefix and AS_PATH list, can you group them together? Sue Hares: Yes. Enke Chen: What is grouping granularity? Sue Hares: Any is possible. Enke: I'm still confused about what it accomplishes. Local implementation will do ordering anyway. I don't know what else it does. Is there anything? Sue: Gives a different ordering. <more discussion not captured> Enke: I need to read it and then we can discuss further. Pedro Marques: What difference does it make which I apply first? The only action is to accept therefore, what does the ordering matter? A&&B == B&&A. Sue: Efficiency of statement of process, some ORFs have permit/deny which gets you to an AND Pedro: I don't think so. Chandra Appanna: Who are you trying to define 'efficiency' for? Sender or receiver? How do you guarantee what is efficient for receiver? Sue: The one doing the filtering Chandra: How can the guy advertising it, know what's efficient for the guy on the other end? Sue: Getting back to Pedro's example, with permit and deny ordering matters. Pedro: No. Chandra: Why scramble the order? Enke: If we're talking about efficiency, this is an implementation detail -- each implementation may want to optimize itself differently. Not sure this needs to be standardized. Sue: Thanks for your feedback. Praveen (co-author): order matters per VPN: ext comm/AS w/in VPN. Pedro: Please send a detailed example to the mailing list. Praveen: OK Jeff Haas: The ORFs we have today are very coarse (AND) ... instead add sequencing and AND them together John Scudder: If you are trying to build route-map semantics the draft doesn't express it clearly. Missed OR'ing, AND'ing instead focused on 'efficiency' Sue: We can update it. Chandra Appanna: If all policy is ANDed there's no issue. Pedro: With your encoding, the ordering w/in a group is now independent but, between groups you are still left w/ the AND'ing problem. Sue: Sequence DOES matter. (Out of time, move to mailing list) - ---- Carrying ATM reachability information in BGP (15 mins) draft-ck-bgp-atm-nlri-00.txt Chaitanya Kodeboyina, Chris Metz, Peter Busschbach Presenter: CK Want to make MPLS network transparent to STM routing/signalling. - - PNNI tunneling through MPLS doesn't scale - - Instead do something almost exactly like 2547 but for PNNI - - Why BGP? Same reasons as for 2547 -- Solves adjacency problem, fits existing carrier infrastructure, can use RR, solves interdomain problem. - - "We use BGP to carry everything else so why not ATM reachability information?" Solution: BGP carries ATM info, passes to ATM route selector(ATM topo db) and signaled to/from PNNI Define new AF/SAF Use Route Distinguishers between ATM switches in different domains New extcomm values: ATM admin weight (~= PNNI metric) Use RT to manage independent ATM networks over single core Note, also presented to L2VPN WG Questions/Comments: Yakov: whole proposal is really L2VPN, only peripherally IDR WG. Should wait to see if L2VPN accepts, then if accepted look at it in IDR MDT SAFI and Connector Attribute (10 mins) draft-nalawade-idr-mdt-safi-01.txt Gargi Nalawade, Arjun Sreekantiah Presenter: Gargi Two proposals -- MDT SAFI, Connector attribute. Could be split to two documents as needed. Problem: Multicast VPNs is incongruent w/ unicast topology <see rosen-mcast-vpn-07.txt> What is a Multicast Domain? set of PE routers connected by a mcast tunnel MD per mcast-enabled VPN a default MDT (multicast distribution tree) connects all PEs Autodiscovery: MDT setup by PIM-SM, Bidir PIM or PIM SSM For SSM each PE needs to know the src addr of each of the other PEs in the same MD Therefore need autodisc of src addr of each of PEs in the same MD Therefore use new MDT SAFI RD - assigned to one mcast domain IPaddr - dest addr (PE) MDT - addr of given MD RTs in the ext comm attr and/or the RD used to associate w/ the correct VRF Why connector attr? If use NHself then originating PE is overridden Need original original NH of VPNv4 update to find which tunnel to use Called Connector because it connects a VPNv4 prefix's update w/ the MDT safi. (Suggestions for better name solicited.) Indicates the correlation and depnd between the 2 safi's and/or carries NGH value by an originating BGP speaker More discussion @ L3VPN WG Questions/Comments: Yakov: Part of a larger work that is in L3VPN WG (mcast 2547) but, BGP specific part depends on whole solution by L3VPN WG. Therefore, don't spend time talking about this work but, the L3VPN WG. (Didn't get name, from Cisco): If other WG accepts pkg, does that mean IDR is supposed to accept it? Yakov: no, it means if other WG doesn't accept it, there's no point in us even spending time Alex: I agree with Yakov unless you (IDR) see a showstopper in this proposal Yakov: well it's not broken so don't worry about that Yakov: please hold other questions until after Rahul's talk - ---- Preserving BGP Next-Hops (10 mins) draft-raggarwa-bgp-nexthop-rewrite-00.txt Rahul Aggarwal, Chaitanya Kodeboyina Presenter: Rahul Applications: - - MVPN 2547 inter-AS option B - - Others possible BGP NH of unicast routes are rewritten in option B... PIM RPF fails Address of multicast source must be preserved Solution: Preserve original Next Hop Carried as optional/transitive attribute Address family inferred from length of attribute Compared to "Connector": - - Connector doesn't have well-defined semantics (inferred from AFI/SAFI) - - This attribute has specific semantics Questions/Comments (for previous two presentations): Gargi: disagree w/ statement that connector semantics are not well-defined. it is just a matter of listing out other uses. Also, not just bit-bucket but, types define what is to be carried Pedro Marques: MDT safi - on one slide the RD can identify the VRF, or the RT can identify the VRF: can have more than one RD per VPN. The RT model is always used to leak between VPN. Please stick to using just RT. Gargi: OK. Yakov: Then RT model will be consistent for unicast Gargi: We can talk. John Scudder: To Rahul ... were you serious about inferring the AF/SAF from length of attr? ... there may be other AF in the future (ATM, IPV9) in which you cannot infer Rahul: Not solving hypothetical problems..... Yakov: What happens when something has the wrong length. The semantics of the value are directly stated as type V6 and length is 128 bits Eric Rosen: I don't see that semantics is undefined here. The two proposals appear to be just about the same. Any claims for lack of definition are by further type setting. The BGP NH or connector attr must be able to specify. The issue is only if you think that you don't need MDT attr. Rahul: difference comes down to non-congruent topologies, we should discuss that in L3VPN WG Eric: The incongruent topology is to have MDT and BGP NH/connector attr. Otherwise, these drafts are extremely close. Someone from Cisco: There are implementations out there that don't use BGP NH for VPN addresses. Therefore, we have to specify this. Eric Rosen: if we work out non-congruent stuff in L3VPN, shoudn't these converge? Rahul: quite likely Yakov: who control the type space for MDT/connector? Gargi: IANA or IDR Yakov: IDR doesn't control type space Everyone: IANA Someone from Alcatel: Don't need RD ... only need group mcast addr as global unicast addr must be local IP addr. Gargi: Think of it like an VPN NRLI (MDT in this case like a label) .... kept RD to understand one NLRI from the other. Allows addr overlap. Yakov: is the combination of ip addr (loopback) and group addr globally unique? Gargi: not necessarily, could be shared by number of PEs. Why RD is there? Look at L3VPN proposal: join to the group from another signaling manner Yakov: When won't it? Gargi: (Something about two PE's having the same loopback address) Yakov: In that case unicast wouldn't work. Gargi: OK then the PE addrs must be unique. Yakov: Well then is the combination unique? Gargi: Yes. Yakov: Well that was the other guy's point. Enke Chen: here is another application - eliminating route oscillation: make it TLV based so can include multiple original nexthops and also carry AF/SAF. I agree with John about AF/SAF. Enke: Also you can carry ASN with nexthop, carry multiple. Rahul: Very interesting. CK: draft actually says that orig_NH has same type as the normal NH type, it's not implied by length at all Pedro (to Enke): Just because the encoding is convenient doesn't mean it's OK -- still have same amount of scaling issues from carrying extra data. Enke: I don't care about encoding efficiency, it's to let MED be derived from orig NH while still allowing RR to rewrite NH. Rahul: I have another application for it but I haven't thought it out well yet. Someone from Juniper: Type of original NH is not from length but, apply the rule that is used to derive from the NRLI that is passed Eric Rosen: There is no rule that NH passed is same AF/SAF as NRLI. Therefore, cannot rely on the packet type to derive the NH. CK: deriving AFI and SAFI of nexthop is hard, but that's independent of this draft. Yakov : we are in the weeds of details that should be in L3VPN WG Someone from Cisco: Question to chairs, isn't one draft a subset of the other? can the chairs suggest a way to resolve this? Yakov: we aren't going to progress any of them until we have guidance from L3VPN. Rahul: I don't agree the one is a subset of the other. Sue: We're not doing anything until L3VPN does something. Bill Fenner: specific problem or generalizing to something bigger? It's a continuum. Sue: Thank you. - ---- Wrap up: Sue: We are requested to review MPLS BGP GR and private LAN service doc. I need reviewers to volunteer. You need to read doc, see if it fits with existing IDR practice/implementation. |