© 2010 Cisco and/or its affiliates. All rights reserved. Cisco ......3 Outbound Route Filtering RFC 5291 4 Multiple Routes to Destination RFC 3107 5 Extended Next Hop Encoding RFC

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2 © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2 © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2 Cisco Confidential 2 © 2010 Cisco and/or its affiliates. All rights reserved.

Josef Ungerman

Consulting SE, CCIE#6167


•  Technical Activities Update IETF Summary

•  Fast Convergence IP Fast Reroute (FRR) BGP Protocol Independent Convergence (PIC) BGP Add-Paths

•  New Protocols SIDR MPLS-TP TRILL

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential Presentation_ID 4

“The mission of the IETF is make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.”

H. Alvestrand RFC 3935 A Mission Statement for the IETF October 2004 http://www.ietf.org/rfc/rfc3935.txt

IP Networks

their network.


The IETF is organized into 8 areas:

General (chaired by the IETF Chair)

Applications

Internet

Operations and Management

Real-time Applications and Infrastructure

Routing

Security

Transport

...for a total of more than 125 working groups!!


•  Routing Area bfd Bidirectional Forwarding Detection idr Inter-Domain Routing isis IS-IS for IP Internets ospf Open Shortest Path First IGP pim Protocol Independent Multicast rtgwg Routing Area Working Group l2vpn Layer 2 Virtual Private Networks l3vpn Layer 3 Virtual Private Networks mpls Multiprotocol Label Switching pwe3 Pseudowire Emulation Edge to Edge sidr Secure Inter-Domain Routing vrrp Virtual Router Redundancy Protocol

•  Internet Area lisp Locator/ID Separation Protocol (Internet Area) savi Source Address Validation Improvements softwire Softwires (like 6rd, 4rd) trill Transparent Interconnection of Lots of Links (Internet Area)


•  In general, routing protocols are mature. Networks serve mission critical roles.

•  Convergence, Availability and Scalability Enhancements to routing protocols are now incremental and look to enhance Convergence, Availability and Scalability.

BFD, IP FRR, Loop Free Convergence, BGP PIC BGP Optional Attribute Error Handling and Advisory Message, BGP Bestpath Selection Criteria, BGP Graceful Shutdown BGP ADD_PATH, Virtual Aggregation, EIGRP DMVPN Scalability LISP – Internet routing hierarchy, scalability, geo independence

•  Security The network infrastructure’s security is being enhanced.

SIDR Origin Validation OSPFv2, IS-IS and EIGRP Authentication Keying and Authentication for Routing Protocols (KARP) WG


•  Reuse of Routing Technology Reliable delivery of information to any node in the network, and the ability to calculate loop free paths is now being applied to solve non-traditional problems. Layer 2 Routing IS-IS L2 Extensions, TRILL, OTV

Service Discovery and Distribution BGP flow-spec, bmp, OSPF Transport Instance, Advertising Generic Information in IS-IS, Proximity and Service Advertisement Framework

•  Evolution of MPLS technologies MPLS-TP (Transport Profile) MPLS-TP OAM (inc. BFD for LSP)


LFA (Loop-Free Alternate) Fast Reroute aka. IPFRR (IP Fast Reroute)


Edge POP (Intra-POP)

Core (Inter-POP)

Classical convergence Few min. Few 10 sec.

Fast Convergence


•  LSP/LSA generation is optimized

•  Flooding & passing is optimized

•  Support of incremental SPT and optimized for full SPT.

•  Prefix Prioritization Priority 1: IPTV sources Priority 2: High BGP next hop Priority 3: Other BGP next hop Priority 4: No customer traffic


•  A natural extension to ISIS or OSPF FC behavior Boosts ISIS convergence -


S F

R1

D

Primary Path Backup Path

Route D (L:55) P NH: F, L: 33 B NH: R1, L: 66

R2

20

Route D (L:33) NH: F, L: 22

Route D (L:66) NH: F, L: 22

Route D (L:22) NH: D, L: pop


S F

R1

D

Route D P NH: F, L22 B NH: no LFA

Route D NH: S R2

20

Route D NH: R3

R3

20

10 10

10

BRKIPM-3000 (Advanced LFA - a simple protection technique for IP/MPLS networks )


•  IGP FC: a fast IGP is one of the main building block for any FC deployments.

•  LFA FRR: is a intra POP natural extension for IGP FC.

•  MPLS TE FRR: is a inter POP natural extension for IGP FC.

PoP

PoP

PoP

PoP

