1600-1630 20170929 szarkowicz fast egress protection v1

Egress Protection (draft-shen-mpls-egress-protection-framework)

Presented by Krzysztof G. Szarkowicz NANOG71

October 4, 2017

draft-shen-mpls-egress-protection-framework-05

Current status

•  Co-authored by Juniper Networks, Orange, RtBrick, Deutsche Telekom and Huawei Technologies

•  Current draft (05) issued around two months ago (on July 31, 2017) –  Discusses the overall framework for

•  egress node protection •  egress link protection

–  Provides some examples for •  egress node protection •  egress link protection

•  First deployment started few years ago in one of DT’s network –  Proven and stable architecture

Lets start

•  Lets start with –  Clarifying the model –  Clarifying the terminology

•  Before jumping to the deeper level

Seamless MPLS Architectural Model

Area 1 Area 0 Area 2 Area 1 Area 0 Area 2

Intra-domain (area or autonomous system) transport Inter-domain (area or autonomous system) transport Inter-domain end-to-end LSP model

AS X AS Y AN SN TN BN TN BN TN BN BN TN BN TN BN TN SN AN CE PE P ABR P ABR P ASBR ASBR P ABR P ABR P PE CE

IGP IGP IGP IGP IGP IGP IGP IGP IGP IGP IGP IGP LDP/RSVP LDP/RSVP LDP/RSVP LDP/RSVP LDP/RSVP LDP/RSVP LDP/RSVP LDP/RSVP LDP/RSVP LDP/RSVP LDP/RSVP LDP/RSVP

iBGP-LU iBGP-LU iBGP-LU eBGP-LU iBGP-LU iBGP-LU iBGP-LU nhs nhs nhs nhs nhs nhs nhs nhs nhs nhs nhs nhs nhs nhs

NODES

BGP-LU LSP LDP/RSVP LSP LDP/RSVP LDP LDP/RSVP LDP LDP/RSVP LSP LDP/RSVP LSP LDP/RSVP LSP

Legend

AN – Access Node (CE, CPE) BN – Border Node (ABR, ASBR) SN – Services Node (PE) TN – Transport Node (P)

NODES

E2E protection Terminology •  Access Node (AN)

–  Non-MPLS node connected to MPLS based Service Node (PE) –  AN (CE, CPE) in seamless MPLS architecture

•  Ingress Node (IN) –  First node of intra-area (LDP/RSVP) LSP –  SN (PE) or BN (ABR, ASBR) in seamless MPLS architecture

•  Egress Node (EN) –  Last node of intra-area (LDP/RSVP) LSP –  BN that has directly connected downstream BGP-LU neighbor with not underlying LDP/RSVP LSP (e.g. ASBR

scenario) –  SN (PE) or BN (ABR, ASBR) in seamless MPLS architecture

•  Transit Node (TN) –  Transit node (between ingress and egress) in intra-area (LDP/RSVP) LSP –  TN (P) in seamless MPLS architecture

•  Each intra-area (LDP/RSVP) LSP has exactly one ingress node, exactly one egress node and may have (multiple) transit node(s), if LSP is longer than one hop

E2E protection Terminology






ACCESS NODE (AN)

Traffic flow direction

Legend


LDP/RSVP LSP LDP/RSVP LDP LDP/RSVP LDP LDP/RSVP LSP LDP/RSVP LSP LDP/RSVP LSP BGP-LU LSP







INGRESS NODE (IN)



Legend








TRANSIT NODE (TN)



Legend








EGRESS NODE (EN)



Legend


INGRESS AND TRANSIT PROTECTION

E2E protection Terminology •  Ingress Protection

–  Measures to protect against failure of ingress Service Node (ingress SN) –  Point of Local Repair (PLR) is AN that is multi-homed to multiple SNs –  AN after detecting failure (via LOS, OAM, BFD, etc.) of SN (or link to SN) switches the outgoing

traffic to another SN •  Transit Protection

–  Measures to protect against failure of Transit Node (TN) –  Point of Local Repair (PLR) is IN or TN (non-penultimate node) of intra-area LSP –  Downstream node – IN or TN – on intra-area LSP after detecting the failure of upstream TN (or

link to upstream TN) redirects the traffic (going still to the same EN) via different transit link/node:

•  LFA (basic LFA, RLFA, TI-LFA) •  RSVP + facility protection (node-link protection) •  RSVP + one-to-one protection (fast-reroute)

