Rethinking kubernetes networking with SRv6 and Contiv-VPP - - PowerPoint PPT Presentation

▶
rethinking kubernetes networking with srv6 and contiv vpp
SMART_READER_LITE
LIVE PREVIEW

Rethinking kubernetes networking with SRv6 and Contiv-VPP - - PowerPoint PPT Presentation

Nov 01, 2022 118 likes •824 views

FOSDEM 20 Rethinking kubernetes networking with SRv6 and Contiv-VPP Abdelsalam, Cisco Systems ; ; Daniel Bernier, Bell Canada ; Ah Ahmed Ab ; Rastislav Szabo, Filip Gs Gschwandtner, , Pantheon.tech ; ; Mi Miroslaw Wa Walukiewicz, ,

slide-1
SLIDE 1

FOSDEM 2020

Ah Ahmed Ab Abdelsalam, Cisco Systems; ; Daniel Bernier, Bell Canada; ; Rastislav Szabo, Filip Gs Gschwandtner, , Pantheon.tech; ; Mi Miroslaw Wa Walukiewicz, , Intel

Rethinking kubernetes networking with SRv6 and Contiv-VPP

FOSDEM’20

slide-2
SLIDE 2

FOSDEM 2020

Agend nda

  • Kubernetes networking
  • SRv6

– Introduction to SRv6 – Kubernetes networking with SRv6

  • Contiv-VPP

– Introduction to Contiv-VPP – SRv6 support in Contiv-VPP

  • Accelerating SRv6 with Intel N3000 smartNIC
slide-3
SLIDE 3

FOSDEM 2020

Kuberne netes ne networking ng (1)

  • Kubernetes does not provide any solution for

handling containers networking

– It offloads networking to third-party certified plugins called CNI plugins

  • Connectivity

– Create an interface inside the pod – Connect the pod interface to the fabric – Allocate the Pod IP

  • Reachability

– Make Pod IP reachable by the whole cluster.

vs1

K8s-worker-node

B:B:B:1:1:0:C:1/128 B:B:B:1:1:0:C:2/128 B:B:B:1:1:0:C:3/128

vs2

K8s-worker-node

B:B:B:2:2:0:C:1/128 B:B:B:2:2:0:C:2/128 B:B:B:2:2:0:C:3/128

slide-4
SLIDE 4

FOSDEM 2020

Kuberne netes ne networking ng (2)

  • Problem statement

– All your Containers need IP addresses – We do not have more enough IPv4 addresses

  • Solution

– IPv6

ht https://ripe78.ripe.ne net/present ntations ns/39-2019 2019-05 05-23 23-bgp2 bgp2018.pdf pdf ht https://twitter.com/ripenc ncc/status/1198977232452145152

slide-5
SLIDE 5

FOSDEM 2020

Kuberne netes ne networking ng (3)

  • Problem statement

– Pod-to-Pod – Network policy – Kubernetes services – Ingress – Service chaining – Inter-cluster, hybrid cloud, multi-cloud, …

  • Solution

– SRv6

slide-6
SLIDE 6

FOSDEM 2020

Kuberne netes ne networking ng (4)

  • Problem statement

– Dataplane for fast packet I/O

>Kernel forwarding >XDP >VPP

  • Solution

– VPP – smartNIC (accelerated VPP)

ht https://arxiv.org/pdf/2001.06182v1.pdf ht https://www.int ntel.la/cont ntent nt/dam/www/programmable/us/en/ n/pdfs/liter at ature/wp/wp-01295 01295-hc hcl-se segment-ro routing-ov

  • ver-ip

ipv6-ac accelerat ation- us using-in intel-fp fpga-pr progr grammabl ble-ac accelerat ation-ca card-n3 n3000.pdf

slide-7
SLIDE 7

FOSDEM 2020

SRv6

slide-8
SLIDE 8

FOSDEM 2020

Segment nt Routing ng

  • Source Routing

– A node steers a packet through an ordered list of instructions, called "segments". – Each segment has a segment identifier (SID) based on the dataplane instantiation – the topological and service (NFV) path is encoded in packet header

  • Scalability

– the network fabric does not hold any per-flow state for TE or NFV

  • Simplicity

