intra-va-01.txt -01 Draft of: “FIB Suppression with Virtual Aggregation and Default Routes” Paul Francis, Hitesh Ballani Cornell Univ Xiaohu Xu, Huawei

Outline: Changes in the -01 draft Implementation status Next steps (technical) Project status within IETF

Main 00  01 changes: BCP instead of RFC Added “Edge-suppression” mode Removed need for new attribute “Merge”, “add”, “split”, and “remove” procedures for Virtual Prefixes (VP) Edges default to core No wire protocol changes

Recall that “Virtual Aggregation” uses “Virtual Prefixes” (VP) VPs are bigger than any “real” prefix Certain routers FIB-install routes (tunnel) to all sub-prefixes in a VP

Edge Suppression (ES) Mode: Core routers FIB-install all routes Edge routers FIB-install zero or more routes, and a default route to a core ES mode allows all edge routers (not just customer edge) to have small FIBs Routes to customers, popular prefixes.... (Thanks Robert Raszuk)

Removal of new attribute In order to know which prefixes must be FIB-installed, routers need to know: Full set of VPs (Thanks Daniel Ginsburg) VPs for which they are an Aggregation Point -00 used new attribute to convey VPs -01 uses configuration

Merge-add-split-remove FIB-size management sometimes requires redefinition of VPs Must be done without service disruption or temporarily large FIB size See draft....

Implementation Status In VRP5 (Huawei Router OS) Currently GRE (no key) tunnels Huawei wants to use inter-domain tunnels to reduce stretch penalty To ASBR: routers must FIB-install routes learned from neighbor AS Need auto-config of tunnels to remove this restriction

Next Steps (technical) Define automatic configuration of GRE keys in BGP draft-ietf-softwire-encaps-safi For FIB-suppression: GRE key identifies external peer Two possible approaches: Extended attributes (Huawei engineers prefer this because reuses existing mechanism)

GRE tunnel config example: BR router with external peers R1 and R2 R1  BR: NH=R1, NLRI=1.1/16 R2  BR: NH=R2, NLRI=2.2/16 BR advertises: Update1: NH=BR, E-NLRI=BR, Key=1, NLRI=1.1/16 Update2: NH=BR, E-NLRI=BR, Key=2, NLRI=2.2/16 BR can FIB-suppress 1.1/16 and 2.2/16 Received tunneled packets with Key=1 are sent to R1 Received tunneled packets with Key=2 are sent to R2 Encapsulation NLRI Tunnel Encapsulation Attribute

Discussion.... (next steps for BCP....)

tunnel-00.txt -00 Draft of: “Tunnel Endpoints in BGP” Xiaohu Xu, Huawei Paul Francis, Cornell Univ

Inter-AS IP tunnels Motivated by stretch and latency induced by (intra-domain) VA But other benefits may exist Load balance, fast restoration... Idea is simple: Always FIB-install tunnels, avoid extra hops in ASes doing VA

Inter-AS IP tunnels This draft assumes softwire-encaps- safi In softwire draft, tunnel endpoint must be BGP nexthop We extend this across ASes Could be implemented as Extended Attributes or softwire-encaps-safi Would welcome feedback here....

softwire-encaps-safi defines the Tunnel Encapsulation Attribute Our draft adds a sub-TLV which identifies the tunnel endpoint Optional Transitive Meaning: This tunnel can be used to reach the NLRI in this UPDATE Defines tunnel parameters (GRE, L2TPv3) “Endpoint Address Sub-TLV”

Endpoint Address Sub-TLV | Address Family Identifier (2 octets) | | Reserved (1 octet) | | Length of Autonomous System Number (1 octet) | | Autonomous System Number (Variable) | | Endpoint Address (variable) | IPv4 or IPv6 (NLRI may be either type) AS Number must match origin AS Tunnel Endpoint Address

AS-path is the same whether tunnel is used or not Origin AS is origin both for route to tunnel and route to NLRI By including AS Number in attribute, we detect when this is no longer true Could happen, for instance, as a result of upstream aggregation NLRI containing tunnel address is in the same UPDATE

All routers in SP use the same tunnel endpoint address Anycasted across all routers (this optional if site hosts tunnel endpoint) Prevents error where an upstream AS aggregates NLRI, and drops one of the tunnel endpoints ASes using VA should FIB-install routes to tunnel endpoints Makes tunneled packets shortest path

What about load balance? If upstream deaggregates, only one of the resulting routes can have a working tunnel One improvement might be to make the tunnel address a CIDR block Other routes can be used, only without tunnel Upstream ASes would have to know to deaggregate the tunnel address

AS=A, 1/8, 2/8 TE= AS=BAS=C AS=D A; 1/8, 2/8; TE= ; A; 1/8, 2/8; TE= ; A,B; 1/8, 2/8; TE= ; A,C; 1/8, 2/8 ; TE= ; A,B,D; 1/8; TE= ; A,C,D; 2/8 Draft as currently written: If D prefers B for 1/8 and C for 2/8, D cannot use tunnel for packets to 2/8

AS=A, 1/8, 2/8 TE= /28 AS=BAS=C AS=D A; 1/8, 2/8; TE= /29; A; 1/8, 2/8; TE= /29; A,B; 1/8, 2/8; TE= /29; A,C; 1/8, 2/8 ; TE= /29; A,B,D; 1/8; TE= /29; A,C,D; 2/8, /29; TE= /29; With CIDR-block tunnel endpoint addresses:

AS=A, 1/8, 2/8 TE= /28 AS=BAS=C AS=D A; 1/8, 2/8; TE= /29; A; 1/8, 2/8; TE= /29; A,B; 1/8, 2/8; TE= /29; A,C; 1/8, 2/8 ; TE= /29; A,B,D; 1/8; TE= /29; A,C,D; 2/8, /29; TE= /29; With CIDR-block tunnel endpoint addresses: Note that routers in D can now individually select paths to 1/8 and 2/8 Results in finer- grained traffic engineering And fast restoration

AS=A, 1/8, 2/8 TE= /28 AS=BAS=C AS=D A; 1/8, 2/8; TE= /29; A; 1/8, 2/8; TE= /29; A,B; 1/8, 2/8; TE= /29; A,C; 1/8, 2/8 ; TE= /29; A,[B,C],D; 1/8, 2/8; TE= /28; A,[B,C],D; 1/8, 2/8; TE= /28; Use AS-set to convey this path diversity... Can aggregate tunnel (reduces churn)

AS=A, 1/8, 2/8 TE= /28 AS=BAS=C AS=D A; 1/8, 2/8; TE= /29,IAC=30; A; 1/8, 2/8; TE= /29,IAC=60; A,B; 1/8, 2/8; TE= /29,IAC=30; A,C; 1/8, 2/8 ; TE= /29,IAC=60; A,[B,C],D; 1/8, 2/8; TE= /29, IAC=30; TE= /29,IAC=60; A,[B,C],D; 1/8, 2/8; TE= /29, IAC=30; TE= /29,IAC=60; By applying Iljitsch’s IAC weights to tunnels, we can take both sending and receiving AS load balancing needs into account

Discussion....