< draft-chunduri-lsr-ospf-preferred-path-routing-02.txt   draft-chunduri-lsr-ospf-preferred-path-routing-03.txt >
LSR Working Group U. Chunduri LSR Working Group U. Chunduri
Internet-Draft Y. Qu Internet-Draft Y. Qu
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
February 14, 2019 May 16, 2019
Preferred Path Routing (PPR) in OSPF Preferred Path Routing (PPR) in OSPF
draft-chunduri-lsr-ospf-preferred-path-routing-02 draft-chunduri-lsr-ospf-preferred-path-routing-03
Abstract Abstract
This document specifies a Preferred Path Routing (PPR), a routing This document specifies a Preferred Path Routing (PPR), a routing
protocol mechanism to simplify the path description of data plane protocol mechanism to simplify the path description of data plane
traffic in Segment Routing (SR) deployments with OSPFv2 and OSPFv3 traffic in Segment Routing (SR) deployments with OSPFv2 and OSPFv3
protocols. PPR aims to mitigate the MTU and data plane processing protocols. PPR aims to mitigate the MTU and data plane processing
issues that may result from SR packet overheads; and also supports issues that may result from SR packet overheads; and also supports
traffic measurement, accounting statistics and further attribute further extensions along the paths. Preferred path routing is
extensions along the paths. Preferred Path Routing is achieved achieved through the addition of path descriptions to the OSPF
through the addition of descriptions to OSPF advertised prefixes, and advertised prefixes, and mapping those to a PPR data-plane
mapping those to a PPR data-plane identifier. 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 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2019. This Internet-Draft will expire on November 17, 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OSPFv2 PPR TLV . . . . . . . . . . . . . . . . . . . . . . . 4 2. OSPFv2 PPR TLV . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. PPR-Flags . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. PPR-Flags . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . . . 6 2.2. PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . . . . 6
2.3. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 7 2.3. PPR-ID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 7
2.4. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9 2.4. PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9
2.5. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . . . 10 2.5. PPR-Attributes Sub-TLV . . . . . . . . . . . . . . . . . 11
3. OSPFv3 PPR TLV . . . . . . . . . . . . . . . . . . . . . . . 11 3. OSPFv3 PPR TLV . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. OSPFv3 PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . 13 3.1. OSPFv3 PPR-Prefix Sub-TLV . . . . . . . . . . . . . . . . 13
3.2. OSPFv3 PPR-ID Sub-TLVs . . . . . . . . . . . . . . . . . 13 3.2. OSPFv3 PPR-ID Sub-TLVs . . . . . . . . . . . . . . . . . 14
3.3. OSPFv3 PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . 15 3.3. OSPFv3 PPR-PDE Sub-TLV . . . . . . . . . . . . . . . . . 16
3.4. OSPFv3 PPR-Attributes Sub-TLV . . . . . . . . . . . . . . 17 3.4. OSPFv3 PPR-Attributes Sub-TLV . . . . . . . . . . . . . . 19
4. Other Considerations . . . . . . . . . . . . . . . . . . . . 18 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 19
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 [I-D.ietf-spring-segment-routing]. SR capabilities are defined for
MPLS and IPv6 data planes called SR-MPLS and SRv6 respectively. MPLS and IPv6 data planes called SR-MPLS and SRv6 respectively.
In SR-MPLS, a segment is encoded as a label and an ordered list of In SR-MPLS, a segment is encoded as a label and an ordered list of
segments is encoded as a stack of labels on the data packet. In segments is encoded as a stack of labels on the data packet. In
SRv6, a segment is encoded as an IPv6 address, with in a new type of SRv6, a segment is encoded as an IPv6 address, with in a new type of
IPv6 hop-by-hop routing header/extension header (EH) called SRH IPv6 hop-by-hop routing header/extension header (EH) called SRH
[I-D.ietf-6man-segment-routing-header], where an ordered list of IPv6 [I-D.ietf-6man-segment-routing-header], where an ordered list of IPv6
addresses/segments is encoded in SRH. addresses/segments is encoded in SRH.
The issues caused by the large SID depth, and existing methods for Preferred path routing cab be described as a) enabling route
mitigation are introduced in computation based on the specific path described along with the
[I-D.chunduri-lsr-isis-preferred-path-routing] section 1.2 and 1.3. prefix as opposed to shortest path towards the prefix and b)
To mitigate these issues , and also to facilitate forwarding plane a forwarding based on the abstracted path identifier as opposed to the
mechanism to identify the path with a corresponding data plane individual segments on the packet. This also further described in
identifier for accounting of traffic for SR paths, this draft Section 2 of [I-D.chunduri-lsr-isis-preferred-path-routing].
proposes a new OSPFv2 PPR TLV (Section 2), OSPFv3 PPR TLV (Section 3)
to use the path with a corresponding data plane identifier.
Preferred Path Routing means enabling route computation based on the
specific path described along with the prefix as opposed to shortest
path towards the prefix. This also further described in Section 2 of
[I-D.chunduri-lsr-isis-preferred-path-routing].
Any prefix advertised with a path description from any node in the Any prefix advertised with a path description from any node in the
network is called Preferred Path Route. A PPR could be an SR path, network is called PPR. A PPR could be an SR path, an explicitly
an explicitly provisioned Fast Re-Route (FRR) path or a service provisioned Fast Re-Route (FRR) path or a service chained path. A
chained path. A PPR can be signaled by any node, which receives the PPR can be signaled by any node, which receives the SR path computed
SR path computed by a central controller, or by operator by by a central controller, or by statically configuring the same on a
statically configuring the same on a node in the network. node in the network.
With corresponding data plane, Section 4 mechanism as in [I- The issues caused by the large SID depth, and existing methods for
D.chunduri-isis-preferred-path-routing], reduces the SID stack in the mitigation are introduced in
data plane with a single PPR ID. [I-D.chunduri-lsr-isis-preferred-path-routing] in Appendix A.1 and
A.2. To mitigate these issues and also to facilitate forwarding
plane extensibility, this draft proposes a new OSPFv2 PPR TLV
(Section 2), OSPFv3 PPR TLV (Section 3) to use the path with a
corresponding data plane identifier.
1.1. Acronyms 1.1. Acronyms
EL - Entropy Label EL - Entropy Label
ELI - Entropy Label Indicator ELI - Entropy Label Indicator
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
PPR - Preferred Path Route
NSP - Non Shortest Path
SID - Segment Identifier SID - Segment Identifier
SPF - Shortest Path First SPF - Shortest Path First
SR - Segment Routing SR - Segment Routing
SRH - Segment Routing Header SRH - Segment Routing Header
SR-MPLS - Segment Routing with MPLS data plane SR-MPLS - Segment Routing with MPLS data plane
skipping to change at page 6, line 9 skipping to change at page 6, line 9
o PPR-PDEs - Variable number of ordered PDE Sub-TLVs which o PPR-PDEs - Variable number of ordered PDE Sub-TLVs which
represents the path. This is defined in Section 2.4. represents the path. This is defined in Section 2.4.
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 2.5. represent the path attributes. These are defined in Section 2.5.
2.1. PPR-Flags 2.1. PPR-Flags
Flags: 2 octet field of PPR TLV has following flags defined: Flags: 2 octet field of PPR TLV has following flags defined:
NSPF ID Flags Format PPR TLV Flags Format
0 1 2 3 4 5 6 7 15 0 1 2 3 4 5 6 7 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IA|A | Reserved | |IA|A | Reserved |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
w=Where: w=Where:
IA-Flag: Inter-Area flag. If set, advertisement is of inter-area IA-Flag: Inter-Area flag. If set, advertisement is of inter-area
type. An Area Boarder Router (ABR) that is advertising the OSPF type. An Area Boarder Router (ABR) that is advertising the OSPF
PPR TLV between areas MUST set this bit. PPR TLV between areas MUST set this bit.
skipping to change at page 6, line 35 skipping to change at page 6, line 35
behalf of the originating node of the "OSPF Prefix". If PPR TLV behalf of the originating node of the "OSPF Prefix". If PPR TLV
is propagated to other areas the A-flag MUST be cleared. In case is propagated to other areas the A-flag MUST be cleared. In case
if the originating node of the prefix has to be disambiguated for if the originating node of the prefix has to be disambiguated for
any reason including, if it is a Multi Homed Prefix (MHP) or any reason including, if it is a Multi Homed Prefix (MHP) or
propagated to a different OSPF area, then PPR-Attribute Sub-TLV propagated to a different OSPF area, then PPR-Attribute Sub-TLV
Source Router ID SHOULD be included. Source Router ID SHOULD be included.
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.
PPR path description for each OSPF area is computed and given to one
of the nodes in that area for dissemination. Similarly path
information when crossing the area boundaries MUST be relevant to the
destination area. If there is no path information available for the
destination area, PPR TLV MUST NOT be leaked regardless of the IA bit
status.
2.2. PPR-Prefix Sub-TLV 2.2. PPR-Prefix Sub-TLV
The structure of PPR-Prefix, for which path description is attached The structure of PPR-Prefix, for which path description is attached
to is as follows: to is as follows:
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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | Prefix Length | Mask Length | Reserved | | MT-ID | Prefix Length | Mask Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OSPFv2 Prefix (variable) // // OSPFv2 Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-Prefix Sub-TLVs (variable) | | PPR-Prefix Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PPR-Prefix Sub-TLV Format Figure 2: PPR-Prefix Sub-TLV Format
o Type - TBD (See IANA for suggested value) from OSPFv2 PPR TLV o Type - 1 (suggested value, IANA TBD) from OSPFv2 PPR TLV Section 2
Section 2 Sub-TLV registry. Sub-TLV registry.
o Length - Total length of the value field in bytes (variable). o Length - Total length of the value field in bytes (variable).
o MT-ID - Multi-Topology ID (as defined in [RFC4915]). o MT-ID - Multi-Topology ID (as defined in [RFC4915]).
o Prefix Len - contains the length of the prefix in bits. Only the o Prefix Len - contains the length of the OSPF prefix being encoded
most significant octets of the Prefix are encoded. in 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 OSPFv2 Prefix - represents the OSPFv2 prefix at the tail-end of o OSPFv2 Prefix - represents the OSPFv2 prefix at the tail-end of
the advertised PPR. For the address family IPv4 unicast, the the advertised PPR. For the address family IPv4 unicast, the
prefix itself is encoded as a 32-bit value. The default route is prefix itself is encoded as a 32-bit value. The default route is
represented by a prefix of length 0. represented by a prefix of length 0.
o PPR-Prefix Sub-TLVs - TBD. It has 2 octet type, 2 octet length o PPR-Prefix Sub-TLVs have2 octet type, 2 octet length and value
and value field is defined per type. field is defined per type.
2.3. PPR-ID Sub-TLV 2.3. PPR-ID Sub-TLV
This represents the actual data plane identifier in the packet and This represents the actual data plane identifier in the packet 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
OSPF Prefix and PPR-ID MUST belong to a same node in the network. OSPF Prefix and PPR-ID MUST belong 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 46 skipping to change at page 8, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-ID Flags | PPR-ID Type | PPR-ID Length | | PPR-ID Flags | PPR-ID Type | PPR-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PPR-ID Mask Len| Algo | PPR-ID // |PPR-ID Mask Len| Algo | PPR-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// PPR-ID (cont., variable size) // // PPR-ID (cont., variable size) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PPR-ID Sub-TLV Format Figure 3: PPR-ID Sub-TLV Format
o Type - TBD (See IANA for suggested value) from OSPFv2 PPR TLV o Type - 2 (suggested value, IANA TBD) from OSPFv2 PPR TLV Section 2
Section 2 Sub-TLV registry. Sub-TLV registry.
o Length - Total length of the value field in bytes (variable). o Length - Total length of the value field in bytes (variable).
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) for this Sub-TLV and the defined types are as follows: (TBD IANA) 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|A| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1. L - If set, the PPR path is a Loose-PPR. If the flag is unset, Reserved - Reserved bits for future use. Reserved bits MUST be
then the path described is a Strict-PPR. A Strict-PPR lists reset on transmission and ignored on receive.
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 OSPF area 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 MUST be unset.
3. Reserved - Reserved bits for future use. Reserved bits MUST be o PPR-ID Type - Data plane type of PPR-ID. Values are defined in
reset on transmission and ignored on receive. [I-D.chunduri-lsr-isis-preferred-path-routing]. Only Type 1 and
Type 2 are applicable here.
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 Len - It is applicable for only for PPR-ID Type 2. o PPR-ID Mask Len - It is applicable for only for PPR-ID Type 2.
For Type 1 this value MUST be set to zero. It contains the length For Type 1 this value MUST be set to zero. It contains the length
of the PPR-ID Prefix in bits. Only the most significant octets of of the PPR-ID Prefix in bits. Only the most significant octets of
the Prefix are encoded. This is needed, if PPR-ID followed is an the Prefix are encoded. This is needed, if PPR-ID followed is an
IPv4 Prefix instead of 4 octet Address respectively. IPv4 Prefix instead of 4 octet 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-ospf-segment-routing-extensions]. [I-D.ietf-ospf-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. SR-MPLS SID/Label. For Type 2 this is a 4 byte IPv4 address
encoded similar to PPR-Prefix.
2.4. PPR-PDE Sub-TLV 2.4. PPR-PDE Sub-TLV
This is a new Sub-TLV type in PPR TLV Section 2 and is called as PPR This is a new Sub-TLV type in PPR TLV Section 2 and is called as PPR
Path Description Element (PDE). PPR-PDEs are used to describe the Path Description Element (PDE). PPR-PDEs are used to describe the
path in the form of set of contiguous and ordered Sub-TLVs, where path in the form of set of contiguous and ordered Sub-TLVs, where
first Sub-TLV represents (the top of the stack in MPLS data plane or) first Sub-TLV represents (the top of the stack in MPLS data plane or)
first node/segment of the path. These set of ordered Sub-TLVs can first node/segment of the path. These set of ordered Sub-TLVs can
have both topological SIDs and non-topological SIDs (e.g., service have both topological SIDs and non-topological SIDs (e.g., service
segments). segments).
skipping to change at page 9, line 31 skipping to change at page 9, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-PDE Flags | PDE-ID Value // | PPR-PDE Flags | PDE-ID Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// PDE-ID Value (Contd., Variable size) // // PDE-ID Value (Contd., Variable size) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-PDE Sub-TLVs (variable) | | PPR-PDE Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PPR-PDE Sub-TLV Format Figure 4: PPR-PDE Sub-TLV Format
o Type - TBD (See IANA for suggested value) from OSPFv2 PPR TLV o Type - 3 (TBD IANA, suggested value) from OSPFv2 PPR TLV Section 2
Section 2 Sub-TLV registry. Sub-TLV registry.
o Length - Total length of the value field in bytes (variable). o Length - Total length of the value field in bytes (variable).
o PPR-PDE Type - This is a new registry (TBD IANA) for this Sub-TLV o PPR-PDE Type - This is a new registry (TBD IANA) for this Sub-TLV
and the defined types are as follows: and the 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. This is a o PDE-ID Type - 1 Octet PDE-forwarding IDentifier Type. This is a
new registry (TBD IANA) for this Sub-TLV and the defined types and new registry (TBD IANA) for this Sub-TLV and the defined types and
corresponding PDE-ID Len, PDE-ID Value are as follows: corresponding PDE-ID Len, PDE-ID Value are as follows:
a. Type 1: SID/Label Sub-TLV as defined in Type 0: This value MUST be set only when PPR-PDE Type is Non-
[I-D.ietf-ospf-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.1 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 Sub-TLV as defined in
as Type 1. [I-D.ietf-ospf-segment-routing-extensions]. PDE-ID Len and PDE-
ID Value fields are per Section 2.1 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 2.2.
Type 4: IPv4 Node Address. PDE-ID Len is 4 bytes and PDE-ID
Value is 4 bytes IPv4 address encoded similar to IPv4 Prefix
described in Section 2.2.
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 2.2.
Type 6: IPv4 LAN 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 2.2. This type MUST have OSPF
Neighbor ID sub-TLV in the PDE.
o PDE-ID Len - 1 Octet. Length of PDE-ID field. o PDE-ID Len - 1 Octet. Length of PDE-ID field.
o Reserved - 1 Octet reserved bits for future use. Reserved bits o Reserved - 1 Octet reserved bits for future use. Reserved bits
MUST be reset on transmission and ignored on receive. MUST be reset on transmission and ignored on receive.
o PPR-PDE Flags - 2 Octet flags for this TLV are described below: o PPR-PDE Flags - 2 Octet flags for this TLV are 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: This bit indicates the type of next "Topological PDE-ID" in L: Loose Bit: This bit indicates the type of next "Topological
the path description and overrides the L bit in Section 2.3. If PDE-ID" in the path description. If set, the next PDE is Loose.
set, the next PDE is Loose. If this flag is unset, the next If this flag is unset, the next Topological PDE is Strict Type.
Topological PDE is Strict Type.
2. D: By default this bit MUST be unset. This bit MUST be set only D: Destination Bit: By default this bit MUST be unset. This bit
for PPR-PDE Type is Topological and this PDE represents the PDE- MUST be set only for PPR-PDE Type is Topological and this PDE
ID corresponding to the PPR-Prefix Section 2.2. represents the PDE-ID corresponding to the PPR-Prefix
Section 2.2.
3. Reserved: Reserved bits for future use. Reserved bits MUST be E: Egress Bit. By default this bit MUST be unset. This bit MUST
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. It has 2 octet type, 2 octet length and Reserved: Reserved bits for future use. Reserved bits MUST be
value field is defined per type. reset on transmission and ignored on receive.
o PPR-PDE Sub-TLVs have 2 octet type, 2 octet length and value field
is defined per type.
o PPR-PDE Sub-TLV: Type 4 (IANA TBD), Length Total length of value
field in bytes, Value: The Router ID of the neighbor for which the
LAN interface is advertised. This Sub-TLV MUST NOT be present, if
the PPR-PDE Type is not equal to 1 i.e., Topological PDE and PDE-
ID Type 6.
2.5. PPR-Attributes Sub-TLV 2.5. 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): This is Packet Traffic o Type 1 (Suggested Value, IANA TBD): PPR-Metric Sub-TLV. Length 4
accounting Sub-TLV. Length 0 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): This is Traffic statistics in
Bytes Sub-TLV. Length 0 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-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).
3. OSPFv3 PPR TLV 3. OSPFv3 PPR TLV
The OSPFv3 PPR TLV s a top level TLV of the following LSAs defined in The OSPFv3 PPR TLV s a top level TLV of the following LSAs defined in
[I-D.ietf-ospf-ospfv3-lsa-extend]. [I-D.ietf-ospf-ospfv3-lsa-extend].
E-Intra-Area-Prefix-LSA E-Intra-Area-Prefix-LSA
E-Inter-Area-Prefix-LSA E-Inter-Area-Prefix-LSA
skipping to change at page 12, line 13 skipping to change at page 12, line 47
Figure 5: OSPFv3 PPR TLV Format Figure 5: OSPFv3 PPR TLV Format
o Type - TBD (IANA)from OSPF Extended Prefix Opaque LSA registry. o Type - TBD (IANA)from OSPF Extended Prefix Opaque LSA registry.
o Length - Total length of the value field in bytes (variable). o Length - Total length of the value field in bytes (variable).
o PPR-Flags - 2 Octet flags for this TLV are described below. o PPR-Flags - 2 Octet flags for this TLV are described below.
o AF: Address family for the prefix. o AF: Address family for the prefix.
o AF: 0 - IPv4 unicast
AF: 0 - IPv4 unicast
AF: 1 - IPv6 unicast AF: 1 - IPv6 unicast
o Reserved - 1 Octet reserved bits for future use. Reserved bits o Reserved - 1 Octet reserved bits for future use. Reserved bits
MUST be reset on transmission and ignored on receive. MUST be reset on transmission and ignored on receive.
Flags: 2 octet field. The following flags are defined: Flags: 2 octet field. The following flags are defined:
OSPFv3 PPR Flags Format OSPFv3 PPR TLV Flags Format
0 1 2 3 4 5 6 7 15 0 1 2 3 4 5 6 7 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|IA|A | Rsrvd | |IA|A | Reserved |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
IA-Flag: Inter-Area flag. If set, advertisement is of inter-area IA-Flag: Inter-Area flag. If set, advertisement is of inter-area
type. An ABR that is advertising the OSPF PPR TLV between areas type. An ABR that is advertising the OSPF PPR TLV between areas
MUST set this bit. MUST set this bit.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
A: The originator of the PPR TLV MUST set the A bit in order to 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 are signal that the prefixes and PPR-IDs advertised in the PPR TLV are
directly connected to the originators. If this bit is not set, directly connected to the originators. If this bit is not set,
this allows any other node in the network advertise this TLV on this allows any other node in the network advertise this TLV on
behalf of the originating node of the "OSPF Prefix". If PPR TLV behalf of the originating node of the "OSPF Prefix". If PPR TLV
is propagated to other areas the A-flag MUST be cleared. In case is propagated to other areas the A-flag MUST be cleared. In case
if the originating node of the prefix has to be disambiguated for if the originating node of the prefix has to be disambiguated for
any reason including, if it is a Multi Homed Prefix (MHP) or any reason including, if it is a Multi Homed Prefix (MHP) or
propagated to a different OSPF area, then PPR-Attribute Sub-TLV propagated to a different OSPF area, then PPR-Attribute Sub-TLV
Source Router ID SHOULD be included. Source Router ID SHOULD be included.
Rsrvd - reserved bits for future use. Reserved bits MUST be reset Reserved - reserved bits for future use. Reserved bits MUST be
on transmission and ignored on receive. reset on transmission and ignored on receive.
PPR path description for each OSPF area is computed and given to one
of the nodes in that area for dissemination. Similarly path
information when crossing the area boundaries MUST be relevant to the
destination area. If there is no path information available for the
destination area, PPR TLV MUST NOT be leaked regardless of the IA bit
status.
3.1. OSPFv3 PPR-Prefix Sub-TLV 3.1. OSPFv3 PPR-Prefix Sub-TLV
The structure of OSPFv3 PPR-Prefix, for which path description is The structure of OSPFv3 PPR-Prefix, for which path description is
attached to is as follows: attached to is as follows:
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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Mask Length | Reserved | | Prefix Length | Mask Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OSPFv3 Prefix (variable) // // OSPFv3 Prefix (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-Prefix Sub-TLVs (variable) | | PPR-Prefix Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OSPFv3 PPR-Prefix Sub-TLV Format Figure 6: OSPFv3 PPR-Prefix Sub-TLV Format
o Type - TBD (See IANA for suggested value) from OSPFv3 PPR TLV o Type - 1 (suggested value, IANA TBD) from OSPFv3 PPR TLV Section 3
Section 3 Sub-TLV registry. Sub-TLV registry.
o Length - Total length of the value field in bytes (variable). o Length - Total length of the value field in bytes (variable).
o Prefix Len - contains the length of the prefix in bits. Only the o Prefix Len - contains the length of the prefix in bits. Only the
most significant octets of the Prefix are encoded. most significant octets of the Prefix are encoded.
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 OSPFv3 Prefix - represents the OSPFv3 prefix at the tail-end of o OSPFv3 Prefix - represents the OSPFv3 prefix at the tail-end of
the advertised PPR. For the address family IPv4 unicast, the the advertised PPR. For the address family IPv4 unicast, the
prefix itself is encoded as a 32-bit value. The default route is prefix itself is encoded as a 32-bit value. The default route is
represented by a prefix of length 0. For the address family (AF represented by a prefix of length 0. For the address family (AF
in OSPFv3 PPR TLV) in IPv6 unicast, the prefix, encoded as an even in OSPFv3 PPR TLV) in IPv6 unicast, the prefix, encoded as an even
multiple of 32-bit words, padded with zeroed bits as necessary. multiple of 32-bit words, padded with zeroed bits as necessary.
This encoding consumes ((PrefixLength + 31) / 32) 32-bit words. This encoding consumes ((PrefixLength + 31) / 32) 32-bit words.
o PPR-Prefix Sub-TLVs - TBD. It has 2 octet type, 2 octet length o PPR-Prefix Sub-TLVs have2 octet type, 2 octet length and value
and value field is defined per type. field is defined per type.
3.2. OSPFv3 PPR-ID Sub-TLVs 3.2. OSPFv3 PPR-ID Sub-TLVs
This represents the actual data plane identifier in the packet and This represents the actual data plane identifier in the packet 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
OSPF Prefix and PPR-ID MUST belong to a same node in the network. OSPF Prefix and PPR-ID MUST belong 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 19 skipping to change at page 15, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-ID Flags | PPR-ID Type | PPR-ID Length | | PPR-ID Flags | PPR-ID Type | PPR-ID Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PPR-ID Mask Len| Algo | PPR-ID // |PPR-ID Mask Len| Algo | PPR-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// PPR-ID (cont, variable size) // // PPR-ID (cont, variable size) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: OSPFv3 PPR-ID Sub-TLV Format Figure 7: OSPFv3 PPR-ID Sub-TLV Format
o Type - TBD (See IANA for suggested value) from OSPFv3 PPR TLV o Type - 2 (suggested value, IANA TBD) from OSPFv3 PPR TLV Section 3
Section 3 Sub-TLV registry. Sub-TLV registry.
o Length - Total length of the value field in bytes (variable). o Length - Total length of the value field in bytes (variable).
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) for this Sub-TLV and the defined types are as follows: (TBD IANA) 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|A| Rsrvd | |L|A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1. L - If set, the PPR path is a Loose-PPR. If the flag is unset, Reserved - Reserved bits for future use. Reserved bits MUST be
then the path described is a Strict-PPR. A Strict-PPR lists reset on transmission and ignored on receive.
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 OSPF area 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 MUST be unset.
3. Reserved - Reserved bits for future use. Reserved bits MUST be
reset on transmission and ignored on receive.
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 Len - 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 o Algo - 1 octet value represents the SPF algorithm. Algorithm
registry is as defined in registry is as defined in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-ospfv3-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 encoded as 4 byte IPv4
this is a 16 byte IPv6 address. For Type 2 and Type 3 encoding is address. For Type 3 this is encoded as 16 byte IPv6 address. For
similar to OSPF Prefix as specified in Section 2.2. For Type 4, Type 2 and Type 3 encoding is similar to OSPF Prefix as specified
it is a 16 byte IPv6 SID. in Section 2.2. For Type 4, this is encoded as 16 byte IPv6 SID.
3.3. OSPFv3 PPR-PDE Sub-TLV 3.3. OSPFv3 PPR-PDE Sub-TLV
This is a new Sub-TLV type in PPR TLV Section 3 and is called as PPR This is a new Sub-TLV type in PPR TLV Section 3 and is called as PPR
Path Description Element (PDE). PPR-PDEs are used to describe the Path Description Element (PDE). PPR-PDEs are used to describe the
path in the form of set of contiguous and ordered Sub-TLVs, where path in the form of set of contiguous and ordered Sub-TLVs, where
first Sub-TLV represents (the top of the stack in MPLS data plane or) first Sub-TLV represents (the top of the stack in MPLS data plane or)
first node/segment of the path. These set of ordered Sub-TLVs can first node/segment of the path. These set of ordered Sub-TLVs can
have both topological SIDs and non-topological SIDs (e.g., service have both topological SIDs and non-topological SIDs (e.g., service
segments). segments).
skipping to change at page 16, line 21 skipping to change at page 16, line 50
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-PDE Flags | PDE-ID Value // | PPR-PDE Flags | PDE-ID Value //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// PDE-ID Value (Contd., Variable size) // // PDE-ID Value (Contd., Variable size) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPR-PDE Sub-TLVs (variable) | | PPR-PDE Sub-TLVs (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: OSPFv3 PPR-PDE Sub-TLV Format Figure 8: OSPFv3 PPR-PDE Sub-TLV Format
o Type - TBD (See IANA for suggested value) from OSPFv3 PPR TLV o Type - 3 (suggested value, IANA TBD) from OSPFv3 PPR TLV Section 3
Section 3 Sub-TLV registry. Sub-TLV registry.
o Length - Total length of the value field in bytes (variable). o Length - Total length of the value field in bytes (variable).
o PPR-PDE Type - This is a new registry (TBD IANA) for this Sub-TLV o PPR-PDE Type - This is a new registry (TBD IANA) for this Sub-TLV
and the defined types are as follows: and the 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. This is a o PDE-ID Type - 1 Octet PDE-forwarding IDentifier Type. This is a
new registry (TBD IANA) for this Sub-TLV and the defined types and new registry (TBD IANA) for this Sub-TLV and the defined types and
corresponding PDE-ID Len, PDE-ID Value are as follows: corresponding PDE-ID Len, PDE-ID Value are as follows:
a. Type 1: SID/Label Sub-TLV as defined in Type 0: This value MUST be set only when PPR-PDE Type is Non-
[I-D.ietf-ospf-segment-routing-extensions]. PED-ID Len and PDE- Topological. PDE-ID Len specified in bytes and encoded in NBO
ID Value fields are per Section 2.1 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 Sub-TLV as defined in
as Type 1. [I-D.ietf-ospf-segment-routing-extensions]. PED-ID Len and PDE-
ID Value fields are per Section 2.1 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 2.2.
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 2.2. described in Section 2.2.
f. Type 6: SRv6 Node SID as defined in Type 5: IPv4 P2P interface Address. PDE-ID Len is 4 bytes and
[I-D.li-ospf-ospfv3-srv6-extensions]. PDE-ID Len and PDE-ID PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4
Value are as defined in SRv6 SID. Prefix described in Section 2.2.
g. Type 7: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Value are as Type 6: IPv4 LAN interface Address. PDE-ID Len is 4 bytes and
defined in Type 6. PDE-ID Value is 4 bytes IPv4 address encoded similar to IPv4
Prefix described in Section 2.2. This type MUST have OSPF
Neighbor 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 2.2.
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 2.2.
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 2.2. This type MUST have OSPF
Neighbor ID Sub-TLV in the PDE.
Type 10: SRv6 Node SID as defined in
[I-D.li-ospf-ospfv3-srv6-extensions]. PDE-ID Len and PDE-ID
Value are as defined in SRv6 SID.
Type 11: SRv6 Adjacency-SID. PDE-ID Len and PDE-ID Value are as
defined in Type 6.
o PDE-ID Len - 1 Octet. Length of PDE-ID field. o PDE-ID Len - 1 Octet. Length of PDE-ID field.
o Reserved - 1 Octet reserved bits for future use. Reserved bits o Reserved - 1 Octet reserved bits for future use. Reserved bits
MUST be reset on transmission and ignored on receive. MUST be reset on transmission and ignored on receive.
o PPR-PDE Flags - 2 Octet flags for this TLV are described below: o PPR-PDE Flags - 2 Octet flags for this TLV are 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| Rsrvd | |L|D|E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1. L - This bit indicates the type of next "Topological PDE-ID" in L: Loose Bit. This bit indicates the type of next "Topological
the path description and overrides the L bit in Section 3.2. If PDE-ID" in the path description and overrides the L bit in
set, the next PDE is Loose. If this flag is unset, the next Section 3.2. If set, the next PDE is Loose. If this flag is
Topological PDE is Strict Type. unset, the next Topological PDE is Strict Type.
2. D - By default this bit MUST be unset. This bit MUST be set only D: Destination Bit. By default this bit MUST be unset. This bit
for PPR-PDE Type is Topological and this PDE represents the PDE- MUST be set only for PPR-PDE Type is Topological and this PDE
ID corresponding to the PPR-Prefix Section 3.1. represents the PDE-ID corresponding to the PPR-Prefix
Section 3.1.
3. Rsrvd - Reserved bits for future use. Reserved bits MUST be E: Egress Bit. By default this bit MUST be unset. This bit MUST
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. It has 2 octet type, 2 octet length and Reserved - Reserved bits for future use. Reserved bits MUST be
value field is defined per type. reset on transmission and ignored on receive.
o PPR-PDE Sub-TLVs have 2 octet type, 2 octet length and value field
is defined per type.
o PPR-PDE Sub-TLV: Type 4 (IANA TBD), Length Total length of value
field in bytes, Value: The Router ID of the neighbor for which the
LAN interface is advertised. This Sub-TLV MUST NOT be present, if
the PPR-PDE Type is not equal to 1 i.e., Topological PDE and PDE-
ID Type 6/9.
3.4. OSPFv3 PPR-Attributes Sub-TLV 3.4. OSPFv3 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): This is Packet Traffic o Type 1 (suggested value, IANA TBD): PPR-Metric Sub-TLV. Length 4
accounting Sub-TLV. Length 0 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): This is Traffic statistics in
Bytes Sub-TLV. Length 0 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-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. Other Considerations 4. Other Considerations
Please refer to [I-D.chunduri-isis-preferred-path-routing] section 4, Please refer to [I-D.chunduri-isis-preferred-path-routing] section 4,
5, 6 and 7. 5, 6 and 7.
5. Acknowledgements 5. Acknowledgements
Thanks to Richard Li, Alex Clemm, Padma Pillay-Esnault, Toerless Thanks to Richard Li, Alex Clemm, Padma Pillay-Esnault, Toerless
Eckert, Kiran Makhijani and Lin Han for initial discussions on this Eckert, Kiran Makhijani and Lin Han for initial discussions on this
skipping to change at page 19, line 46 skipping to change at page 20, line 50
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.chunduri-lsr-isis-preferred-path-routing] [I-D.chunduri-lsr-isis-preferred-path-routing]
Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, Chunduri, U., Li, R., White, R., Tantsura, J., Contreras,
L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS",
draft-chunduri-lsr-isis-preferred-path-routing-01 (work in draft-chunduri-lsr-isis-preferred-path-routing-02 (work in
progress), July 2018. progress), February 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., 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-ospf-ospfv3-lsa-extend] [I-D.ietf-ospf-ospfv3-lsa-extend]
Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. Lindem, A., Roy, A., Goethals, D., Vallem, V., and F.
Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3-
lsa-extend-23 (work in progress), January 2018. lsa-extend-23 (work in progress), January 2018.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment
Routing", draft-ietf-ospf-ospfv3-segment-routing- Routing", draft-ietf-ospf-ospfv3-segment-routing-
extensions-23 (work in progress), January 2019. extensions-23 (work in progress), January 2019.
skipping to change at page 20, line 36 skipping to change at page 21, line 36
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018. in progress), January 2018.
[I-D.li-ospf-ospfv3-srv6-extensions] [I-D.li-ospf-ospfv3-srv6-extensions]
Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak,
"OSPFv3 Extensions for SRv6", draft-li-ospf- "OSPFv3 Extensions for SRv6", draft-li-ospf-
ospfv3-srv6-extensions-02 (work in progress), September ospfv3-srv6-extensions-03 (work in progress), March 2019.
2018.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007, RFC 4915, DOI 10.17487/RFC4915, June 2007,
<https://www.rfc-editor.org/info/rfc4915>. <https://www.rfc-editor.org/info/rfc4915>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key "Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<https://www.rfc-editor.org/info/rfc7474>. <https://www.rfc-editor.org/info/rfc7474>.
 End of changes. 73 change blocks. 
201 lines changed or deleted 230 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/