– automation: TILFA sub-50msec FRR – protocol elimination: LDP, RSVP-TE, NSH, VXLAN…

  • End-to-End

– DC, Metro, WAN

slide-9
SLIDE 9

FOSDEM 2020

IPv6 – SRv6

  • leverages RFC8200 provision for source routing extension header
  • 1 SID = 1 IPv6 address
  • defines a new IPv6 extension header, called SRH.
  • SID list = an address list in the SRH

Tw Two dataplane ne ins nstant ntiations ns

MPLS - SRMPLS

  • leverage the mature MPLS HW with only SW upgrade
  • 1 SID = 1 MPLS label
  • SID list = MPLS label stack

Segment Routing

slide-10
SLIDE 10

FOSDEM 2020

SR SRv6 Ec Ecosyste tem

NFV Partners Smart NIC Open-Source Applications

Pyroute2

SERA

Merchant Silicon Open-Source Networking Stacks Network Equipment Manufacturers

slide-11
SLIDE 11

FOSDEM 2020

SRv6 Network programming ng

  • The SRv6 Network Programming framework enables a network
  • perator or an application to specify a packet packet processing

program by encoding a sequence of instructions in the IPv6 packet header.

  • Each instruction is implemented on one or several nodes in the network

and identified by an SRv6 Segment Identifier in the packet.

  • IETF standardization in progress

– https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-08

slide-12
SLIDE 12

FOSDEM 2020

Network ins nstruction

  • 128-bit SRv6 SID

– Locator: routed to the node performing the function – Function: any possible function

either local to NPU or app in VM/Container

– Flexible bit-length selection Function Locator

slide-13
SLIDE 13

FOSDEM 2020

Network Program in the Packet Header

Lo Locator 1 Fu Func nction

  • n 1

Lo Locator 2 Fu Func nction

  • n 2

Lo Locator 3 Fu Func nction

  • n 3

TC TCP, UD UDP, QUI UIC

Lo Locator 1 Fu Func nction

  • n 1

So Source Address

Active Segment

IPv6 header Segment Routing Header IPv6 payload

slide-14
SLIDE 14

FOSDEM 2020

SR SRv6 Header

Metadata TLV

Se Segments Left Lo Locator 1 Fu Func nction

  • n 1

Lo Locator 2 Fu Func nction

  • n 2

Lo Locator 3 Fu Func nction

  • n 3

TA TAG

slide-15
SLIDE 15

FOSDEM 2020

SRv6 beha haviors specs summary

En Endpoint Be Behavior Us Use-cas case End Endpoint TE (underlay) End.X Endpoint with Layer-3 cross-connect End.DX6 Endpoint with decapsulation and IPv6 cross-connect IPv6 L3VPN (overlay) End.DT6 Endpoint with decapsulation and specific IPv6 table lookup End.DX4 Endpoint with decapsulation and IPv4 cross-connect IPv4 L3VPN (overlay) End.DT4 Endpoint with decapsulation and specific IPv4 table lookup End.DX2 Endpoint with decapsulation and Layer-2 cross-connect L2VPN (overlay) End.AS Endpoint to SR-unaware APP via static proxy Service chaining End.AD Endpoint to SR-unaware APP via dynamic proxy End.AM Endpoint to SR-unaware APP via masquerading proxy He Headend Be Behavior Us Use-cas case H.Encaps SR Headend with Encapsulation in an SRv6 Policy L3 Traffic H.Encaps.L2 H.Encaps Applied to Received L2 Frames L2 traffic

slide-16
SLIDE 16

FOSDEM 2020

  • Automated
  • No tunnel to configure
  • Simple
  • Protocol elimination
  • Efficient
  • SRv6 for everything

Overlay

1 2 4 V/ V/64 3 T/ T/64

IPv6 Hdr SA = A1 A1::0, DA = A2 A2::C4 Payload IPv6 Hdr SA = T::1, DA = V: V::2

Green Overlay V/64 via A2::C4

IPv6 Hdr SA = T::1, DA = V: V::2 Payload IPv6 Hdr SA = T::1, DA = V: V::2 Payload

slide-17
SLIDE 17

FOSDEM 2020

  • SRv6 does not only eliminate

unneeded overlay protocols

  • SRv6 solves problems that