PE

P

P

PoP


BGP PIC Prefix Independent Convergence


VPN 1 site B x.x.x.x/y

RD 1:1 RD 2:1

RD 3:1

RR1 RR2

RR4 RR3

PE1 PE2

PE3

CE2 CE1

VPN 1 site A

1.  link PE2-CE2 fails If BGP PIC Edge implemented, then traffic

goes PE1,PE2,PE3,CE2

BGP PIC Edge



RD 1:1 RD 2:1

RD 3:1

RR1 RR2

RR4 RR3

PE1 PE2

PE3

CE2 CE1

VPN 1 site A

6.  PE1 deletes path via PE2, now going via PE3

5.  RR1 and RR3 propagate withdraws

3.  PE2 withdraws paths

4.  RR2 and RR4 propagate withdraws

1.  link PE2-CE2 fails If BGP PIC Edge implemented, then traffic

goes PE1,PE2,PE3,CE2

2. Fast External Fallover scans BGP table, calculating new bestpaths



RD 1:1 RD 2:1

RD 3:1

RR1 RR2

RR4 RR3

PE1 PE2

PE3

CE2 CE1

VPN 1 site A

3.  PE1 withdraws paths If BGP PIC Edge implemented, then

traffic goes PE1,PE3,CE2

1.  link PE2 fails

2. The IGP does propagate the BGP NH failure


1

10

100

1000

10000

100000

10000000

5000

0

1000

00

1500

00

2000

00

2500

00

3000

00

3500

00

4000

00

4500

00

5000

00

Prefix

msec

250k PIC250k no PIC500k PIC500k no PIC


•  Initially BGP has been build to signal the best path only.

•  For Fast Convergence, BGP need to signal multipath and primary/backup path.

•  L3VPN - Use unique RD: Unique VPNv4 addresses. - If using BGP policy (MED, ...) then BGP Best External option allow to signalling the best eBGP learn path (without withdrawing it received best internal path). -  In some cases ADD-PATH option will be required


Aggregators (RRs, [confed] border routers) should advertise backup paths

backup-path-RR

PE3

RR1

Z/p

PE1

PE2 Z/p à PE2

Z/p à PE1

Z/p à PE1 Z/p à PE2

backup-path-edge

PE3

RR1

PE1 Z/p PR1

PR2 No next-hop-self

PE2

Z/p à PR1 Z/p à PR2

Additional-path


•  The following CLI will be used to configure add-path for a global address-family

•  A per-neighbor CLI will be available to turn off the add-path capability

•  interim solution is best-external

router bgp address-family additional-paths {[receive] [route-policy ]} ! neighbor 10.0.101.1 capability additional-paths {receive | advertise} [disable] ! !

Value Description Reference

0 Reserved RFC 5492

1 Multiprotocol Extensions RFC 2858

2 Route Refresh RFC 2918

3 Outbound Route Filtering RFC 5291

4 Multiple Routes to Destination RFC 3107

5 Extended Next Hop Encoding RFC 5549

64 Graceful Restart RFC 4724

65 4-octet AS number RFC 4893

69 ADD-PATH draft-ietf-idr-add-paths

BGP OPEN message – CAPABILITIES


Why SIDR?

•  eg. YouTube prefix hijack case

•  IPv4 Exhaustion – prefix trading security

•  News: Microsoft to buy IP space for millions $$

Current SIDR Work

•  Origin authentication only (AS_PATH tbd)

•  The RIRs maintain a database of all known address assignments

Route Origination Authorizations, or ROAs X.509 certificates containing the assigned AS and

a prefix block

•  Each edge (eBGP) router in the network connects to a local server (database distributed through rsync)

•  Through this, the router determines if each advertisement is valid or not

RIR

X.509 ROA

rsync

Srv

r-R

tr P

roto

col

Srv

r-R

tr P

roto

col

Srv

r-R

tr P

roto

col

Srv

r-R

tr P

roto

col


MPLS-TP Transport Profile

Cisco Confidential 26 © 2010 Cisco and/or its affiliates. All rights reserved.

Working LSP

PE PE

Protect LSP

NMS for Network Management Control *

Client node Client node

MPLS-TP LSP (Static or Dynamic) Pseudowire

Client Signal

e2e and segment OAM Section Section

*Can use dynamic control plane (G.MPLS)

Connection Oriented, pre-determined working path and protect path Transport Tunnel 1:1 or 1+1 protection, switching triggered by in-band OAM, NMS for static provisioning, optional control plane for routing and signaling

