< draft-filsfils-spring-srv6-net-pgm-illustration-00.txt   draft-filsfils-spring-srv6-net-pgm-illustration-01.txt >
SPRING C. Filsfils SPRING C. Filsfils
Internet-Draft P. Camarillo, Ed. Internet-Draft P. Camarillo, Ed.
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: August 18, 2019 Z. Li Expires: February 15, 2020 Z. Li
Huawei Technologies Huawei Technologies
S. Matsushima S. Matsushima
SoftBank SoftBank
B. Decraene B. Decraene
Orange Orange
D. Steinberg D. Steinberg
Steinberg Consulting Lapishills Consulting Limited
D. Lebrun D. Lebrun
Google Google
R. Raszuk R. Raszuk
Bloomberg LP Bloomberg LP
J. Leddy J. Leddy
Comcast Individual Contributor
February 14, 2019 August 14, 2019
Illustrations for SRv6 Network Programming Illustrations for SRv6 Network Programming
draft-filsfils-spring-srv6-net-pgm-illustration-00 draft-filsfils-spring-srv6-net-pgm-illustration-01
Abstract Abstract
This document illustrates how SRv6 Network Programming This document illustrates how SRv6 Network Programming
[I-D.filsfils-spring-srv6-network-programming] can be used to create [I-D.ietf-spring-srv6-network-programming] can be used to create
interoperable and protected overlays with underlay optimization and interoperable and protected overlays with underlay optimization and
service programming. service programming.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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 August 18, 2019. This Internet-Draft will expire on February 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 20 skipping to change at page 3, line 20
Segment Routing leverages the source routing paradigm. An ingress Segment Routing leverages the source routing paradigm. An ingress
node steers a packet through a ordered list of instructions, called node steers a packet through a ordered list of instructions, called
segments. Each one of these instructions represents a function to be segments. Each one of these instructions represents a function to be
called at a specific location in the network. A function is locally called at a specific location in the network. A function is locally
defined on the node where it is executed and may range from simply defined on the node where it is executed and may range from simply
moving forward in the segment list to any complex user-defined moving forward in the segment list to any complex user-defined
behavior. The network programming consists in combining segment behavior. The network programming consists in combining segment
routing functions, both simple and complex, to achieve a networking routing functions, both simple and complex, to achieve a networking
objective that goes beyond mere packet routing. objective that goes beyond mere packet routing.
[I-D.filsfils-spring-srv6-network-programming] defines the SRv6 [I-D.ietf-spring-srv6-network-programming] defines the SRv6 Network
Network Programming concept and the main segment routing behaviors. Programming concept and the main segment routing behaviors.
This document illustrates how these concepts can be used to enable This document illustrates how these concepts can be used to enable
the creation of interoperable overlays with underlay optimization and the creation of interoperable overlays with underlay optimization and
service programming. service programming.
The terminology for this document is defined in The terminology for this document is defined in
[I-D.filsfils-spring-srv6-network-programming]. [I-D.ietf-spring-srv6-network-programming].
2. Illustration 2. Illustration
We introduce a simplified SID allocation technique to ease the We introduce a simplified SID allocation technique to ease the
reading of the text. We document the reference diagram. We then reading of the text. We document the reference diagram. We then
illustrate the network programming concept through different use- illustrate the network programming concept through different use-
cases. These use-cases have been thought to allow straightforward cases. These use-cases have been thought to allow straightforward
combination between each other. combination between each other.
2.1. Simplified SID allocation 2.1. Simplified SID allocation
skipping to change at page 11, line 48 skipping to change at page 11, line 48
pushed. Node 8 then forwards the resulting packet on the shortest pushed. Node 8 then forwards the resulting packet on the shortest
path to B:8::/32. EVPN intra-subnet forwarding is then achieved. path to B:8::/32. EVPN intra-subnet forwarding is then achieved.
2.8. SR TE for Underlay SLA 2.8. SR TE for Underlay SLA
2.8.1. SR policy from the Ingress PE 2.8.1. SR policy from the Ingress PE
Let's assume that node 1's tenant-100 IPv4 route "20/8 via Let's assume that node 1's tenant-100 IPv4 route "20/8 via
B:8:D100::" is programmed with a color/community that requires low- B:8:D100::" is programmed with a color/community that requires low-
latency underlay optimization latency underlay optimization
[I-D.filsfils-spring-segment-routing-policy]. [I-D.ietf-spring-segment-routing-policy].
In such case, node 1 either computes the low-latency path to the In such case, node 1 either computes the low-latency path to the
egress node itself or delegates the computation to a PCE. egress node itself or delegates the computation to a PCE.
In either case, the location of the egress PE can easily be found by In either case, the location of the egress PE can easily be found by
looking for who originates the locator comprising the SID B:8:D100::. looking for who originates the locator comprising the SID B:8:D100::.
This can be found in the IGP's LSDB for a single domain case, and in This can be found in the IGP's LSDB for a single domain case, and in
the BGP-LS LSDB for a multi-domain case. the BGP-LS LSDB for a multi-domain case.
Let us assume that the TE metric encodes the per-link propagation Let us assume that the TE metric encodes the per-link propagation
skipping to change at page 21, line 20 skipping to change at page 21, line 20
6. Informative References 6. Informative References
[I-D.dawra-idr-srv6-vpn] [I-D.dawra-idr-srv6-vpn]
Dawra, G., Filsfils, C., Dukes, D., Brissette, P., Dawra, G., Filsfils, C., Dukes, D., Brissette, P.,
Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
Decraene, B., Matsushima, S., and S. Zhuang, "BGP Decraene, B., Matsushima, S., and S. Zhuang, "BGP
Signaling for SRv6 based Services.", draft-dawra-idr- Signaling for SRv6 based Services.", draft-dawra-idr-
srv6-vpn-05 (work in progress), October 2018. srv6-vpn-05 (work in progress), October 2018.
[I-D.filsfils-spring-segment-routing-policy] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Sivabalan, S., Hegde, S., Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., Routing Header (SRH)", draft-ietf-6man-segment-routing-
Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, header-22 (work in progress), August 2019.
J., Clad, F., and K. Raza, "Segment Routing Policy
Architecture", draft-filsfils-spring-segment-routing-
policy-06 (work in progress), May 2018.
[I-D.filsfils-spring-srv6-network-programming] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing-
policy-03 (work in progress), May 2019.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network- Network Programming", draft-ietf-spring-srv6-network-
programming-06 (work in progress), October 2018. programming-01 (work in progress), July 2019.
[I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in
progress), February 2019.
[I-D.xuclad-spring-sr-service-programming] [I-D.xuclad-spring-sr-service-programming]
Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
Henderickx, W., and S. Salsano, "Service Programming with Henderickx, W., and S. Salsano, "Service Programming with
Segment Routing", draft-xuclad-spring-sr-service- Segment Routing", draft-xuclad-spring-sr-service-
programming-01 (work in progress), October 2018. programming-02 (work in progress), April 2019.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 23, line 5 skipping to change at page 23, line 5
Japan Japan
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Bruno Decraene Bruno Decraene
Orange Orange
France France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Dirk Steinberg Dirk Steinberg
Steinberg Consulting Lapishills Consulting Limited
Germany Cyprus
Email: dws@dirksteinberg.de Email: dirk@lapishills.com
David Lebrun David Lebrun
Google Google
Belgium Belgium
Email: david.lebrun@uclouvain.be Email: david.lebrun@uclouvain.be
Robert Raszuk Robert Raszuk
Bloomberg LP Bloomberg LP
United States of America United States of America
Email: robert@raszuk.net Email: robert@raszuk.net
John Leddy John Leddy
Comcast Individual Contributor
United States of America United States of America
Email: john_leddy@cable.comcast.com Email: john@leddy.net
 End of changes. 17 change blocks. 
33 lines changed or deleted 30 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/