these protocols cannot solve

Overlay with Underlay Control

1 2 4 V/ V/64 3 T/ T/64

Green Overlay V/64 via A2::C4 with Latency

IPv6 Hdr SA = T::1, DA = V: V::2 Payload IPv6 Hdr SA = T::1, DA = V: V::2 Payload

3

IPv6 Hdr SA = A1 A1::0, DA = A3 A3::1 Payload IPv6 Hdr SA = T::1, DA = V: V::2 SR Hdr < A3 A3::1, A2::C4 > IPv6 Hdr SA = A1 A1::0, DA = A2 A2::C4 Payload IPv6 Hdr SA = T::1, DA = V: V::2 SR Hdr < A3::1, A2 A2::C4 >

slide-18
SLIDE 18

FOSDEM 2020

Kubernetes networking with SRv6

slide-19
SLIDE 19

FOSDEM 2020

kuberne netes ne networking ng (current ntly)

  • CNI plugins are responsible for networking in kubernetes

– Load Balancing à Linux iptables NAT / VPP NAT

– Port Forwarding

à Linux iptables NAT / VPP NAT

– Network Policy à Linux iptables firewall/VPP ACLs – Overlay networking à VXLAN/IP-in-IP/GENEVE/GRE/... – Service chaining à stitching of interfaces/VXLAN tunnels

  • The result

– NAT everywhere – Complex network policy model that relies on container IPs – iptables everywhere which uses non scalable linear search matching – Service chaining is very complex “nearly impossible” – Inter-cluster communication, hybrid cloud, multi-cloud, network wide policy ???

slide-20
SLIDE 20

FOSDEM 2020

kuberne netes ne networking ng (IPv6 + SRv6)

  • IPv6 for reachability
  • SRv6 for everything

– Overlay with no extra protocols à SRv6 Encap + Decap – Scalable network policy model à Leveraging SRH TAG – Port forwarding à An IPv6 address per application – Load Balancing à One SR policy + multiple SID lists – Service chaining à Out-of-box using the SRH SID list – Inter-cluster, hybrid cloud, multi-cloud, … à SRv6 + NSM

slide-21
SLIDE 21

FOSDEM 2020

Spine1 Leaf1 vS1

Compute-1

Spine2 Leaf2 vS2

Compute-2

Leaf3 vS3

Compute-3 R1 G1 B1 R2 G2 B2 R3 G3 B3

SRH: [TAG]=Red SA: R1, DA: B3 Payload SA: Vs1, DA: Vs2 SA: R1, DA: B3 Payload SA: R1, DA: B3 Payload Policies table src dst action Red Blue ACCEPT Red Green DROP

Network policy using ng SRv6

  • Scalable policy table
  • Fully integrated with the overlay
  • Independent of container IP’s

SRH: [TAG]=Red SA: R1, DA: B3 Payload SA: Vs1, DA: Vs2

slide-22
SLIDE 22

FOSDEM 2020

Contiv-VPP CNI Intro

slide-23
SLIDE 23

Contiv-VPP CNI

  • Uses FD.io VPP with DPDK as the data-plane for packet forwarding
  • Kube-proxy implemented in the user space (on VPP)
  • Production-ready CNI (passes all k8s conformance tests)
  • Swiss army knife CNI for cloud-native networking deployments:
  • Multiple network interfaces per pod
  • Multiple isolated L2/L3 networks
  • Service chaining between pods for CNF (Cloud-Native Network Functions)

deployments

  • IPv6 support
  • SRv6 support
slide-24
SLIDE 24

Contiv-VPP Data Plane

Kubernetes node Contiv vSwitch pod Pod 1

VPP

Pod 2 Interconnection Fabric Other Kubernetes nodes

slide-25
SLIDE 25

Multiple Pod Interfaces & Custom Networks

https://github.com/contiv/vpp/tree/master/k8s/examples/custom-network

  • apiVersion: contivpp.io/v1

kind: CustomNetwork metadata: name: l2net spec: type: L2

  • kind: Pod

metadata: name: linux-cnf1 annotations: contivpp.io/custom-if: tap1/tap/l2net spec: …

slide-26
SLIDE 26