Cisco Confidential 27 © 2010 Cisco and/or its affiliates. All rights reserved.

MPLS-TP Standards Update   11 IETF RFCs published

  17 Working Group Drafts (4 in IETF editor’s Queue)

  35 Individual Drafts Active 2008

History of T-MPLS and MPLS-TP

Huawei/ALU claim T-MPLS/PTN to be standards-based MPLS-TP, misleading customers & creating market confusion

CALL TO ACTION: Effective Education of Customers   T-MPLS/PTN is NOT MPLS-TP, and is STILL DEAD, it is not standards   T-MPLS/PTN will NOT interoperate or migrate to MPLS-TP or IP/MPLS

T-MPLS/PTN is not a standard!


IP/MPLS MPLS-TP T-MPLS/PTN Data Plane

MPLS Forwarding MPLS Forwarding, with - Bi-directional LSP - No PHP as default -  No ECMP -  Label 13 for OAM

MPLS-TP like forwarding, But: -  Using Label 14 for OAM (NOT interoperable w/ MPLS)

Control Plane MPLS, Routing, TE & GMPLS

- Static provisioning - NMS -  GMPLS Control Plane

Static Only

OAM MPLS OAM Tools: - BFD (proactive) - LSP Ping (reactive) - VCCV

Extended MPLS OAM tools - New: AIS/RDI/LDI - New: Perforrmance Monitoring

Y.1731 (Ethernet ) OAM with modification - Incomplete specification (NOT consistent w/ MPLS OAM)

Recovery Routing Protocols MPLS-TE Fast Reroute

1+1, 1:1 and 1:n Path/Segment, Linear & Ring protection

Protection triggered by OAM

Based on ITU-T SONET/SDH-style Automatic Protection Switching

IP/MPLS MPLS-TP T-MPLS/PTN Compatibility with IP/MPLS YES YES NO

Compatibility with MPLS-TP YES YES NO

Easy migration to MPLS-TP or IP/MPLS YES YES NO

LTE suitable YES YES NO

Operational Impact:

Protocol Comparisons:

Cisco Confidential 29 © 2010 Cisco and/or its affiliates. All rights reserved. 29

•  A generic OAM mechanism based on PW Associated Channel (ACH)

•  Generic Alert Label allow this to be applied to existing MPLS LSPs

•  OAM Requirements described in RFC5860 Alarms – LDI, RDI, AIS, APS Proactive monitoring – BFD over LSP (eg. Cisco CPT has 3.3ms bfd hello) Reactive troubleshooting – ping/traceroute, loopback... Performance monitoring – loss, delay, jitter

L1 L2 ACH Channel Payload

0001 | Ver | Resv | Channel Type

ACH structure (RFC4385)

L1 L2 GAL/BoS Generic ACH Channel Payload

0001 | Ver | Resv | Channel Type

Generic ACH with Generic Alert Label


Multiservice Core"Aggregation" Edge" Core"Static MPLS-TP Access

IP/MPLS “Lite” Access

Ethernet Access

IP/MPLS “Lite” IP/MPLS IP/MPLS

L3 IP + Services Placement Circuit Emulation + Ethernet

Aggregation" Edge" Core"

Ethernet Access Static/Dynamic MPLS-TP IP/MPLS IP/MPLS

Static MPLS-TP Access

L3 IP + Services Placement


ACCESS / AGG. (Metro Transport)

AGGREGATION PRE-AGG. ACCESS (Mobile Backhaul)

Next Generation

MWR

ME 3800X

ME 3600X

PRIME IP NGN – NMS/OSS

CTM Support: Q1 2011

7600 ASR 9000

CPT50

CPT600

CPT200

UPD


TRILL Transparent Interconnection of Lots of Links


•  Branches of trees never interconnect (no loop!!!)

  Spanning Tree Protocol (STP) uses the same approach to build loop-free L2 logical topology

  Over-subscription ratio exacerbated by STP algorithm

11 Physical Links (or Link Bundles)

5 Logical Links (or Link Bundles)


•  Assigned switch addresses to all TRILL/FabricPath enabled switches automatically (no user configuration required)

•  Compute shortest, pair-wise paths •  Support equal-cost paths between any TRILL/FabricPath

switch pairs

Plug-N-Play L2 IS-IS is used to manage forwarding topology

L1 L2

S1 S2 S3 S4

S11 S12 S42 L2 Fabric

L3

L4

FabricPath Routing Table

Switch IF

S1 L1

S2 L2

S3 L3