•  Both ingress and transit protection are well known techniques, thus they are not covered in this presentation







INGRESS PROTECTION



Legend

AN – Access Node (CE, CPE) BN – Border Node (ABR, ASBR) SN – Services Node (PE) TN – Transport Node (P) Point of Local Repair (PLR) Node being protected







TRANSIT PROTECTION



Legend


TERMS USED WITH EGRESS PROTECTION


•  Primary Egress Node – Primary EN (SN) –  SN (PE) with multi-homed access site, that terminates VPN traffic flow

originated at Ingress SN (PE) •  Backup Egress Node – Backup EN (SN)

–  SN (PE) having corresponding (backup) VPN route as Primary Egress SN (PE)

–  Multi-homed access sites are connected to Primary and Backup Egress SN (PE)

EGRESS PROTECTION (TRADITIONAL)


•  Egress Protection –  Measures to protect against failure of Egress Node (EN) –  Traditionally, egress protection is executed on ingress node

•  Ingress node realizes primary egress node failure •  Ingress node switches the traffic to backup egress node using pre-programed next-

hop in the FIB •  This concept is called BGP Prefix Independent Convergence (PIC) Edge

Egress protection Concept

Area 1 Area 0 Area 2 Area 1 Area 0 Area 2 AS X AS Y

AN SN TN BN TN BN TN BN BN TN BN TN BN TN SN AN CE PE P ABR P ABR P ASBR ASBR P ABR P ABR P PE CE

EGRESS PE PROTECTION WITH BGP PIC EDGE


Ingress PE

Primary Egress PE

Backup Egress PE

•  Ingress PE pre-installs next-hops towards both egress PEs in the FIB •  Traffic restoration independent from the size of BGP table

Egress protection Concept EGRESS PE PROTECTION WITH BGP PIC EDGE

•  Ingress PE must realize primary egress PE failure in order to switch to pre-installed backup egress PE

•  This might be achieved using –  Global IGP convergence in single IGP domain design

•  Typically ~200-500 ms in small IGP domains •  Typically ~0.5…1 (or more) seconds in large IGP domains

–  Global IGP + BGP-LU convergence in multiple IGP domain design •  Might reach multiple seconds in large network

–  PE-to-PE OAM (BFD) •  Might introduce scaling challenges when large number of BFD (for MPLS tunnels)

session with aggressive timers are deployed

Egress protection Concept EGRESS PE PROTECTION WITH BGP PIC EDGE

•  Depending on –  traffic restoration requirements (sub-second, sub-500 ms, sub-100 ms, etc.) –  network complexity (small IGP domain, large IGP domain, multiple IGP

domains) BGP PIC Edge might not provide suitable protection for egress PE failure

•  New concept of egress protection shifts the duty of protecting the traffic from ingress PE to some node closer (directly connected) to egress PE –  Large global IGP/BGP-LU convergence irrelevant –  No problems with BFD scaling – only local link BFD might be required

EGRESS PROTECTION (NEW)

E2E protection Terminology •  Egress Protection

–  Measures to protect against failure of Egress Node (EN) –  Point of Local Repair (PLR) is penultimate node (one before EN: IN for single-hop

LSPs, TN for multi-hop LSPs) of intra-area LSP –  Penultimate node on intra-area LSP after detecting the failure of EN (or link to EN)

switches the traffic to another (protector/backup) EN –  Protector/backup EN must understand the labels (e.g. VPN labels) assigned by first

(primary) EN in order to be able to forward the traffic •  Labels allocated by EN have local significance (e.g. label for VPN prefix ‘X’ allocated by

primary EN is different than label allocated for the same VPN prefix ‘X’ allocated by protector/backup EN)

•  Primary and protector/backup EN has to understand (exchange and use: mirror) each other labels

•  Due to this paradigm, egress protection (called as well ‘service mirroring’) is more complex than ingress or transit protection

ADDITIONAL TERMS USED WITH EGRESS PROTECTION

E2E protection Terminology •  Point of Local Repair – PLR

–  Penultimate router directly connected to Primary EN –  Upon detection of Primary EN (or link to Primary EN) failure, PLR redirects traffic via MPLS

local repair mechanism (e.g. LFA) to Protector/Backup EN •  Protector

–  Performs translation between Primary and Backup EN labels –  Protector Must know Primary and Backup EN routes –  Can be combined (and usually is) with Backup EN on one node