Service Chaining Between CNF Pods (L2-XConnect -Based)

https://github.com/contiv/vpp/tree/master/k8s/examples/sfc

  • apiVersion: contivpp.io/v1

kind: ServiceFunctionChain metadata: name: vpp-chain spec: chain:

  • name: CNF 1

type: Pod podSelector: cnf: vpp-cnf1 interface: memif1

  • name: CNF 2

type: Pod podSelector: cnf: vpp-cnf2 inputInterface: memif1

  • utputInterface: memif2
  • name: CNF 3

type: Pod podSelector: cnf: vpp-cnf3 interface: memif1

slide-27
SLIDE 27

Service Chaining With External Interfaces (L2-XConnect -Based)

https://github.com/contiv/vpp/tree/master/k8s/examples/sfc

  • apiVersion: contivpp.io/v1

kind: ExternalInterface metadata: name: vlan-200 spec: type: L2 nodes:

  • node: k8s-master

vppInterfaceName: GigabitEthernet0/a/0 vlan: 200

  • apiVersion: contivpp.io/v1

kind: ServiceFunctionChain metadata: name: vpp-chain spec: chain:

  • name: VLAN 200 interface

type: ExternalInterface interface: vlan-200

  • name: CNF

type: Pod podSelector: cnf: vpp-cnf

slide-28
SLIDE 28

FOSDEM 2020

SRv6 in Contiv-VPP CNI

slide-29
SLIDE 29

Node 1 Node 2 Pod 1 Pod 2 VPP VPP PodVRF MainVRF PodVRF MainVRF

Pod-to-pod Communication in Contiv/VPP with SRv6

Steering Policy

Pod 1

LocalSid- DT6 Table lookup Table lookup

slide-30
SLIDE 30
  • For, implemented with NAT on VPP
  • WithIPv4 SRv6, NAT is eliminated
  • Traffic is steered via SRv6 policies, load-balanced between multiple SRv6

segment lists

K8s Services with SRv6

Service Pod 1 Pod N

…..

load-balance

  • Steering based on destination

IP - Service Virtual IP address (Cluster IP)

  • Steering based on destination

port on K8s node (NodePort)

https://github.com/contiv/vpp/blob/master/docs/setup/SRV6.md

slide-31
SLIDE 31

Node 2 Pod 2 VPP PodVRF MainVRF

Pod-to-service Communication with SRv6

LocalSid- End LocalSid- DX6 Table lookup Table lookup

Node 1 Pod 1 VPP PodVRF MainVRF

Steering Policy

Pod 2

LocalSid- DX6 Table lookup Table lookup

slide-32
SLIDE 32
  • SRv6 implementation for handling chains between SR-unaware CNFs
  • “Snake" CNF chaining only (“Pipeline" is more complex to be done at the

CNI level)

  • Uses the same CRD APIs as the L2-Xconnect –based SFC

Service Function Chaining with SRv6

CNF 1 CNF 1 CNF 1 VPP VPP

Snake

CNF 1 CNF 1 CNF 1 VPP VPP

Pipeline

https://github.com/contiv/vpp/blob/master/docs/dev-guide/SFC.md#srv6-renderer

slide-33
SLIDE 33

Node 1 Node 2 VPP VPP

Service Function Chain Between CNFs

CNF-Input CNF-Output CNF 1 CNF 2

slide-34
SLIDE 34

Node 1 Node 2 VPP VPP PodVRF MainVRF PodVRF MainVRF

SFC Rendering with SRv6

L3 Steering Policy LocalSid- AD Table lookup LocalSid- End LocalSid- AD Table lookup LocalSid- DX6

CNF-Input CNF 2 CNF-Output CNF 1

slide-35
SLIDE 35

CNF 1-1 CNF 1-2 CNF 2-1 CNF 2-2 CNF 2-3 Node 1 Node 2

Multi-path SFC Rendering with SRv6

CNF-Input-1 CNF-Input-2 CNF-Input-3 CNF-Input-X …. …. CNF-Output-1

Steering + Policy

Chain: CNF-Input => CNF 1 => CNF 2 => CNF-Output

slide-36
SLIDE 36

CNF 1-1 CNF 1-2 CNF 2-1 CNF 2-2 CNF 2-3 Node 1 Node 2