S4 L4

S12 L1, L2, L3, L4

… …

S42 L1, L2, L3, L4


STP Domain TRILL/FabricPath

STP Domain 1 STP Domain 2

•  TRILL/FabricPath header is imposed by the ingress switch •  Addresses assigned to ingress and egress switches are used

to make “Routing” decision •  No MAC learning required inside the L2 Fabric

Encapsulation to creates hierarchical address scheme

A C

S11 S42

C

A

DATA

C

A

DATA

TRILL/FabricPath

Header

Ingress Switch

S11

S42

Egress Switch

S11 S42 TRILL/FabricPath Routing

L2 Bridging

A C A C

A C


•  Support more than 2 active paths (up to 16) across the Fabric •  Increase bi-sectional bandwidth beyond port-channel •  High availability with N+1 path redundancy

Forwarding decision based on ‘TRILL/FabricPath Routing Table’

A

L1 L2

S1 S2 S3 S4

S11 S12 S42 L2 Fabric

L3

L4

C

Switch IF

… …

S42 L1, L2, L3, L4

MAC IF

A 1/1

… …

C S42 1/1


•  Several ‘Trees’ are rooted in key location inside the fabric •  All Switches in L2 Fabric share the same view for each ‘Tree’ •  Multicast traffic load-balanced across these ‘Trees’

Forwarding through distinct ‘Trees’

A

L2 Fabric

C

Root for Tree #1

Root for Tree #2

Root for Tree #3

Root for Tree #4

Ingress switch for TRILL/ FabricPath decides which “tree” to be used and add tree number in the header


•  NHDA & NHSA are MAC addresses used to cross a legacy Ethernet Cloud

•  V = Version

•  R = Reserved

•  M = Multi-destination

•  Opl = Option Length

•  Hop_Count = TTL

•  Egress Nickname = ODA

•  Ingress Nickname = OSA


•  FabricPath bridges support multiple logical topologies over a single physical network, for example, by assigning different cost sets to the links

encoded Egress Bridge Nickname (ODA)

encoded Ingress Bridge Nickname (OSA) • Switch ID: Unique ID of each L2 Fabric device • Sub-Switch ID: to identify vPC+ pair (MC-LAG) • Tree ID: Unique ID of each distribution “Tree”

Tree ID = topology selector


TRILL FabricPath SPB (802.1aq ) OTV

Standard Yes (IETF, end 2010) No (Cisco pre-

standard TRILL) Yes (IEEE, end

2011) IETF

Data Plane VLAN + TRILL header VLAN-like header

(upgradable to TRILL)

MAC Learning (QinQ, MAC-in-

MAC) IP

Outer MAC swapping hop-by-hop hop-by-hop end-to-end hop-by-hop

Loop Avoidance TTL TTL, RFP RPF TTL, RPF

Control Plane ISIS ISIS ISIS ISIS, PIM

Implementation 2011? 2010 2012? 2010

IXP, Supercomputing MAN? DCI


32 Chassis

16 Chassis

16-way ECMP

8,192 10GE user ports per System 512 10GE FabricPath ports per box

256 10GE FabricPath Ports

160 Tbps System Bandwidth (8K end-user 10GE ports)

Open I/O Slots for connectivity

Spine Switch

Edge Switch 16-port Etherchannel

FabricPath

Nexus 7000 (32x TGE – F1 modules)

HPC Requirements

•  HPC Clusters require high-density of compute nodes

•  Minimal over-subscription

•  Low server to server latency

FabricPath Benefits for HPC

  FabricPath enables building a high-density fat-tree network

  Fully non-blocking with FabricPath ECMP & port-channels

  Minimize switch hops to reduce server to server latencies


Nexus 7000 or Nexus 5500

IXP Requirements   Layer 2 Peering enables multiple

providers to peer their internet routers with one another

  10GE non-blocking fabric   Scale to thousands of ports

FabricPath Benefits for IXP   Transparent Layer 2 fabric

  Scalable to thousands of ports   Bandwidth not limited by chassis /

port-channel limitations

  Simple to manage, economical to build

Provider A Provider B

Provider C Provider D


LISP Location/ID Separation Protocol


Before LISP - all this state in red circle

After LISP - this amount in red circle

A 16-bit value! 10^7 routes 10^4 routes


1.  Improve Enterprise multi-homing –  Can control egress with IGP routing –  Hard to control ingress without more

specific route injection –  Desire to be low OpEx multi-homed

(avoid complex protocols, no NAT)

