draft-ietf-spring-segment-routing-central-epe-08.txt   draft-ietf-spring-segment-routing-central-epe-09.txt 
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft S. Previdi Internet-Draft S. Previdi
Intended status: Informational G. Dawra, Ed. Intended status: Informational G. Dawra, Ed.
Expires: June 21, 2018 Cisco Systems, Inc. Expires: June 24, 2018 Cisco Systems, Inc.
E. Aries E. Aries
Juniper Networks Juniper Networks
D. Afanasiev D. Afanasiev
Yandex Yandex
December 18, 2017 December 21, 2017
Segment Routing Centralized BGP Egress Peer Engineering Segment Routing Centralized BGP Egress Peer Engineering
draft-ietf-spring-segment-routing-central-epe-08 draft-ietf-spring-segment-routing-central-epe-09
Abstract Abstract
Segment Routing (SR) leverages source routing. A node steers a Segment Routing (SR) leverages source routing. A node steers a
packet through a controlled set of instructions, called segments, by packet through a controlled set of instructions, called segments, by
prepending the packet with an SR header. A segment can represent any prepending the packet with an SR header. A segment can represent any
instruction topological or service-based. SR allows to enforce a instruction topological or service-based. SR allows to enforce a
flow through any topological path while maintaining per-flow state flow through any topological path while maintaining per-flow state
only at the ingress node of the SR domain. only at the ingress node of the SR domain.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 June 21, 2018. This Internet-Draft will expire on June 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 50 skipping to change at page 2, line 50
4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10 4.1. Valid Paths From Peers . . . . . . . . . . . . . . . . . 10
4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11 4.2. Intra-Domain Topology . . . . . . . . . . . . . . . . . . 11
4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11 4.3. External Topology . . . . . . . . . . . . . . . . . . . . 11
4.4. SLA characteristics of each peer . . . . . . . . . . . . 12 4.4. SLA characteristics of each peer . . . . . . . . . . . . 12
4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12 4.5. Traffic Matrix . . . . . . . . . . . . . . . . . . . . . 12
4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12 4.6. Business Policies . . . . . . . . . . . . . . . . . . . . 12
4.7. BGP-EPE Policy . . . . . . . . . . . . . . . . . . . . . 12 4.7. BGP-EPE Policy . . . . . . . . . . . . . . . . . . . . . 12
5. Programming an input policy . . . . . . . . . . . . . . . . . 13 5. Programming an input policy . . . . . . . . . . . . . . . . . 13
5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. At a Host . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13 5.2. At a router - SR Traffic Engineering tunnel . . . . . . . 13
5.3. At a Router - RFC3107 policy route . . . . . . . . . . . 14 5.3. At a Router - BGP Labeled Unicast route (RFC8277) . . . . 14
5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14 5.4. At a Router - VPN policy route . . . . . . . . . . . . . 14
6. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 15 6. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 15
7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Manageability Considerations . . . . . . . . . . . . . . . . 16 9. Manageability Considerations . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16
skipping to change at page 14, line 12 skipping to change at page 14, line 12
o Netconf ([RFC6241]). o Netconf ([RFC6241]).
o Other static or ephemeral APIs o Other static or ephemeral APIs
Example: at router A (Figure 1). Example: at router A (Figure 1).
Tunnel T1: push {64, 1042} Tunnel T1: push {64, 1042}
IP route L/8 set next-hop T1 IP route L/8 set next-hop T1
5.3. At a Router - RFC3107 policy route 5.3. At a Router - BGP Labeled Unicast route (RFC8277)
The BGP-EPE Controller could build a RFC3107 ([RFC8277]) route (from The BGP-EPE Controller could build a BGP Labeled Unicast route
scratch) and send it to the ingress router: [RFC8277]) route (from scratch) and send it to the ingress router:
o NLRI: the destination prefix to engineer: e.g., L/8. o NLRI: the destination prefix to engineer: e.g., L/8.
o Next-Hop: the selected egress border router: C. o Next-Hop: the selected egress border router: C.
o Label: the selected egress peer: 1042. o Label: the selected egress peer: 1042.
o AS path: reflecting the selected valid AS path. o AS path: reflecting the selected valid AS path.
o Some BGP policy to ensure it will be selected as best by the o Some BGP policy to ensure it will be selected as best by the
ingress router. ingress router. Note that as discussed in RFC 8277 section 5, the
comparison of labeled and unlabeled unicast BGP route is
implementation dependent and hence may require an implementation
specific policy on each ingress router.
This RFC3107 policy route "overwrites" an equivalent or less-specific This BGP Labeled unicast route (RFC8277) "overwrites" an equivalent
"best path". As the best-path is changed, this BGP-EPE input policy or less-specific "best path". As the best-path is changed, this BGP-
option may influence the path propagated to the upstream peer/ EPE input policy option may influence the path propagated to the
customers. Indeed, implementations treating the SAFI-1 and SAFI-4 upstream peer/customers. Indeed, implementations treating the SAFI-1
routes for a given prefix as comparable would trigger a BGP WITHDRAW and SAFI-4 routes for a given prefix as comparable would trigger a
of the SAFI-1 route to their BGP upstream peers. BGP WITHDRAW of the SAFI-1 route to their BGP upstream peers.
5.4. At a Router - VPN policy route 5.4. At a Router - VPN policy route
The BGP-EPE Controller could build a VPNv4 route (from scratch) and The BGP-EPE Controller could build a VPNv4 route (from scratch) and
send it to the ingress router: send it to the ingress router:
o NLRI: the destination prefix to engineer: e.g., L/8. o NLRI: the destination prefix to engineer: e.g., L/8.
o Next-Hop: the selected egress border router: C. o Next-Hop: the selected egress border router: C.
o Label: the selected egress peer: 1042. o Label: the selected egress peer: 1042.
o Route-Target: selecting the appropriate VRF at the ingress router. o Route-Target: selecting the appropriate VRF at the ingress router.
o AS path: reflecting the selected valid AS path. o AS path: reflecting the selected valid AS path.
o Some BGP policy to ensure it will be selected as best by the o Some BGP policy to ensure it will be selected as best by the
ingress router in the related VRF. ingress router. Note that as discussed in RFC 8277 section 5, the
comparison of labeled and unlabeled unicast BGP route is
implementation dependent and hence may require an implementation
specific policy on each ingress router in the related VRF.
The related VRF must be preconfigured. A VRF fallback to the main The related VRF must be preconfigured. A VRF fallback to the main
FIB might be beneficial to avoid replicating all the "normal" FIB might be beneficial to avoid replicating all the "normal"
Internet paths in each VRF. Internet paths in each VRF.
6. IPv6 Dataplane 6. IPv6 Dataplane
The described solution is applicable to IPv6, either with MPLS-based The described solution is applicable to IPv6, either with MPLS-based
or IPv6-Native segments. In both cases, the same three steps of the or IPv6-Native segments. In both cases, the same three steps of the
solution are applicable: solution are applicable:
skipping to change at page 16, line 48 skipping to change at page 16, line 52
contribution. contribution.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Previdi, S., Filsfils, C., Patel, K., Ray, S., and J.
Dong, "BGP-LS extensions for Segment Routing BGP Egress Dong, "BGP-LS extensions for Segment Routing BGP Egress
Peer Engineering", draft-ietf-idr-bgpls-segment-routing- Peer Engineering", draft-ietf-idr-bgpls-segment-routing-
epe-13 (work in progress), June 2017. epe-14 (work in progress), December 2017.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-13 (work Architecture", draft-ietf-spring-segment-routing-14 (work
in progress), October 2017. in progress), December 2017.
[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>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
 End of changes. 12 change blocks. 
19 lines changed or deleted 25 lines changed or added

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