draft-ietf-bess-datacenter-gateway-05.txt   draft-ietf-bess-datacenter-gateway-06.txt 
BESS Working Group A. Farrel BESS Working Group A. Farrel
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended status: Standards Track J. Drake Intended status: Standards Track J. Drake
Expires: September 12, 2020 E. Rosen Expires: December 3, 2020 E. Rosen
Juniper Networks Juniper Networks
K. Patel K. Patel
Arrcus, Inc. Arrcus, Inc.
L. Jalil L. Jalil
Verizon Verizon
March 11, 2020 June 1, 2020
Gateway Auto-Discovery and Route Advertisement for Segment Routing Gateway Auto-Discovery and Route Advertisement for Segment Routing
Enabled Domain Interconnection Enabled Domain Interconnection
draft-ietf-bess-datacenter-gateway-05 draft-ietf-bess-datacenter-gateway-06
Abstract Abstract
Data centers are critical components of the infrastructure used by Data centers are critical components of the infrastructure used by
network operators to provide services to their customers. Data network operators to provide services to their customers. Data
centers are attached to the Internet or a backbone network by gateway centers are attached to the Internet or a backbone network by gateway
routers. One data center typically has more than one gateway for routers. One data center typically has more than one gateway for
commercial, load balancing, and resiliency reasons. commercial, load balancing, and resiliency reasons.
Segment Routing is a popular protocol mechanism for use within a data Segment Routing is a protocol mechanism that can be used within a
center, but also for steering traffic that flows between two data data center, and also for steering traffic that flows between two
center sites. In order that one data center site may load balance data center sites. In order that one data center site may load
the traffic it sends to another data center site, it needs to know balance the traffic it sends to another data center site, it needs to
the complete set of gateway routers at the remote data center, the know the complete set of gateway routers at the remote data center,
points of connection from those gateways to the backbone network, and the points of connection from those gateways to the backbone network,
the connectivity across the backbone network. and the connectivity across the backbone network.
Segment Routing may also be operated in other domains, such as access Segment Routing may also be operated in other domains, such as access
networks. Those domains also need to be connected across backbone networks. Those domains also need to be connected across backbone
networks through gateways. networks through gateways.
This document defines a mechanism using the BGP Tunnel Encapsulation This document defines a mechanism using the BGP Tunnel Encapsulation
attribute to allow each gateway router to advertise the routes to the attribute to allow each gateway router to advertise the routes to the
prefixes in the Segment Routing domains to which it provides access, prefixes in the Segment Routing domains to which it provides access,
and also to advertise on behalf of each other gateway to the same and also to advertise on behalf of each other gateway to the same
Segment Routing domain. Segment Routing domain.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2020. This Internet-Draft will expire on December 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
1. Introduction 1. Introduction
Data centers (DCs) are critical components of the infrastructure used Data centers (DCs) are critical components of the infrastructure used
by network operators to provide services to their customers. DCs are by network operators to provide services to their customers. DCs are
attached to the Internet or a backbone network by gateway routers attached to the Internet or a backbone network by gateway routers
(GWs). One DC typically has more than one GW for various reasons (GWs). One DC typically has more than one GW for various reasons
including commercial preferences, load balancing, and resiliency including commercial preferences, load balancing, and resiliency
against connection of device failure. against connection of device failure.
Segment Routing (SR) [RFC8402] is a popular protocol mechanism for Segment Routing (SR) [RFC8402] is a protocol mechanism that can be
use within a DC, but also for steering traffic that flows between two used within a DC, and also for steering traffic that flows between
DC sites. In order for a source (ingress) DC that uses SR to load two DC sites. In order for a source (ingress) DC that uses SR to
balance the flows it sends to a destination (egress) DC, it needs to load balance the flows it sends to a destination (egress) DC, it
know the complete set of entry nodes (i.e., GWs) for that egress DC needs to know the complete set of entry nodes (i.e., GWs) for that
from the backbone network connecting the two DCs. Note that it is egress DC from the backbone network connecting the two DCs. Note
assumed that the connected set of DCs and the backbone network that it is assumed that the connected set of DCs and the backbone
connecting them are part of the same SR BGP Link State (LS) instance network connecting them are part of the same SR BGP Link State (LS)
([RFC7752] and [I-D.ietf-idr-bgpls-segment-routing-epe]) so that instance ([RFC7752] and [I-D.ietf-idr-bgpls-segment-routing-epe]) so
traffic engineering using SR may be used for these flows. that traffic engineering using SR may be used for these flows.
SR may also be operated in other domains, such as access networks. SR may also be operated in other domains, such as access networks.
Those domains also need to be connected across backbone networks Those domains also need to be connected across backbone networks
through gateways. through gateways.
Suppose that there are two gateways, GW1 and GW2 as shown in Suppose that there are two gateways, GW1 and GW2 as shown in
Figure 1, for a given egress SR domain and that they each advertise a Figure 1, for a given egress SR domain and that they each advertise a
route to prefix X which is located within the egress SR domain with route to prefix X which is located within the egress SR domain with
each setting itself as next hop. One might think that the GWs for X each setting itself as next hop. One might think that the GWs for X
could be inferred from the routes' next hop fields, but typically it could be inferred from the routes' next hop fields, but typically it
skipping to change at page 9, line 46 skipping to change at page 9, line 46
assigned to every GW to the same domain, and each domain MUST have a assigned to every GW to the same domain, and each domain MUST have a
different identifier. This requires coordination, probably through a different identifier. This requires coordination, probably through a
central management agent. central management agent.
It should be noted that BGP peerings are not discovered, but always It should be noted that BGP peerings are not discovered, but always
arise from explicit configuration. This is no different from any arise from explicit configuration. This is no different from any
other BGP operation. other BGP operation.
10. Acknowledgements 10. Acknowledgements
Thanks to Bruno Rijsman and Stephane Litkowsji for review comments, Thanks to Bruno Rijsman, Stephane Litkowsji, and Boris Hassanov for
and to Robert Raszuk for useful discussions. review comments, and to Robert Raszuk for useful discussions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
S., and J. Dong, "BGP-LS extensions for Segment Routing S., and J. Dong, "BGP-LS extensions for Segment Routing
BGP Egress Peer Engineering", draft-ietf-idr-bgpls- BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
segment-routing-epe-19 (work in progress), May 2019. segment-routing-epe-19 (work in progress), May 2019.
 End of changes. 7 change blocks. 
23 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/