< draft-chunduri-lsr-isis-preferred-path-routing-02.txt   draft-chunduri-lsr-isis-preferred-path-routing-03.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 Huawei USA
Expires: August 18, 2019 R. White Expires: November 17, 2019 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 Huawei USA
February 14, 2019 May 16, 2019
Preferred Path Routing (PPR) in IS-IS Preferred Path Routing (PPR) in IS-IS
draft-chunduri-lsr-isis-preferred-path-routing-02 draft-chunduri-lsr-isis-preferred-path-routing-03
Abstract Abstract
This document specifies a Preferred Path Routing (PPR), a routing This document specifies Preferred Path Routing (PPR), a routing
protocol mechanism to simplify the path description of data plane protocol extension to simplify the path description on the packet for
traffic in Segment Routing (SR) deployments. 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 overheads; and also supports traffic measurement, accounting packet overhead; and also supports further extensions along the
statistics and further attribute extensions along the paths. paths.
Preferred Path Routing is achieved through the addition of
descriptions to IS-IS advertised prefixes, and mapping those to a PPR
data-plane identifier.
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119], document are to be interpreted as described in RFC2119 [RFC2119],
RFC8174 [RFC8174] when, and only when they appear in all capitals, as RFC8174 [RFC8174] when, and only when they appear in all capitals, as
shown here. shown here.
Status of This Memo Status of This Memo
skipping to change at page 2, line 9 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 August 18, 2019.
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
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
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Challenges with Increased SID Depth . . . . . . . . . . . 4 2. Preferred Path Routing (PPR) . . . . . . . . . . . . . . . . 4
1.3. Mitigation with MSD . . . . . . . . . . . . . . . . . . . 6 2.1. PPR-ID and Data Plane Extensibility . . . . . . . . . . . 4
2. Preferred Path Routing (PPR) . . . . . . . . . . . . . . . . 6 2.2. PPR Path Description . . . . . . . . . . . . . . . . . . 4
2.1. PPR-ID and PPR Path Description . . . . . . . . . . . . . 7 2.3. ECMP Considerations . . . . . . . . . . . . . . . . . . . 5
3. PPR Related TLVs . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Scalability and PPR Graphs . . . . . . . . . . . . . . . 5
3.1. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . . . 9 3. PPR Related TLVs . . . . . . . . . . . . . . . . . . . . . . 5
3.2. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 10 3.1. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . . . 8
3.3. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . . . 12 3.2. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 8
3.4. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . . . 14 3.3. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . . . 10
4. PPR Processing Procedure Example . . . . . . . . . . . . . . 15 3.4. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . . . 13
4.1. PPR TLV Processing . . . . . . . . . . . . . . . . . . . 17 4. PPR Processing Procedure Example . . . . . . . . . . . . . . 13
4.2. Path Fragments . . . . . . . . . . . . . . . . . . . . . 18 4.1. PPR TLV Processing . . . . . . . . . . . . . . . . . . . 15
5. PPR Data Plane aspects . . . . . . . . . . . . . . . . . . . 18 4.2. Path Fragments . . . . . . . . . . . . . . . . . . . . . 16
5.1. SR-MPLS with PPR . . . . . . . . . . . . . . . . . . . . 18 5. PPR Data Plane aspects . . . . . . . . . . . . . . . . . . . 16
5.2. SRv6 with PPR . . . . . . . . . . . . . . . . . . . . . . 19 5.1. SR-MPLS with PPR . . . . . . . . . . . . . . . . . . . . 16
5.3. PPR Native IP Data Planes . . . . . . . . . . . . . . . . 19 5.2. PPR Native IP Data Planes . . . . . . . . . . . . . . . . 17
6. PPR Scaling Considerations . . . . . . . . . . . . . . . . . 19 5.3. SRv6 with PPR . . . . . . . . . . . . . . . . . . . . . . 17
7. PPR Traffic Accounting . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.1. PPR Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7.2. IGP Parameters . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 22
A.1. Challenges with Increased SID Depth . . . . . . . . . . . 22
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
packet header. Each SID uniquely identifies a segment as defined in packet header. Each SID uniquely identifies a segment as defined in
[I-D.ietf-spring-segment-routing]. SR capabilities are defined for [RFC8402] . SR capabilities are defined for MPLS and IPv6 data planes
MPLS and IPv6 data planes called SR-MPLS and SRv6 respectively. called SR-MPLS and SRv6 respectively. Appendix A.1 and Appendix A.2
describe performance, hardware capabilities and various associated
In SR-MPLS, each segment is encoded as a label, and an ordered list issues which may result in SR deployments.
of segments are encoded as a stack of labels. This stack of labels
is carried as part of the packet header. In SRv6, a segment is
encoded as an IPv6 address, within a new type of IPv6 hop-by-hop
routing header/extension header (EH) called SRH
[I-D.ietf-6man-segment-routing-header]; an ordered list of IPv6
addresses/segments are encoded in SRH.
Section 1.2 and Section 1.3 describe performance, hardware The above motivate the proposed solution, Preferred Path Routing
capabilities and various associated issues which may result in SR (PPR). In brief, PPR involves, associating path descriptions to IS-
deployments. These motivate the proposed solution, Preferred Path IS advertised prefixes, mapping those to a data-plane identifier and
Routing, which is specified in Section 2. specifying a mechanism to route packets with the abstracted
identifier (PPR-ID), as opposed to individual segments on the packet.
This is specified in detail in Section 2 and Section 3.
1.1. Acronyms 1.1. Acronyms
EL - Entropy Label EL - Entropy Label
ELI - Entropy Label Indicator ELI - Entropy Label Indicator
LSP - IS-IS Link State PDU LSP - IS-IS Link State PDU
MPLS - Multi Protocol Label Switching MPLS - Multi Protocol Label Switching
MSD - Maximum SID Depth MSD - Maximum SID Depth
MTU - Maximum Transferrable Unit MTU - Maximum Transferrable Unit
NH - Next-Hop
PPR - Preferred Path Routing/Route PPR - Preferred Path Routing/Route
PPR-ID - Preferred Path Route Identifier, a data plane identifier PPR-ID - Preferred Path Route Identifier, a data plane identifier
SID - Segment Identifier SID - Segment Identifier
SPF - Shortest Path First SPF - Shortest Path First
SR-MPLS - Segment Routing with MPLS data plane SR-MPLS - Segment Routing with MPLS data plane
SRH - Segment Routing Header - IPv6 routing Extension headr
SRv6 - Segment Routing with Ipv6 data plane with SRH SRH - Segment Routing Header - IPv6 routing Extension header
SRv6 - Segment Routing with IPv6 data plane with SRH
TE - Traffic Engineering TE - Traffic Engineering
1.2. Challenges with Increased SID Depth
SR label stacks carried in the packet header create challenges in the
design and deployment of networks and networking equipment.
Following examples illustrates the need for increased SID depth in
various use cases:
(a). Consider the following network where SR-MPLS data plane is in
use and with same SRGB (5000-6000) on all nodes i.e., A1 to A7 and B1
to B7 for illustration:
SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70
A1--------A2-------A3-------A4-------A5===============A6-- ----------A7
| \ / \5 5/ \ SID:310(Ay) \ /
| 5 \ 10 10/ +-A10-+ \ \10 10/
| \ SID:80 / |SID:100 \ \ /
A11 SID:111 \A8-----A9/ | \ 40 \ /
| / SID:90 \ +-----+ +---+ \ /
| 5 /10 \10 5 \ \ \ /
| /SID:125(B2x) \ \ \ \/
B1-------B2==============B3----B4------B5-------=B6----------B7
SID:127(B2y)
SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170
=== = Path with Parallel Adjecencies and ADJ-SIDs
--- = Shortest Path Nodal SID
Figure 1: SR-MPLS Network
Global ADJ-SIDs are provisioned between A5-A6 and B2-B3 (with
parallel adjecencies). All other SIDs shown are nodal SID
indices.
All metrics of the links are set to 1, unless marked otherwise.
Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7
Path-x: From A1 to A7 - A2-A8-B2-B2x-A9-A10-Ax-A7; Pushed Label
Stack @A1: 5020:5080:5120:5125:5090:5100:5300:5070 (where B2x is a
local ADJ-SID and Ax is a global ADJ-SID).
In this example, the traffic engineered path is represented with a
combination of Adjacency and Node SIDs with a stack of 8 labels.
However, this value can be larger, if the use of entropy label
[RFC6790] is desired and based on the Readable Label Depth
(Section 1.3) capabilities of each node and additional labels
required to insert ELI/EL at appropriate places.
Though above network is shown with SR-MPLS data plane, if the
network were to use SR-IPv6 data plane, path size would be
increased even more because of the size of the IPv6 SID (16 bytes)
in SRH.
(b). Apart from the TE case above, when deploying
[I-D.ietf-mpls-sfc] or [I-D.xuclad-spring-sr-service-chaining], with
the inclusion of services, or non-topological segments on the label
stack, can also make the size of the stack much larger.
(c). Some SR-MPLS deployments need accounting statistics for path
monitoring and traffic re-optimizations.
[I-D.hegde-spring-traffic-accounting-for-sr-paths] and
[I-D.cheng-spring-mpls-path-segment] propose solutions with various
forms of path segments (either with special labels or PATH segment
encoded at the bottom of the stack respectively). However, these
proposals further increases the depth of SID stack, when it is
compounded with MSD/RLDs of various nodes in the path.
Overall the additional path overhead in various SR deployments may
cause the following issues:
a. HW Capabilities: Not all nodes in the path can support the
ability to push or read label stack (with additional non-
topological and special labels) needed
[I-D.ietf-isis-segment-routing-msd] to satisfy user/operator
requirements. Alternate paths, which meet these user/operator
requirements may not be available.
b. Line Rate: Potential performance issues in deployments, which use
SRH data plane with the increased size of the SRH with 16 byte
SIDs.
c. MTU: Larger SID stacks on the data packet can cause potential
MTU/fragmentation issues (SRH).
d. Header Tax: Some deployments, such as 5G, require minimal packet
overhead in order to conserve network resources. Carrying 40 or
50 octets of data in a packet with hundreds of octet of header
would be an unacceptable use of available bandwidth (SRH).
With the solution proposed in this document (Section 5) and
Section 4), for Path-x in the example network Figure 1 above, SID
stack would be reduced from 8 SIDs to a single SID.
1.3. Mitigation with MSD
The number of SIDs in the stack a node can impose is referred as
Maximum SID Depth (MSD) capability
[I-D.ietf-isis-segment-routing-msd], which must be taken into
consideration when computing a path to transport a data packet in a
network implementing segment routing. [I-D.ietf-isis-mpls-elc]
defines another MSD type, Readable Label Depth (RLD) that is used by
a head-end to insert Entropy Label pair (ELI/EL) at appropriate
depth, so it could be read by transit nodes. There are situations
where the source routed path can be excessive as path represented by
SR SIDs need to describe all the nodes and ELI/EL based on the
readability of the nodes in that path.
[I-D.ietf-isis-segment-routing-msd] defines one registry element
applicable for MPLS data plane and this registry can be used for IPv6
data plane with SRH.
MSDs (and RLD type) capabilities advertisement help mitigate the
problem for a central entity to create the right source routed path
per application/operator requirements. However the availability of
actual paths meeting these requirements are still limited by the
underlying hardware and their MSD capabilities in the data path.
2. Preferred Path Routing (PPR) 2. Preferred Path Routing (PPR)
PPR mitigates the issues described in Section 1.2, while continuing PPR mitigates the issues described in Appendix A.1, while continuing
to allow the direction of traffic along an engineered path through to allow the direction of traffic along an engineered path through
the network by replacing the label stack with a PPR-ID. The PPR-ID the network by replacing the label stack with a PPR-ID. The PPR-ID
can either be a single label or a native destination address. To can either be a single label or a native destination address. To
facilitate the use of a single label to describe an entire path, a facilitate the use of a single label to describe an entire path, a
new TLV is added to IS-IS, as described below in Section 3. new TLV is added to IS-IS, as described below in Section 3.
A PPR could be an SR path, a traffic engineered path computed based A PPR could be an SR path, a traffic engineered path computed based
on some constraints, an explicitly provisioned Fast Re-Route (FRR) on some constraints, an explicitly provisioned Fast Re-Route (FRR)
path or a service chained path. A PPR can be signaled by any node, path or a service chained path. A PPR can be signaled by any node,
computed by a central controller, or manually configured by an computed by a central controller, or manually configured by an
operator. PPR extends the source routing and path steering operator. PPR extends the source routing and path steering
capabilities to native IP (IPv4 and IPv6) data planes without capabilities to native IP (IPv4 and IPv6) data planes without
hardware upgrades; see Section 5. hardware upgrades; see Section 5.
2.1. PPR-ID and PPR Path Description 2.1. PPR-ID and Data Plane Extensibility
The PPR-ID describes a path through the network. For SR- MPLS this The PPR-ID describes a path through the network. A data plane type
is an MPLS Label/SID and for SRv6 this is an IPv6-SID. For native IP and corresponding data plane identifier as specified in Section 3.2
data planes this is either IPv4 or IPv6 address/prefix. is mapped to PPR-ID to allow data plane extensibility.
For SR-MPLS, PPR-ID is mapped to an MPLS Label/SID and for SRv6, this
is mapped to an IPv6-SID. For native IP data planes, this is mapped
to either IPv4 or IPv6 address/prefix.
2.2. PPR Path Description
The path identified by the PPR-ID is described as a set of Path The path identified by the PPR-ID is described as a set of Path
Description Elements (PDEs), each of which represents a segment of Description Elements (PDEs), each of which represents a segment of
the path. Each node determines its location in the path as the path. Each node determines its location in the path as
described, and forwards to the next segment/hop or label of the path described, and forwards to the next segment/hop or label of the path
description (see the Forwarding Procedure Example later in this description (see the Forwarding Procedure Example later in this
document). document).
These PPR-PDEs as defined in Section 3.3, like SR SIDs, can represent These PPR-PDEs as defined in Section 3.3, like SR SIDs, can represent
topological elements like links/nodes, backup nodes, as well as non- topological elements like links/nodes, backup nodes, as well as non-
topological elements such as a service, function, or context on a topological elements such as a service, function, or context on a
particular node. PPR-PDE optionally, can also have more information particular node.
as described with in their Sub-TLVs.
A PPR path can be described as a Strict-PPR or a Loose-PPR. In a A PPR path can be described as a Strict-PPR or a Loose-PPR. In a
Strict-PPR all nodes/links on the path are described with SR SIDs for Strict-PPR all nodes/links on the path are described with SR SIDs for
SR data planes or IPv4/IPV6 addresses for native IP data planes. In SR data planes or IPv4/IPV6 addresses for native IP data planes. In
a Loose-PPR only some of the nodes/links from source to destination a Loose-PPR only some of the nodes/links from source to destination
are described. More specifics and restrictions around Strict/Loose are described. More specifics and restrictions around Strict/Loose
PPRs are described in respective data planes in Section 5. Each PDE PPRs are described in respective data planes in Section 5. Each PDE
is described as either an MPLS label towards the next hop in MPLS is described as either an MPLS label towards the Next-Hop (NH) in
enabled networks, or as an IP next hop, in the case of either MPLS enabled networks, or as an IP NH, in the case of either
"plain"/"native" IP or SRv6 enabled networks. A PPR path is related "plain"/"native" IP or SRv6 enabled networks. A PPR path is related
to a set of PDEs using the following TLVs. to a set of PDEs using the TLVs as specified in Section 3.
2.3. ECMP Considerations
PPR inherently supports Equal Cost Multi Path (ECMP) for both strict
and loose paths. If a path is described using nodes, would have ECMP
NHs established for PPR-ID along the path. However, one can avoid
ECMP on any segment of the path by pinning the path using link
identifier to the next segment.
2.4. Scalability and PPR Graphs
In a network of N nodes O(N^2) total (unidirectional) paths are
necessary to establish any-to-any connectivity, and multiple (k) such
path sets may be desirable if multiple path policies are to be
supported (lowest latency, highest throughput etc.).
In many solutions and topologies, N may be small enough and/or only a
small set of paths need to be preferred paths, for example for high
value traffic (DetNet, some of the defined 5G slices), and then the
technology specified in this document can support these deployments.
However, to address the scale needed when a larger number of PPR
paths are required, the PPR TREE structure can be used [I-D.draft-ce-
ppr-graph-00]. Each PPR Tree uses one label/SID and defines paths
from any set of nodes to one destination, thus reduces the number of
entries needed in SRGB at each node (for SR-MPLS data plane
Section 5.1). These paths form a tree rooted in the destination. In
other word, PPR Tree identifiers are destination identifiers and PPR
Treed are path engineered destination routes (like IP routes) and it
scaling simplifies to linear in N i.e., O(k*N).
3. PPR Related TLVs 3. PPR Related TLVs
This section describes the encoding of PPR TLV. This TLV can be seen This section describes the encoding of PPR TLV. This TLV can be seen
as having 4 logical sections viz., encoding of the PPR-Prefix (IS-IS as having 4 logical sections viz, encoding of the PPR-Prefix (IS-IS
Prefix), encoding of PPR-ID, encoding of path description with an Prefix), encoding of PPR-ID, encoding of path description with an
ordered PDE Sub-TLVs and a set of optional PPR attribute Sub-TLVs, ordered PDE Sub-TLVs and a set of optional PPR attribute Sub-TLVs,
which can be used to describe one or more parameters of the path. which can be used to describe one or more parameters of the path.
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 and with corresponding PDE Sub-TLVS. The PPR different PPR-ID Type (data plane) and with corresponding PDE Sub-
TLV has Type TBD (suggested value xxx), and has the following format: TLVS. The PPR TLV has Type TBD (suggested value xxx), and has the
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 2: PPR TLV Format Figure 1: PPR TLV Format
o Type: TBD (IANA) from IS-IS top level TLV registry. o Type: 1555555 (Suggested Value, TBD IANA) from IS-IS top level TLV
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 PPR-Prefix: A variable size sub-TLV representing the destination 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
path, L bit MUST be set and this value MUST be set to 0.
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 | Fragment-ID | |S|D|A|L|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1. S: If set, the PPR TLV MUST be flooded across the entire routing 1. S: If set, the PPR TLV MUST be flooded across the entire routing
domain. If the S flag is not set, the PPR TLV MUST NOT be leaked domain. If the S flag is not set, the PPR TLV MUST NOT be leaked
between IS-IS levels. This bit MUST NOT be altered during the between IS-IS levels. This bit MUST NOT be altered during the
TLV leaking TLV leaking
2. D: When the PPR TLV is leaked from IS-IS level-2 to level-1, the 2. D: When the PPR TLV is leaked from IS-IS level-2 to level-1, the
D bit MUST be set. Otherwise, this bit MUST be clear. PPR TLVs D bit MUST be set. Otherwise, this bit MUST be clear. PPR TLVs
with the D bit set MUST NOT be leaked from level-1 to level-2. with the D bit set MUST NOT be leaked from level-1 to level-2.
This is to prevent TLV looping across levels. 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: The originator of the PPR TLV MUST set the A bit in order to
signal that the prefixes and PPR-IDs advertised in the PPR TLV signal that the prefixes and PPR-IDs advertised in the PPR TLV
are directly connected to the originators. If this bit is not are directly connected to the originators. If this bit is not
set, this allows any other node in the network advertise this TLV set, this allows any other node in the network to advertise this
on behalf of the originating node of the PPR-Prefix. If PPR TLV TLV on behalf of the originating node of the PPR-Prefix. If PPR
is leaked to other areas/levels the A-flag MUST be cleared. In TLV is leaked to other areas/levels the A-flag MUST be cleared.
case if the originating node of the prefix must be disambiguated In case if the originating node of the prefix must be
for any reason including, if it is a Multi Homed Prefix (MHP) or disambiguated for any reason including, if it is a Multi Homed
leaked to a different IS-IS level or because [RFC7794] X-Flag is Prefix (MHP) or leaked to a different IS-IS level or because
set, then PPR-Attribute Sub-TLV Source Router ID SHOULD be [RFC7794] X-Flag is set, then PPR-Attribute Sub-TLV Source Router
included. ID SHOULD be included.
4. L: L bit MUST be set if a path has only one fragment or if it is 4. L: L bit MUST be set if a path has only one fragment or if it is
the last Fragment of the path. PPR-ID value for all fragments of the last Fragment of the path. PPR-ID value for all fragments of
the same path MUST be same. 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.
6. Fragment-ID: This is a 7-bit Identifier value (0-127) of the PPR path description for each IS-IS level is computed and given to
fragment. If fragments are not needed to represent the complete one of the nodes for L1 and L2 respectively. Similarly path
path, L bit MUST be set and this value MUST be set to 0. information when crossing the level boundaries MUST be relevant to
the destination level. If there is no path information available for
the destination level PPR TLV MUST NOT be leaked regardless of S and
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
this registry is to be created by IANA, and administered using the as specified in Section 7.1 and Section 7.2.
first come first serve process.
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 | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Mask Length | IS-IS Prefix | | Prefix Length | Mask Length | IS-IS Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IS-IS Prefix (continued, variable) // // IS-IS Prefix (continued, variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-Prefix Sub-TLVs (variable) | | PPR-Prefix Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PPR-Prefix Sub-TLV Format Figure 2: PPR-Prefix Sub-TLV Format
o Type: TBD (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 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 most significant bits MUST be set to 0 on transmit and ignored on
receive. The remaining 12-bit field contains the MT-ID. receive. The remaining 12-bit field contains the MT-ID.
o Prefix Length: The length of the prefix in bytes. For IPv4 it o Prefix Length: The length of the IS-IS Prefix being encoded in
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). Value of this field MUST be 4 octets for IPv4 Flag/N-Flag) in the IS-IS reachability TLVs. Length of this field
Prefix and MUST be 16 octets for IPv6 Prefix. Encoding is similar MUST be as per "Prefix Length". Encoding is same as TLV 135
to TLV 135 [RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] [RFC5305] and TLV 236 [RFC5308] or MT-Capable [RFC5120] IPv4 (TLV
IPv4 (TLV 235) and IPv6 Prefixes (TLV 237) respectively. 235) and IPv6 Prefixes (TLV 237) respectively.
o PPR-Prefix Sub-TLVs - TBD. These have 1 octet type, 1 octet o PPR-Prefix Sub-TLVs have 1 octet type, 1 octet length and value
length and value field is defined per the type field. 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 MUST belong 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| Algo |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// PPR-ID (variable size) // // PPR-ID (variable size) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PPR-ID Sub-TLV Format Figure 3: PPR-ID Sub-TLV Format
o Type: TBD (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 o PPR-ID Flags: 2 Octet field for PPR-ID flags:
* PPR-ID Flags: 2 Octet field for PPR-ID flags:
o
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|A|Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved: For future use; MUST be set to 0 on transmit and
ignored on receive.
1. L: If set, the PPR path is a Loose-PPR. If the this flag is
unset, then the PPR path is a Strict-PPR. A Strict-PPR lists
every single node or adjacency in the path description from
source to the destination.
2. A: If set, all non-PPR path nodes in the IS-IS area/domain
MUST add a FIB entry for the PPR-ID with NH set to the
shortest path NH for the prefix being advertised. The use of
this is TBD. By default this flag MUST be unset.
3. Reserved: For future use; MUST be set to 0 on transmit and
ignored on receive.
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
defined types are as follows:
o 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
defined types are as follows:
A. Type: 1 MPLS SID/Label Type: 1 SR-MPLS SID/Label
B. Type: 2 Native IPv4 Address/Prefix Type: 2 Native IPv4 Address/Prefix
C. Type: 3 Native IPv6 Address/Prefix Type: 3 Native IPv6 Address/Prefix
D. 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. See PPR-ID below for the length of
this field and other considerations. 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 Length: 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 o Algo: 1 octet value represents the SPF algorithm. Algorithm
registry is as defined in registry is as defined in
[I-D.ietf-isis-segment-routing-extensions]. [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 and MPLS and it depends on the PPR-ID Type - for Type 1, this is encoded as
SID/Label. For Type 2 this is a 4 byte IPv4 address. For Type 3 SR-MPLS SID/Label. For Type 2 this is a 4 byte IPv4 address. For
this is a 16 byte IPv6 address. For Type 2 and Type 3 encoding is Type 3 this is a 16 byte IPv6 address. For Type 2 and Type 3
similar to "IS-IS Prefix" as specified in Section 3.1. For Type encoding is similar to "IS-IS Prefix" as specified in Section 3.1.
4, it is a 16 byte IPv6 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, if the PPR-ID Len is set to non-zero
value, then the PPR-ID MUST NOT be advertised as a routable prefix in value, then the PPR-ID MUST NOT be advertised as a routable prefix in
TLV 135, TLV 235, TLV 236 and TLV 237. Also PPR-ID MUST belong to TLV 135, TLV 235, TLV 236 and TLV 237. Also PPR-ID MUST belong to
the node where Prefix is advertised from. PPR-ID Len = 0 case is a the node where Prefix is advertised from. PPR-ID Len = 0 case is a
special case and is discussed in Section 4.1. 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-
skipping to change at page 13, line 20 skipping to change at page 10, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | PPR-PDE Type | Reserved | | Type | Length | PPR-PDE Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDE-ID Type | PDE-ID Len | PPR-PDE Flags | | PDE-ID Type | PDE-ID Len | PPR-PDE Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// PDE-ID Value (continued, variable size) // // PDE-ID Value (continued, variable size) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-PDE Sub-TLVs (variable) | | PPR-PDE Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PPR-PDE Sub-TLV Format Figure 4: PPR-PDE Sub-TLV Format
o Type: TBD (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:
a. Type: 1 Topological Type: 1 Topological
b. 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 (TBD IANA) for this Sub-TLV and the defined types and registry (Suggested Values as listed, IANA TBD) for this Sub-TLV
corresponding PDE-ID Len, PDE-ID Value are as follows: and the defined types and corresponding PDE-ID Len, PDE-ID Value
are as follows:
a. Type 1: SID/Label type as defined in Type 0: This value MUST be set only when PPR-PDE Type is Non-
[I-D.ietf-isis-segment-routing-extensions]. PDE-ID Len and PDE- Topological. PDE-ID Len specified in bytes and encoded in NBO
ID Value fields are per Section 2.3 of the referenced document. in PDE-ID Value field which can represent a service/function.
This information is provisioned on the immediate topological PDE
preceding to this PDE based on the 'E' bit.
b. Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are same Type 1: SID/Label type as defined in
as Type 1. [I-D.ietf-isis-segment-routing-extensions]. PDE-ID Len and PDE-
ID Value fields are per Section 2.3 of the referenced document.
c. Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are Type 2: SR-MPLS Prefix SID. PDE-ID Len and PDE-ID Value are
same as Type 1. same as Type 1.
d. Type 4: IPv4 Address. PDE-ID Len is 4 bytes and PDE-ID Value is Type 3: SR-MPLS Adjacency SID. PDE-ID Len and PDE-ID Value are
4 bytes IPv4 address encoded similar to IPv4 Prefix described in same as Type 1.
Section 3.1.
e. Type 5: IPv6 Address. PDE-ID Len is 16 bytes and PDE-ID Value is Type 4: IPv4 Node Address. PDE-ID Len is 4 bytes and PDE-ID
16 bytes IPv6 address encoded similar to IPv6 Prefix described in Value is 4 bytes IPv4 address encoded similar to IPv4 Prefix
Section 3.1. described in Section 3.1.
f. Type 6: SRv6 Node SID as defined in Type 5: IPv4 P2P interface Address. PDE-ID Len is 4 bytes and
[I-D.bashandy-isis-srv6-extensions]. PDE-ID Len and PDE-ID Value PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4
are as defined in SRv6 SID from the refrenced draft. Prefix described in Section 3.1.
g. Type 7: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Values are Type 6: IPv4 LAN interface Address. PDE-ID Len is 4 bytes and
similar to SRv6 Node SID above. PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4
Prefix described in Section 3.1. This type MUST have IS-IS
System-ID Sub-TLV in the PDE.
Type 7: IPv6 Node Address. PDE-ID Len is 16 bytes and PDE-ID
Value is 16 bytes IPv6 address encoded similar to IPv6 Prefix
described in Section 3.1.
Type 8: IPv6 P2P interface Address. PDE-ID Len is 16 bytes and
PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6
Prefix described in Section 3.1.
Type 9: IPv6 LAN interface Address. PDE-ID Len is 16 bytes and
PDE-ID Value is 16 bytes IPv6 address encoded similar to IPv6
Prefix described in Section 3.1. This type MUST have IS-IS
System-ID Sub-TLV in the PDE.
Type 10: SRv6 Node SID as defined in
[I-D.bashandy-isis-srv6-extensions]. PDE-ID Len and PDE-ID
Value are as defined in SRv6 SID from the referenced draft.
Type 11: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Values are
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|Reserved | |L|D|E|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1. 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 and overrides the L bit in Section 3.2. If the path description. If set, the next Topological PDE is
set, the next PDE is Loose. If this flag is unset, the next Loose. If this flag is unset, the next Topological PDE is
Topological PDE is Strict Type. Strict Type.
2. D: Destination bit. By default this bit MUST be unset. This bit D: Destination Bit. By default this bit MUST be unset. This bit
MUST be set only for PPR-PDE Type is 1 i.e., Topological and this MUST be set only for PPR-PDE Type is 1 i.e., Topological and
PDE represents the node PPR-Prefix Section 3.1 belongs to, if this PDE represents the node PPR-Prefix Section 3.1 belongs to,
there is no sub-sub-TLV to override PPR-Prefix and PPR-ID values. if there is no further PDE specific Sub-TLVs to override PPR-
Prefix and PPR-ID values.
3. Reserved: 1 Octet reserved bits for future use. Reserved bits E: Egress Bit. By default this bit MUST be unset. This bit MUST
MUST be reset on transmission and ignored on receive. 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
topological PDE preceding this PDE.
o PPR-PDE Sub-TLVs: TBD. These have 1 octet type, 1 octet length Reserved: Reserved bits for future use. Reserved bits MUST be
and value field is defined per the type field. reset on transmission and ignored on receive.
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
in Section 7 and the length field represents the length of the
value field in bytes.
PPR-PDE Sub-TLV: Type 4 (IANA TBD), Length Total length of value
field in bytes, Value: IS-IS System-ID of length "ID Length" as
defined in [ISO.10589.1992]. This Sub-TLV MUST NOT be present,
if the PPR-PDE Type is not equal to 1 i.e, Topological PDE.
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. The
following sub-TLVs draw from a new registry for sub-TLV numbers; this following Sub-TLVs draw from a new registry for Sub-TLV numbers; this
registry is to be created by IANA, and administered using the first registry is to be created by IANA, and administered using the first
come first serve process: come first serve process:
o Type 1 (Suggested Value - IANA TBD): Packet Traffic accounting o Type 1 (Suggested Value - IANA TBD): PPR-Prefix originating node's
Sub-TLV. Length 0 and no value field. Specifies to create a
counter to count number of packets forwarded on this PPR-ID on
each node in the path description.
o Type 2 (Suggested Value - IANA TBD): Traffic statistics in Bytes
Sub-TLV. Length 0 and no value field. Specifies to create a
counter to count number of bytes forwarded on this PPR-ID
specified in the network header (e.g. IPv4, IPv6) on each node in
the path description.
o Type 3 (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 4 (Suggested Value - IANA TBD): PPR-Prefix originating node's o Type 2 (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 5 (Suggested Value - IANA TBD): PPR-Metric Sub-TLV. Length 4 o Type 3 (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 (TBD more, on receiving node MUST consider the lowest metric value.
what happens when metric is same for two different set of PPR-PDE
Sub-TLVs).
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
defined in Section 3: defined in Section 3:
1 1
_______ _______
skipping to change at page 16, line 24 skipping to change at page 14, line 24
R1------R6 R7-----------R4 R1------R6 R7-----------R4
\ 2 \__R14__/ 2 /\ \ 2 \__R14__/ 2 /\
\ 2 2 / \ \ 2 2 / \
3 \ / 3 \1 3 \ / 3 \1
\ 4 / \ \ 4 / \
+----R8------R9-----R10------R12 +----R8------R9-----R10------R12
\ 1 / \ 1 /
1 \ / 1 1 \ / 1
+----R11---+ +----R11---+
Figure 6: IS-IS Network Figure 5: IS-IS Network
In the (Figure 6) shown, consider node R1 as an ingress node, or a In the (Figure 5), consider node R1 as an ingress node, or a head-end
head-end node, and the node R4 MAY be an egress node or another head- node, and the node R4 may be an egress node or another head-end node.
end node. The numbers shown on links between nodes R1-R14 indicate The numbers shown on links between nodes indicate the bi-directional
the bi-directional IS-IS metric as provisioned. R1 may be configured IS-IS metric as provisioned. R1 may be configured to receive TE
to receive TE source routed path information from a central entity source routed path information from a central entity (PCE [RFC5440],
(PCE [RFC5440], Netconf [RFC6241] or a Controller) that comprises of Netconf [RFC6241] or a Controller) that comprises of PPR information
PPR information which relates to sources that are attached to R1. It which relates to sources that are attached to R1. It is also
is also possible to have a PPR provisioned locally by the operator possible to have a PPR provisioned locally by the operator for non-TE
for non-TE needs (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-PDE represented with a PPR-ID (Section 3.2). The PPR TLV includes PPR-
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
requirements may include bandwidth, jitter, latency, throughput, requirements may include bandwidth, jitter, latency, throughput,
error rate, etc. error rate, etc.
o A first PPR may be identified by PPR-ID = 1 (value) and may o A first PPR may be identified by PPR-ID = 1 (value) and may
include the path of R1-R6-R7-R4 for a Prefix advertised by R4. include the path of R1-R6-R7-R4 for a Prefix advertised by R4.
This is an example for a Loose-PPR and 'L' bit MUST be set on This is an example for a Loose-PPR and 'L' bit MUST be set
Section 3.2. appropriately at Section 3.3.
o A second PPR may be identified by PPR-ID = 2 (value) and may o A second PPR may be identified by PPR-ID = 2 (value) and may
include the path of R1-R8-R9-R10-R4. This is an example for a include the path of R1-R8-R9-R10-R4. This is an example for a
Strict-PPR and 'L' bit MUST be unset on Section 3.2. Though this Strict-PPR and 'L' bit MUST be unset appropriately at Section 3.3.
example shows PPR with all nodal SIDs, it is possible to have a Though this example shows PPR with all nodal SIDs, it is possible
PPR with combination of node and adjacency SIDs (local or global) to have a PPR with combination of node and adjacency SIDs (local
or with PPR-PDE Type set to Non-Topological as defined in or global) or with PPR-PDE Type set to Non-Topological as defined
Section 3.3 elements along with these. in Section 3.3 elements along with these.
4.1. PPR TLV Processing 4.1. PPR TLV Processing
The first topological sub-object or PDE (Section 3.3) relative to the The first topological sub-object or PDE (Section 3.3) relative to the
beginning of PPR Path contains the information about the first node beginning of PPR Path contains the information about the first node
(e.g. in SR-MPLS it's the topmost label). The last topological sub- (e.g. in SR-MPLS it's the topmost label). The last topological sub-
object or PDE contains information about the last node (e.g. in SR- object or PDE contains information about the last node (e.g. in SR-
MPLS it's the bottommost label). MPLS it's the bottommost label).
Each receiving node, determines whether an advertised PPR includes Each receiving node, determines whether an advertised PPR includes
information regarding the receiving node. Before processing any information regarding the receiving node. Before processing any
further, validation MUST be done to see if any PPR topological PDE is further, validation MUST be done to see if any PPR topological PDE is
seen more than once (possible loop), if yes, this PPR TLV MUST be seen more than once (possible loop), if yes, this PPR TLV MUST be
ignored. Processing of PPR TLVs can be done, during the end of the ignored. Processing of PPR TLVs may be done, during the end of the
SPF computation (for MTID that is advertised in this TLV) and for the SPF computation (for MTID that is advertised in this TLV) and for
each prefix described through PPR TLV. For example, node R9 receives each prefix described through PPR TLV. For example, node R9 receives
the PPR information, and ignores the PPR-ID=1 (Section 4) because the PPR information, and ignores the PPR-ID=1 (Section 4) because
this PPR TLV does not include node R9 in the path description/ordered this PPR TLV does not include node R9 in the path description/ordered
PPR-PDE list. PPR-PDE list.
However, node R9 may determine that the second PPR identified by PPR- However, node R9 may determine that the second PPR identified by PPR-
ID = 2 does include the node R9 in its PDE list. Therefore, node R9 ID = 2 does include the node R9 in its PDE list. Therefore, node R9
updates the local forwarding database to include an entry for the updates the local forwarding database to include an entry for the
destination address of R4 indicates, that when a data packet destination address that R4 indicates, so that when a data packet
comprising a PPR-ID of 2 is received, forward the data packet to node comprising a PPR-ID of 2 is received, forward the data packet to node
R10 instead of R11. This is even though from R9 the shortest path to R10 instead of R11. This is done, even though from R9 the shortest
reach R4 via R11 (Cost 3: R9-R11-R12-R4) it chooses the nexthop to path to reach R4 via R11 (Cost 3: R9-R11-R12-R4) it chooses the NH to
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
shortest path nexthop computed towards PPR Prefix to the shortest PPR-ID's shortest path NH towards the next topological PDE in the
path nexthop 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 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 0, then Prefix would also become the PPR-ID (a special case). This
can be used for some situations, where certain optimizations are can be used for some situations, where certain optimizations are
required in the network. For this, path described in the PPR TLV required in the network. For this, path described in the PPR TLV
SHOULD be completely dis-joint from the shortest path route to the SHOULD be completely disjoint from the shortest path route to the
prefix. If the disjoint-ness property is not maintained then 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 traffic may not be using the PPR path, as and when it encounters any
node which is not in the path description. 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 to (where N>1). In this case Fragment (N-1) MUST set the L bit (PPR-
indicate it is the last fragment. If Fragment-ID is non zero in the Flags) to indicate it is the last fragment. If Fragment-ID is non
TLV, then it MUST not carry PPR-Prefix Sub-TLV. The optional PPR zero in the TLV, then it MUST not carry PPR-Prefix Sub-TLV. The
Attribute Sub-TLVs which describe the path overall MUST be included optional PPR Attribute Sub-TLVs which describe the path overall MUST
in the last fragment only (i.e., when the L bit is set). be included in the last fragment only (i.e., when the L 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. Other data planes other than described below which selects the PPR.
can also use this TLV to describe the PPR. Further details TBD.
5.1. SR-MPLS with PPR 5.1. SR-MPLS with PPR
If PPR-ID Type is 1, then the PPR belongs to SR-MPLS data plane and If PPR-ID Type is 1, then the PPR belongs to SR-MPLS data plane and
the complete PPR stack is represented with a unique SR SID/Label and the complete PPR stack is represented with a unique SR SID/Label and
this gets programmed on the data plane of each node, with the this gets programmed on the data plane of each node, with the
appropriate nexthop computed as specified in Section 4. PPR-ID here appropriate NH computed as specified in Section 4. PPR-ID here is a
is a label/index from the SRGB (like another node SID or global ADJ- label/index from the SRGB (like another node SID or global ADJ-SID).
SID). PPR path description here is a set of ordered SIDs represented PPR path description here is a set of ordered SIDs represented with
with PPR-PDE (Section 3.2) Sub-TLVs. Non-Topological segments also PPR-PDE (Section 3.2) Sub-TLVs. Non-Topological segments also
programmed in the forwarding to enable specific function/service, programmed in the forwarding to enable specific function/service,
when the data packet hits with corresponding PPR-ID. when the data packet hits with corresponding PPR-ID.
Based on 'L' flag in PPR-ID Flags (Section 3.2), for SR-MPLS data Based on 'L' flag in PPR-ID Flags (Section 3.2), for SR-MPLS data
plane either 1 label or 2 labels need to be provisioned on individual plane either 1 label or 2 labels need to be provisioned on individual
nodes on the path description. For the example network in Section 4, nodes on the path description. For the example network in Section 4,
for PPR-ID=1, which is a loose path, node R6 programs the bottom for PPR-ID=1, which is a loose path, node R6 programs the bottom
label as PPR-ID and the top label as the next topological PPR-PDE in label as PPR-ID and the top label as the next topological PPR-PDE in
the path, which is a node SID of R7. The NH computed at R6 would be the path, which is a node SID of R7. The NH computed at R6 would be
the shortest path towards R7 i.e., the interface towards R13. If 'L' the shortest path towards R7 i.e., the interface towards R13. If 'L'
flag is unset only PPR-ID is programmed on the data plane with NH set flag is unset only PPR-ID is programmed on the data plane with NH set
to the shortest path towards next topological PPR-PDE. to the shortest path towards next topological PPR-PDE.
5.2. SRv6 with PPR 5.2. PPR Native IP Data Planes
If PPR-ID Type is 4, the PPR belongs to SRv6 with SRH data plane and
the complete PPR stack is represented with IPv6 SIDs and this gets
programmed on the data plane with the appropriate nexthop computed as
specified in Section 4. PPR-ID here is a SRv6 SID. PPR path
description here is a set of ordered SID TLVs similar to as specified
in Section 5.1. One way PPR-ID would be used in this case is by
setting the same as the destination IPv6 address and SL field in SRH
would be set to 0; however SRH [I-D.ietf-6man-segment-routing-header]
can contain any other TLVs and non-topological SIDs as needed.
5.3. PPR Native IP Data Planes
If PPR-ID Type is 2 then source routing and packet steering can be If PPR-ID Type is 2 then source routing and packet steering can be
done in IPv4 data plane (PPR-IPv4), along the path as described in done in IPv4 data plane (PPR-IPv4), along the path as described in
PPR Path description. This is achieved by setting the destination IP PPR Path description. This is achieved by setting the destination IP
address as PPR-ID, which is an IPv4 address in the data packet address as PPR-ID, which is an IPv4 address in the data packet
(tunneled/encapsulated). There is no data plane change or upgrade (tunneled/encapsulated). There is no data plane change or upgrade
needed to support this. However this is applicable to only Strict- needed to support this.
PPR paths ('L' bit as specified in Section 3.2 MUST be unset).
Similarly for PPR-ID Type is 3, then source routing and packet Similarly for PPR-ID Type is 3, then source routing and packet
steering can be done in IPv6 data plane (PPR-IPv6), along the path as steering can be done in IPv6 data plane (PPR-IPv6), along the path as
described in PPR Path description. Whatever specified above for IPv4 described in PPR Path description. Whatever specified above for IPv4
applies here too, except that destination IP address of the data applies here too, except that destination IP address of the data
packet is IPv6 Address (PPR-ID). This doesn't require any IPv6 packet is an IPv6 Address (PPR-ID). This doesn't require any IPv6
extension headers (EH), if there is no metadata/TLVs need to be extension headers (EH), if there is no metadata/TLVs need to be
carried in the data packet. carried in the data packet.
6. PPR Scaling Considerations Based on 'L' flag in PPR-ID Flags (Section 3.2), for PPR-ID Type 2 or
3 (Native IPv4 or IPv6 data planes respectively) the packet has to be
In a network of N nodes O(N^2) total (unidirectional) paths are encapsulated using the capabilities (either dynamically signaled
necessary to establish any-to-any connectivity, and multiple (k) such through [I-D.ietf-isis-encapsulation-cap] or statically provisioned
path sets may be desirable if multiple path policies are to be on the nodes) of the next loose PDE in the path description.
supported (lowest latency, highest throughput etc.).
In many solutions and topologies, N may be small enough and/or only a
small set of paths need to be preferred paths, for example for high
value traffic (DetNet, some of the defined 5G slices), and then the
technology specified in this document can support these deployments.
However, to address the scale needed when a larger number of PPR
paths are required, the PPR TREE structure can be used [I-D.draft-ce-
ppr-graph-00]. Each PPR Tree uses one label/SID and defines paths
from any set of nodes to one destination, thus reduces the number of
entries needed in SRGB at each node (for SR-MPLS data plane
Section 5.1). These paths form a tree rooted in the destination. In
other word, PPR Tree identifiers are destination identifiers and PPR
Treed are path engineered destination routes (like IP routes) and it
scaling simplifies to linear in N i.e., O(k*N).
7. PPR Traffic Accounting
Section 3.4 defines few PPR-Attributes to indicate creation of For the example network in Section 4, for PPR-ID=1, which is a loose
traffic accounting statistics in each node of the PPR path path, node R6 programs to encapsulate the data packet towards the
description. Presence of "Packet Traffic Accounting" and "Traffic next loose topological PPR-PDE in the path, which is R7. The NH
Statistics" Sub-TLVs instruct to provision the hardware, to account computed at R6 would be the shortest path towards R7 i.e., the
for the respective traffic statistics. Traffic accounting should interface towards R13. If 'L' flag is unset only PPR-ID is
happen, when the actual data traffic hits for the PPR-ID in the programmed on the data plane with NH set to the shortest path towards
forwarding plane. This allows more granular and dynamic enablement next topological PPR-PDE, with no further encapsulation of the data
of traffic statistics for only certain PPRs as needed. packet.
This approach, thus is more safe and secure than any mechanism that 5.3. SRv6 with PPR
involves creation of the state in the nodes with the data traffic
itself. This is because, creation and deletion of the traffic
accounting state for PPRs happen through IS-IS LSP processing and IS-
IS protocol control plane security Section 10 options are applicable
to this TLV.
How the traffic accounting is distributed to a central entity is out If PPR-ID Type is 4, the PPR belongs to SRv6 with SRH data plane and
of scope of this document. One can use any method (e.g. gRPC) to the complete PPR stack is represented with IPv6 SIDs and this gets
extract the PPR-ID traffic stats from various nodes along the path. programmed on the data plane with the appropriate NH computed as
specified in Section 4. PPR-ID here is a SRv6 SID. PPR path
description here is a set of ordered SID TLVs similar to as specified
in Section 5.1. One way PPR-ID would be used in this case is by
setting it as the destination IPv6 address and SL field in SRH would
be set to 0; however SRH [I-D.ietf-6man-segment-routing-header] can
contain any other TLVs and non-topological SIDs as needed.
8. Acknowledgements 6. Acknowledgements
Thanks to Alex Clemm, Lin Han, Toerless Eckert, Stewart Bryant and Thanks to Alex Clemm, Lin Han, Toerless Eckert, Asit Chakraborti,
Kiran Makhijani for initial discussions on this topic. Thanks to Stewart Bryant and Kiran Makhijani for initial discussions on this
Kevin Smith and Stephen Johnson for various deployment scenarios topic. Thanks to Kevin Smith and Stephen Johnson for various
applicability from ETSI WGs perspective. Authors also acknowledge deployment scenarios applicability from ETSI WGs perspective.
Alexander Vainshtein for detailed discussions and few suggestions on Authors also acknowledge Alexander Vainshtein for detailed
this topic. discussions and few suggestions on this topic.
Earlier versions of draft-ietf-isis-segment-routing-extensions have a Earlier versions of draft-ietf-isis-segment-routing-extensions have a
mechanism to advertise EROs through Binding SID. mechanism to advertise EROs through Binding SID.
9. IANA Considerations 7. IANA Considerations
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
----- -------------- ----- --------------
TBD PPR TLV 155 PPR TLV (Suggested Value, IANA TBD)
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):
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)
This document also requests IANA to create a new Sub-TLV registry for 4 IS-IS System-ID (Section 3.3)
PPR Path attributes with the following initial entries (suggested
values):
Sub-TLV # Sub-TLV Name
--------- ---------------------------------------------------------
1 Packet Traffic Accounting (Section 3.4)
2 Traffic Statistics (Section 3.4)
3 PPR-Prefix Source IPv4 Router ID (Section 3.4)
4 PPR-Prefix Source IPv6 Router ID (Section 3.4)
5 PPR-Metric (Section 3.4) 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.
o "PPR-Flags" - 1 Octet. Bits as described in Section 3 of this o "PPR-Flags" - 1 Octet. Bits as described in Section 3 of this
skipping to change at page 22, line 23 skipping to change at page 19, line 23
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.
10. Security Considerations 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
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 as this extension is security concerns in IS-IS protocol. However, for extensions related
related to SR-MPLS and SRH data planes as defined in ro SR-MPLS and SRH data planes, those particular data plane security
[I-D.ietf-spring-segment-routing], those particular data plane considerations does apply here.
security considerations does apply here.
11. References
11.1. Normative References
[I-D.ietf-isis-segment-routing-msd] 9. References
Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 9.1. Normative References
"Signaling MSD (Maximum SID Depth) using IS-IS", draft-
ietf-isis-segment-routing-msd-19 (work in progress),
October 2018.
[I-D.ietf-spring-segment-routing] [ISO.10589.1992]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., International Organization for Standardization,
Litkowski, S., and R. Shakir, "Segment Routing "Intermediate system to intermediate system intra-domain-
Architecture", draft-ietf-spring-segment-routing-15 (work routing routine information exchange protocol for use in
in progress), January 2018. conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)",
ISO Standard 10589, 1992.
[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>.
11.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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-04 (work Dataplane", draft-bashandy-isis-srv6-extensions-05 (work
in progress), October 2018. in progress), March 2019.
[I-D.cheng-spring-mpls-path-segment]
Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler,
R., and S. Zhan, "Path Segment in MPLS Based Segment
Routing Network", draft-cheng-spring-mpls-path-segment-03
(work in progress), October 2018.
[I-D.hegde-spring-traffic-accounting-for-sr-paths]
Hegde, S., "Traffic Accounting for MPLS Segment Routing
Paths", draft-hegde-spring-traffic-accounting-for-sr-
paths-02 (work in progress), October 2018.
[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., Previdi, S., Leddy, J., Matsushima, S., and
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-16 (work in (SRH)", draft-ietf-6man-segment-routing-header-18 (work in
progress), February 2019. progress), April 2019.
[I-D.ietf-isis-encapsulation-cap]
Xu, X., Decraene, B., Raszuk, R., Chunduri, U., Contreras,
L., and L. Jalil, "Advertising Tunnelling Capability in
IS-IS", draft-ietf-isis-encapsulation-cap-01 (work in
progress), April 2017.
[I-D.ietf-isis-mpls-elc] [I-D.ietf-isis-mpls-elc]
Xu, X., Kini, S., Sivabalan, S., 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-06 (work in progress), September 2018. 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-22 (work in progress), December 2018. extensions-24 (work in progress), April 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-05 (work in progress), February 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
Service Chaining", draft-xuclad-spring-sr-service- Service Chaining", draft-xuclad-spring-sr-service-
chaining-01 (work in progress), March 2018. chaining-01 (work in progress), March 2018.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
skipping to change at page 25, line 20 skipping to change at page 22, line 30
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
March 2016, <https://www.rfc-editor.org/info/rfc7794>. March 2016, <https://www.rfc-editor.org/info/rfc7794>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Decraene, B., Litkowski, S., and R. Shakir, "Segment
May 2017, <https://www.rfc-editor.org/info/rfc8174>. Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>.
Appendix A. Appendix
A.1. Challenges with Increased SID Depth
SR label stacks carried in the packet header create challenges in the
design and deployment of networks and networking equipment.
Following examples illustrates the need for increased SID depth in
various use cases:
(a). Consider the following network where SR-MPLS data plane is in
use and with same SRGB (5000-6000) on all nodes i.e., A1 to A11 and
B1 to B7 for illustration:
SID:10 SID:20 SID:30 SID:40 SID:50 SID:300(Ax) SID:60 SID:70
A1--------A2-------A3-------A4-------A5===============A6-- ----------A7
| \ / \5 5/ \ SID:310(Ay) \ /
| 5 \ 10 10/ +-A10-+ \ \10 10/
| \ SID:80 / |SID:100 \ \ /
A11 SID:111 \A8-----A9/ | \ 40 \ /
| / SID:90 \ +-----+ +---+ \ /
| 5 /10 \10 5 \ \ \ /
| /SID:125(B2x) \ \ \ \/
B1-------B2==============B3----B4------B5-------=B6----------B7
SID:127(B2y)
SID:110 SID:120 SID:130 SID:140 SID:150 SID:160 SID:170
=== = Path with Parallel Adjacencies and ADJ-SIDs
--- = Shortest Path Nodal SID
Figure 6: SR-MPLS Network
Global ADJ-SIDs are provisioned between A5-A6 and B2-B3 (with
parallel adjecencies). All other SIDs shown are nodal SID
indices.
All metrics of the links are set to 1, unless marked otherwise.
Shortest Path from A1 to A7: A2-A3-A4-A5-A6-A7
Path-x: From A1 to A7 - A2-A8-B2-B2x-A9-A10-Ax-A7; Pushed Label
Stack @A1: 5020:5080:5120:5125:5090:5100:5300:5070 (where B2x is a
local ADJ-SID and Ax is a global ADJ-SID).
In this example, the traffic engineered path is represented with a
combination of Adjacency and Node SIDs with a stack of 8 labels.
However, this value can be larger, if the use of entropy label
[RFC6790] is desired and based on the Readable Label Depth
(Appendix A.2) capabilities of each node and additional labels
required to insert ELI/EL at appropriate places.
Though above network is shown with SR-MPLS data plane, if the
network were to use SRv6 data plane, path size would be increased
even more because of the size of the IPv6 SID (16 bytes) in SRH.
(b). Apart from the TE case above, when deploying
[I-D.ietf-mpls-sfc] or [I-D.xuclad-spring-sr-service-chaining], with
the inclusion of services, or non-topological segments on the label
stack, can also make the size of the stack much larger.
Overall the additional path overhead in various SR deployments may
cause the following issues:
a. HW Capabilities: Not all nodes in the path can support the
ability to push or read label stack (with additional non-
topological and special labels) needed to satisfy user/operator
requirements. Alternate paths, which meet these user/operator
requirements may not be available.
b. Line Rate: Potential performance issues in deployments, which use
data plane with extension header as both size of the SIDs in the
extension header and the fixed extension header size itself needs
to be factored by the hardware.
c. MTU: Larger SID stacks on the data packet can cause potential
MTU/fragmentation issues (SRH).
d. Header Tax: Some deployments, such as 5G, require minimal packet
overhead in order to conserve network resources. Carrying 40 or
50 octets of data in a packet with hundreds of octet of header
would be an unacceptable use of available bandwidth.
With the solution proposed in this document (Section 2), for Path-x
in Figure 6 above, SID stack would be reduced from 8 SIDs to a single
SID witout any additional overhead.
A.2. Mitigation with MSD
The number of SIDs in the stack a node can impose is referred as
Maximum SID Depth (MSD) capability [RFC8491], which must be taken
into consideration when computing a path to transport a data packet
in a network implementing segment routing. [I-D.ietf-isis-mpls-elc]
defines another MSD type, Readable Label Depth (RLD) that is used by
a head-end to insert Entropy Label pair (ELI/EL) at appropriate
depth, so it could be read by transit nodes. There are situations
where the source routed path can be excessive as path represented by
SR SIDs need to describe all the nodes and ELI/EL based on the
readability of the nodes in that path. Registries setforth in
[RFC8491] applicable for MPLS data plane and for IPv6 data plane with
SRH.
MSDs (and RLD type) capabilities advertisement help mitigate the
problem for a central entity to create the right source routed path
per application/operator requirements. However the availability of
actual paths meeting these requirements are still limited by the
underlying hardware and their MSD capabilities in the data path.
Authors' Addresses Authors' Addresses
Uma Chunduri Uma Chunduri
Huawei USA Huawei USA
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: uma.chunduri@huawei.com Email: uma.chunduri@huawei.com
 End of changes. 107 change blocks. 
464 lines changed or deleted 473 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/