•  In this presentation only combined Protector/Backup EN deployment is discussed •  Context-ID

–  Virtual next-hop address advertised (originated) in IGP by Primary EN and Protector •  Primary EN advertises Context-ID as preferred by IGP (e.g. with IGP metric 1) •  Protector advertises the same Context-ID as non-preferred by IGP (e.g. with IGP metric max-1)

–  Context-ID must be used as BGP protocol next-hop (instead of usually used lo0.0) IP address in NLRIs advertised by Primary EN for egress protection to work

–  Upon Primary EN failure detection, PLR redirects the traffic to Protector using MPLS local repair mechanism for Context-ID







EGRESS PROTECTION



This node is being protected, as well as acting as PLR for upstream ASBR

Legend


Egress protection Concept

Area 1 Area 0 Area 2 Area 1 Area 0 Area 2 AS X AS Y

AN SN TN BN TN BN TN BN BN TN BN TN BN TN SN AN CE PE P ABR P ABR P ASBR ASBR P ABR P ABR P PE CE

EGRESS PE PROTECTION



Ingress PE

Primary Egress PE

Protector/Backup Egress PE

PLR

Legend


Egress protection Concept EGRESS PE PROTECTION

Ingress PE VRF Red

VRF Red

Primary Egress PE (PE1)

Protector/Backup Egress PE (PE2)

VRF Red PLR

10/8

Egress protection Concept EGRESS PE PROTECTION (1)

Ingress PE PLR VRF Red

VRF Red

Egress PE protection elements

1.  PE1 advertises 1.1 (primary context-ID) with best IGP parameters

1.1, m=1

10/8



VRF Red



VRF Red


1.  PE1 advertises 1.1 (primary context-ID) with best IGP parameters

2. PE2 advertises 1.1 (protector context-ID) with worst IGP parameters

1.1, m=1

1.1, m=16m

10/8



VRF Red



VRF Red


1.  PE1 advertises 1.1 (primary context-ID) with best IGP parameters 2.  PE2 advertises 1.1 (protector context-ID) with worst IGP parameters

3. PLR builds LFA FIB structure for 1.1 (context-ID) with primary/backup next-hops programed in PFE to prefer PE1 over PE2

1.1, m=1

1.1, m=16m

10/8



VRF Red



VRF Red


1.  PE1 advertises 1.1 (primary context-ID) with best IGP parameters 2.  PE2 advertises 1.1 (protector context-ID) with worst IGP parameters 3.  PLR builds LFA FIB structure for 1.1 (context-ID) with primary/backup next-hops

programed in PFE to prefer PE1 over PE2

4. PE1 advertises service prefixes (e.g. L3VPN) with 1.1 (context-ID) as next-hop

1.1, m=1

1.1, m=16m

RR RD:10/8, nh=1.1 RD:10/8, nh=1.1 RD:10/8, nh=1.1 10/8



VRF Red


Ingress PE Primary Egress PE (PE1)


PLR VRF Red

VRF Red



programed in PFE to prefer PE1 over PE2 4.  PE1 advertises service prefixes (e.g. L3VPN) with 1.1 (context-ID) as next-hop

5. For service prefixes with 1.1 as next-hop (for which PE2 is protector) PE2 builds appropriate FIB structures using info (service labels) from primary egress PE

1.1, m=1

1.1, m=16m

RR RD:10/8, nh=1.1 RD:10/8, nh=1.1 RD:10/8, nh=1.1 10/8

VRF Red




PLR VRF Red

VRF Red



programed in PFE to prefer PE1 over PE2 4.  PE1 advertises service prefixes (e.g. L3VPN) with 1.1 (context-ID) as next-hop 5.  For service prefixes with 1.1 as next-hop (for which PE2 is protector) PE2 builds

appropriate FIB structures using info (service labels) from primary egress PE

6.  Ingress PE sends the service (e.g. L3VPN) traffic using LSP established towards 1.1 (context-ID)

1.1, m=1

1.1, m=16m

RR RD:10/8, nh=1.1 RD:10/8, nh=1.1 RD:10/8, nh=1.1 10/8

VRF Red




PLR VRF Red

VRF Red




appropriate FIB structures using info (service labels) from primary egress PE 6.  Ingress PE sends the service (e.g. L3VPN) traffic using LSP established towards

1.1 (context-ID)

7. Upon failure of PE1 or PLRàPE1 link, traffic is locally repaired on PLR and PE2 until global convergence happens

1.1, m=1

