Clarification of Segment ID Sub-TLV Length for RFC 8287 Cisco Systems, Inc.
7200-12 Kit Creek Road Research Triangle Park NC 27709 United States of America naikumar@cisco.com
Cisco Systems, Inc.
7200-11 Kit Creek Road Research Triangle Park NC 27709 United States of America cpignata@cisco.com
Individual
Canada faisal.ietf@gmail.com
ECI Telecom
Israel vainshtein.alex@gmail.com
Internet Network Work group mpls RFC 8287 defines the extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with the MPLS data plane. RFC 8287 proposes three Target Forwarding Equivalence Class (FEC) Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs. This ambiguity has resulted in interoperability issues. This document updates RFC 8287 by clarifying the length of each of the Segment ID sub-TLVs defined in RFC 8287.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
  • .  Introduction
  • .  Terminology
  • .  Requirements Notation
  • .  Length Field Clarification for Segment ID Sub-TLVs
    • .  IPv4 IGP-Prefix Segment ID Sub-TLV
    • .  IPv6 IGP-Prefix Segment ID Sub-TLV
    • .  IGP-Adjacency Segment ID Sub-TLV
  • .  IANA Considerations
  • .  Security Considerations
  • .  Normative References
  • Acknowledgements
  • Contributors
  • Authors' Addresses
Introduction defines the extensions to MPLS LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with the MPLS data plane. proposes three Target FEC Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs, which may result in interoperability issues. This document updates by clarifying the length of each Segment ID sub-TLVs defined in .
Terminology This document uses the terminology defined in , , and ; readers are expected to be familiar with the terms as used in those documents.
Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Length Field Clarification for Segment ID Sub-TLVs defines three different Segment ID sub-TLVs that can be included in the Target FEC Stack TLV defined in . The length of each sub-TLV MUST be calculated as defined in this section. The TLV representations defined in Sections , , and of are updated to clarify the length calculations, as shown in Sections , , and , respectively. The updated TLV representations contain explicitly defined lengths.
IPv4 IGP-Prefix Segment ID Sub-TLV The sub-TLV length for the IPv4 IGP-Prefix Segment ID MUST be set to 8, as shown in the TLV format below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type = 34 (IPv4 IGP-Prefix SID)| Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix Length | Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 IGP-Prefix Segment ID Sub-TLV The sub-TLV length for the IPv6 IGP-Prefix Segment ID MUST be set to 20, as shown in the TLV format below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type = 35 (IPv6 IGP-Prefix SID)| Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | IPv6 Prefix | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix Length | Protocol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IGP-Adjacency Segment ID Sub-TLV The sub-TLV length for the IGP-Adjacency Segment ID varies depending on the Adjacency Type and Protocol. In any of the allowed combinations of Adjacency Type and Protocol, the sub-TLV length MUST be calculated by including 2 octets of the Reserved field. lists the length for different combinations of Adj. Type and Protocol. IGP-Adjacency SID Length Computation
Protocol Length for Adj. Type
Parallel IPv4 IPv6 Unnumbered
OSPF 20 20 44 20
ISIS 24 24 48 24
Any 20 20 44 20
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: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type = 36 (IGP-Adjacency SID) | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adj. Type = 1 | Protocol = 0 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Interface ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Interface ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Node Identifier (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiving Node Identifier (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IANA Considerations IANA has listed this document as an additional reference for the following entries in the "Sub-TLVs for TLV Types 1, 16, and 21" registry: Sub-TLVs for TLV Types 1, 16, and 21 (Updated Entries)
Sub-Type Sub-TLV Name Reference
34 IPv4 IGP-Prefix Segment ID ; RFC 8690
35 IPv6 IGP-Prefix Segment ID ; RFC 8690
36 IGP-Adjacency Segment ID ; RFC 8690
Security Considerations This document updates and does not introduce any additional security considerations.
Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults. This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header. The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane. Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.
Acknowledgements The authors would like to thank Michael Gorokhovsky and Manohar Doppalapudi for investigating the interoperability issue during European Advanced Network Test Center (EANTC) testing.
Contributors The following individual contributed to this document: Zafar Ali, Cisco Systems, Inc.
Authors' Addresses Cisco Systems, Inc.
7200-12 Kit Creek Road Research Triangle Park NC 27709 United States of America naikumar@cisco.com
Cisco Systems, Inc.
7200-11 Kit Creek Road Research Triangle Park NC 27709 United States of America cpignata@cisco.com
Individual
Canada faisal.ietf@gmail.com
ECI Telecom
Israel vainshtein.alex@gmail.com