Segment Routing: a Comprehensive Survey of Research Activities, Standardization Efforts and Implementation Results

Total Page:16

File Type:pdf, Size:1020Kb

Segment Routing: a Comprehensive Survey of Research Activities, Standardization Efforts and Implementation Results SUBMITTED TO IEEE COMMUNICATIONS SURVEYS & TUTORIALS 1 Segment Routing: a Comprehensive Survey of Research Activities, Standardization Efforts and Implementation Results Pier Luigi Ventre, Stefano Salsano, Marco Polverini, Antonio Cianfrani, Ahmed Abdelsalam, Clarence Filsfils, Pablo Camarillo, Francois Clad Revision R2 - June 2020 Abstract—Fixed and mobile telecom operators, enterprise net- APIs, Northbound APIs, Open Source, Software Defined Net- work operators and cloud providers strive to face the challenging working, SDN, Service Function Chaining, SFC, Standards demands coming from the evolution of IP networks (e.g. huge bandwidth requirements, integration of billions of devices and millions of services in the cloud). Proposed in the early 2010s, I. INTRODUCTION Segment Routing (SR) architecture helps face these challenging demands, and it is currently being adopted and deployed. SR Egment Routing (SR) is based on the loose Source architecture is based on the concept of source routing and S Routing concept. A node can include an ordered list of has interesting scalability properties, as it dramatically reduces instructions in the packet headers. These instructions steer the the amount of state information to be configured in the core forwarding and the processing of the packet along its path in nodes to support complex services. SR architecture was first implemented with the MPLS dataplane and then, quite recently, the network. with the IPv6 dataplane (SRv6). IPv6 SR architecture (SRv6) The single instructions are called segments, a sequence of has been extended from the simple steering of packets across instructions can be referred to as a segment list or as an SR nodes to a general network programming approach, making it Policy. Each segment can enforce a topological requirement very suitable for use cases such as Service Function Chaining (e.g. pass through a node) or a service requirement (e.g. and Network Function Virtualization. In this paper we present a tutorial and a comprehensive survey on SR technology, an- execute an operation on the packet). The term segment refers alyzing standardization efforts, patents, research activities and to the fact that a network path towards a destination can be implementation results. We start with an introduction on the split into segments by adding intermediate way-points. The motivations for Segment Routing and an overview of its evolution segment list can be included by the original source of the and standardization. Then, we provide a tutorial on Segment packet or by an intermediate node. When the segment list is Routing technology, with a focus on the novel SRv6 solution. We discuss the standardization efforts and the patents providing inserted by an intermediate node, it can be removed by another details on the most important documents and mentioning other node along the path of the packet, supporting the concept of ongoing activities. We then thoroughly analyze research activities tunneling through an SR domain from an ingress node to an according to a taxonomy. We have identified 8 main categories egress node. during our analysis of the current state of play: Monitoring, Traffic Engineering, Failure Recovery, Centrally Controlled Ar- The implementation of the Segment Routing Architecture chitectures, Path Encoding, Network Programming, Performance requires a data plane which is able to carry the segment lists in Evaluation and Miscellaneous. We report the current status of SR the packet headers and to properly process them. Control plane deployments in production networks and of SR implementations operations complement the data plane functionality, allowing (including several open source projects). Finally, we report our arXiv:1904.03471v5 [cs.NI] 3 Jul 2020 the allocation of segments (i.e. associating a segment identifier experience from this survey work and we identify a set of future research directions related to Segment Routing. to a specific instruction in a node) and the distribution of the segment identifiers within an SR domain. Index Terms—Segment Routing, MPLS, IPv6, SR-MPLS, As for the data plane, two instances of SR Architecture have SRv6, Source Routing, Monitoring, Traffic Engineering, Failure Recovery, Path Encoding, Networking Programming, Perfor- been designed and implemented, SR over MPLS (SR-MPLS) mance, Linux, VPP, Data Plane, Control Plane, Southbound and SR over IPv6 (SRv6). With SR-MPLS, no change to the MPLS forwarding plane is required [1]. SRv6 is based on a P.L. Ventre is with with the Department of Electronic Engineer- new type of IPv6 routing header called SR Header (SRH) [2]. ing at the University of Rome Tor Vergata - Rome, Italy, E-mail: Temporally, SR-MPLS has been the first instance of SR [email protected]. S. Salsano is with the Department of Electronic Engineering at the Architecture, while the recent interest and developments are University of Rome Tor Vergata and with the Consorzio Nazionale In- focusing on SRv6. In particular, the IPv6 data plane for SR teruniversitario per le Telecomunicazioni (CNIT) - Rome, Italy, E-mail: is being extended to support the so-called SRv6 Network [email protected]. M. Polverini and A. Cianfrani are with Department of Informa- Programming Model [3]. According to this model, Segment tion Engineering, Electronics and Telecommunications at the Univer- Routing functions can be combined to achieve an end-to-end sity of Rome Sapienza - Rome, Italy, E-mail: {marco.polverini, anto- (or edge-to-edge) networking objective that can be arbitrarily nio.cianfrani}@uniroma1.it. A. Abdelsalam, C. Filsfils, P. Camarillo and F. Clad are with Cisco Systems, complex. This is appealing for implementing complex services E-mail: {ahabdels, cfilsfil, pcamaril, fclad}@cisco.com such as Service Function Chaining. SRv6 can be used as an SUBMITTED TO IEEE COMMUNICATIONS SURVEYS & TUTORIALS 2 overlay tunneling mechanism directly exposed and used by overcome some scalability issues and limitations [6], which servers (similar to VXLAN tunneling) and as an underlay had been identified in the traffic engineered Multi Protocol transport mechanism in network backbones (supporting Traffic Label Switching (MPLS-TE) solutions used for IP backbones. Engineering and Resilience services). In light of this, SRv6 can In particular it was observed that MPLS-TE requires explicit simplify network architectures avoiding the use of different state to be maintained at all hops along an MPLS path; this protocol layers. may lead to scalability problems in the control-plane and in As for the SR Control Plane operations, they can be based the data-plane. Moreover, the per-connection traffic steering on a distributed, centralized or hybrid architecture. In the model of MPLS-TE does not easily exploit the load balancing distributed approach, the routing protocols are used to signal offered by Equal Cost MultiPath (ECMP) routing. On the other the allocation of segments, and the nodes take independent hand, Segment Routing can steer traffic flows along traffic decisions to bind packets to the segment lists. In the centralized engineered paths with no per-flow state in the nodes along the approach, an SR controller allocates the segments, takes the path and exploit ECMP routing within each segment. decision on which packets need to be associated to which In the early 2010s, the IETF started the “Source Packet SR Policy and configures the nodes accordingly. Very often, Routing in Networking” Working Group (SPRING WG) to an hybrid approach which consists of the combination of the deal with Segment Routing. The activity of the SPRING WG previous strategies is used (see for example [4]). has included the identification of Use Cases and Requirements The goal of this paper is to provide a comprehensive survey for Segment Routing (for example, [7], [8] and [9] have be- on Segment Routing technology, including all the achieved come IETF RFCs). In July 2018, the SPRING WG has issued results and the ongoing work. Hereafter (section I-A), we start the “Segment Routing Architecture” document (RFC 8402 with the historical context behind the development of Segment [10]) along with another informational RFC on monitoring Routing. In section II, we provide an introduction to the main use cases [11]. More recently (December 2019) other 3 RFCs concepts of Segment Routing architecture. We consider both have been issued, while many other documents are still under the SR-MPLS and the SRv6 data planes, but we focus more discussion by the WG, as it will be analyzed later in this paper. deeply on SRv6 which is currently attracting a lot of interest. Looking at the scientific bibliography, the seminal paper on In section III, we provide a classification and a discussion the Segment Routing Architecture is [12]. Published in 2014, of the standardization efforts together with an analysis of the it provides an overview of the motivations for SR, describes most relevant patents. We provide a comprehensive review of a set of important use cases and illustrates the architecture. research activities in section IV, covering 88 scientific papers. The basic concepts proposed in [12] have been elaborated and The most relevant implementation results and the status of refined in the RFC 8402 [10]. ongoing deployments are reported in section V. We report in Currently, Segment Routing is receiving a lot of interest section VI lessons learned and our experience. We highlight from operators for its applications in different types of net- future research directions and open issues in section VII. works (transport backbones, access networks, datacenters and 5G networks). The MPLS based data plane (SR-MPLS) relies on the well A. Segment Routing roots and evolution established MPLS technology. SR-MPLS can be seen as an im- The Source Routing approach consists of the inclusion of provement and a simplification of the traditional MPLS control the route of the packet as a list of hops in the packet header. plane, so it is beneficial to operators with an already deployed This has two variants. Strict Source Routing requires the MPLS infrastructure.
Recommended publications
  • Routing and Congestion Control in Datagram Networks
    Routing and Congestion Control in Datagram Networks Zheng Wang Submitted for the degree of PhD at University College London January 1992 ProQuest Number: 10608852 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a com plete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. uest ProQuest 10608852 Published by ProQuest LLC(2017). Copyright of the Dissertation is held by the Author. All rights reserved. This work is protected against unauthorized copying under Title 17, United States C ode Microform Edition © ProQuest LLC. ProQuest LLC. 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106- 1346 ABSTRACT Routing and congestion control can be viewed as two closely related processes in a resource control system which manages the network resources. One of the basic prob­ lems is to adapt to changing conditions. Our analysis shows that inadequate information and delayed feedback can cause oscillation and instability. In this dissertation we exam­ ine the problems in routing and congestion control in a datagram environment and pro­ pose a number of solutions. The essence of the ideas is to deal with momentary fluctua­ tions and average steady trends separately. The behavior of shorest-path routing algorithms is investigated. A new approach for dynamic routing based on the concept of decentralized decision making is introduced. A dynamic routing algorithm based on this new approach, Shortest Path First with Emer­ gency Exits (SPF-EE)y is developed, which eliminates many of the problems that the Shortest Path First (SPF) algorithm exhibits under heavy and dynamic traffic.
    [Show full text]
  • Test-Beds and Guidelines for Securing Iot Products and for Secure Set-Up Production Environments
    IoT4CPS – Trustworthy IoT for CPS FFG - ICT of the Future Project No. 863129 Deliverable D7.4 Test-beds and guidelines for securing IoT products and for secure set-up production environments The IoT4CPS Consortium: AIT – Austrian Institute of Technology GmbH AVL – AVL List GmbH DUK – Donau-Universit t Krems I!AT – In"neon Technologies Austria AG #KU – JK Universit t Lin$ / Institute for &ervasive 'om(uting #) – Joanneum )esearch !orschungsgesellschaft mbH *+KIA – No,ia -olutions an. Net/or,s 0sterreich GmbH *1& – *1& -emicon.uctors Austria GmbH -2A – -2A )esearch GmbH -)!G – -al$burg )esearch !orschungsgesellschaft -''H – -oft/are 'om(etence 'enter Hagenberg GmbH -AG0 – -iemens AG 0sterreich TTTech – TTTech 'om(utertechni, AG IAIK – TU Gra$ / Institute for A((lie. Information &rocessing an. 'ommunications ITI – TU Gra$ / Institute for Technical Informatics TU3 – TU 3ien / Institute of 'om(uter 4ngineering 1*4T – 1-Net -ervices GmbH © Copyright 2020, the Members of the IoT4CPS Consortium !or more information on this .ocument or the IoT5'&- (ro6ect, (lease contact8 9ario Drobics7 AIT Austrian Institute of Technology7 mario:.robics@ait:ac:at IoT4C&- – <=>?@A Test-be.s an. guidelines for securing IoT (ro.ucts an. for secure set-up (ro.uction environments Dissemination level8 &U2LI' Document Control Title8 Test-be.s an. gui.elines for securing IoT (ro.ucts an. for secure set-u( (ro.uction environments Ty(e8 &ublic 4.itorBsC8 Katharina Kloiber 4-mail8 ,,;D-net:at AuthorBsC8 Katharina Kloiber, Ni,olaus DEr,, -ilvio -tern )evie/erBsC8 -te(hanie von )E.en, Violeta Dam6anovic, Leo Ha((-2otler Doc ID8 DF:5 Amendment History Version Date Author Description/Comments VG:? ?>:G?:@G@G -ilvio -tern Technology Analysis VG:@ ?G:G>:@G@G -ilvio -tern &ossible )esearch !iel.s for the -2I--ystem VG:> >?:G<:@G@G Katharina Kloiber Initial version (re(are.
    [Show full text]
  • DPDK, VPP & Pfsense
    DPDK, VPP & pfSense 3.0 Jim Thompson DPDK Summit Userspace - Dublin- 2017 %whoami Co-founded company in 1992 Focused on network security Originally “Netgate” was name an open source firewall for SunOS 4 Ported to Solaris (2.3), Windows NT, BSDi Added IPsec (then quite new) Wrote CiscoSecure (TACACS+ / RADIUS server) Might know us best for DPDK in a Box DPDK in a Box Simple, easy intro to running DPDK Minnowboard “Turbot” w/ 4C E3845 Atom, 2GB RAM, 32GB M.2 SSD, 2 x i210 Ethernet CentOS + pre-complied / installed DPDK + source code + testpmd DPDK in a Box, next-gen %whoami Co-founded company in 1992 Originally “Netgate” was name an open source firewall for SunOS 4 Also ported to Solaris (2.3), Windows NT, BSDi Also wrote CiscoSecure (TACACS+ server) Might know us best for DPDK in a Box We are the company behind the pfSense project pfSense® software FreeBSD-based router/firewall distribution “Like a Cisco ASA” 100,000 lines of PHP Orchestration + WebGUI Started in 2004 First release 4 October 2006 2.4 release 2 October 2017 1.375 million current installs 960,000+ on 64-bit Intel 8,000 32-bit ARM ARM64 underway October 2014 pfSense under strain after 10 years Increasing use of 10Gbps and higher Ethernet Increasing packet rate requirements No central ‘status’ db, so most config changes require restarting stack No API — makes automated test & interfacing to orchestration difficult Offsite meeting in 2014 Simple goals 10Gbps IP4/IP6 forwarding tinygrams, with ACLs 10Gbps IPsec (large frames) Eliminate PHP Add API Project named Pennybacker Experiments
    [Show full text]
  • Rethinking BGP Programmability
    λBGP: Rethinking BGP programmability Nicholas Hart, Charalampos Rotsos, Vasileios Giotsas, Nicholas Race, David Hutchison School of Computing and Communications, Lancaster University Abstract—BGP has long been the de-facto control plane pro- or supplement the information transmitted to adjacent ASes. tocol for inter-network connectivity. Although initially designed Configuration is stateless and programmability is typically to provide best-effort routing between ASes, the evolution of limited to simple arithmetic and logical expressions. As a Internet services has created a demand for more complex control functionalities using the protocol. At the heart of this challenge result, network managers must maintain large and complex lies the static nature of current BGP policy specification and en- configuration files in order to achieve the required policy forcement, and the limited programmability of production BGP effects, requiring regular updates in order to support changing policy frameworks. Meanwhile, in other contexts, the SDN model network conditions. Misconfiguration errors are a major cause has demonstrated that open and generic network control APIs of BGP problems [2], and connectivity outages and route leaks can greatly improve network functionality and seamlessly enable greater flexibility in network management. In this paper, we at a global or national level are not uncommon [3], [4]. argue that BGP speaking systems can and should provide an open Second, the BGP path selection process in current BGP control API and a richer policy language, in order to address routers is proactive, and its scope is limited to protocol modern era network control requirements. Towards this goal, we information and static configuration data. Many measurement present λBGP, a modular and extensible BGP stack written in studies have highlighted the fact that BGP could improve the Haskell.
    [Show full text]
  • Vector Packet Processor Documentation Release 0.1
    Vector Packet Processor Documentation Release 0.1 John DeNisco Aug 10, 2018 Contents 1 Overview 3 1.1 What is VPP?...............................................3 1.2 Features..................................................5 1.3 Performance............................................... 10 1.4 Architectures and Operating Systems.................................. 12 2 Getting Started 13 2.1 Users................................................... 13 2.2 Developers................................................ 51 2.3 Writing VPP Documentation....................................... 77 3 Use Cases 99 3.1 FD.io VPP with Containers....................................... 99 3.2 FD.io VPP with Virtual Machines.................................... 106 3.3 Using VPP as a Home Gateway..................................... 114 3.4 vSwitch/vRouter............................................. 118 4 Troubleshooting 119 4.1 How to Report an Issue......................................... 119 4.2 CPU Load/Usage............................................. 122 5 User Guides 125 5.1 Progressive VPP Tutorial......................................... 125 5.2 API User Guides............................................. 149 6 Events 151 6.1 Conferences............................................... 151 6.2 Summits................................................. 153 6.3 Meetings................................................. 163 6.4 Calls................................................... 165 6.5 Fd.io Training Event..........................................
    [Show full text]
  • Linux Networking 101
    The Gorilla ® Guide to… Linux Networking 101 Inside this Guide: • Discover how Linux continues its march toward world domination • Learn basic Linux administration tips • See how easy it can be to build your entire network on a Linux foundation • Find out how Cumulus Linux is your ticket to networking freedom David M. Davis ActualTech Media Helping You Navigate The Technology Jungle! In Partnership With www.actualtechmedia.com The Gorilla Guide To… Linux Networking 101 Author David M. Davis, ActualTech Media Editors Hilary Kirchner, Dream Write Creative, LLC Christina Guthrie, Guthrie Writing & Editorial, LLC Madison Emery, Cumulus Networks Layout and Design Scott D. Lowe, ActualTech Media Copyright © 2017 by ActualTech Media. All rights reserved. No portion of this book may be reproduced or used in any manner without the express written permission of the publisher except for the use of brief quotations. The information provided within this eBook is for general informational purposes only. While we try to keep the information up- to-date and correct, there are no representations or warranties, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the information, products, services, or related graphics contained in this book for any purpose. Any use of this information is at your own risk. ActualTech Media Okatie Village Ste 103-157 Bluffton, SC 29909 www.actualtechmedia.com Entering the Jungle Introduction: Six Reasons You Need to Learn Linux ....................................................... 7 1. Linux is the future ........................................................................ 9 2. Linux is on everything .................................................................. 9 3. Linux is adaptable ....................................................................... 10 4. Linux has a strong community and ecosystem ........................... 10 5.
    [Show full text]
  • Source Routing 2.0
    Source Routing 2.0 Why Now? Why Again? Nick Slabakov [email protected] ‹#› v3 Outline Source Routing • Historical Notes SPRING • Principles of operation • Why it has motivated new discussions on source routing SPRING Inspirations • SPRING-inspired second look at existing problems Conclusions ‹#› Terminology Level-Set • Source Routing • Explicit definition of a packet path within the packet header by the source. • Source Routing is a generic term, there are many methods of doing it. • Segment Routing • Emergent network architecture based on the distribution of label (and IPv6 segment) info in the IGP. • Segment Routing is one specific way of doing Source Routing. • SPRING (Source Packet Routing In NetworkinG) • IETF working group tasked with standardizing the architecture and protocols associated with Segment Routing. ‹#› Source Routing – Short History Key idea • Prescribe the path of the packet in its header at the source; the source has unique knowledge about the desired path. • A nice side-effect is that loops can be avoided. • Reduce/remove forwarding state in the network, put it in the packet instead. Examples • Niche high-performance interconnects • Myrinet, SpaceWire, etc. • Token Ring, APPN, ANR (IBM), … • IP • IPv4 – LSRR and SRRR options. • IPv6 – Extension header of routing type. ‹#› IP Header-Based Source Routing Security Concerns and Solutions IPv4 options and IPv6 header extensions • Treated as easily spoof-able and prone to amplification attacks. • Generally disabled on all Internet-connected routers. • RFC5095 actually deprecates Type 0 routing extension header: • “An IPv6 node that receives a packet with a destination address assigned to it and that contains an RH0 extension header MUST NOT execute the algorithm specified in the latter part of Section 4.4 of [RFC2460] for RH0 …”.
    [Show full text]
  • Protecting Routing with RPKI Mark Kosters, ARIN CTO
    Protecting Routing with RPKI Mark Kosters, ARIN CTO @TeamARIN Agenda •Routing, a short •Using ARIN’s RPKI primer components •Operational routing •RPKI Statistics challenges •IRR Status •Do we have a solution? @TeamARIN 1 Core Internet Functions: Routing & DNS •The Internet relies on two critical resources • DNS: Translates domain names to IP addresses and IP addresses to domain names • Routing: Tells us how to get to an IP address •These critical resources are not secure •DNSSEC and RPKI secure these critical resources @TeamARIN 2 Routing – A Primer @TeamARIN 3 Routing Architecture •The Internet uses a two level routing hierarchy: • Interior Gateway (Routing) Protocol - IGP • Exterior Gateway (Routing) Protocol - EGP @TeamARIN 4 Routing Architecture - IGP • Interior Routing Protocols, used by each network to determine how to reach all destinations that lie within the network • Interior Routing protocols maintain the current topology of the network @TeamARIN 5 Routing Architecture - EGP • Exterior Routing Protocol, used to link each component network together into a single whole • Exterior protocols assume that each network is fully interconnected internally @TeamARIN 6 Exterior Routing: BGP •BGP is a large set of bilateral (1:1) routing sessions • A tells B all the destinations (prefixes) that A is capable of reaching • B tells A all the destinations that B is capable of reaching 10.0.0.0/24 192.2.200.0/24 10.1.0.0/16 10.2.0.0/18 A B @TeamARIN 7 Operational Routing Challenges @TeamARIN 8 Focus on Interconnections • Started out as informal
    [Show full text]
  • Multiprotocol Label Switching (MPLS)
    Multiprotocol Label Switching (MPLS) Definition Multiprotocol label switching (MPLS) is a versatile solution to address the problems faced by present-day networks—speed, scalability, quality-of-service (QoS) management, and traffic engineering. MPLS has emerged as an elegant solution to meet the bandwidth-management and service requirements for next- generation Internet protocol (IP)–based backbone networks. MPLS addresses issues related to scalability and routing (based on QoS and service quality metrics) and can exist over existing asynchronous transfer mode (ATM) and frame-relay networks. Overview This tutorial provides an in-depth look at the technology behind MPLS, with an emphasis on the protocols involved. The tutorial also discusses why MPLS is an important component in the deployment of converged networks. Topics 1. Introduction 2. Traditional Routing and Packet Switching 3. MPLS and Its Components 4. MPLS Operation 5. MPLS Protocol Stack Architecture 6. MPLS Applications 7. Standards Groups Self-Test Correct Answers Glossary 1. Introduction Over the last few years, the Internet has evolved into a ubiquitous network and inspired the development of a variety of new applications in business and Web ProForum Tutorials Copyright © 1/24 http://www.iec.org The International Engineering Consortium consumer markets. These new applications have driven the demand for increased and guaranteed bandwidth requirements in the backbone of the network. In addition to the traditional data services currently provided over the Internet, new voice and multimedia services are being developed and deployed. The Internet has emerged as the network of choice for providing these converged services. However, the demands placed on the network by these new applications and services, in terms of speed and bandwidth, have strained the resources of the existing Internet infrastructure.
    [Show full text]
  • Architecture for Programmable Network Infrastructure
    Architecture for programmable network infrastructure Tom Barbette Université de Liège Faculté des Sciences Appliquées Département d’Electricité, Electronique et Informatique Doctoral Dissertation presented in fulfilment of the requirements for the degree of Docteur en Sciences (Informatiques) May 2018 ii Summary Software networking promises a more flexible network infrastructure, poised to leverage the computational power available in datacenters. Virtual Net- work Functions (VNF) can now run on commodity hardware in datacenters instead of using specialized equipment disposed along the network path. VNFs applications like stateful firewalls, carrier-grade NAT or deep packet inspection that are found “in-the-middle”, and therefore often categorized as middleboxes, are now software functions that can be migrated to reduce costs, consolidate the processing or scale easily. But if not carefully implemented, VNFs won’t achieve high-speed and will barely sustain rates of even small networks and therefore fail to fulfil their promise. As of today, out-of-the-box solutions are far from efficient and cannot handle high rates, especially when combined in a single host, as multiple case studies will show in this thesis. We start by reviewing the current obstacles to high-speed software net- working. We leverage current commodity hardware to achieve what seemed impossible to do in software not long ago and made software solutions be- lieved unworthy and untrusted by network operators. Our work paves the way for building a proper software framework for a programmable network infrastructure that can be used to quickly implement network functions. We built FastClick, a faster version of the Click Modular Router, that allows fast packet processing thanks to a careful integration of fast I/O frame- works and a deep study of interactions of their features.
    [Show full text]
  • MPLS Segment Routing Driving a Modern Approach to MPLS Transport
    White Paper MPLS Segment Routing Driving a modern approach to MPLS transport For many years, one of the biggest challenges in network design has been effectively managing traffic flow end-to- end across the network. Stated more specifically: How is traffic intelligently classified and path engineered throughout the network? Furthermore, how can this traffic be classified into differentiated levels of service, without adding unnecessary complication to management, control plane, or data plane state in this critically important part of the network? Now, modern cloud and service provider networks in the SDN era require even more flexible control on steering of their traffic flows, at a much greater scale. With globally optimized SDN controllers utilizing parameters like distance, available bandwidth, latency, cost of long-haul links and business logic into their path computation algorithms, there is an increased need for flexible, intelligent source routing solutions. More and more operators have made a concerted effort to simplify their networks and eliminate the dependency on a wide set of protocols to achieve their goals. As native IPv6 deployments increase, there is a need for a native solution for IPv6 networks and IP backbones that provides the same capabilities as current MPLS networks. This seems like an impossible set of opposing requirements to reconcile. Traditional MPLS implementations did address some of the original challenges, but they came with a complex array of protocols, suffered from scaling challenges and had rigid vendor specific path computation algorithms for Traffic Engineering (TE). They also did not provide native IPv6 support across the protocol stack. Segment routing is the technology that elegantly addresses this varied set of requirements across many different networking domains: datacenter, content delivery networks and metro networks, to name a few.
    [Show full text]
  • One Year of Frrouting
    One year of FRRouting Martin Winter NetDEF / OpenSourceRouting 1 1 Year ago at RIPE 74: What is FRR ? (for the not so technical People) ‣ Open Source (GPLv2+) Routing Stack ‣ Implements RIP, RIPng, OSPF (v2&v3), ISIS, BGP, PIM, LDP ‣ Fork of Quagga ‣ Works on Linux and most BSD based systems ‣ For use in many Clouds as virtual routers, white box vendors and network providers (full routing stack) 2 1 Year ago at RIPE 74: FRR - Why a new fork? Community Led and Driven Fast & Open Development Open Community Model 3 1 Year ago at RIPE 74: FRR - What’s different? ‣ Methodical vetting of submissions ‣ Extensive automated testing of contributions ‣ Git Pull Requests ‣ Github centered development ‣ Elected Maintainers & Steering Committee ‣ Common Assets held in trust by Linux Foundation 4 What happened since the fork? Code size doubled - 11,310 10,000 8000 Commits to FRR since the first public release a year ago 6000 Commits to FRR in fork before the first release 4000 2000 Commits in Quagga from 2002 until the time where the fork began 0 FRRouting fork 500st 1000st 1500st announced Pull Req Pull Req Pull Req submitted submitted submitted Now Apr 2017 Aug Oct Jan 2018 Mar April (May) soon FRR 2.0 FRR 3.0 FRR 4.0 FRR 5.0 LDP IPv4/v6, BGP Add- BGP Large Comm, BGP BGP RPKI, BGP EVPN Type Policy-Based Routing Path, Nexthop tracking, partial EVPN RT-5, LDP 2/3, BGP v4 labeled Daemon, ISIS 3way JSON output, Linux VRF Capabilities, ISIS SPF unicast, ISIS Multitopo, Handshake, BGP VRF lite, OSPF unnumbered, Backoff, PIM SM, PIM EIGRP, BABEL, OSPFv2 with
    [Show full text]