1.1, m=16m

RR RD:10/8, nh=1.1 RD:10/8, nh=1.1 RD:10/8, nh=1.1 10/8

VRF Red

LDP/RSVP tunnel labels locally repaired

Service labels locally repaired




PLR VRF Red

VRF Red

1.1, m=1

1.1, m=16m

RR RD:10/8, nh=1.1 RD:10.10, nh=1.1

RD:10.10, nh=1.1 10/8

VRF Red

RD:10/8, nh=1.2

RD:10.10, nh=1.2



appropriate FIB structures using info (service labels) from primary egress PE 6.  Ingress PE sends the service (e.g. L3VPN) traffic using LSP established towards

1.1 (context-ID) 7.  Upon failure of PE1 or PLRàPE1 link, traffic is locally repaired on PLR and PE2

until global convergence happens

8. After global convergence, ingress PE switches to LSP towards 1.2 (primary context-ID on PE2)


LDP/RSVP tunnel labels locally repaired

Service labels locally repaired

RD:10/8, nh=1.2

OVERALL

Protector Functions

•  As mentioned previously, regardless of the label protocol (LDP/RSVP) protector always binds real label to protector context-id

•  This protector context-id label is used to point to RIB/FIB structure in order to translate labels –  Packet arrives to protector with protector context-id label (on the top) and

label stack with next label allocated by primary PE –  Protector uses context-id label to point to the table with labels learned from

primary PE

PE (L3VPN) PROTECTION

Protector Functions

  __10.1.1.1-<vrf-name>__.inet.0

  POP

  POP

  <vrf-name>.inet.0

  __10.1.1.1__.mpls.0

  mpls.0

MPLS-Lookup: For each advertised Protector Context-ID, transport (real) label mpls.0 RIB entry is created, which points to the Context-ID specific MPLS RIB (__10.1.1.1__mpls.0).

MPLS-lookup (Context Label Table): VPN label lookup, based on the VPN label advertised by Primary PE. Entry points to Context-ID/VPN specific IP RIB, with the name based on VRF, if VRF defined locally on Protector (e.g. __10.1.1.1-<vrf-name>__.inet.0) or with the name based in RT, if VRF not defined locally on Protector (e.g. __10.1.1.1-<rt-name>__.inet.0).

IP lookup (Context IP/VPN Table): IP lookup (within context Context-ID and VPN/RT) to figure out how to send the packet to Backup PE. è effectively Protector does Label translation from Primary PE VPN label to Backup PE VPN label.

Protector Function

Backup PE Function

  __10.1.1.1-<rt-name>__.inet.0 Protector function and Backup PE function can be deployed on one physical device à ‘Combined’ Protector/Backup PE design

PE (L3VPN) PROTECTION

Protector Functions

  __10.1.1.1-<vrf-name>__.inet.0

  POP

  POP

  __10.1.1.1__.mpls.0

Protector Function

  __10.1.1.1-<rt-name>__.inet.0

root@PE2> show route table mpls.0 (…) 301600(S=0) *[MPLS/0] 01:11:20 to table __10.1.1.1__.mpls.0 (…)

root@PE2> show route table __10.1.1.1__.mpls.0 (…) 300368 *[Egress-‐Protection/170] 01:36:09 to table __10.1.1.1-‐vpn-‐101__.inet.0 (…)

root@PE2> show route table __10.1.1.2-‐vpn-‐101__.inet.0 (…) 172.15.89.0/24 *[Egress-‐Protection/170] 01:18:20 to 10.0.2.2 via ge-‐0/0/9.0 172.15.90.0/24 *[Egress-‐Protection/170] 01:18:20 to 10.0.2.4 via ge-‐0/0/3.0 (…)

VPN labels of VPN prefixes advertised by primary (PE1) with NH=10.1.1.1

Real label allocated by Protector (PE2) for Ctx-ID 10.1.1.1

  mpls.0

EGRESS PE PROTECTION

Conclusion

•  Traffic repair duty moved from ingress PE (as in case of BGP PIC Edge) to router(s) closer to egress PE

•  Sub-100 ms protection in case of egress PE failure, independent from –  IGP scale –  BGP scale

•  No requirement for large scale BFD with aggressive timers BFD •  First deployment started at Deutsche Telekom couple of years ago

–  Proven architecture –  Remarkable traffic restoration times –  No issues observed

1600-1630 20170929 szarkowicz fast egress protection v1

Documents