< draft-ietf-spring-segment-routing-policy-21.txt   draft-ietf-spring-segment-routing-policy-22.txt >
SPRING Working Group C. Filsfils SPRING Working Group C. Filsfils
Internet-Draft K. Talaulikar, Ed. Internet-Draft K. Talaulikar, Ed.
Updates: 8402 (if approved) Cisco Systems, Inc. Updates: 8402 (if approved) Cisco Systems, Inc.
Intended status: Standards Track D. Voyer Intended status: Standards Track D. Voyer
Expires: September 20, 2022 Bell Canada Expires: September 23, 2022 Bell Canada
A. Bogdanov A. Bogdanov
British Telecom British Telecom
P. Mattes P. Mattes
Microsoft Microsoft
March 19, 2022 March 22, 2022
Segment Routing Policy Architecture Segment Routing Policy Architecture
draft-ietf-spring-segment-routing-policy-21 draft-ietf-spring-segment-routing-policy-22
Abstract Abstract
Segment Routing (SR) allows a node to steer a packet flow along any Segment Routing (SR) allows a node to steer a packet flow along any
path. Intermediate per-path states are eliminated thanks to source path. Intermediate per-path states are eliminated thanks to source
routing. SR Policy is an ordered list of segments (i.e., routing. SR Policy is an ordered list of segments (i.e.,
instructions) that represent a source-routed policy. Packet flows instructions) that represent a source-routed policy. Packet flows
are steered into a SR Policy on a node where it is instantiated are steered into a SR Policy on a node where it is instantiated
called a headend node. The packets steered into an SR Policy carry called a headend node. The packets steered into an SR Policy carry
an ordered list of segments associated with that SR Policy. an ordered list of segments associated with that SR Policy.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 20, 2022. This Internet-Draft will expire on September 23, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 18 skipping to change at page 3, line 18
8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 26 8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 26
8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 28 8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 28
8.8. Optional Steering Modes for BGP Destinations . . . . . . 28 8.8. Optional Steering Modes for BGP Destinations . . . . . . 28
9. Recovering from Network Failures . . . . . . . . . . . . . . 30 9. Recovering from Network Failures . . . . . . . . . . . . . . 30
9.1. Leveraging TI-LFA local protection of the constituent IGP 9.1. Leveraging TI-LFA local protection of the constituent IGP
segments . . . . . . . . . . . . . . . . . . . . . . . . 30 segments . . . . . . . . . . . . . . . . . . . . . . . . 30
9.2. Using an SR Policy to locally protect a link . . . . . . 30 9.2. Using an SR Policy to locally protect a link . . . . . . 30
9.3. Using a Candidate Path for Path Protection . . . . . . . 31 9.3. Using a Candidate Path for Path Protection . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Manageability Considerations . . . . . . . . . . . . . . . . 32 11. Manageability Considerations . . . . . . . . . . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12.1. Guidance for Designated Experts . . . . . . . . . . . . 33 12.1. Guidance for Designated Experts . . . . . . . . . . . . 33
13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 33 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
15.1. Normative References . . . . . . . . . . . . . . . . . . 35 15.1. Normative References . . . . . . . . . . . . . . . . . . 35
15.2. Informative References . . . . . . . . . . . . . . . . . 36 15.2. Informative References . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Segment Routing (SR) [RFC8402] allows a node to steer a packet flow Segment Routing (SR) [RFC8402] allows a node to steer a packet flow
along any path. The headend is a node where the instructions for along any path. The headend is a node where the instructions for
source routing (i.e., segments) are written into the packet and hence source routing (i.e., segments) are written into the packet and hence
becomes the starting node for a specific segment routing path. becomes the starting node for a specific segment routing path.
Intermediate per-path states are eliminated thanks to source routing. Intermediate per-path states are eliminated thanks to source routing.
A Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of A Segment Routing Policy (SR Policy) [RFC8402] is an ordered list of
skipping to change at page 32, line 26 skipping to change at page 32, line 26
scenarios. The details of these mechanisms are outside the scope of scenarios. The details of these mechanisms are outside the scope of
this document. this document.
The Section 8 specifies mechanism for steering of traffic flows The Section 8 specifies mechanism for steering of traffic flows
corresponding to BGP routes over SR Policies matching the color value corresponding to BGP routes over SR Policies matching the color value
signaled via the BGP Color Extended Community attached with the BGP signaled via the BGP Color Extended Community attached with the BGP
routes. Misconfiguration or error in setting of the Color Extended routes. Misconfiguration or error in setting of the Color Extended
Community with the BGP routes can result in forwarding of packets for Community with the BGP routes can result in forwarding of packets for
those routes along undesired paths. those routes along undesired paths.
In Section 2.1 and Section 2.6, the document mentions that a symbolic
name MAY be signaled along with a candidate path for the SR Policy
and for the SR Policy Candidate Path respectively. While the value
of symbolic names for display clarity is indisputable, as with any
unrestricted freeform text received from external parties, there can
be no absolute assurance that the information the text purports to
show is accurate or even truthful. For this reason, users of
implementations that display such information would be well-advised
not to rely on it without question and to use the specific
identifiers of the SR Policy and SR Policy Candidate Path for
validation. Furthermore, implementations that display such
information might wish to display it in such a fashion as to
differentiate it from known-good information. (Such display
conventions are inherently implementation-specific; one example might
be use of a distinguished text color or style for information that
should be treated with caution.)
This document does not define any new protocol extensions and does This document does not define any new protocol extensions and does
not introduce any further security considerations. not introduce any further security considerations.
11. Manageability Considerations 11. Manageability Considerations
This document specifies in detail the SR Policy construct introduced This document specifies in detail the SR Policy construct introduced
in [RFC8402] and its instantiation on a router supporting SR along in [RFC8402] and its instantiation on a router supporting SR along
with descriptions of mechanisms for steering of traffic flows over with descriptions of mechanisms for steering of traffic flows over
it. Therefore, the manageability considerations of [RFC8402] apply. it. Therefore, the manageability considerations of [RFC8402] apply.
skipping to change at page 37, line 20 skipping to change at page 37, line 44
[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-18 (work in progress), October 2021. algo-18 (work in progress), October 2021.
[I-D.ietf-pce-binding-label-sid] [I-D.ietf-pce-binding-label-sid]
Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. L. (editor), "Carrying Binding Label/Segment and C. L. (editor), "Carrying Binding Label/Segment
Identifier (SID) in PCE-based Networks.", draft-ietf-pce- Identifier (SID) in PCE-based Networks.", draft-ietf-pce-
binding-label-sid-14 (work in progress), March 2022. binding-label-sid-15 (work in progress), March 2022.
[I-D.ietf-pce-segment-routing-policy-cp] [I-D.ietf-pce-segment-routing-policy-cp]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
Bidgoli, "PCEP extension to support Segment Routing Policy Bidgoli, "PCEP extension to support Segment Routing Policy
Candidate Paths", draft-ietf-pce-segment-routing-policy- Candidate Paths", draft-ietf-pce-segment-routing-policy-
cp-06 (work in progress), October 2021. cp-06 (work in progress), October 2021.
[I-D.ietf-rtgwg-segment-routing-ti-lfa] [I-D.ietf-rtgwg-segment-routing-ti-lfa]
Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Litkowski, S., Bashandy, A., Filsfils, C., Francois, P.,
Decraene, B., and D. Voyer, "Topology Independent Fast Decraene, B., and D. Voyer, "Topology Independent Fast
 End of changes. 9 change blocks. 
8 lines changed or deleted 25 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/