< draft-chunduri-lsr-isis-preferred-path-routing-03.txt   draft-chunduri-lsr-isis-preferred-path-routing-04.txt >
LSR Working Group U. Chunduri LSR Working Group U. Chunduri
Internet-Draft R. Li Internet-Draft R. Li
Intended status: Standards Track Huawei USA Intended status: Standards Track Futurewei
Expires: November 17, 2019 R. White Expires: January 9, 2020 R. White
Juniper Networks Juniper Networks
J. Tantsura J. Tantsura
Apstra Inc. Apstra Inc.
L. Contreras L. Contreras
Telefonica Telefonica
Y. Qu Y. Qu
Huawei USA Futurewei
May 16, 2019 July 8, 2019
Preferred Path Routing (PPR) in IS-IS Preferred Path Routing (PPR) in IS-IS
draft-chunduri-lsr-isis-preferred-path-routing-03 draft-chunduri-lsr-isis-preferred-path-routing-04
Abstract Abstract
This document specifies Preferred Path Routing (PPR), a routing This document specifies Preferred Path Routing (PPR), a routing
protocol extension to simplify the path description on the packet for protocol extension to simplify the path description on the packet for
Segment Routing (SR) deployments and beyond. PPR aims to mitigate Segment Routing (SR) deployments and beyond. PPR aims to mitigate
the MTU and data plane processing issues that may result from SR the MTU and data plane processing issues that may result from SR
packet overhead; and also supports further extensions along the packet overhead; and also supports further extensions along the
paths. paths.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 17, 2019. This Internet-Draft will expire on January 9, 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 2, line 45 skipping to change at page 2, line 45
4. PPR Processing Procedure Example . . . . . . . . . . . . . . 13 4. PPR Processing Procedure Example . . . . . . . . . . . . . . 13
4.1. PPR TLV Processing . . . . . . . . . . . . . . . . . . . 15 4.1. PPR TLV Processing . . . . . . . . . . . . . . . . . . . 15
4.2. Path Fragments . . . . . . . . . . . . . . . . . . . . . 16 4.2. Path Fragments . . . . . . . . . . . . . . . . . . . . . 16
5. PPR Data Plane aspects . . . . . . . . . . . . . . . . . . . 16 5. PPR Data Plane aspects . . . . . . . . . . . . . . . . . . . 16
5.1. SR-MPLS with PPR . . . . . . . . . . . . . . . . . . . . 16 5.1. SR-MPLS with PPR . . . . . . . . . . . . . . . . . . . . 16
5.2. PPR Native IP Data Planes . . . . . . . . . . . . . . . . 17 5.2. PPR Native IP Data Planes . . . . . . . . . . . . . . . . 17
5.3. SRv6 with PPR . . . . . . . . . . . . . . . . . . . . . . 17 5.3. SRv6 with PPR . . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. PPR Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 18 7.1. PPR Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 18
7.2. IGP Parameters . . . . . . . . . . . . . . . . . . . . . 18 7.2. IGP Parameters . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 22
A.1. Challenges with Increased SID Depth . . . . . . . . . . . 22 A.1. Challenges with Increased SID Depth . . . . . . . . . . . 22
A.2. Mitigation with MSD . . . . . . . . . . . . . . . . . . . 24 A.2. Mitigation with MSD . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In a network implementing Segment Routing (SR), packets are steered In a network implementing Segment Routing (SR), packets are steered
through the network using Segment Identifiers (SIDs) carried in the through the network using Segment Identifiers (SIDs) carried in the
skipping to change at page 6, line 12 skipping to change at page 6, line 12
Multiple instances of this TLV MAY be advertised in IS-IS LSPs with Multiple instances of this TLV MAY be advertised in IS-IS LSPs with
different PPR-ID Type (data plane) and with corresponding PDE Sub- different PPR-ID Type (data plane) and with corresponding PDE Sub-
TLVS. The PPR TLV has Type TBD (suggested value xxx), and has the TLVS. The PPR TLV has Type TBD (suggested value xxx), and has the
following format: following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | PPR-Flags | | Type | Length | PPR-Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment-ID | | Fragment-ID | MT-ID | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-Prefix Sub-TLV (variable size) | | PPR-Prefix Sub-TLV (variable size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-ID Sub-TLV (variable size) | | PPR-ID Sub-TLV (variable size) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-PDE Sub-TLVs (variable) | | PPR-PDE Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-Attribute Sub-TLVs (variable) | | PPR-Attribute Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PPR TLV Format Figure 1: PPR TLV Format
o Type: 1555555 (Suggested Value, TBD IANA) from IS-IS top level TLV o Type: 155 (Suggested Value, TBD IANA) from IS-IS top level TLV
registry. registry.
o Length: Total length of the value field in bytes. o Length: Total length of the value field in bytes.
o PPR-Flags: 2 Octet bit-field of flags for this TLV; described o PPR-Flags: 2 Octet bit-field of flags for this TLV; described
below. below.
o Fragment-ID: This is an 8-bit Identifier value (0-255) of the TLV o Fragment-ID: This is an 8-bit Identifier value (0-255) of the TLV
fragment. If fragments are not needed to represent the complete fragment. If fragments are not needed to represent the complete
path, L bit MUST be set and this value MUST be set to 0. path, 'U' bit MUST be set and this value MUST be set to 0.
o MT-ID: The multi-topology identifier defined in [RFC5120]; the 4
most significant bits MUST be set to 0 on transmit and ignored on
receive. The remaining 12-bit field contains the MT-ID.
o Algorithm: 1 octet value represents the route computation
algorithm. Algorithm registry is as defined in
[I-D.ietf-isis-segment-routing-extensions]. Computation towards
PPR-ID (Section 3.2) happens per MT-ID/Algorithm pair.
o PPR-Prefix: A variable size Sub-TLV representing the destination o PPR-Prefix: A variable size Sub-TLV representing the destination
of the path being described. This is defined in Section 3.1. of the path being described. This is defined in Section 3.1.
o PPR-ID: A variable size Sub-TLV representing the data plane or o PPR-ID: A variable size Sub-TLV representing the data plane or
forwarding identifier of the PPR. Defined in Section 3.2. forwarding identifier of the PPR. Defined in Section 3.2.
o PPR-PDEs: Variable number of ordered PDE Sub-TLVs which represents o PPR-PDEs: Variable number of ordered PDE Sub-TLVs which represents
the path. This is defined in Section 3.3. the path. This is defined in Section 3.3.
o PPR-Attributes: Variable number of PPR-Attribute Sub-TLVs which o PPR-Attributes: Variable number of PPR-Attribute Sub-TLVs which
represent the path attributes. These are defined in Section 3.4. represent the path attributes. These are defined in Section 3.4.
The Flags field has the following flag bits defined: The Flags field has the following flag bits defined:
PPR TLV Flags Format PPR TLV Flags Format
0 1 2 3 4 5 6 7 15 0 1 2 3 4 5 6 7 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|D|A|L|Reserved | |F|D|A|U|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1. S: If set, the PPR TLV MUST be flooded across the entire routing 1. F: Flood bit. If set, the PPR TLV MUST be flooded across the
domain. If the S flag is not set, the PPR TLV MUST NOT be leaked entire routing domain. If the F bit is not set, the PPR TLV MUST
between IS-IS levels. This bit MUST NOT be altered during the NOT be leaked between IS-IS levels. This bit MUST NOT be altered
TLV leaking during the TLV leaking
2. D: When the PPR TLV is leaked from IS-IS level-2 to level-1, the 2. D: Down Bit. When the PPR TLV is leaked from IS-IS level-2 to
D bit MUST be set. Otherwise, this bit MUST be clear. PPR TLVs level-1, the D bit MUST be set. Otherwise, this bit MUST be
with the D bit set MUST NOT be leaked from level-1 to level-2. clear. PPR TLVs with the D bit set MUST NOT be leaked from
This is to prevent TLV looping across levels. level-1 to level-2. This is to prevent TLV looping across
levels.
3. A: The originator of the PPR TLV MUST set the A bit in order to 3. A: Attach bit. The originator of the PPR TLV MUST set the A bit
signal that the prefixes and PPR-IDs advertised in the PPR TLV in order to signal that the prefix and PPR-ID advertised in the
are directly connected to the originators. If this bit is not PPR TLV are directly connected to the originators. If this bit
set, this allows any other node in the network to advertise this is not set, this allows any other node in the network to
TLV on behalf of the originating node of the PPR-Prefix. If PPR advertise this TLV on behalf of the originating node of the PPR-
TLV is leaked to other areas/levels the A-flag MUST be cleared. Prefix. If PPR TLV is leaked to other areas/levels the A-flag
In case if the originating node of the prefix must be MUST be cleared. In case if the originating node of the prefix
disambiguated for any reason including, if it is a Multi Homed must be disambiguated for any reason including, if it is a Multi
Prefix (MHP) or leaked to a different IS-IS level or because Homed Prefix (MHP) or leaked to a different IS-IS level or
[RFC7794] X-Flag is set, then PPR-Attribute Sub-TLV Source Router because [RFC7794] X-Flag is set, then PPR-Attribute Sub-TLV
ID SHOULD be included. Source Router ID SHOULD be included.
4. L: L bit MUST be set if a path has only one fragment or if it is 4. U: Ultimate fragment bit. bit MUST be set if a path has only one
the last Fragment of the path. PPR-ID value for all fragments of fragment or if it is the last Fragment of the path. PPR-ID value
the same path MUST be same. for all fragments of the same path MUST be same.
5. Reserved: For future use; MUST be set to 0 on transmit and 5. Reserved: For future use; MUST be set to 0 on transmit and
ignored on receive. ignored on receive.
PPR path description for each IS-IS level is computed and given to PPR path description for each IS-IS level is computed and given to
one of the nodes for L1 and L2 respectively. Similarly path one of the nodes for L1 and L2 respectively. Similarly path
information when crossing the level boundaries MUST be relevant to information when crossing the level boundaries MUST be relevant to
the destination level. If there is no path information available for the destination level. If there is no path information available for
the destination level PPR TLV MUST NOT be leaked regardless of S and the destination level PPR TLV MUST NOT be leaked regardless of F and
D bits as defined above. D bits as defined above.
The following Sub-TLVs draw from a new registry for Sub-TLV numbers The following Sub-TLVs draw from a new registry for Sub-TLV numbers
as specified in Section 7.1 and Section 7.2. as specified in Section 7.1 and Section 7.2.
3.1. PPR-Prefix Sub-TLV 3.1. PPR-Prefix Sub-TLV
The structure of PPR-Prefix is: The structure of PPR-Prefix is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MT-ID | | Type | Length | Prefix Length | Mask Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Mask Length | IS-IS Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IS-IS Prefix (continued, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-Prefix Sub-TLVs (variable) | // IS-IS Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PPR-Prefix Sub-TLV Format Figure 2: PPR-Prefix Sub-TLV Format
o Type: 1 (IANA to assign from Sub-TLV registry described above). o Type: 1 (IANA to assign from Sub-TLV registry described above).
o Length: Total length of the value field in bytes. o Length: Total length of the value field in bytes.
o MT-ID: The multi-topology identifier defined in [RFC5120]; the 4
most significant bits MUST be set to 0 on transmit and ignored on
receive. The remaining 12-bit field contains the MT-ID.
o Prefix Length: The length of the IS-IS Prefix being encoded in o Prefix Length: The length of the IS-IS Prefix being encoded in
bytes. For IPv4 it MUST be 4 and IPv6 it MUST be 16 bytes. bytes. For IPv4 it MUST be 4 and IPv6 it MUST be 16 bytes.
o Mask Length: The length of the prefix in bits. Only the most o Mask Length: The length of the prefix in bits. Only the most
significant octets of the Prefix are encoded. significant octets of the Prefix are encoded.
o IS-IS Prefix: The IS-IS prefix at the tail-end of the advertised o IS-IS Prefix: The IS-IS prefix at the tail-end of the advertised
PPR. This corresponds to a routable prefix of the originating PPR. This corresponds to a routable prefix of the originating
node and it MAY have one of the [RFC7794] flags set (X-Flag/R- node and it MAY have one of the [RFC7794] flags set (X-Flag/R-
Flag/N-Flag) in the IS-IS reachability TLVs. Length of this field Flag/N-Flag) in the IS-IS reachability TLVs. Length of this field
MUST be as per "Prefix Length". Encoding is same as TLV 135 MUST be as per "Prefix Length". Encoding is same as TLV 135
[RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] IPv4 (TLV [RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] IPv4 (TLV
235) and IPv6 Prefixes (TLV 237) respectively. 235) and IPv6 Prefixes (TLV 237) respectively.
o PPR-Prefix Sub-TLVs have 1 octet type, 1 octet length and value
field is defined per the type field.
3.2. PPR-ID Sub-TLV 3.2. PPR-ID Sub-TLV
This is the actual data plane identifier in the packet header and This is the actual data plane identifier in the packet header and
could be of any data plane as defined in PPR-ID Type field. Both could be of any data plane as defined in PPR-ID Type field. Both
PPR-Prefix and PPR-ID belongs to a same node in the network. PPR-Prefix and PPR-ID belongs to a same node in the network.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |PPR-ID Flags | | Type | Length |PPR-ID Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-ID Type | PPR-ID Length |PPR-ID Mask Len| Algo | | PPR-ID Type | PPR-ID Length |PPR-ID Mask Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// PPR-ID (variable size) // // PPR-ID (variable size) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PPR-ID Sub-TLV Format Figure 3: PPR-ID Sub-TLV Format
o Type: 2 (IANA to assign from Sub-TLV registry described above). o Type: 2 (IANA to assign from Sub-TLV registry described above).
o Length: Total length of the value field in bytes. o Length: Total length of the value field in bytes.
o PPR-ID Flags: 2 Octet field for PPR-ID flags: o PPR-ID Flags: 2 Octet field for PPR-ID flags:
PPR-ID Flags Format PPR-ID Flags Format
0 1 2 3 4 5 6 7.. 15 0 1 2 3 4 5 6 7.. 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: For future use; MUST be set to 0 on transmit and Reserved: For future use; MUST be set to 0 on transmit and
ignored on receive. ignored on receive.
o PPR-ID Type: Data plane type of PPR-ID. This is a new registry o PPR-ID Type: Data plane type of PPR-ID. This is a new registry
(TBD IANA - Suggested values as below) for this Sub-TLV and the (TBD IANA - Suggested values as below) for this Sub-TLV and the
defined types are as follows: defined types are as follows:
Type: 1 SR-MPLS SID/Label Type: 1 SR-MPLS SID/Label
Type: 2 Native IPv4 Address/Prefix Type: 2 Native IPv4 Address/Prefix
Type: 3 Native IPv6 Address/Prefix Type: 3 Native IPv6 Address/Prefix
Type: 4 IPv6 SID in SRv6 with SRH Type: 4 IPv6 SID in SRv6 with SRH
o PPR-ID Length: Length of the PPR-ID field in octets and this o PPR-ID Length: Length of the PPR-ID field in octets and this
depends on the PPR-ID type. See PPR-ID below for the length of depends on the PPR-ID type.
this field and other considerations.
o PPR-ID Mask Length: It is applicable for only for PPR-ID Type 2, 3 o PPR-ID Mask Len: It is applicable for only for PPR-ID Type 2, 3
and 4. For Type 1 this value MUST be set to zero. It contains and 4. For Type 1 this value MUST be set to zero. It contains
the length of the PPR-ID Prefix in bits. Only the most the length of the PPR-ID Prefix in bits. Only the most
significant octets of the Prefix are encoded. This is needed, if significant octets of the Prefix are encoded. This is needed, if
PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet PPR-ID followed is an IPv4/IPv6 Prefix instead of 4/16 octet
Address respectively. Address respectively.
o Algo: 1 octet value represents the SPF algorithm. Algorithm
registry is as defined in
[I-D.ietf-isis-segment-routing-extensions].
o PPR-ID: This is the Preferred Path forwarding identifier that o PPR-ID: This is the Preferred Path forwarding identifier that
would be on the data packet. The value of this field is variable would be on the data packet. The value of this field is variable
and it depends on the PPR-ID Type - for Type 1, this is encoded as and it depends on the PPR-ID Type - for Type 1, this is encoded as
SR-MPLS SID/Label. For Type 2 this is a 4 byte IPv4 address. For SR-MPLS SID/Label. For Type 2 this is a 4 byte IPv4 address. For
Type 3 this is a 16 byte IPv6 address. For Type 2 and Type 3 Type 3 this is a 16 byte IPv6 address. For Type 2 and Type 3
encoding is similar to "IS-IS Prefix" as specified in Section 3.1. encoding is similar to "IS-IS Prefix" as specified in Section 3.1.
For Type 4, this is encoded as 16 byte SRv6 SID. For Type 4, this is encoded as 16 byte SRv6 SID.
For PPR-ID Type 2, 3 or 4, if the PPR-ID Len is set to non-zero For PPR-ID Type 2, 3 or 4, PPR-ID MUST NOT be advertised as a
value, then the PPR-ID MUST NOT be advertised as a routable prefix in routable prefix in TLV 135, TLV 235, TLV 236 and TLV 237. PPR-ID
TLV 135, TLV 235, TLV 236 and TLV 237. Also PPR-ID MUST belong to MUST belong to the node, from where the PPR-Prefix (Section 3.1) is
the node where Prefix is advertised from. PPR-ID Len = 0 case is a advertised.
special case and is discussed in Section 4.1.
3.3. PPR-PDE Sub-TLV 3.3. PPR-PDE Sub-TLV
This Sub-TLV represents the PPR Path Description Element (PDE). PPR- This Sub-TLV represents the PPR Path Description Element (PDE). PPR-
PDEs are used to describe the path in the form of set of contiguous PDEs are used to describe the path in the form of set of contiguous
and ordered Sub-TLVs, where first Sub-TLV represents (the top of the and ordered Sub-TLVs, where first Sub-TLV represents (the top of the
stack in MPLS data plane or) first node/segment of the path. These stack in MPLS data plane or) first node/segment of the path. These
set of ordered Sub-TLVs can have both topological elements and non- set of ordered Sub-TLVs can have both topological elements and non-
topological elements (e.g., service segments). topological elements (e.g., service segments).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | PPR-PDE Type | Reserved | | Type | Length | PPR-PDE Type | PDE-ID Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDE-ID Type | PDE-ID Len | PPR-PDE Flags | | PDE-ID Length | PPR-PDE Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// PDE-ID Value (continued, variable size) // // PDE-ID Value (variable size) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-PDE Sub-TLVs (variable) | |Sub-TLV Length | PPR-PDE Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PPR-PDE Sub-TLV Format Figure 4: PPR-PDE Sub-TLV Format
o Type: 3 (See IANA for suggested value) from IS-IS PPR TLV o Type: 3 (See IANA for suggested value) from IS-IS PPR TLV
Section 3 Sub-TLV registry. Section 3 Sub-TLV registry.
o Length: Total length of the value field in bytes. o Length: Total length of the value field in bytes.
o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the
skipping to change at page 11, line 11 skipping to change at page 11, line 4
o Type: 3 (See IANA for suggested value) from IS-IS PPR TLV o Type: 3 (See IANA for suggested value) from IS-IS PPR TLV
Section 3 Sub-TLV registry. Section 3 Sub-TLV registry.
o Length: Total length of the value field in bytes. o Length: Total length of the value field in bytes.
o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the o PPR-PDE Type: A new registry (TBD IANA) for this Sub-TLV and the
defined types are as follows: defined types are as follows:
Type: 1 Topological Type: 1 Topological
Type: 2 Non-Topological Type: 2 Non-Topological
o PDE-ID Type: 1 Octet PDE-forwarding IDentifier Type. A new o PDE-ID Type: 1 Octet PDE-forwarding IDentifier Type. A new
registry (Suggested Values as listed, IANA TBD) for this Sub-TLV registry (Suggested Values as listed, IANA TBD) for this Sub-TLV
and the defined types and corresponding PDE-ID Len, PDE-ID Value and the defined types and corresponding PDE-ID Length, PDE-ID
are as follows: Value are as follows:
Type 0: This value MUST be set only when PPR-PDE Type is Non- Type 0: This value MUST be set only when PPR-PDE Type is Non-
Topological. PDE-ID Len specified in bytes and encoded in NBO Topological. PDE-ID Length indicates the length of the PDE-ID
in PDE-ID Value field which can represent a service/function. Value field in bytes. For this type, PDE-ID value represents a
This information is provisioned on the immediate topological PDE service/function. This information is provisioned on the
preceding to this PDE based on the 'E' bit. immediate topological PDE preceding to this PDE based on the 'E'
bit.
Type 1: SID/Label type as defined in Type 1: SID/Label type as defined in
[I-D.ietf-isis-segment-routing-extensions]. PDE-ID Len and PDE- [I-D.ietf-isis-segment-routing-extensions]. PDE-ID Length and
ID Value fields are per Section 2.3 of the referenced document. PDE-ID Value fields are per Section 2.3 of the referenced
document.
Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are
same as Type 1.
Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are Type 2: SR-MPLS Prefix SID. PDE-ID Length and PDE-ID Value are
same as Type 1. same as Type 1.
Type 4: IPv4 Node Address. PDE-ID Len is 4 bytes and PDE-ID Type 3: SR-MPLS Adjacency SID. PDE-ID Length and PDE-ID Value
Value is 4 bytes IPv4 address encoded similar to IPv4 Prefix are same as Type 1.
described in Section 3.1.
Type 5: IPv4 P2P interface Address. PDE-ID Len is 4 bytes and
PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4
Prefix described in Section 3.1.
Type 6: IPv4 LAN interface Address. PDE-ID Len is 4 bytes and Type 4: IPv4 Node Loopback Address. PDE-ID Length 4 bytes and
PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4 PDE-ID Value is full 4 bytes IPv4 address encoded as specified
Prefix described in Section 3.1. This type MUST have IS-IS in "4-octet IPv4 address" of Sub-TLV 6/TLV 22 in [RFC5305].
System-ID Sub-TLV in the PDE.
Type 7: IPv6 Node Address. PDE-ID Len is 16 bytes and PDE-ID Type 5: IPv4 Interface Address. PDE-ID Length is 4 bytes and
Value is 16 bytes IPv6 address encoded similar to IPv6 Prefix PDE-ID Value is full 4 bytes IPv4 address encoded as specified
described in Section 3.1. in "4-octet IPv4 address" of Sub-TLV 6/TLV 22 in [RFC5305].
This PDE-ID in the path description represents the egress
interface of the path segment and correponding adjacency is set
as nexthop for the PPR-ID.
Type 8: IPv6 P2P interface Address. PDE-ID Len is 16 bytes and Type 6: IPv6 Node Loopback Address. PDE-ID Length and PDE-ID
PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6 Value are encoded as specified in "Prefix Len" and "prefix"
Prefix described in Section 3.1. portion of TLV 236 in [RFC5308] respectively.
Type 9: IPv6 LAN interface Address. PDE-ID Len is 16 bytes and Type 7: IPv6 Interface Address. PDE-ID Length is 16 bytes and
PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6 PDE-ID Value is full 16 bytes IPv6 address encoded as specified
Prefix described in Section 3.1. This type MUST have IS-IS in "Interface Address 1" portion of TLV 232 in [RFC5308]. This
System-ID Sub-TLV in the PDE. PDE-ID in the path description represents the egress interface
of the path segment and correponding adjacency is set as nexthop
for the PPR-ID.
Type 10: SRv6 Node SID as defined in Type 8: SRv6 Node SID as defined in
[I-D.bashandy-isis-srv6-extensions]. PDE-ID Len and PDE-ID [I-D.bashandy-isis-srv6-extensions]. PDE-ID Length and PDE-ID
Value are as defined in SRv6 SID from the referenced draft. Value are as defined in SRv6 SID from the referenced draft.
Type 11: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Values are Type 9: SRv6 Adjacency-SID. PDE-ID Length and PDE-ID Values are
similar to SRv6 Node SID above. similar to SRv6 Node SID above.
o PPR-PDE Flags: 2 Octet bit-field of flags; described below: o PPR-PDE Flags: 2 Octet bit-field of flags; described below:
PPR-PDE Flags Format PPR-PDE Flags Format
0 1 2 3 4 5 6 7 .. 15 0 1 2 3 4 5 6 7 .. 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|D|E|Reserved | |L|N|E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: Loose Bit. Indicates the type of next "Topological PDE-ID" in L: Loose Bit. Indicates the type of next "Topological PDE-ID" in
the path description. If set, the next Topological PDE is the path description. This bit MUST be set for only Node/Prefix
Loose. If this flag is unset, the next Topological PDE is PDE type. If this flag is unset, the next Topological PDE is
Strict Type. Strict Type.
D: Destination Bit. By default this bit MUST be unset. This bit N: Node Bit. By default this bit MUST be unset. This bit MUST
MUST be set only for PPR-PDE Type is 1 i.e., Topological and be set only for PPR-PDE Type is 1 i.e., Topological and this PDE
this PDE represents the node PPR-Prefix Section 3.1 belongs to, represents the node, where PPR-Prefix (Section 3.1) belongs to
if there is no further PDE specific Sub-TLVs to override PPR- (if there is no further PDE specific Sub-TLVs to override PPR-
Prefix and PPR-ID values. Prefix and PPR-ID values).
E: Egress Bit. By default this bit MUST be unset. This bit MUST E: Egress Bit. By default this bit MUST be unset. This bit MUST
be set only for PPR-PDE Type is 2 i.e., Non-Topological and the be set only for PPR-PDE Type is 2 i.e., Non-Topological and the
service needs to be applied on the egress side of the service needs to be applied on the egress side of the
topological PDE preceding this PDE. topological PDE preceding this PDE.
Reserved: Reserved bits for future use. Reserved bits MUST be Reserved: Reserved bits for future use. Reserved bits MUST be
reset on transmission and ignored on receive. reset on transmission and ignored on receive.
o Sub-TLV Length: 1 byte length of all Sub-TLVs followed. It MUST
be set to 0 if no further Sub-TLVs are present.
o PPR-PDE Sub-TLVs: These have 1 octet type, 1 octet length and o PPR-PDE Sub-TLVs: These have 1 octet type, 1 octet length and
value field is defined per the type field. Types are as defined value field is defined per the type field. Types are as defined
in Section 7 and the length field represents the length of the in PPR-TLV Sub-TLVs (Section 7), encoded further as sub-sub-TLVs
of PPR-PDE and the length field represents the total length of the
value field in bytes. value field in bytes.
PPR-PDE Sub-TLV: Type 4 (IANA TBD), Length Total length of value IS-IS System-ID Sub-TLV: Type 4 (IANA TBD), Length Total length
field in bytes, Value: IS-IS System-ID of length "ID Length" as of value field in bytes, Value: IS-IS System-ID of length "ID
defined in [ISO.10589.1992]. This Sub-TLV MUST NOT be present, Length" as defined in [ISO.10589.1992]. This Sub-TLV MUST NOT
if the PPR-PDE Type is not equal to 1 i.e, Topological PDE. be present, if the PPR-PDE Type is not Topological. Though the
type for this come from the PPR Sub-TLV registry, here this is a
sub-sub-TLV and is part of PPR-ID/PPR-PDE Sub-TLV.
3.4. PPR-Attributes Sub-TLV 3.4. PPR-Attributes Sub-TLV
PPR-Attribute Sub-TLVs describe the attributes of the path. The PPR-Attribute Sub-TLVs describe the attributes of the path. This
following Sub-TLVs draw from a new registry for Sub-TLV numbers; this document defines the following optional PPR-Attribute Sub-TLVs:
registry is to be created by IANA, and administered using the first
come first serve process:
o Type 1 (Suggested Value - IANA TBD): PPR-Prefix originating node's o Type 5 (Suggested Value - IANA TBD): PPR-Prefix originating node's
IPv4 Router ID Sub-TLV. Length and Value field are as specified IPv4 Router ID Sub-TLV. Length and Value field are as specified
in [RFC7794]. in [RFC7794].
o Type 2 (Suggested Value - IANA TBD): PPR-Prefix originating node's o Type 6 (Suggested Value - IANA TBD): PPR-Prefix originating node's
IPv6 Router ID Sub-TLV. Length and Value field are as specified IPv6 Router ID Sub-TLV. Length and Value field are as specified
in [RFC7794]. in [RFC7794].
o Type 3 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 o Type 7 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4
bytes, and Value is metric of this path represented through the bytes, and Value is metric of this path represented through the
PPR-ID. Different nodes can advertise the same PPR-ID for the PPR-ID. Different nodes can advertise the same PPR-ID for the
same Prefix with a different set of PPR-PDE Sub-TLVs and the same Prefix with a different set of PPR-PDE Sub-TLVs and the
receiving node MUST consider the lowest metric value. receiving node MUST consider the lowest metric value.
4. PPR Processing Procedure Example 4. PPR Processing Procedure Example
As specified in Section 2, a PPR can be a TE path, locally As specified in Section 2, a PPR can be a TE path, locally
provisioned by the operator or by a controller. Consider the provisioned by the operator or by a controller. Consider the
following IS-IS network to describe the operation of PPR TLV as following IS-IS network to describe the operation of PPR TLV as
skipping to change at page 14, line 39 skipping to change at page 14, line 39
IS-IS metric as provisioned. R1 may be configured to receive TE IS-IS metric as provisioned. R1 may be configured to receive TE
source routed path information from a central entity (PCE [RFC5440], source routed path information from a central entity (PCE [RFC5440],
Netconf [RFC6241] or a Controller) that comprises of PPR information Netconf [RFC6241] or a Controller) that comprises of PPR information
which relates to sources that are attached to R1. It is also which relates to sources that are attached to R1. It is also
possible to have a PPR provisioned locally by the operator for non-TE possible to have a PPR provisioned locally by the operator for non-TE
needs (e.g. FRR or for chaining certain services). needs (e.g. FRR or for chaining certain services).
The PPR TLV (as specified in Section 3) is encoded as an ordered list The PPR TLV (as specified in Section 3) is encoded as an ordered list
of PPR-PDEs from source to a destination node in the network and is of PPR-PDEs from source to a destination node in the network and is
represented with a PPR-ID (Section 3.2). The PPR TLV includes PPR- represented with a PPR-ID (Section 3.2). The PPR TLV includes PPR-
PDE Sub-TLVS Section 3.3, which represent both topological and non- PDE Sub-TLVs Section 3.3, which represent both topological and non-
topological elements and specifies the actual path towards a PPR- topological elements and specifies the actual path towards a PPR-
Prefix at R4. Prefix at R4.
o The shortest path towards R4 from R1 are through the following o The shortest path towards R4 from R1 are through the following
sequence of nodes: R1-R2-R3-R4 based on the provisioned metrics. sequence of nodes: R1-R2-R3-R4 based on the provisioned metrics.
o The central entity can define a few PPRs from R1 to R4 that o The central entity can define a few PPRs from R1 to R4 that
deviate from the shortest path based on other network deviate from the shortest path based on other network
characteristic requirements as requested by an application or characteristic requirements as requested by an application or
service. For example, the network characteristics or performance service. For example, the network characteristics or performance
skipping to change at page 16, line 5 skipping to change at page 16, line 5
R10 to reach R4 as specified in the PPR path description. Same R10 to reach R4 as specified in the PPR path description. Same
process happens to all nodes or all topological PDEs as described in process happens to all nodes or all topological PDEs as described in
the PPR TLV. the PPR TLV.
In summary, the receiving node checks first, if this node is on the In summary, the receiving node checks first, if this node is on the
path by checking the node's topological elements (with PPR-PDE Type path by checking the node's topological elements (with PPR-PDE Type
set to Topological) in the path list. If yes, it adds/adjusts the set to Topological) in the path list. If yes, it adds/adjusts the
PPR-ID's shortest path NH towards the next topological PDE in the PPR-ID's shortest path NH towards the next topological PDE in the
PPR's Path. PPR's Path.
For PPR-ID (Section 3.2) Type 2, 3 or 4, if the PPR-ID Len is set to
0, then Prefix would also become the PPR-ID (a special case). This
can be used for some situations, where certain optimizations are
required in the network. For this, path described in the PPR TLV
SHOULD be completely disjoint from the shortest path route to the
prefix. If the disjoint-ness property is not maintained then the
traffic may not be using the PPR path, as and when it encounters any
node which is not in the path description.
4.2. Path Fragments 4.2. Path Fragments
A complete PPR path may not fit into maximum allowable size of the A complete PPR path may not fit into maximum allowable size of the
IS-IS TLV. To overcome this a 7 bit Fragment-ID field is defined in IS-IS TLV. To overcome this a 7 bit Fragment-ID field is defined in
Section 3 . With this, a single PPR path is represented via one or Section 3 . With this, a single PPR path is represented via one or
more fragmented PPR path TLVs, with all having the same PPR-ID. Each more fragmented PPR path TLVs, with all having the same PPR-ID. Each
fragment carries the PPR-ID as well as a numeric Fragment-ID from 0 fragment carries the PPR-ID as well as a numeric Fragment-ID from 0
to (N-1), when N fragments are needed to describe the PPR Graph to (N-1), when N fragments are needed to describe the PPR Graph
(where N>1). In this case Fragment (N-1) MUST set the L bit (PPR- (where N>1). In this case Fragment (N-1) MUST set the 'U' bit (PPR-
Flags) to indicate it is the last fragment. If Fragment-ID is non Flags) to indicate it is the last fragment. If Fragment-ID is non
zero in the TLV, then it MUST not carry PPR-Prefix Sub-TLV. The zero in the TLV, then it MUST not carry PPR-Prefix Sub-TLV. The
optional PPR Attribute Sub-TLVs which describe the path overall MUST optional PPR Attribute Sub-TLVs which describe the path overall MUST
be included in the last fragment only (i.e., when the L bit is set). be included in the last fragment only (i.e., when the 'U' bit is
set).
5. PPR Data Plane aspects 5. PPR Data Plane aspects
Data plane for PPR-ID is selected by the entity (e.g., a controller, Data plane for PPR-ID is selected by the entity (e.g., a controller,
locally provisioned by operator), which selects a particular PPR in locally provisioned by operator), which selects a particular PPR in
the network. Section 3.2 defines various data plane identifier types the network. Section 3.2 defines various data plane identifier types
and a corresponding data plane identifier is selected by the entity and a corresponding data plane identifier is selected by the entity
which selects the PPR. which selects the PPR.
5.1. SR-MPLS with PPR 5.1. SR-MPLS with PPR
skipping to change at page 18, line 29 skipping to change at page 18, line 29
This document requests the following new TLV in IANA IS-IS TLV code- This document requests the following new TLV in IANA IS-IS TLV code-
point registry. point registry.
TLV # Name TLV # Name
----- -------------- ----- --------------
155 PPR TLV (Suggested Value, IANA TBD) 155 PPR TLV (Suggested Value, IANA TBD)
7.1. PPR Sub-TLVs 7.1. PPR Sub-TLVs
This document requests IANA to create a new Sub-TLV registry for PPR This document requests IANA to create a new Sub-TLV registry for PPR
TLV Section 3 with the following initial entries (suggested values): TLV Section 3 with the following initial entries (suggested values).
Though these are defined as Sub-TLVs of PPR TLV, these can be part of
another Sub-TLV as a nested sub-sub-TLV (e.g. IS-IS System-ID).
Sub-TLV # Sub-TLV Name Sub-TLV # Sub-TLV Name
--------- --------------------------------------------------------- --------- ---------------------------------------------------------
1 PPR-Prefix (Section 3.1) 1 PPR-Prefix (Section 3.1)
2 PPR-ID (Section 3.2) 2 PPR-ID (Section 3.2)
3 PPR-PDE (Section 3.3) 3 PPR-PDE (Section 3.3)
4 IS-IS System-ID (Section 3.3) 4 IS-IS System-ID (Section 3.3)
5 PPR-Prefix Source IPv4 Router ID (Section 3.4)
6 PPR-Prefix Source IPv6 Router ID (Section 3.4)
7 PPR-Metric (Section 3.4)
7.2. IGP Parameters 7.2. IGP Parameters
This document requests additional IANA registries in an IANA managed This document requests additional IANA registries in an IANA managed
registry "Interior Gateway Protocol (IGP) Parameters" for various PPR registry "Interior Gateway Protocol (IGP) Parameters" for various PPR
TLV parameters. The registration procedure is based on the "Expert TLV parameters. The registration procedure is based on the "Expert
Review" as defined in [RFC8126]. The suggested registry names are: Review" as defined in [RFC8126]. The suggested registry names are:
o "PPR-Type" - Types are an unsigned 8 bit numbers. Values are as o "PPR-Type" - Types are an unsigned 8 bit numbers. Values are as
defined in Section 3 of this document. defined in Section 3 of this document.
skipping to change at page 19, line 23 skipping to change at page 19, line 33
o "PPR-PDE Type" - Types are an unsigned 8 bit numbers. Values are o "PPR-PDE Type" - Types are an unsigned 8 bit numbers. Values are
as defined in Section 3.3 of this document. as defined in Section 3.3 of this document.
o "PPR-PDE Flags" - 1 Octet. Bits as described in Section 3.3 of o "PPR-PDE Flags" - 1 Octet. Bits as described in Section 3.3 of
this document. this document.
o "PDE-ID Type" - Types are an unsigned 8 bit numbers. Values are o "PDE-ID Type" - Types are an unsigned 8 bit numbers. Values are
as defined in Section 3.3 of this document. as defined in Section 3.3 of this document.
This document also requests IANA to create a new Sub-TLV registry in
"Interior Gateway Protocol (IGP) Parameters" for PPR Path attributes
with the following initial entries (suggested values):
Sub-TLV # Sub-TLV Name
--------- ---------------------------------------------------------
1 PPR-Prefix Source IPv4 Router ID (Section 3.4)
2 PPR-Prefix Source IPv6 Router ID (Section 3.4)
3 PPR-Metric (Section 3.4)
8. Security Considerations 8. Security Considerations
Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310].
Further security analysis for IS-IS protocol is done in [RFC7645] Further security analysis for IS-IS protocol is done in [RFC7645]
with detailed analysis of various security threats and why [RFC5304] with detailed analysis of various security threats and why [RFC5304]
should not be used in the deployments. Advertisement of the should not be used in the deployments. Advertisement of the
additional information defined in this document introduces no new additional information defined in this document introduces no new
security concerns in IS-IS protocol. However, for extensions related security concerns in IS-IS protocol. However, for extensions related
ro SR-MPLS and SRH data planes, those particular data plane security ro SR-MPLS and SRH data planes, those particular data plane security
considerations does apply here. considerations does apply here.
skipping to change at page 20, line 32 skipping to change at page 20, line 31
9.2. Informative References 9.2. Informative References
[I-D.bashandy-isis-srv6-extensions] [I-D.bashandy-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extensions to Support Routing over IPv6 Z. Hu, "IS-IS Extensions to Support Routing over IPv6
Dataplane", draft-bashandy-isis-srv6-extensions-05 (work Dataplane", draft-bashandy-isis-srv6-extensions-05 (work
in progress), March 2019. in progress), March 2019.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
(SRH)", draft-ietf-6man-segment-routing-header-18 (work in Routing Header (SRH)", draft-ietf-6man-segment-routing-
progress), April 2019. header-21 (work in progress), June 2019.
[I-D.ietf-isis-encapsulation-cap] [I-D.ietf-isis-encapsulation-cap]
Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras, Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras,
L., and L. Jalil, "Advertising Tunnelling Capability in L., and L. Jalil, "Advertising Tunnelling Capability in
IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in
progress), April 2017. progress), April 2017.
[I-D.ietf-isis-mpls-elc] [I-D.ietf-isis-mpls-elc]
Xu, X., Kini, S., Psenak, P., Filsfils, C., and S. Xu, X., Kini, S., Psenak, P., Filsfils, C., and S.
Litkowski, "Signaling Entropy Label Capability and Entropy Litkowski, "Signaling Entropy Label Capability and Entropy
Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- Readable Label Depth Using IS-IS", draft-ietf-isis-mpls-
elc-07 (work in progress), May 2019. elc-07 (work in progress), May 2019.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for Gredler, H., and B. Decraene, "IS-IS Extensions for
Segment Routing", draft-ietf-isis-segment-routing- Segment Routing", draft-ietf-isis-segment-routing-
extensions-24 (work in progress), April 2019. extensions-25 (work in progress), May 2019.
[I-D.ietf-mpls-sfc] [I-D.ietf-mpls-sfc]
Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
Forwarding Plane for Service Function Chaining", draft- Forwarding Plane for Service Function Chaining", draft-
ietf-mpls-sfc-07 (work in progress), March 2019. ietf-mpls-sfc-07 (work in progress), March 2019.
[I-D.xuclad-spring-sr-service-chaining] [I-D.xuclad-spring-sr-service-chaining]
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, "Segment Routing for Henderickx, W., and S. Salsano, "Segment Routing for
skipping to change at page 25, line 8 skipping to change at page 25, line 8
MSDs (and RLD type) capabilities advertisement help mitigate the MSDs (and RLD type) capabilities advertisement help mitigate the
problem for a central entity to create the right source routed path problem for a central entity to create the right source routed path
per application/operator requirements. However the availability of per application/operator requirements. However the availability of
actual paths meeting these requirements are still limited by the actual paths meeting these requirements are still limited by the
underlying hardware and their MSD capabilities in the data path. underlying hardware and their MSD capabilities in the data path.
Authors' Addresses Authors' Addresses
Uma Chunduri Uma Chunduri
Huawei USA Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: uma.chunduri@huawei.com Email: umac.ietf@gmail.com
Richard Li Richard Li
Huawei USA Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: renwei.li@huawei.com Email: richard.li@futurewei.com
Russ White Russ White
Juniper Networks Juniper Networks
Oak Island, NC 28465 Oak Island, NC 28465
USA USA
Email: russ@riw.us Email: russ@riw.us
Jeff Tantsura Jeff Tantsura
Apstra Inc. Apstra Inc.
skipping to change at page 26, line 5 skipping to change at page 26, line 5
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Luis M. Contreras Luis M. Contreras
Telefonica Telefonica
Sur-3 building, 3rd floor Sur-3 building, 3rd floor
Madrid 28050 Madrid 28050
Spain Spain
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
Yingzhen Qu Yingzhen Qu
Huawei USA Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: yingzhen.qu@huawei.com Email: yingzhen.qu@futurewei.com
 End of changes. 66 change blocks. 
159 lines changed or deleted 140 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/