Multi-path SFC Rendering with SRv6 – Multi-node

CNF-Input-1 CNF-Input-2 CNF-Input-3 CNF-Input-X …. …. CNF-Output-1

Steering + Policy

Chain: CNF-Input => CNF 1 => CNF 2 => CNF-Output

Node 3

Steering + Policy

slide-37
SLIDE 37

FOSDEM 2020

Accelerating SRv6 with Intel N3000 smartNIC

slide-38
SLIDE 38

SRv6 Acceleration Solution

slide-39
SLIDE 39
slide-40
SLIDE 40

14B 96B 82B Ethernet IPv6+SR HDR payload

SRv6 Packet 192 Byte size

IPv6 Version 0.5 Trafic Class 1 Flow Label 2.5 Payload Length 2 Next Header 1 Hop Limit 1 Src Addr 16 Dest Addr 16 SRv6 Next Header 1 Hdr Ext Len 1 Routing Type 1 Segment Left 1 Last Entry 1 Flags 1 Tag 2 SID List - SID0 16 SID1 16 SID2 16 P P 1

VPP PAC FPGA

P 2 P 3

VPP PAC FPGA

SRv6 Service Function Chaining

14B 96B 82B Ethernet IPv6+SR HDR payload 82B payload 14B 96B 82B Ethernet IPv6+SR HDR payload 14B 96B 82B Ethernet IPv6+SR HDR payload

Offloaded Headers

Payload is a Tenant Packet starts with ethernet/IPv4/IP6

Compute Node A Compute Node B

VN F 82B payload VNF IPv6 DA = SID2 SL=2 IPv6 DA = SID0 SL=0 IPv6 DA = SID1 SL=1

SRv6 acceleration use case scenario

slide-41
SLIDE 41
slide-42
SLIDE 42

Pe Performance Benchmarking – 192 192 Byte – SR SRv6 E END.AD

31,640 32,576 35,156 43,359 46,093 46,093 44,92 50,00 0,000 20,000 40,000 60,000 4 6 8 10 12 14

Packet rate - GBPS Cores

SRv6 AD2 Acceleration - 192B - GBPS

SRv6 SW 27,344 37,500 39,453 42,969 46,094 46,094 45,703 50,000 0,000 50,000 100,000 4 8 10 12 14 16

Packet rate - GBPS Cores

SRv6 AD4 Acceleration - 192B - GBPS

SRv6 SW SRv6 Acc 26,563 34,375 40,234 44,531 46,094 46,094 45,703 50,000 0,000 50,000 100,000 4 8 10 12 14 16

Packet rate - GBPS Cores

SRv6 AD6 Acceleration - 192B - GBPS

SRv6 SW

ü 3x Throughput Performance improvement ü 8 to 10 cores savings

slide-43
SLIDE 43

FOSDEM 2020

Conclusion

slide-44
SLIDE 44

FOSDEM 2020

Conc nclusion n

  • Kubernetes does not provide any solution for handling containers
  • networking. Instead, it offloads networking to the CNI plugins.
  • CNI Plugins provides both connectivity and reachability to k8s pods
  • IPv6 is needed to provide addressing and reachability for continuously

increasing number of endpoints (i.e., containers/pods)

  • SRv6 leverages the IPv6 dataplane and can handles the various k8s

networking use-cases in simple and scalable way.

  • Contiv-VPP + DPDK and Intel PAC N3000 smartNIC can provide faster

I/O for k8s pods

– They both support SRv6

slide-45
SLIDE 45

FOSDEM 2020

Backup

slide-46
SLIDE 46

FOSDEM 2020

  • For simplicity function 1 denotes the most basic function
  • Shortest-path to the Node

Endpoint function

A1 A1 A1:: A3 A3 A3:: A2 A2 A2:: A5 A5 A5:: A4 A4 A4::

50 50

A6 A6 A6:: A7 A7 A7:: A8 A8 A8::

Default metric 10 SR SR: 〈A4: A4::1, 1, A6: A6::1, 1, A8: A8::〉

>VPP: show sr localsid LocalSID Behavior A6::1 End Total SR LocalSIDs: 1 >VPP: show sr localsid LocalSID Behavior A4::1 End Total SR LocalSIDs: 1

