draft-ietf-mpls-rfc8287-len-clarification-02.txt   draft-ietf-mpls-rfc8287-len-clarification-03.txt 
Network Work group N. Nainar Network Work group N. Nainar
Internet-Draft C. Pignataro Internet-Draft C. Pignataro
Updates: 8287 (if approved) Cisco Systems, Inc. Updates: 8287 (if approved) Cisco Systems, Inc.
Intended status: Standards Track F. Iqbal Intended status: Standards Track F. Iqbal
Expires: December 2, 2019 Individual Expires: February 9, 2020 Individual
A. Vainshtein A. Vainshtein
ECI Telecom ECI Telecom
May 31, 2019 August 8, 2019
RFC8287 Sub-TLV Length Clarification RFC8287 Sub-TLV Length Clarification
draft-ietf-mpls-rfc8287-len-clarification-02 draft-ietf-mpls-rfc8287-len-clarification-03
Abstract Abstract
RFC8287 defines the extensions to MPLS LSP Ping and Traceroute for RFC8287 defines the extensions to MPLS LSP Ping and Traceroute for
Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier
(SIDs) with an MPLS data plane. RFC8287 proposes 3 Target FEC Stack (SIDs) with an MPLS data plane. RFC8287 proposes 3 Target FEC Stack
Sub-TLVs. While the standard defines the format and procedure to Sub-TLVs. While the standard defines the format and procedure to
handle those Sub-TLVs, it does not sufficiently clarify how the handle those Sub-TLVs, it does not sufficiently clarify how the
length of the Segment ID Sub-TLVs should be computed to include in length of the Segment ID Sub-TLVs should be computed to include in
the Length field of the Sub-TLVs which may result in interoperability the Length field of the Sub-TLVs which may result in interoperability
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 December 2, 2019. This Internet-Draft will expire on February 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 15 skipping to change at page 3, line 15
2. Terminology 2. Terminology
This document uses the terminologies defined in [RFC8402], [RFC8029], This document uses the terminologies defined in [RFC8402], [RFC8029],
[RFC8287] and so the readers are expected to be familiar with the [RFC8287] and so the readers are expected to be familiar with the
same. same.
3. Requirements notation 3. Requirements notation
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] [RFC8174]. document are to be interpreted as described in [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
4. Length field clarification for Segment ID Sub-TLVs 4. Length field clarification for Segment ID Sub-TLVs
Section 5 of [RFC8287] defines 3 different Segment ID Sub-TLVs that Section 5 of [RFC8287] defines 3 different Segment ID Sub-TLVs that
will be included in Target FEC Stack TLV defined in [RFC8029]. The will be included in Target FEC Stack TLV defined in [RFC8029]. The
length of each Sub-TLVs MUST be calculated as defined in this length of each Sub-TLVs MUST be calculated as defined in this
section. section.
The figures in section 5.1, 5.2 and 5.3 of [RFC8287] are replaced by The TLVs representation defined in section 5.1, 5.2 and 5.3 of
the below figures in section 4.1, 4.2 and 4.3 respectively. The [RFC8287] are updated to clarify the length calculation as shown in
updated figures contain explicitly defined length. section 4.1, 4.2 and 4.3 respectively. The updated TLV
representation contain explicitly defined length.
4.1. IPv4 IGP-Prefix Segment ID Sub-TLV 4.1. IPv4 IGP-Prefix Segment ID Sub-TLV
The Sub-TLV length for IPv4 IGP-Prefix Segment ID MUST be set to 8 as The Sub-TLV length for IPv4 IGP-Prefix Segment ID MUST be set to 8 as
shown in the below TLV format: shown in the below TLV 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 = 34 (IPv4 IGP-Prefix SID)| Length = 8 | |Type = 34 (IPv4 IGP-Prefix SID)| Length = 8 |
skipping to change at page 4, line 8 skipping to change at page 4, line 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. IPv6 IGP-Prefix Segment ID Sub-TLV 4.2. IPv6 IGP-Prefix Segment ID Sub-TLV
The Sub-TLV length for IPv6 IGP-Prefix Segment ID MUST be set to 20 The Sub-TLV length for IPv6 IGP-Prefix Segment ID MUST be set to 20
as shown in the below TLV format: as shown in the below TLV 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 = 35 (IPv4 IGP-Prefix SID)| Length = 20 | |Type = 35 (IPv6 IGP-Prefix SID)| Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| IPv6 Prefix | | IPv6 Prefix |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Prefix Length | Protocol | Reserved | |Prefix Length | Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. IGP-Adjacency Segment ID Sub-TLV 4.3. IGP-Adjacency Segment ID Sub-TLV
The Sub-TLV length for IGP-Adjacency Segment ID varies depending on The Sub-TLV length for IGP-Adjacency Segment ID varies depending on
the Adjacency Type and Protocol. In any of the allowed combination the Adjacency Type and Protocol. In any of the allowed combination
of Adjacency Type and Protocol, the sub-TLV length MUST be calculated of Adjacency Type and Protocol, the sub-TLV length MUST be calculated
by including 2 octets of Reserved field. Below is a table that list by including 2 octets of Reserved field. Table 1 below list the
the length for different combinations. length for different combinations of Adj.Type and Protocol.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Length for Adj.Type | | Protocol | Length for Adj.Type |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Parallel | IPv4 | IPv6 | | | Parallel | IPv4 | IPv6 | Unnumbered|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF | 20 | 20 | 44 | | OSPF | 20 | 20 | 44 | 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISIS | 24 | 24 | 48 | | ISIS | 24 | 24 | 48 | 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Any | 20 | 20 | 44 | | Any | 20 | 20 | 44 | 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Table 1. IGP-Adjacency SID Length Comparison
For example, when the Adj. Type is set to Parallel Adjacency and the For example, when the Adj. Type is set to Parallel Adjacency and the
Protocol is set to 0, the Sub-TLV will be as below: Protocol is set to 0, the Sub-TLV will be as below:
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 = 36 (IGP-Adjacency SID) | Length = 20 | |Type = 36 (IGP-Adjacency SID) | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adj. Type = 1 | Protocol =0 | Reserved | | Adj. Type = 1 | Protocol = 0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) | | Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID (4 octets) | | Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Node Identifier (4 octets) | | Advertising Node Identifier (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Node Identifier (4 octets) | | Receiving Node Identifier (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. IANA Considerations 5. IANA Considerations
This document does not introduce any IANA consideration. This document does not introduce any IANA consideration.
6. Security Considerations 6. Security Considerations
This document updates [RFC8287] and does not introduce any security This document updates [RFC8287] and does not introduce any additional
considerations. security considerations.
7. Contributors 7. Contributors
The below individuals contributed to this document: The below individuals contributed to this document:
Zafar Ali, Cisco Systems, Inc. Zafar Ali, Cisco Systems, Inc.
8. Acknowledgement 8. Acknowledgement
The authors would like to thank Michael Gorokhovsky and Manohar The authors would like to thank Michael Gorokhovsky and Manohar
 End of changes. 11 change blocks. 
25 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/