2.  Improve ISP multi-homing –  Same problem for providers, can control

egress but not ingress, more specific routing only tool to circumvent BGP path selection

Provider A 10.0.0.0/8

Provider B 11.0.0.0/8

S

R1 R2

BGP


Identification (EID) used inside of sites

Locator (RLOC) used in the core



S

R1 R2

3. Decouple site addressing from provider –  Avoid renumbering when site

changes providers –  Site host and router addressing

decoupled from core topology

4. Add new addressing domains –  From possibly separate

allocation entities

5. Do 1 thru 4 and reduce the size of the core routing tables


Locator ID

Locator

.10.0.0.1

ID

2001:0102:0304:0506:1111:2222:3333:4444 IPv6:

ID & Location

209.131.36.158 IPv4:

ID & Location

Fixed ID + Changed Locator = graceful host mobility

Changing the Semantics of the IP Address •  Create a new Level of Indirection Keep ID and Location independent


Address Components:

•  EIDs or IDs = new namespace (not globally routed) End-site addrs for hosts and routers at the site (they go in DNS records)

•  RLOCs or Locators = existing namespace (globally routed) Infrastructure addrs for LISP routers and ISP routers (invisible to hosts)

Site Devices (features of CE routers):

•  ITR – Ingress Tunnel Router Receives packets from site-facing interfaces and encaps to remote LISP site or natively forwards to non-LISP site

•  ETR – Egress Tunnel Router Receives packets from core-facing interfaces and decaps to deliver to local EIDs at the site


Unicast Packet Forwarding Example



S

ITR

D ITR

ETR

ETR

Provider Y 13.0.0.0/8

Provider X 12.0.0.0/8 S1

S2

D1

D2

PI EID-prefix 1.0.0.0/8 PI EID-prefix 2.0.0.0/8

DNS entry: D.abc.com A 2.0.0.2 EID-prefix: 2.0.0.0/8

Locator-set:

12.0.0.2, priority: 1, weight: 50 (D1)

13.0.0.2, priority: 1, weight: 50 (D2)

Mapping Entry

1.0.0.1 -> 2.0.0.2

1.0.0.1 -> 2.0.0.2 11.0.0.1 -> 12.0.0.2

Legend: EIDs -> Green Locators -> Red

1.0.0.1 -> 2.0.0.2 11.0.0.1 -> 12.0.0.2

1.0.0.1 -> 2.0.0.2

12.0.0.2

13.0.0.2

10.0.0.1

11.0.0.1

Policy controlled by destination site


•  Control plane “data-triggered” mapping service Map-Request messages

–  sent from an ITR to Map-Resolver when it needs a mapping for an EID, wants to test an RLOC for reachability, or wants to refresh a mapping before TTL expiration

– Map-Resolver just decapsulates the request and forwards to ALT –  the correct Map-Server gets the request from ALT, encapsulates and sends to

the registered ETR

•  Control plane EID Registration Map-Register messages

–  sent by an ETR to a Map-Server to register its associated EID prefixes, and to specify the RLOC(s) to be used by the Map-Server when forwarding Map-Requests to the ETR

Map-Reply messages –  sent from an ETR directly to ITR in response to a valid map-request to provide

the EID/RLOC mapping and site ingress Policy for the requested EID


LISP Control Plane

ETR

12.0.0.1

ITR

11.0.0.1

Legend: EIDs -> Green Locators -> Red BGP-over-GRE Physical link

S

D


Provider X 12.0.0.0/8

PI EID-prefix 1.0.0.0/8

EID Topology



LISP Control Plane

ETR

12.0.0.1

ITR

11.0.0.1

S

D




Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2

Map-Server

Map-Resolver, Map-Server and ALT Infrastructure



ALT = Alternate Topology control-plane only (no data) ALT Advertise EID-prefixes in BGP on an alternate topology of GRE tunnels ALT-only router for aggregating other ALT peering connections (can be any router or server)


LISP Control Plane

ETR

12.0.0.1

ITR

11.0.0.1

S

D




Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2

Map-Server

(1) 12.0.0.1 -> 66.2.2.2

LISP Map-Register (in AH)

(2) 2.0.0.0/8

(3) 2.0.0.0/8

[1] Map-Server Registration



(4) 2.0.0.0/8


LISP Control Plane

ETR

12.0.0.1

ITR

11.0.0.1

S

D





Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2

Map-Server

[2] Data request Triggers Map-Request

1.0.0.1 -> 2.0.0.1 How do I get to 2.0.0.1?

