draft-ietf-dmm-srv6-mobile-uplane-12.txt   draft-ietf-dmm-srv6-mobile-uplane-13.txt 
DMM Working Group S. Matsushima, Ed. DMM Working Group S. Matsushima, Ed.
Internet-Draft SoftBank Internet-Draft SoftBank
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: November 5, 2021 M. Kohno Expires: November 22, 2021 M. Kohno
P. Camarillo, Ed. P. Camarillo, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
D. Voyer D. Voyer
Bell Canada Bell Canada
C. Perkins C. Perkins
Futurewei Lupin Lodge
May 4, 2021 May 21, 2021
Segment Routing IPv6 for Mobile User Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-12 draft-ietf-dmm-srv6-mobile-uplane-13
Abstract Abstract
This document shows the applicability of SRv6 (Segment Routing IPv6) This document shows the applicability of SRv6 (Segment Routing IPv6)
to the user-plane of mobile networks. The network programming nature to the user-plane of mobile networks. The network programming nature
of SRv6 accomplishes mobile user-plane functions in a simple manner. of SRv6 accomplishes mobile user-plane functions in a simple manner.
The statelessness of SRv6 and its ability to control both service The statelessness of SRv6 and its ability to control both service
layer path and underlying transport can be beneficial to the mobile layer path and underlying transport can be beneficial to the mobile
user-plane, providing flexibility, end-to-end network slicing, and user-plane, providing flexibility, end-to-end network slicing, and
SLA control for various applications. This document describes the SLA control for various applications. This document describes the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 November 5, 2021. This Internet-Draft will expire on November 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 2, line 37 skipping to change at page 2, line 37
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. 3GPP Reference Architecture . . . . . . . . . . . . . . . . . 6 4. 3GPP Reference Architecture . . . . . . . . . . . . . . . . . 6
5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7 5. User-plane behaviors . . . . . . . . . . . . . . . . . . . . 7
5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7 5.1. Traditional mode . . . . . . . . . . . . . . . . . . . . 7
5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8 5.1.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 8
5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9 5.1.2. Packet flow - Downlink . . . . . . . . . . . . . . . 9
5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Enhanced Mode . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10 5.2.1. Packet flow - Uplink . . . . . . . . . . . . . . . . 10
5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11 5.2.2. Packet flow - Downlink . . . . . . . . . . . . . . . 11
5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 11 5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 11
5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 12
5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12
5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15
5.3.3. Extensions to the interworking mechanisms . . . . . . 17 5.3.3. Extensions to the interworking mechanisms . . . . . . 17
5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17 5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17
6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 19 6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 19
6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19
6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20
6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 21 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 21
6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 22 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 7, line 11 skipping to change at page 7, line 11
IP address from the DHCP block of its UPF. The UPF advertises that IP address from the DHCP block of its UPF. The UPF advertises that
IP address block toward the Internet, ensuring that return traffic is IP address block toward the Internet, ensuring that return traffic is
routed to the right UPF. routed to the right UPF.
5. User-plane behaviors 5. User-plane behaviors
This section introduces an SRv6 based mobile user-plane. This section introduces an SRv6 based mobile user-plane.
In order to simplify the adoption of SRv6, we present two different In order to simplify the adoption of SRv6, we present two different
"modes" that vary with respect to the use of SRv6. The first one is "modes" that vary with respect to the use of SRv6. The first one is
the "Traditional mode", which inherits the current 3GPP mobile user- the "Traditional mode", which inherits the current 3GPP mobile
plane. In this mode GTP-U protocol [TS.29281] is replaced by SRv6, architecture. In this mode GTP-U protocol [TS.29281] is replaced by
however the N3, N9 and N6 interfaces are still point-to-point SRv6, however the N3, N9 and N6 interfaces are still point-to-point
interfaces with no intermediate waypoints as in the current mobile interfaces with no intermediate waypoints as in the current mobile
network architecture. network architecture.
The second mode is the "Enhanced mode". This is an evolution from The second mode is the "Enhanced mode". This is an evolution from
the "Traditional mode". In this mode the N3, N9 or N6 interfaces the "Traditional mode". In this mode the N3, N9 or N6 interfaces
have intermediate waypoints -SIDs- that are used for Traffic have intermediate waypoints -SIDs- that are used for Traffic
Engineering or VNF purposes. This results in optimal end-to-end Engineering or VNF purposes. This results in optimal end-to-end
policies across the mobile network with transport and services policies across the mobile network with transport and services
awareness. awareness.
skipping to change at page 7, line 52 skipping to change at page 8, line 4
5.1. Traditional mode 5.1. Traditional mode
In the traditional mode, the existing mobile UPFs remain unchanged In the traditional mode, the existing mobile UPFs remain unchanged
with the sole exception of the use of SRv6 as the data plane instead with the sole exception of the use of SRv6 as the data plane instead
of GTP-U. There is no impact to the rest of the mobile system. of GTP-U. There is no impact to the rest of the mobile system.
In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1
with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored
here to replace GTP encapsulation with the SRv6 encapsulation, while here to replace GTP encapsulation with the SRv6 encapsulation, while
not changing anything else. There will be a unique SRv6 SID not changing anything else. There will be a unique SRv6 SID
associated with each PDU Session. associated with each PDU Session, and the SID list only contains a
single SID.
The traditional mode minimizes the changes required to the mobile The traditional mode minimizes the changes required to the mobile
system; hence it is a good starting point for forming a common system; hence it is a good starting point for forming a common
ground. ground.
The gNB/UPF control-plane (N2/N4 interface) is unchanged,
specifically a single IPv6 address is provided to the gNB. The same
control plane signalling is used, and the gNB/UPF decides to use SRv6
based on signaled GTP-U parameters per local policy.
Our example topology is shown in Figure 2. In traditional mode the Our example topology is shown in Figure 2. In traditional mode the
gNB and the UPFs are SR-aware. In the descriptions of the uplink and gNB and the UPFs are SR-aware. In the descriptions of the uplink and
downlink packet flow, A is an IPv6 address of the UE, and Z is an downlink packet flow, A is an IPv6 address of the UE, and Z is an
IPv6 address reachable within the Data Network DN. A new SRv6 IPv6 address reachable within the Data Network DN. A new SRv6
Endpoint Behavior, End.MAP, defined in Section 6.2, is used. Endpoint Behavior, End.MAP, defined in Section 6.2, is used.
________ ________
SRv6 SRv6 / \ SRv6 SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN / |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
skipping to change at page 9, line 47 skipping to change at page 10, line 6
Thus, the main difference is that the SR policy MAY include SIDs for Thus, the main difference is that the SR policy MAY include SIDs for
traffic engineering and service programming in addition to the traffic engineering and service programming in addition to the
anchoring SIDs at UPFs. anchoring SIDs at UPFs.
Additionally in this mode the operator may choose to aggregate Additionally in this mode the operator may choose to aggregate
several devices under the same SID list (e.g., stationary residential several devices under the same SID list (e.g., stationary residential
meters connected to the same cell) to improve scalability. meters connected to the same cell) to improve scalability.
The gNB control-plane (N2 interface) is unchanged, specifically a The gNB control-plane (N2 interface) is unchanged, specifically a
single IPv6 address is provided to the gNB. single IPv6 address is provided to the gNB. A local policy instructs
the gNB to use SRv6.
The gNB MAY resolve the IP address received via the control plane The gNB MAY resolve the IP address received via the control plane
into a SID list using a mechanism like PCEP, DNS-lookup, LISP into a SID list using a mechanism like PCEP, DNS-lookup, LISP
control-plane or others. The resolution mechanism is out of the control-plane or others. The resolution mechanism is out of the
scope of this document. scope of this document.
Note that the SIDs MAY use the arguments Args.Mob.Session if required Note that the SIDs MAY use the arguments Args.Mob.Session if required
by the UPFs. by the UPFs.
Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the Figure 3 shows an Enhanced mode topology. In the Enhanced mode, the
skipping to change at page 11, line 47 skipping to change at page 12, line 12
compared to Traditional Mode (unique SID per UE) and compared to compared to Traditional Mode (unique SID per UE) and compared to
GTP-U (dedicated TEID per UE). GTP-U (dedicated TEID per UE).
5.3. Enhanced mode with unchanged gNB GTP behavior 5.3. Enhanced mode with unchanged gNB GTP behavior
This section describes two mechanisms for interworking with legacy This section describes two mechanisms for interworking with legacy
gNBs that still use GTP: one for IPv4, and another for IPv6. gNBs that still use GTP: one for IPv4, and another for IPv6.
In the interworking scenarios as illustrated in Figure 4, the gNB In the interworking scenarios as illustrated in Figure 4, the gNB
does not support SRv6. The gNB supports GTP encapsulation over IPv4 does not support SRv6. The gNB supports GTP encapsulation over IPv4
or IPv6. To achieve interworking, an SR Gateway (SRGW-UPF1) entity or IPv6. To achieve interworking, an SR Gateway (SRGW) entity is
is added. The SRGW maps the GTP traffic into SRv6. added. The SRGW maps the GTP traffic into SRv6.
The SRGW is not an anchor point and maintains very little state. For The SRGW is not an anchor point and maintains very little state. For
this reason, both IPv4 and IPv6 methods scale to millions of UEs. this reason, both IPv4 and IPv6 methods scale to millions of UEs.
_______ _______
IP GTP SRv6 / \ IP GTP SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \ +--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |---------\ DN / |UE|------| gNB |------| SRGW |--------| UPF |---------\ DN /
+--+ +-----+ +------+ +------+ \_______/ +--+ +-----+ +------+ +------+ \_______/
SR Gateway SRv6 node SR Gateway SRv6 node
Figure 4: Example topology for interworking Figure 4: Example topology for interworking
Both of the mechanisms described in this section are applicable to Both of the mechanisms described in this section are applicable to
either the Traditional Mode or the Enhanced Mode. either the Traditional Mode or the Enhanced Mode.
5.3.1. Interworking with IPv6 GTP 5.3.1. Interworking with IPv6 GTP
skipping to change at page 12, line 37 skipping to change at page 12, line 50
one IPv6 address is needed (i.e. a BSID at the SRGW). one IPv6 address is needed (i.e. a BSID at the SRGW).
o In the uplink, the SRGW removes GTP, finds the SID list related to o In the uplink, the SRGW removes GTP, finds the SID list related to
the IPv6 DA, and adds SRH with the SID list. the IPv6 DA, and adds SRH with the SID list.
o There is no state for the downlink at the SRGW. o There is no state for the downlink at the SRGW.
o There is simple state in the uplink at the SRGW; using Enhanced o There is simple state in the uplink at the SRGW; using Enhanced
mode results in fewer SR policies on this node. An SR policy is mode results in fewer SR policies on this node. An SR policy is
shared across UEs. shared across UEs.
o When a packet from the UE leaves the gNB, it is SR-routed. This o When a packet from the UE leaves the gNB, it is SR-routed. This
simplifies network slicing [I-D.ietf-lsr-flex-algo]. simplifies network slicing [I-D.ietf-lsr-flex-algo].
o In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic o In the uplink, the SRv6 BSID located in the IPv6 DA steers traffic
into an SR policy when it arrives at the SRGW-UPF1. into an SR policy when it arrives at the SRGW.
An example topology is shown in Figure 5. An example topology is shown in Figure 5.
S1 and C1 are two service segments. S1 represents a VNF in the S1 and C1 are two service segments. S1 represents a VNF in the
network, and C1 represents a router configured for Traffic network, and C1 represents a router configured for Traffic
Engineering. Engineering.
+----+ +----+
IPv6/GTP -| S1 |- ___ IPv6/GTP -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ / +--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] / |UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN +--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP \ +------+ / +----+ +------+ \___ GTP \ +------+ / +----+ +------+ \___
-| UPF1 |- SRv6 SRv6 -| SRGW |- SRv6 SRv6
+------+ TE +------+ TE
SR Gateway SR Gateway
Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior
5.3.1.1. Packet flow - Uplink 5.3.1.1. Packet flow - Uplink
The uplink packet flow is as follows: The uplink packet flow is as follows:
UE_out : (A,Z) UE_out : (A,Z)
skipping to change at page 17, line 31 skipping to change at page 17, line 34
gNBs and UPFs that do not support SRv6. These mechanisms are used to gNBs and UPFs that do not support SRv6. These mechanisms are used to
support GTP over IPv4 and IPv6. support GTP over IPv4 and IPv6.
Even though we have presented these methods as an extension to the Even though we have presented these methods as an extension to the
"Enhanced mode", it is straightforward in its applicability to the "Enhanced mode", it is straightforward in its applicability to the
"Traditional mode". "Traditional mode".
Furthermore, although these mechanisms are designed for interworking Furthermore, although these mechanisms are designed for interworking
with legacy RAN at the N3 interface, these methods could also be with legacy RAN at the N3 interface, these methods could also be
applied for interworking with a non-SRv6 capable UPF at the N9 applied for interworking with a non-SRv6 capable UPF at the N9
interface (e.g., L3-anchor is SRv6 capable but L2-anchor is not). interface.
5.4. SRv6 Drop-in Interworking 5.4. SRv6 Drop-in Interworking
In this section we introduce another mode useful for legacy gNB and In this section we introduce another mode useful for legacy gNB and
UPFs that still operate with GTP-U. This mode provides an UPFs that still operate with GTP-U. This mode provides an
SRv6-enabled user plane in between two GTP-U tunnel endpoints. SRv6-enabled user plane in between two GTP-U tunnel endpoints.
In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and In this mode we employ two SRGWs that map GTP-U traffic to SRv6 and
vice-versa. vice-versa.
skipping to change at page 23, line 21 skipping to change at page 23, line 21
Code 0 (Erroneous header field encountered), Code 0 (Erroneous header field encountered),
Pointer set to the Segments Left field, Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet. interrupt packet processing, and discard the packet.
S04. } S04. }
S05. Proceed to process the next header in the packet S05. Proceed to process the next header in the packet
S06. } S06. }
When processing the Upper-layer header of a packet matching a FIB When processing the Upper-layer header of a packet matching a FIB
entry locally instantiated as an End.M.GTP6.E SID, N does: entry locally instantiated as an End.M.GTP6.E SID, N does:
S01. If (Next Header = UDP & UDP_Dest_port = GTP) { S01. Copy SRH[0] and S to buffer memory
S02. Copy SRH[0] to buffer memory S02. Pop the IPv6 header and all its extension headers
S03. Pop the IPv6 header and all its extension headers S03. Push a new IPv6 header with a UDP/GTP Header
S04. Push a new IPv6 header with a UDP/GTP Header S04. Set the outer IPv6 SA to A
S05. Set the outer IPv6 SA to A S05. Set the outer IPv6 DA from buffer memory
S06. Set the outer IPv6 DA to the first SID of B S06. Set the outer Payload Length, Traffic Class, Flow Label,
S07. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next-Header fields Hop Limit, and Next-Header fields
S08. Set the GTP TEID (from buffer memory) S07. Set the GTP TEID (from buffer memory)
S09. Submit the packet to the egress IPv6 FIB lookup and S08. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination transmission to the new destination
S10. } Else { S09. }
S11. Process as per [RFC8986] Section 4.1.1
S12. }
Notes: Notes:
An End.M.GTP6.E SID MUST always be the penultimate SID. An End.M.GTP6.E SID MUST always be the penultimate SID.
The TEID is extracted from the argument space of the current SID. The TEID is extracted from the argument space of the current SID.
The source address A SHOULD be an End.M.GTP6.D SID instantiated at an The source address A SHOULD be an End.M.GTP6.D SID instantiated at an
SR gateway. SR gateway.
6.6. End.M.GTP4.E 6.6. End.M.GTP4.E
skipping to change at page 29, line 8 skipping to change at page 29, line 8
Email: tetsuya.ietf@gmail.com Email: tetsuya.ietf@gmail.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-09 (work in progress), ietf-spring-segment-routing-policy-11 (work in progress),
November 2020. April 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
skipping to change at page 30, line 20 skipping to change at page 30, line 20
[I-D.ietf-dmm-fpc-cpdp] [I-D.ietf-dmm-fpc-cpdp]
Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S., Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
Moses, D., and C. E. Perkins, "Protocol for Forwarding Moses, D., and C. E. Perkins, "Protocol for Forwarding
Policy Configuration (FPC) in DMM", draft-ietf-dmm-fpc- Policy Configuration (FPC) in DMM", draft-ietf-dmm-fpc-
cpdp-14 (work in progress), September 2020. cpdp-14 (work in progress), September 2020.
[I-D.ietf-lsr-flex-algo] [I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-14 (work in progress), February 2021. algo-15 (work in progress), April 2021.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
Afanasiev, "Segment Routing Centralized BGP Egress Peer Afanasiev, "Segment Routing Centralized BGP Egress Peer
Engineering", draft-ietf-spring-segment-routing-central- Engineering", draft-ietf-spring-segment-routing-central-
epe-10 (work in progress), December 2017. epe-10 (work in progress), December 2017.
[I-D.ietf-spring-sr-service-programming] [I-D.ietf-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
skipping to change at page 32, line 17 skipping to change at page 32, line 17
Email: pcamaril@cisco.com Email: pcamaril@cisco.com
Daniel Voyer Daniel Voyer
Bell Canada Bell Canada
Canada Canada
Email: daniel.voyer@bell.ca Email: daniel.voyer@bell.ca
Charles E. Perkins Charles E. Perkins
Futurewei Inc. Lupin Lodge
2330 Central Expressway 20600 Aldercroft Heights Rd.
Santa Clara, CA 95050 Los Gatos, CA 95033
USA USA
Phone: +1-408-330-4586
Email: charliep@computer.org Email: charliep@computer.org
 End of changes. 21 change blocks. 
36 lines changed or deleted 39 lines changed or added

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