slide-47
SLIDE 47

FOSDEM 2020

Endpoint then xconnect to neighbor function

A1 A1 A1:: A3 A3 A3:: A2 A2 A2:: A5 A5 A5:: A4 A4 A4::

50 50

A6 A6 A6:: A7 A7 A7:: A8 A8 A8::

Default metric 10 SR SR: 〈A4: A4::C5, 5, A6: A6::1, 1, A8: A8::〉

>VPP: show sr localsid LocalSID Behavior A6::1 End Total SR LocalSIDs: 1 >VPP: show sr localsid LocalSID Behavior A4::C5 End.X {TenGE0/1/0 A5::} Total SR LocalSIDs: 1

  • For simplicity Ak::Cj denotes:
  • Shortest-path to the Node K and then x-connect (function C) to the neighbor J
slide-48
SLIDE 48

FOSDEM 2020

Deployment use-cases

slide-49
SLIDE 49

FOSDEM 2020

  • 50msec Protection upon

local link, node or SRLG failure

  • Simple to operate and understand
  • automatically computed by the router’s IGP process
  • 100% coverage across any topology
  • predictable (backup = postconvergence)
  • Optimum backup path
  • leverages the post-convergence path, planned to carry the traffic
  • avoid any intermediate flap via alternate path
  • Incremental deployment
  • Distributed and Automated Intelligence

TILFA

2 4 6 5 1

A5 A5::0 A5 A5::/6 /64 Pri Pri → vi via 5 A2 A2::C4 C4 A5 A5::0 FR FRR → ins nsert A2::C4 A5 A5::0 <50mec FR FRR

100

slide-50
SLIDE 50

FOSDEM 2020

  • IGP minimizes cost instead of latency

Distributed & Automated TE

SF SFO 4 NY NY 5 BR BRU 1 MO MOS 2 TOK TOK 3

A2 A2::0 A3 A3::0 A3 A3::0

FI FIB

A2::/64 → OIF MOS A3::/64 → OIF NY

FI FIB

A3::/64 → OIF TOK

BG BGP

Advert X/64 Advert Y/64 with Latency

slide-51
SLIDE 51

FOSDEM 2020

  • Distributed and Automated Intelligence
  • Dynamic SRTE Policy triggered by learning a BGP route with SLA contract
  • No PBR steering complexity, No PBR performance tax, No RSVP, No tunnel to configure

Distributed & Automated TE

SF SFO 4 NY NY 5 BR BRU 1 MO MOS 2 TOK TOK 3

Y/ Y/64 via A3::0 Low-Latenc ncy X/64 via A3::0 along ng IGP path

BG BGP

X/64 → A3::0 Y/64 → A3::0 with Lat.

FI FIB

A2::/64 → OIF MOS A3::/64 → OIF NY X/64 → A3::0 Y/64 → insert <A2::1, A3::1> On On-Demand nd distributed TE

slide-52
SLIDE 52

FOSDEM 2020

Input Acquisition

  • BGP-LS
  • Telemetry

Policy Instantiation

  • PCEP
  • BGP-TE
  • Netconf / Yang

Algorithm

  • SR native

Centralized TE

DC (BGP-SR)

10 10 11 11 12 12 13 13 14 14 2 4 6 5 7

WAN (IGP-SR)

3 1

PEER

Lo Low La Lat, , Low BW

50 50

Default ISIS cost metric: 10

<A1::1, A2::C4, A4::C7>

Lo Low-La Latency to to 7 fo for a application … …

slide-53
SLIDE 53

FOSDEM 2020

  • Automated
  • No tunnel to configure
  • Simple
  • Protocol elimination
  • Efficient
  • SRv6 for everything

Overlay

1 2 4 V/ V/64 3 T/ T/64

IPv6 Hdr SA = A1 A1::0, DA = A2 A2::C4 Payload IPv6 Hdr SA = T::1, DA = V: V::2

Green Overlay V/64 via A2::C4

IPv6 Hdr SA = T::1, DA = V: V::2 Payload IPv6 Hdr SA = T::1, DA = V: V::2 Payload

slide-54
SLIDE 54

FOSDEM 2020

  • SRv6 does not only eliminate