11.0.0.1 -> 2.0.0.1 Map-Request

UDP 4342

11.0.0.1 -> 65.1.1.1 LISP Packet UDP 4341

(1) ?


(3) ? (2)

?

(4) ?

11.0.0.1 -> 2.0.0.1 Map-Request

UDP 4342

11.0.0.1 -> 2.0.0.1 Map-Request

UDP 4342

66.2.2.2 -> 12.0.0.1 LISP Packet UDP 4341

(5) ?


LISP Control Plane

ETR

12.0.0.1

ITR

11.0.0.1

S

D





Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2

Map-Server

[3] Map-Request Evokes Map-Reply

1.0.0.1 -> 2.0.0.1 How do I get to 2.0.0.1?

11.0.0.1 -> 2.0.0.1 Map-Request

UDP 4342

11.0.0.1 -> 65.1.1.1 LISP Packet UDP 4341

(1) ?


(3) ? (2)

?

(4) ?

11.0.0.1 -> 2.0.0.1 Map-Request

UDP 4342

11.0.0.1 -> 2.0.0.1 Map-Request

UDP 4342

66.2.2.2 -> 12.0.0.1 LISP Packet UDP 4341

(5) ?

(6) 12.0.0.1 -> 11.0.0.1

Map-Reply UDP 4342


LISP Control Plane

ETR

12.0.0.1

ITR

11.0.0.1

S

D





Map-Resolver

LISP-ALT LISP-ALT

LISP-ALT LISP-ALT

65.1.1.1

66.2.2.2

Map-Server

1.0.0.1 -> 2.0.0.1 How do I get to 2.0.0.1?

11.0.0.1 -> 2.0.0.1 Map-Request

UDP 4342

11.0.0.1 -> 65.1.1.1 LISP Packet UDP 4341

(1) ?


(3) ? (2)

?

(4) ?

11.0.0.1 -> 2.0.0.1 Map-Request

UDP 4342

11.0.0.1 -> 2.0.0.1 Map-Request

UDP 4342

66.2.2.2 -> 12.0.0.1 LISP Packet UDP 4341

(5) ?

(6) 12.0.0.1 -> 11.0.0.1

Map-Reply UDP 4342

[4] Map-Cache Populated, data packets can flow

Policy Controlled by destination

site

EID-prefix: 2.0.0.0/8 Locator-set: 12.0.0.2, priority: 1, weight: 100 (D1)

Map-Cache Entry


•  Two important Interworking cases must be supported LISP site to non-LISP site non-LISP site to LISP site

•  LISP Interworking allows LISP to be deployed incrementally

LISP NAT PTR – Proxy ITR/ETR

•  PTRs allow LISP sites to see the benefits of ingress TE “day-one”


Interworking Using PTRs

R-prefix 65.1.0.0/16

R-prefix 65.2.0.0/16

R-prefix 65.3.0.0/16

65.0.0.0/12 66.0.0.0/12

Infrastructure Solution Legend: LISP Sites -> Green (and EIDs) non-LISP Sites -> Red (and RLOCs) xTR

NR-prefix 1.2.0.0/16



66.2.2.2 65.9.2.1

PTR BGP Advertise:

1.0.0.0/8

PTR BGP Advertise:

1.0.0.0/8

PTR BGP Advertise:

1.0.0.0/8

65.9.3.1

65.9.1.1

65.1.1.1 -> 1.1.1.1 (1)

1.1.1.1 -> 65.1.1.1

Forward Na

tively

(3)

Encapsulate

65.1.1.1 -> 1.1.1.1 65.9.1.1 -> 66.1.1.1

(2)


•  Cisco-operated –  >3 years operational –  >60 sites, 10 countries

•  Built for LISP demonstration, experimentation, and proof-of-concept testing –  IPv4 and IPv6 –  PITR/PETR

•  Notable sites: –  http://www.lisp4.facebook.com, m.lisp6.facebook.com (Facebook) –  http://www.lisp4.net, http://www.lisp6.net (Univ of Oregon) –  http://lisp4.cisco.com, http://lisp6.cisco.com (Cisco)


•  Technical Activities Update IETF Summary

•  Fast Convergence IP Fast Reroute (FRR) BGP Protocol Independent Convergence (PIC) BGP Add-Paths

•  New Protocols SIDR MPLS-TP TRILL (LISP)

Thank you.

Documents

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco ......3 Outbound Route Filtering RFC 5291 4 Multiple Routes to Destination RFC 3107 5 Extended Next Hop Encoding RFC