< draft-ietf-pce-segment-routing-08.txt   draft-ietf-pce-segment-routing-09.txt >
Network Working Group S. Sivabalan PCE S. Sivabalan
Internet-Draft J. Medved Internet-Draft C. Filsfils
Intended status: Standards Track C. Filsfils Intended status: Standards Track Cisco Systems, Inc.
Expires: April 7, 2017 Cisco Systems, Inc. Expires: October 12, 2017 J. Tantsura
E. Crabbe
Oracle
R. Raszuk
Mirantis Inc.
V. Lopez
Telefonica I+D
J. Tantsura
Individual Individual
W. Henderickx W. Henderickx
Nokia Nokia
J. Hardwick J. Hardwick
Metaswitch Networks Metaswitch Networks
October 4, 2016 April 10, 2017
PCEP Extensions for Segment Routing PCEP Extensions for Segment Routing
draft-ietf-pce-segment-routing-08 draft-ietf-pce-segment-routing-09
Abstract Abstract
Segment Routing (SR) enables any head-end node to select any path Segment Routing (SR) enables any head-end node to select any path
without relying on a hop-by-hop signaling technique (e.g., LDP or without relying on a hop-by-hop signaling technique (e.g., LDP or
RSVP-TE). It depends only on "segments" that are advertised by Link- RSVP-TE). It depends only on "segments" that are advertised by Link-
State Interior Gateway Protocols (IGPs). A Segment Routed Path can State Interior Gateway Protocols (IGPs). A Segment Routed Path can
be derived from a variety of mechanisms, including an IGP Shortest be derived from a variety of mechanisms, including an IGP Shortest
Path Tree (SPT), explicit configuration, or a Path Computation Path Tree (SPT), explicit configuration, or a Path Computation
Element (PCE). This document specifies extensions to the Path Element (PCE). This document specifies extensions to the Path
skipping to change at page 2, line 15 skipping to change at page 2, line 7
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 April 7, 2017. This Internet-Draft will expire on October 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5 3. Overview of PCEP Operation in SR Networks . . . . . . . . . . 5
4. SR-Specific PCEP Message Extensions . . . . . . . . . . . . . 7 4. SR-Specific PCEP Message Extensions . . . . . . . . . . . . . 6
5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7
5.1.1. The SR PCE Capability TLV . . . . . . . . . . . . . . 7 5.1.1. The SR PCE Capability TLV . . . . . . . . . . . . . . 7
5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9 5.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 8
5.3. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. ERO Object . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9 5.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . . . 9
5.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 11 5.3.2. NAI Associated with SID . . . . . . . . . . . . . . . 11
5.3.3. ERO Processing . . . . . . . . . . . . . . . . . . . 13 5.3.3. ERO Processing . . . . . . . . . . . . . . . . . . . 12
5.4. RRO Object . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. RRO Object . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.1. RRO Processing . . . . . . . . . . . . . . . . . . . 14 5.4.1. RRO Processing . . . . . . . . . . . . . . . . . . . 14
5.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 15 5.5. METRIC Object . . . . . . . . . . . . . . . . . . . . . . 14
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15
7. Management Considerations . . . . . . . . . . . . . . . . . . 15 7. Management Considerations . . . . . . . . . . . . . . . . . . 15
7.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. The PCEP Data Model . . . . . . . . . . . . . . . . . . . 16 7.2. The PCEP Data Model . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16 9.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16
9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16 9.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 16
9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 17 9.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 17
9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 17 9.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 17
9.5. New Metric Type . . . . . . . . . . . . . . . . . . . . . 17 9.5. New Metric Type . . . . . . . . . . . . . . . . . . . . . 17
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
SR technology leverages the source routing and tunneling paradigms. SR technology leverages the source routing and tunneling paradigms.
A source node can choose a path without relying on hop-by-hop A source node can choose a path without relying on hop-by-hop
signaling protocols such as LDP or RSVP-TE. Each path is specified signaling protocols such as LDP or RSVP-TE. Each path is specified
skipping to change at page 8, line 45 skipping to change at page 8, line 30
SIDs exceeding that MSD value. If a PCC needs to modify the MSD SIDs exceeding that MSD value. If a PCC needs to modify the MSD
value, the PCEP session MUST be closed and re-established with the value, the PCEP session MUST be closed and re-established with the
new MSD value. If a PCEP session is established with a non-zero MSD new MSD value. If a PCEP session is established with a non-zero MSD
value, and the PCC receives an SR-TE path containing more SIDs than value, and the PCC receives an SR-TE path containing more SIDs than
specified in the MSD value, the PCC MUST send a PCErr message with specified in the MSD value, the PCC MUST send a PCErr message with
Error-Type 10 (Reception of an invalid object) and Error-Value 3 Error-Type 10 (Reception of an invalid object) and Error-Value 3
(Unsupported number of Segment ERO). If a PCEP session is (Unsupported number of Segment ERO). If a PCEP session is
established with an MSD value of zero, then the PCC MAY specify an established with an MSD value of zero, then the PCC MAY specify an
MSD for each path computation request that it sends to the PCE. MSD for each path computation request that it sends to the PCE.
The SR Capability TLV is meaningful only in the OPEN message sent The MSD value inside SR Capability TLV is meaningful only in the OPEN
from a PCC to a PCE. As such, a PCE does not need to set MSD value message sent from a PCC to a PCE. As such, a PCE does not need to
in outbound message to a PCC. Similarly, a PCC ignores any MSD value set MSD value in outbound message to a PCC. Similarly, a PCC ignores
received from a PCE. If a PCE receives multiple SR-PCE-CAPABILITY any MSD value received from a PCE. If a PCE receives multiple SR-
TLVs in an OPEN message, it processes only the first TLV received. PCE-CAPABILITY TLVs in an OPEN message, it processes only the first
TLV received.
5.2. The RP/SRP Object 5.2. The RP/SRP Object
In order to setup an SR-TE LSP using SR, RP or SRP object MUST PATH- In order to setup an SR-TE LSP using SR, RP or SRP object MUST
SETUP-TYPE TLV specified in [I-D.ietf-pce-lsp-setup-type]. This include PATH-SETUP-TYPE TLV specified in
document defines a new Path Setup Type (PST) for SR as follows: [I-D.ietf-pce-lsp-setup-type]. This document defines a new Path
Setup Type (PST) for SR as follows:
o PST = 1: Path is setup using Segment Routing Traffic Engineering o PST = 1: Path is setup using Segment Routing Traffic Engineering
technique. technique.
LSP-IDENTIFIERS TLV MAY be present for the above PST type.
5.3. ERO Object 5.3. ERO Object
An SR-TE path consists of one or more SID(s) where each SID MAY be An SR-TE path consists of one or more SID(s) where each SID MAY be
associated with the identifier that represents the node or adjacency associated with the identifier that represents the node or adjacency
corresponding to the SID. This identifier is referred to as the corresponding to the SID. This identifier is referred to as the
'Node or Adjacency Identifier' (NAI). As described later, a NAI can 'Node or Adjacency Identifier' (NAI). As described later, a NAI can
be represented in various formats (e.g., IPv4 address, IPv6 address, be represented in various formats (e.g., IPv4 address, IPv6 address,
etc). Furthermore, a NAI is used for troubleshooting purposes and, etc). Furthermore, a NAI is used for troubleshooting purposes and,
if necessary, to derive SID value as described below. if necessary, to derive SID value as described below.
The ERO object specified in [RFC5440] is used to carry SR-TE path The ERO object specified in [RFC5440] is used to carry SR-TE path
information. In order to carry SID and/or NAI, this document defines information. In order to carry SID and/or NAI, this document defines
a new ERO subobject referred to as "SR-ERO subobject" whose format is a new ERO subobject referred to as "SR-ERO subobject" whose format is
specified in the following section. An ERO object carrying an SR-TE specified in the following section. An ERO object carrying an SR-TE
path consists of one or more ERO subobject(s), and MUST carry only path consists of one or more ERO subobject(s), and MUST carry only
SR-ERO subobject. Note that an SR-ERO subobject does not need to SR-ERO subobject(s). Note that an SR-ERO subobject does not need to
have both SID and NAI. However, at least one of them MUST be have both SID and NAI. However, at least one of them MUST be
present. present.
When building the MPLS label stack from ERO, a PCC MUST assume that When building the MPLS label stack from ERO, a PCC MUST assume that
SR-ERO subobjects are organized as a last-in-first-out stack. The SR-ERO subobjects are organized as a last-in-first-out stack. The
first subobject relative to the beginning of ERO contains the first subobject relative to the beginning of ERO contains the
information about the topmost label. The last subobject contains information about the topmost label. The last subobject contains
information about the bottommost label. information about the bottommost label.
5.3.1. SR-ERO Subobject 5.3.1. SR-ERO Subobject
skipping to change at page 13, line 19 skipping to change at page 12, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID | | Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Node-ID | | Remote Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID | | Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs Figure 5: NAI for Unnumbered adjacency with IPv4 Node IDs
Editorial Note: We are yet to decide if another SID subobject is
required for unnumbered adjacency with 128 bit node ID.
5.3.3. ERO Processing 5.3.3. ERO Processing
A PCEP speaker that does not recognize the SR-ERO subobject in PCRep, A PCEP speaker that does not recognize the SR-ERO subobject in PCRep,
PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP
message and MUST send a PCErr message with Error-Type=3 ("Unknown message and MUST send a PCErr message with Error-Type=3 ("Unknown
Object") and Error-Value=2 ("Unrecognized object Type") or Error- Object") and Error-Value=2 ("Unrecognized object Type") or Error-
Type=4 ("Not supported object") and Error-Value=2 ("Not supported Type=4 ("Not supported object") and Error-Value=2 ("Not supported
object Type"), defined in [RFC5440]. object Type"), defined in [RFC5440].
When the SID represents an MPLS label (i.e. the M bit is set), its When the SID represents an MPLS label (i.e. the M bit is set), its
value (20 most significant bits) MUST be larger than 15, unless it is value (20 most significant bits) MUST be larger than 15, unless it is
special purpose label, such as an Entropy Label Indicator (ELI). If special purpose label, such as an Entropy Label Indicator (ELI). If
a PCEP speaker receives a label ERO subobject with an invalid value, a PCEP speaker receives an invalid value, it MUST send a PCErr
it MUST send a PCErr message with Error-Type = 10 ("Reception of an message with Error-Type = 10 ("Reception of an invalid object") and
invalid object") and Error Value = TBD ("Bad label value"). If both Error Value = TBD ("Bad label value"). If both M and C bits of an
M and C bits of an ERO subobject are set, and if a PCEP speaker finds SR-ERO subobject are set, and if a PCEP speaker finds erroneous
erroneous setting in one or more of TC, S, and TTL fields, it MUST setting in one or more of TC, S, and TTL fields, it MUST send a PCErr
send a PCErr message with Error-Type = 10 ("Reception of an invalid message with Error-Type = 10 ("Reception of an invalid object") and
object") and Error-Value = TBD ("Bad label format"). Error-Value = TBD ("Bad label format").
If a PCC receives a stack of SR-ERO subobjects, and the number of If a PCC receives a stack of SR-ERO subobjects, and the number of
stack exceeds the maximum number of SIDs that the PCC can impose on stack exceeds the maximum number of SIDs that the PCC can impose on
the packet, it MAY send a PCErr message with Error-Type = 10 the packet, it MAY send a PCErr message with Error-Type = 10
("Reception of an invalid object") and Error-Value = TBD ("Reception of an invalid object") and Error-Value = TBD
("Unsupported number of Segment ERO subobjects"). ("Unsupported number of Segment ERO subobjects").
When a PCEP speaker detects that all subobjects of ERO are not When a PCEP speaker detects that all subobjects of ERO are not
identical, and if it does not handle such ERO, it MUST send a PCErr identical, and if it does not handle such ERO, it MUST send a PCErr
message with Error-Type = 10 ("Reception of an invalid object") and message with Error-Type = 10 ("Reception of an invalid object") and
skipping to change at page 18, line 10 skipping to change at page 17, line 42
Value Description Reference Value Description Reference
------------------------- ---------------------------- -------------- ------------------------- ---------------------------- --------------
TBD (recommended 11) Segment-ID (SID) Depth. This document TBD (recommended 11) Segment-ID (SID) Depth. This document
10. Contributors 10. Contributors
The following people contributed to this document: The following people contributed to this document:
- Lakshmi Sharma - Lakshmi Sharma
- Jan Medved
- Edward Crabbe
- Robert Raszuk
- Victor Lopez
11. Acknowledgements 11. Acknowledgements
We like to thank Ina Minei, George Swallow, Marek Zavodsky and Tomas We like to thank Ina Minei, George Swallow, Marek Zavodsky, Dhruv
Janciga for the valuable comments. Dhody, Ing-Wher Chen and Tomas Janciga for the valuable comments.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.filsfils-rtgwg-segment-routing] [I-D.filsfils-rtgwg-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-rtgwg- "Segment Routing Architecture", draft-filsfils-rtgwg-
skipping to change at page 20, line 31 skipping to change at page 20, line 20
Authors' Addresses Authors' Addresses
Siva Sivabalan Siva Sivabalan
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario K2K 3E8 Kanata, Ontario K2K 3E8
Canada Canada
Email: msiva@cisco.com Email: msiva@cisco.com
Jan Medved
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
US
Email: jmedved@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Pegasus Parc Pegasus Parc
De kleetlaan 6a, DIEGEM BRABANT 1831 De kleetlaan 6a, DIEGEM BRABANT 1831
BELGIUM BELGIUM
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Edward Crabbe
Oracle
1501 4th Ave, suite 1800
Seattle, WA 98101
USA
Email: edward.crabbe@oracle.com
Robert Raszuk
Mirantis Inc.
100-615 National Ave.
Mountain View, CA 94043
US
Email: robert@raszuk.net
Victor Lopez
Telefonica I+D
Don Ramon de la Cruz 82-84
Madrid 28045
Spain
Email: vlopez@tid.es
Jeff Tantsura Jeff Tantsura
Individual Individual
444 San Antonio Rd, 10A 444 San Antonio Rd, 10A
Palo Alto, CA 94306 Palo Alto, CA 94306
USA USA
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Wim Henderickx Wim Henderickx
 End of changes. 21 change blocks. 
78 lines changed or deleted 45 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/