unneeded overlay protocols

  • SRv6 solves problems that

these protocols cannot solve

Overlay with Underlay Control

1 2 4 V/ V/64 3 T/ T/64

Green Overlay V/64 via A2::C4 with Latency

IPv6 Hdr SA = T::1, DA = V: V::2 Payload IPv6 Hdr SA = T::1, DA = V: V::2 Payload

3

IPv6 Hdr SA = A1 A1::0, DA = A3 A3::1 Payload IPv6 Hdr SA = T::1, DA = V: V::2 SR Hdr < A3 A3::1, A2::C4 > IPv6 Hdr SA = A1 A1::0, DA = A2 A2::C4 Payload IPv6 Hdr SA = T::1, DA = V: V::2 SR Hdr < A3::1, A2 A2::C4 >

slide-55
SLIDE 55

FOSDEM 2020

Service chaining

slide-56
SLIDE 56

FOSDEM 2020

Service Chaining

Packets from are steered through a sequence of services on their way to the server

slide-57
SLIDE 57

FOSDEM 2020

Service Chaining with NS NSH

  • De

Dedicated encapsul ulation header

  • State to be maintained for each service chain

Packets from are steered through a sequence of services on their way to the server

slide-58
SLIDE 58

FOSDEM 2020

  • Ser

Services es are expressed with se segments

  • Flexible
  • Scalable
  • Stateless

Packets from are steered through a sequence of services on their way to the server

Service Chaining with SR SRv6

S1 S1 S2 S2 S3 S3 D SR SR: : 〈S1 S1, S2 S2, S3 S3, D〉

slide-59
SLIDE 59

FOSDEM 2020

  • Ser

Services es are expressed with se segments

  • Flexible
  • Scalable
  • Stateless

Packets from are steered through a sequence of services on their way to the server

Service Chaining with SR SRv6

S1 S1 S2 S2 S3 S3 D SR SR: 〈S1 S1, C1, S2 S2, S3 S3, D〉 C1 C1

slide-60
SLIDE 60

FOSDEM 2020

  • Stateless
  • NSH creates per-chain state

in the fabric

  • SR does not
  • App is SR aware or not
  • App can work on IPv4, IPv6
  • r L2

Integrated NFV

1 2 4 V/ V/64 3 T/ T/64 4

Ap App 76 VM VM

Se Server 5

5 3

Ap App 32 Co Contai ainer

Se Server 3

IPv6 Hdr SA = A1 A1::0, DA = A3 A3::A3 A32 Payload IPv6 Hdr SA = T::1, DA = V: V::2 SR Hdr < A3 A3::A3 A32, A4::1, A5::A76, A2::C4 > IPv6 Hdr SA = T::1, DA = V: V::2 Payload

slide-61
SLIDE 61

FOSDEM 2020

  • Integrated with underlay SLA

Integrated NFV

1 2 4 V/ V/64 3 T/ T/64 4

Ap App 76 VM VM

Se Server 5

5 3

Ap App 32 Co Contai ainer

Se Server 3

IPv6 Hdr SA = A1 A1::0, DA = A4 A4::1 Payload IPv6 Hdr SA = T::1, DA = V: V::2 SR Hdr < A3::A32, A4 A4::1, A5::A76, A2::C4 >

slide-62
SLIDE 62

FOSDEM 2020

  • Stateless
  • NSH creates per-chain state

in the fabric

  • SR does not
  • App is SR aware or not
  • App can work on IPv4, IPv6
  • r L2

Integrated NFV

1 2 4 V/ V/64 3 T/ T/64 4

Ap App 76 VM VM

Se Server 5

5 3

Ap App 32 Co Contai ainer

Se Server 3

IPv6 Hdr SA = A1 A1::0, DA = A5 A5::A7 A76 Payload IPv6 Hdr SA = T::1, DA = V: V::2 SR Hdr < A3::A32, A4::1, A5 A5::A7 A76, A2::C4 >

slide-63
SLIDE 63

FOSDEM 2020

  • Integrated with Overlay

Integrated NFV

1 2 4 V/ V/64 3 T/ T/64 4

Ap App 76 VM VM

Se Server 5

5 3

Ap App 32 Co Contai ainer

