2.5.4 Inter-Domain Routing (idr)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-01

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/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
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
  • - draft-ietf-idr-bgp4-24.txt
  • - draft-ietf-idr-bgp4-mib-14.txt
  • - draft-ietf-idr-route-filter-10.txt
  • - draft-ietf-idr-restart-10.txt
  • - draft-ietf-idr-as4bytes-08.txt
  • - draft-ietf-idr-bgp-ext-communities-07.txt
  • - draft-ietf-idr-aspath-orf-06.txt
  • - draft-ietf-idr-dynamic-cap-05.txt
  • - draft-ietf-idr-cease-subcode-05.txt
  • - draft-ietf-idr-rfc2858bis-06.txt
  • - draft-ietf-idr-bgp-gr-survey-01.txt
  • - draft-ietf-idr-bgp-analysis-05.txt
  • - draft-ietf-idr-bgp-vuln-00.txt
  • - draft-ietf-idr-bgp4-experience-protocol-04.txt
  • - draft-ietf-idr-rfc3065bis-02.txt
  • - draft-ietf-idr-bgp-mibagent-survey-01.txt
  • - draft-ietf-idr-bgp-implementation-01.txt
  • - draft-ietf-idr-rfc2796bis-01.txt
  • - draft-ietf-idr-bgp-multisession-00.txt
  • - draft-ietf-idr-avoid-transition-00.txt
  • Request For Comments:
    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

    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
    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


    Susan Harris: Just to clarify - which document was reclassified to historic?

    Yakov: RFC 1863.

    - ----

    Dynamic Capability for BGP-4 (10 mins)
    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?


    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)
    E. Chen, N. Chen

    Presenter: Enke

    Why? Persistent oscillation issues -- RR or confederation.

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

    - - 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)

    - - only RR/confed BR need to advertise multiple paths
    - - non-RR need only to Rx, not Tx -- Rx is easy

    - - Use group-best, incremental deployment.
    group-multi solves more problems but too many paths


    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)
    N. Dubois, B. Decraene, B. Fondeviole

    Presenter: Nicolas

    - - 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


    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)
    Praveen Muley, Susan Hares, Keyur Patel

    Presenter: Sue

    There is a whole bunch of ORF types, may not have efficient policy together.
    Multiple policies but no grouping.

    Apply in order by putting a Group_id wrapper

    Add group
    apply in grouping order

    VPN policies
    Global routing


    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)
    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?"

    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


    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)
    Gargi Nalawade, Arjun Sreekantiah

    Presenter: Gargi

    Two proposals -- MDT SAFI, Connector attribute.
    Could be split to two documents as needed.

    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


    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


    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)
    Rahul Aggarwal, Chaitanya Kodeboyina

    Presenter: Rahul

    - - 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

    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.


    None received.