We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byAnnette Dunaway
Modified over 2 years ago
LATEST DEVELOPMENTS IN THE IETF ROUTING AREA Adrian Farrel IETF Routing Area Director firstname.lastname@example.org email@example.com firstname.lastname@example.org email@example.com AUSNOG, Sydney, September 2013
2 Copyright © 2013 Juniper Networks, Inc. www.juniper.net LATEST DEVELOPMENTS IN THE IETF ROUTING AREA Objectives Introduce some of the newer ideas in the Routing Area Get you interested enough to read and comment on the work Non-objectives Discuss IETF things outside the Routing Area Cover anything old or established Cover everything new Go into much detail Explain what Juniper is doing or thinks about this stuff Me… One of two Routing Area Directors One of 15 Area Directors on the Internet Engineering Steering Group Funded by Juniper Networks –…but these are just my views
3 Copyright © 2013 Juniper Networks, Inc. www.juniper.net AGENDA Security and Privacy How can the routing infrastructure contribute to network security and privacy? Interface to the Routing System Wouldn’t it be nice if I had a standardised way to talk to the routing infrastructure? Source Routing What can we achieve if each packet carries information about its planned path through the network? Service Chaining How can we enable network function virtualisation and what is the interaction with routing? How to Participate in the IETF What can you do and how do you get involved?
SECURITY AND PRIVACY
5 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SECURITY AND PRIVACY Who cares and why do they care? The main concern seems to be the stability of the global routing system Route hijacks Fat fingers –“99% of mis-announcements are accidental originations of someone else’s prefix” Randy Bush quoting Google, UU, IIJ, et al. Security of internal protocols (IGP, MPLS, etc.) “less of a concern” ACLs make it harder to inject Stability of routing is of value to attackers! Security and privacy are beginning to be taken seriously post- PRISM Making it harder (more expensive) to snoop Hiding who is talking to whom
6 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SECURITY AND PRIVACY – WHAT IS THE IETF DOING? SIDR Working specifically on vulnerabilities in the inter-domain routing system Is an Autonomous System (AS) authorized to originate an IP prefix? Is the AS-Path represented in the route the same as the path through which the NLRI travelled? Not new work, and becoming mature 19 RFCs on RPKI and Origin Validation Examining additional security features for BGP Questions are now about adoption and deployment KARP Investigating security vulnerabilities in core routing protocols Identifying areas for work – devolved to the protocol working groups Formulating “best practices” Also not new work, and no surprises Clear text passwords and MD5 are not too clever TCP-AO would be good to use There are some holes around Discovery and Hello mechanisms Automatic key rotation is missing and might not be wanted PERPASS A new mailing list for discussion of privacy
INTERFACE TO THE ROUTING SYSTEM
8 Copyright © 2013 Juniper Networks, Inc. www.juniper.net WHY INTERFACE TO THE ROUTING SYSTEM (I2RS) SDN focuses on programming the data plane Switch programming (cross-connects) Forwarding (FIB) There are many functions and features not covered by SDN Control of routers Control of routing protocols Management of the “routing system” Existing techniques are non-standard Using CLI to achieve these functions is very frustrating Expensive, time-consuming, error-prone, risky Need for a standard approach Strong desire for a simple and standard approach
9 Copyright © 2013 Juniper Networks, Inc. www.juniper.net I2RS ARCHITECTURE Forwarding Plane FIB RIBs and RIB Manager Policy DB Routing and Signaling Protocols Topology DB OAM, Events and Measurement I2RS Agent I2RS Client Router Server Application I2RS Protocol & Data Encoding
10 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SIMPLE USE CASES FOR I2RS Use cases are being driven by conversations with operators Only working on ideas that operators want to deploy soon Reality of use cases depends on vendors’ implementations Some functions are easier to achieve than others! Starting with simple use cases that can be achieved easily and which will make significant difference to operational practices Current work is to net down to a few key use cases Programming and managing the RIB BGP use cases Traffic steering and classification DDoS mitigation Topology reading, monitoring, and control Service chaining
11 Copyright © 2013 Juniper Networks, Inc. www.juniper.net I2RS – PROGRAMMING AND MANAGING THE RIB Read/write data in the RIB Routes installed Candidate routes for different purposes IP Multicast MPLS RIB Tables RIB change notifications (on specific filters) Read-only data from FIB Prefix + next-hop for verification of FIB programming Optimizing exit control Route traffic from a network device to a given edge device / interface based on business logic Control outgoing encapsulation IP, GRE, MPLS, etc.
12 Copyright © 2013 Juniper Networks, Inc. www.juniper.net I2RS – BGP USE CASES Troubleshooting and Analysis of BGP Route reachability, Expected exit points Route hijacking detection, Route stability analysis and damping Reporting routes dropped (Policy based, Malformed, etc) Reporting damped/unstable routes Protocol statistics Performance Based Routing Compute least delay exit paths, least cost exit paths Assure SLAs Reduce jitter and RTT of data plane Spread utilization of external links BGP configuration Centralize BGP policy VPN provisioning and stitching Advanced BGP uses Service chaining (requires protocol updates) Route manipulation
13 Copyright © 2013 Juniper Networks, Inc. www.juniper.net I2RS – WHAT WORK IS NEEDED? Architecture Now a working group draft Use Cases Converging on some key cases Information Models Work well progressed on RIB information model Requirements Requirements for Data Encoding Language(s) Parsable, extensible, recursion, programmable Requirements for Data Exchange Protocol(s) Non-blocking transactions, stateless, duplex, multi-channel Protocol Choices and Extensions Encoding candidates YANG, XML, ForCES schema, JSON, SMI Protocol candidates Netconf, XMPP, HTTP, COAP, ForCES, IPFIX Work to be done in the appropriate working group Data Models
15 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SOURCE ROUTING – AN OVERLOADED TERM IP Source Routing A list of IP hops to traverse IPv4 Options for Loose and Strict Source Routes Only 9 hops, don’t cross AS boundaries, not used IPv6 Source Route Deprecated! Source-aware Routing Hop-by-hop routing decisions take account of source as well as destination A form of policy-based routing Source-based Classification to a Tunnel A concept applying to any tunnelling and especially MPLS Packets are labelled and then follow an LSP Explicit Routing A term usually associated with MPLS-TE path establishment Packets follow the path of a pinned LSP
16 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SOURCE ROUTING – IGP LABELS Suppose: Every router in a IGP domain creates 1-hop LSPs to its IGP neighbors For each such neighbor advertise the label in the IGP Flood to everyone in the IGP domain the label used by the LSP terminating at the neighbor (as well as the identity of the neighbor) Label effectively identifies a neighbor or even an interface
17 Copyright © 2013 Juniper Networks, Inc. www.juniper.net IGP LABELS - CONSEQUENCES A source node can impose a path by using a label stack Can be used to describe an arbitrary number of paths in the network Potential uses Per-micro-flow traffic engineering Signaling-free (state-free) traffic engineering Fast reroute Directed OAM Concerns and limitations How big is the label stack? Interaction with special-purpose labels? Path computation requirements? No change to the data plane
18 Copyright © 2013 Juniper Networks, Inc. www.juniper.net IGP LABELS : EXAMPLE FOR EXPLICIT PATHS
19 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SOURCE ROUTING – TUNNELS AS LABELS Existing LSPs become “hops” LDP or RSVP LSPs IGP en-queues LSP tail end routes into tunnel RIBs I.e., the tunnel provides a forwarding adjacency Third-party next hop gets set to originating router transport loopback Label stack construction At the head end is a sequence of “hops” Is expanded as part of route resolution
20 Copyright © 2013 Juniper Networks, Inc. www.juniper.net TUNNELS AS LABELS - EXAMPLE LDP 301 302 301300302200100 Example Label Stack
21 Copyright © 2013 Juniper Networks, Inc. www.juniper.net TUNNELS AS LABELS - CONSEQUENCES A source node can impose a path that includes LSPs Can be used to stitch together different types of LSP Potential uses “Seamless MPLS” Extend MPLS to the edge Reduce label stack size on long paths Distribute responsibility for path computation Fast reroute and pre-planned path segments Even IGP reachable label paths can be represented Models VPNs and BGP reachability Concerns and limitations More complex additions to IGPs or BGP More complex management/debug No change to the data plane
22 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SOURCE ROUTING – WHAT IS THE IETF DOING? It is really early stages in the IETF for source routing A bunch of drafts from Cisco and Juniper Lots of interest from service providers Held a BoF at IETF-87 on “segment routing” called STATUS Lots of enthusiasm Some oceans were boiled The STATUS email list is active Discussing drafts and technology Trying to focus towards a working group Likely to meet at IETF-88 as a BoF or a Working Group Scoped to architecture and use cases? Technology independent? IPv6 in or out of scope?
24 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SERVICE CHAINING – PROBLEM STATEMENT Today’s workloads consist of multi-tiered applications Multiple distributed entities (e.g., Web server, load balancers, data base servers, etc.) cooperate to provide a service Individual workload components communicate with each other in carefully defined ways Traffic between components is required (by policy) to flow through specialized network services (e.g., firewalls, IDS, etc.) Resultant communication flows are modelled as “service chains” Today, steering of traffic between services within a service chain is achieved via L2/L3 data plane forwarding Complex and difficult to automate Predicted scaling challenges Current network service deployment models are generally static, hard to manipulate (create, move, destroy) Currently no (efficient) way to share information between the network and services, or among services in a chain Virtual platforms require an agile service insertion model With horizontal/vertical scaling requirements Source: after Guichard and Narten (IETF-87)
25 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SERVICE CHAINING – MODEL Services provided off-path by physical or virtual service nodes Packets diverted through tunnels Return to forwarding path By tunnel Via forwarding After attention by other service nodes Shortest path Tunnel Forwarding path
26 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SERVICE CHAINING - QUESTIONS What services are we talking about? At what level is service chaining applied? Per transaction Per flow Per packet How is the service chain determined? By operators / planning tools By the service nodes themselves Where is the chain of services encoded? In configuration at the service nodes In messages in the transactions/flows In per-packet data Is this really a data centre / virtualization problem? How do service nodes exchange information? Why would they want to? What are the security implications? Is there a communications protocol? Do we need meta-data in packets?
27 Copyright © 2013 Juniper Networks, Inc. www.juniper.net SERVICE CHAINING – WHAT IS THE IETF DOING? It is really early stages in the IETF for service chaining A bunch of drafts from Cisco and Huawei Lots of interest from network operators Held a BoF at IETF-87 on “network service chaining” called NSC Limited to presentations of use cases by network operators Lots of enthusiasm Focus and common use of terms was absent The NSC email list is active Discussing drafts and terminology Trying to focus scope towards another BoF at IETF-88 Intent is to make this WG-forming Issues of overlap with other work I2RS? Source Routing? ALTO?
HOW TO PARTICIPATE IN THE IETF
29 Copyright © 2013 Juniper Networks, Inc. www.juniper.net HOW DOES THE IETF WORK? The IETF is an open standards organisation All standards documents are freely downloadable Participation is open to everyone Work in progress is openly accessible Standards gestate as internet-Drafts Anyone can write and post an Internet-Draft Work is broken up into broad topics A working group for each topic Governed by a charter with deliverables The work is done predominantly by email Mailing list for each working group Anyone can subscribe Review and discussion of Internet-Drafts Face-to-face meetings three times per year Useful for high-bandwidth communications Attendance is far from essential
30 Copyright © 2013 Juniper Networks, Inc. www.juniper.net HOW CAN YOU CONTRIBUTE TO THE IETF? Participation by network operators is particularly welcomed Some operators are quite active (Orange, DT, Google, …) Internet Engineering Providers Group (IEPG) Informal meeting before every IETF meeting Things to do… Subscribe to mailing lists and read the threads Read Internet-Drafts and comment on them In private to the authors if you are shy Make editorial or technical comments Initiate work you care about Send mail Write an Internet-Draft Ask vendors to work with you Ask an Area Director for help
Questions? firstname.lastname@example.org email@example.com
NEW OUTLOOK ON MULTI-DOMAIN AND MULTI-LAYER TRAFFIC ENGINEERING Adrian Farrel
The Impact of SDN On MPLS Networks Adrian Farrel Juniper Networks
Chapter 1: Introduction to Scaling Networks
Recent Progress in Routing Standardization An IETF update for UKNOF 23 Old Dog Consulting Adrian
Multihoming and Multi-path Routing
© 2010 Cisco and/or its affiliates. All rights reserved. 1 Segment Routing Clarence Filsfils – Distinguished Engineer Christian Martin –
OLD DOG CONSULTING Challenges and Solutions for OAM in Point-to-Multipoint MPLS Adrian Farrel, Old Dog Consulting Ltd. Zafar Ali, Cisco Systems, Inc.
Segment Routing: An Architecture build with SDN in mind and addressing the evolving network requirements Brian Meaney Cisco SP Consulting Team.
Draft-mackie-sfc-using-virtual-networking-02 S. Mackie, B. Rijsman, Juniper Networks M. Napierala, AT&T D. Daino, Telecom Italia D.R. Lopez, Telefonica.
Model-based Programmable Networks
A Snapshot on MPLS Reliability Features Ping Pan March, 2002.
An Architecture for Application-Based Network Operations Adrian Farrel - Old Dog Consulting Daniel King –
MPLS H/W update Brief description of the lab What it is? Why do we need it? Mechanisms and Protocols.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v MPLS VPN Technology Introducing the MPLS VPN Routing Model.
1 Multi-Protocol Label Switching (MPLS) presented by: chitralekha tamrakar (B.S.E.) divya krit tamrakar (B.S.E.) Rashmi shrivastava(B.S.E.) prakriti.
© 2007 Cisco Systems, Inc. All rights reserved.Cisco Public ITE PC v4.0 Chapter 1 1 Link-State Routing Protocols Routing Protocols and Concepts – Chapter.
A New Paradigm for Inter-Domain Traffic Engineering Adrian Farrel Juniper Networks
Identifying MPLS Applications
Moving towards an IRS WG Charter Ross Callon IETF 85, Atlanta.
© 2009 Cisco Systems, Inc. All rights reserved. Cisco Public Presentation_ID 1 BGP-Prefix Segment in large-scale data centers draft-filsfils-spring-segment-routing-msdc-00.
Page 1 iPOP2009, Tokyo, Japan Selecting Domain Paths in Inter-Domain MPLS-TE and GMPLS Adrian Farrel, Old Dog Consulting Daniel King, Old Dog Consulting.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—2-1 Label Assignment and Distribution Introducing Typical Label Distribution in Frame-Mode MPLS.
Virtual Topologies for Service Chaining in BGP IP/MPLS VPNs draft-rfernando-bess-service-chaining-00 (previously draft-rfernando-l3vpn-service-chaining-04)
Network Monitoring System In CSTNET Long Chun China Science & Technology Network.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v MPLS VPN Technology Introducing MPLS VPN Architecture.
Logically Centralized Control Class 2. Types of Networks ISP Networks – Entity only owns the switches – Throughput: 100GB-10TB – Heterogeneous devices:
MPLS L3 and L2 VPNs Virtual Private Network –Connect sites of a customer over a public infrastructure Requires: –Isolation of traffic Terminology –PE,
Draft-li-rtgwg-cc-igp-arch-00IETF 88 RTGWG1 An Architecture of Central Controlled Interior Gateway Protocol (IGP) draft-li-rtgwg-cc-igp-arch-00 Zhenbin.
Multi-protocol Label Switching. MPLS Introduction Motivation MPLS Basics Components and Protocols Operation Advantages and Disadvantages.
Copyright © 2004 Juniper Networks, Inc. Proprietary and Confidentialwww.juniper.net 1 Multicast in BGP/MPLS VPNs draft-ietf-l3vpn-2547bis-mcast-00.txt.
Dynamic Routing Overview 1.
Internetworking II: MPLS, Security, and Traffic Engineering
Application-Based Network Operations (ABNO) IETF 88 – SDN RG
Multihoming and Multi-path Routing CS 7260 Nick Feamster January
Why SDN and MPLS? Saurav Das, Ali Reza Sharafat, Guru Parulkar, Nick McKeown Clean Slate CTO Summit 9 th November, 2011.
More on Internet Routing A large portion of this lecture material comes from BGP tutorial given by Philip Smith from Cisco (ftp://ftp- eng.cisco.com/pfs/seminars/APRICOT2004.
Deployment of MPLS VPN in Large ISP Networks
An Operational Perspective on BGP Security Geoff Huston GROW WG IETF 63 August 2005.
Optical Control Plane Activities in IETF and OIF L. Ong 9 July 2002 L. Ong 9 July 2002
MPLS Introduction How MPLS Works ?? MPLS - The Motivation MPLS Application MPLS Advantages Conclusion.
Introduction to OSPF Nishal Goburdhan. Routing and Forwarding Routing is not the same as Forwarding Routing is the building of maps Each routing protocol.
1 Multi Protocol Label Switching Presented by: Petros Ioannou Dept. of Electrical and Computer Engineering, UCY.
Virtual Links: VLANs and Tunneling
The Platform as a Service Model for Networking Eric Keller, Jennifer Rexford Princeton University INM/WREN 2010.
Dynamic Routing Scalable Infrastructure Workshop, AfNOG2008.
FORUM ON NEXT GENERATION STANDARDIZATION (Colombo, Sri Lanka, 7-10 April 2009) A Pilot Implementation of an NGN Dual Stack IPv4/IPv6 network for MEWC,
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—8-1 MPLS TE Overview Understanding MPLS TE Components.
© 2017 SlidePlayer.com Inc. All rights reserved.