Se Server 3

IPv6 Hdr SA = A1 A1::0, DA = A2 A2::C4 Payload IPv6 Hdr SA = T::1, DA = V: V::2 SR Hdr < A3::A32, A4::1, A5::A76, A2 A2::C4 > IPv6 Hdr SA = T::1, DA = V: V::2 Payload

slide-64
SLIDE 64

FOSDEM 2020

SR-UnAware VNFs:

  • Application is not aware of SR at all
  • Leverage VPP as a vm/container vSwitch to do SRv6 processing

Service Chaining with SR SRv6

SR-Aware VNFs:

  • Leverage SRv6 Kernel support to create smarter applications
  • SERA: SR-Aware Firewall (extension to iptables)

Types of VNFs

slide-65
SLIDE 65

FOSDEM 2020

  • End.AM – Endpoint to SR-unaware app via masquerading
  • End.AD – Endpoint to SR-unaware app via dynamic proxy
  • End.ASM – Endpoint to SR-unaware app via shared memory

SR-UnAware VNFs

S1 S1 D SR SR: 〈S1 S1, C1, S2 S2, S3 S3, D〉 C1 C1 S2 S2 S3 S3

slide-66
SLIDE 66

FOSDEM 2020

RFC2460: “A Routing header is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header.”

End.AM – Endpoint to SR-unaware app via masquerading

Te TenGE0/1/0 Te TenGE0/2/0

VN VNF VP VPP E1 E1::

IPv6 Hdr SA = A: A::, DA = E1 E1::A Payload SR Hdr ( B::, C3::, E1 E1::A ) SL=2 IPv6 Hdr SA = A: A::, DA = B: B:: Payload SR Hdr ( B::, C3 C3::, E1::A ) SL=1 IPv6 Hdr SA = A: A::, DA = C3 C3:: Payload SR Hdr ( B::, C3 C3::, E1::A ) SL=1

>VPP: show sr localsid LocalSID Behavior E1::A End.AM {OIF: TenGE0/1/0, NH: 2001::a, IIF: TenGE0/2/0} Total SR LocalSIDs: 1

  • Ingress:
  • Active SID is E1::A where function 0xA is

associated with End.AM

  • Replace DA with the last segment B:

B::

  • Forward to VNF (OIF, NH)
  • Egress:
  • Inspect SRH and update DA with active

segment C3 C3::

slide-67
SLIDE 67

FOSDEM 2020

End.AD – Endpoint to SR-unaware app via dynamic proxy

Te TenGE0/1/0 Te TenGE0/2/0

VN VNF VP VPP E1 E1::

IPv6 Hdr SA = A: A::, DA = B: B:: Payload

>VPP: show sr localsid LocalSID Behavior E1::B End.AD {OIF: TenGE0/1/0, NH: 2001::a, IIF: TenGE0/2/0} Total SR LocalSIDs: 1

  • Ingress:
  • Active SID is E1::B where function 0xB is

associated with End.AD

  • Pop and st

store outer IP and SR headers

  • Forward to VNF (OIF, NH)
  • Egress:
  • Push the IP and SR headers
  • Forward based on next segment
  • Valid for IPv4 and

nd IPv6 traffic

  • Pe

Per-cha hain n dyna namic conf nfiguration

IPv6 Hdr SA = C1 C1::, DA = E1 E1::C SR Hdr ( E2::, C2::, E1 E1::C ) SL=2 IPv6 Hdr SA = A::, DA = B: B:: Payload IPv6 Hdr SA = C1 C1::, DA = C2 C2:: SR Hdr ( E2::, C2 C2::, E1::C ) SL=1 IPv6 Hdr SA = A::, DA = B: B:: Payload

slide-68
SLIDE 68

FOSDEM 2020

End.ASM – Endpoint to SR-unaware app via shared mem.

1.

Put the received packet in a shared memory region

2.

Perform SR processing on the host Pass a point nter of the inner packet to S2

3.

Perform SR processing on the host Pass a point nter of the inner packet to S3

4.

Move the packet from the shared memory into the output iface buffer ring

  • Valid for IPv4 and

nd IPv6 traffic

  • Max. the

heoretical achi hievable performanc nce S2 S2 S3 S3