LSR Working Group U. Chunduri Internet-Draft Y. Qu Intended status: Standards Track Huawei USA Expires: September 25, 2018 J. Tantsura Nuage Networks March 24, 2018 Usage of Non Shortest Path Forwarding (NSPF) IDs in OSPF draft-ct-ospf-nspfid-for-sr-paths-00 Abstract This document specifies the advertisement of Non Shortest Path Forwarding IDentifier (NSPF ID) TLV and the computation procedures for the same in OSPFv2 and OSPFv3 protocols. NSPF ID allows to simplify the data plane path description of data traffic in SR deployments. This helps to mitigate the MTU issues that are caused by additional SR overhead of the packet and allows traffic statistics. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 25, 2018. Chunduri, et al. Expires September 25, 2018 [Page 1] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 Copyright Notice Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 2. OSPF NSPF ID TLV . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. NSPF-ID Fields . . . . . . . . . . . . . . . . . . . . . 5 2.3. NSP sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Non-NSP sub-TLVs . . . . . . . . . . . . . . . . . . . . 7 3. OSPFv3 NSPF ID TLV . . . . . . . . . . . . . . . . . . . . . 7 3.1. OSPFv3 NSPF-ID Fields . . . . . . . . . . . . . . . . . . 9 3.2. OSPFv3 NSP sub-TLVs . . . . . . . . . . . . . . . . . . . 10 3.3. OSPFv3 Non-NSP sub-TLVs . . . . . . . . . . . . . . . . . 11 4. Other Considerations . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction In a network implementing source routing, packets may be transported through the use of segment identifiers (SIDs), where a SID uniquely identifies a segment as defined in [I-D.ietf-spring-segment-routing]. In SR-MPLS, a segment is encoded as a label and an ordered list of segments is encoded as a stack of labels. In SRv6, a segment is encoded as an IPv6 address, with a new type of IPv6 routing header called SRH. An ordered list of segments is encoded as an ordered list of IPv6 addresses in SRH [I-D.ietf-6man-segment-routing-header]. Chunduri, et al. Expires September 25, 2018 [Page 2] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 A segment may include one or more nodes, unidirectional adjecencies between two nodes or service instruction by a particular node in the network. A Non Shortest Path (NSP) could be a Traffic Engineered (TE) path or an explicitly provisioned FRR path or a service chained path. NSP can be described using list of segments in SR. However, this creates a problem of having a relatively large stack imposed on the data packet. A path that is encoded with SIDs can be a loose or strict path. In a strict path all the nodes/links on the path are encoded as SIDs, with the expense of number of total SIDs in the stack. The issues caused by the large SID depth, and existing methods for mitigation are introduced in [I-D.ct-isis-nspfid-for-sr-paths] section 1.1 and 1.2. To mitigate the these issues, and also to facilitate forwarding plane a mechanism to identify the SR path with a corresponding data plane identifier for accounting of traffic for SR paths, this draft proposes a new OSPFv2 TLV (Section 2), OSPFv3 TLV (Section 3) to advertise the NSPs with Non Shortest Path Forwarding IDentifier (NSPF ID). With corresponding data plane, Section 3 mechanism as in [I-D.ct-isis-nspfid-for-sr-paths], reduces the SID stack in the data plane with a single NSPF ID. 1.1. Acronyms EL - Entropy Label ELI - Entropy Label Indicator MPLS - Multi Protocol Label Switching MSD - Maximum SID Depth MTU - Maximum Transferrable Unit NSP - Non Shortest Path SID - Segment Identifier SPF - Shortest Path First SR - Segment Routing SRH - Segment Routing Header SR-MPLS - Segment Routing with MPLS data plane Chunduri, et al. Expires September 25, 2018 [Page 3] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 SRv6 - Segment Routing with Ipv6 data plane with SRH SRH - IPv6 Segment Routing Header TE - Traffic Engineering 2. OSPF NSPF ID TLV Extended Prefix Opaque LSAs defined in [RFC7684] are used for advertisements of NSPF ID TLV. Multiple OSPF NSPF ID TLVs MAY be advertised in each OSPF Extended Prefix Opaque LSA, but all TLVs included in a single OSPF Extended Prefix Opaque LSA MUST have the same flooding scope. The NSPF-ID TLV has Type TBD (suggested value xxx), and has the following format: 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | AF | Prefix Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // FEC Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSPF-ID Type | NSPF-ID Len | NSPF-ID Flags | NSPF-ID Algo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NSPF-ID (continued, variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |No.of NSP-STs | NSP sub-TLVs (Variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |No.of Other-STs| Non-NSP sub-TLVs(variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: NSPF ID TLV Format Type - TBD (IANA) from OSPF Extended Prefix Opaque LSA registry. Length - Total length of the value field in bytes (variable). Reserved - 1 Octet reserved bits for future use. Reserved bits MUST be reset on transmission and ignored on receive. Flags - Flags for this TLV are described in Section 2.1. Chunduri, et al. Expires September 25, 2018 [Page 4] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 AF - Address family for the prefix. Currently, the only supported value is 0 for IPv4 unicast. The inclusion of address family in this TLV allows for future extension. Prefix Len - contains the length of the prefix in bits. FEC Prefix - represents the Forwarding Equivalence Class at the tail-end of the advertised NSP. The "FEC Prefix" corresponds to a routable prefix of the originating node. Value of this field MUST be 4 octets for IPv4 "FEC Prefix". 2.1. Flags Flags: 1 octet field of NSPD ID TLV has following flags defined: NSPF ID Flags Format 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |IA| Rsrvd | +--+--+--+--+--+--+--+--+ w=Where: IA-Flag: Inter-Area flag. If set, advertisement is of inter-area type. An ABR that is advertising the OSPF NSPF ID TLV between areas MUST set this bit. Rsrvd - reserved bits for future use. Reserved bits MUST be reset on transmission and ignored on receive. 2.2. NSPF-ID Fields This represents the actual data plane identifier in the packet and could be of any data plane as defined in type field. Both "FEC Prefix" and NSPF-ID MUST belong to a same node in the network. 1. NSPF-ID Type: This is a new registry (TBD IANA) for this TLV and the defined types are as follows.Type: 1 - MPLS SID/Label Type: 2 Native IPv4 Address 2. NSPF-ID Len: Length of the NSPF Identifier field in octets and this depends on the NSPF-ID type. See NSPF-ID below for the length of this field and other considerations. 3. NSPF-ID Flags: 1 Octet field for NSPF-ID flags. Some of the bits could be NSPF-ID type specific and each new type MUST define the flags applicable to the NSPF-ID type. For NSPF-ID Type 1, the flags are same as definition in Chunduri, et al. Expires September 25, 2018 [Page 5] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 [I-D.ietf-ospf-segment-routing-extensions]. Undefined flags for each NSPF-ID type MUST be considered as reserved. Reserved flag bits in each NSPF-ID type specific flags MUST be reset on transmission and ignored on receive. 4. NSPF-ID Algo: 1 octet value represents the SPF algorithm. Algorithm registry is as defined in [I-D.ietf-ospf-segment-routing-extensions]. 5. NSPF-ID: This is the NSP forwarding identifier that would be on the data packet. The value of this field is variable and it depends on the NSPF-ID Type. For Type 1, this is and MPLS SID/ Label. For Type 2 this is a 4-byte IPv4 address. For NSPF-ID Type 2, if the NSPF-ID Len is set to 0, then FEC Prefix would also become the NSPF-ID. In the case when NSPF-ID Len is 0, NSPF-ID Type is 2, then FEC Prefix length MUST be a 4-byte IPv4 address. 6. No.of NSP-STs: Total number of the NSP sub-TLVs are defined with this 1-octet field. The value MUST NOT be zero. 2.3. NSP sub-TLVs A new sub-TLV registry is created (TBD IANA) called NSP sub-TLVs. These are used to describe the path in the form of set of contiguous and ordered sub-TLVs, with first sub-TLV representing the top of the stack or first segment. These set of ordered TLVs can have both topological SIDs and non-topological SIDs (e.g., service segments). Type 1: SID/Label sub-TLV as defined in [I-D.ietf-ospf-segment-routing-extensions]. Only Type is defined and Length/Value fields are per secton 2.1 of the referenced document. Type 2: Prefix SID sub-TLV as defined in [I-D.ietf-ospf-segment-routing-extensions]. Only Type is defined and Length/Value fields are per section 5 of the referenced document. Type 3: Adjacency SID sub-TLV as defined in [I-D.ietf-ospf-segment-routing-extensions]. Only Type is defined and Length/Value fields are per section 6 of the referenced document. Type 4: Length 4 bytes, value is 4 bytes IPv4 address encoded similar to IPv4 FEC Prefix described above. Chunduri, et al. Expires September 25, 2018 [Page 6] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 2.4. Non-NSP sub-TLVs NSPF ID TLV also defines a new sub-TLV registry (TBD IANA) for defining extensible set of sub-TLVs other than describing the path sub-TLVs. Total number of the path sub-TLVs to describe the path are defined in 1-octet field "No.of Other-STs" just before the Non-NSP sub-TLVs. This field serves as a demarcation for set of ordered NSP sub-TLVs and Non-NSP sub-TLVs. Type 1: Length 0 No value field. Specifies a counter to count number of packets forwarded on this NSPF-ID. Type 2: Length 0 No value field. Specifies a counter to count number of bytes forwarded on this NSPF-ID specified in the network header (e.g. IPv4, IPv6). Type 3: Length 4 bytes, and Value is metric of this path represented through the NSPF-ID. Different nodes can advertise the same NSPF-ID for the same FEC-Prefix with a different set of NSP sub-TLVs and the receiving node MUST consider the lowest metric value (TBD more, what happens when metric is same for two different set of NSP sub-TLVs). 3. OSPFv3 NSPF ID TLV The OSPFv3 NSPF ID TLV s a top level TLV of the following LSAs defined in [I-D.ietf-ospf-ospfv3-lsa-extend]. E-Intra-Area-Prefix-LSA E-Inter-Area-Prefix-LSA E-AS-External-LSA E-Type-7-LSA Multiple OSPFv3 NSPF ID TLVs MAY be advertised in each LSA mentioned above. The OSPFv3 NSPF ID TLV has the following format: Chunduri, et al. Expires September 25, 2018 [Page 7] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | AF | Prefix Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // FEC Prefix (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSPF-ID Type | NSPF-ID Len | NSPF-ID Flags | NSPF-ID Algo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NSPF-ID (continued, variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |No.of NSP-STs | NSP sub-TLVs (Variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |No.of Other-STs| Non-NSP sub-TLVs(variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: OSPFv3 NSPF ID TLV Format where: Type: TBD Length: Variable, in octets, depends on Sub-TLVs. prefix length: Length of prefix in bytes. AF: Address family for the prefix. AF: 0 - IPv4 unicast AF: 1 - IPv6 unicast Flags: Single octet field. The following flags are defined: NSPF ID Flags Format 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |IA| Rsrvd | +--+--+--+--+--+--+--+--+ Chunduri, et al. Expires September 25, 2018 [Page 8] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 IA-Flag: Inter-Area flag. If set, advertisement is of inter- area type. An ABR that is advertising the OSPF NSPF ID TLV between areas MUST set this bit. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Rsrvd - reserved bits for future use. Reserved bits MUST be reset on transmission and ignored on receive. FEC Prefix - represents the Forwarding Equivalence Class at the tail-end of the advertised NSP. The "FEC Prefix" corresponds to a routable prefix of the originating node. Value of this field MUST be 4 octets for IPv4 "FEC Prefix". Value of this field MUST be 16 octets for IPv6 "FEC Prefix". 3.1. OSPFv3 NSPF-ID Fields This represents the actual data plane identifier in the packet and could be of any data plane as defined in type field. Both "FEC Prefix" and NSPF-ID MUST belong to a same node in the network. 1. NSPF-ID Type: This is a new registry (TBD IANA) for this TLV and the defined types are as follows. Type: 1 - MPLS SID/Label Type: 2 Native IPv4 Address Type: 3 Native IPv6 Address Type 4: IPv6 SID in SRv6 with SRH 2. NSPF-ID Len: Length of the NSPF Identifier field in octets and this depends on the NSPF-ID type. See NSPF-ID below for the length of this field and other considerations. 3. NSPF-ID Flags: 1 Octet field for NSPF-ID flags. Some of the bits could be NSPF-ID type specific and each new type MUST define the flags applicable to the NSPF-ID type. For NSPF-ID Type 1, the flags are same as Section 2.1 definition in [I-D.ietf-ospf-segment-routing-extensions]. For NSPF-ID Type 2, 3 and NSPF-ID Type 4 only 'R' flag is applicable. Undefined flags for each NSPF-ID type MUST be considered as reserved. Reserved flag bits in each NSPF-ID type specific flags MUST be reset on transmission and ignored on receive. 4. NSPF-ID Algo: 1 octet value represents the SPF algorithm. Algorithm registry is as defined in [I-D.ietf-ospf-segment-routing-extensions]. 5. NSPF-ID: This is the NSP forwarding identifier that would be on the data packet. The value of this field is variable and it depends on the NSPF-ID Type. For Type 1, this is and MPLS SID/ Label. For Type 2 this is a 4 byte IPv4 address. For Type 3 and Type 4, it is a 16 byte IPv6 address. For NSPF-ID Type 2, 3 or Chunduri, et al. Expires September 25, 2018 [Page 9] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 4, if the NSPF-ID Len is set to 0, then FEC Prefix would also become the NSPF-ID. In the case when NSPF-ID Len is 0, NSPF-ID Type is 2, then FEC Prefix length MUST be a 4 byte IPv4 address. Similarly, if NSPF-ID Type is 3 or 4 with NSPF-ID Len is set to 0, then FEC Prefix MUST be of a 16 byte IPv6 Address. 6. No.of NSP-STs: Total number of the NSP sub-TLVs are defined with this 1-octet field. The value MUST NOT be zero. 3.2. OSPFv3 NSP sub-TLVs A new sub-TLV registry is created (TBD IANA) called NSP sub-TLVs. These are used to describe the path in the form of set of contiguous and ordered sub-TLVs, with first sub-TLV representing the top of the stack or first segment. These set of ordered TLVs can have both topological SIDs and non-topological SIDs (e.g., service segments). Type 1: SID/Label sub-TLV as defined in [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Only Type is defined and Length/Value fields are per section 2.1 of the referenced document. Type 2: Prefix SID sub-TLV as defined in [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Only Type is defined and Length/Value fields are per section 5 of the referenced document. Type 3: Adjacency SID sub-TLV as defined in [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Only Type is defined and Length/Value fields are per section 6 of the referenced document. Type 4: Length 4 bytes, value is 4 bytes IPv4 address encoded similar to IPv4 FEC Prefix described above. Type 5: Length 16 bytes; value is 16 bytes IPv6 address encoded similar to IPv6 FEC Prefix described above. Type 6: SRv6 Node SID TLV as defined in [I-D.li-ospf-ospfv3-srv6-extensions]. Only Type is defined and Length/Value fields are in the referenced document. Type 7: SRv6 Adjacency-SID sub-TLV as defined in [I-D.li-ospf-ospfv3-srv6-extensions]. Only Type is defined and Length/Value fields are in the referenced document. Chunduri, et al. Expires September 25, 2018 [Page 10] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 Type 8: SRv6 LAN Adjacency-SID sub-TLV as defined in [I-D.li-ospf-ospfv3-srv6-extensions]. Only Type is defined and Length/Value fields are in the referenced document. 3.3. OSPFv3 Non-NSP sub-TLVs NSPF ID TLV also defines a new sub-TLV registry (TBD IANA) for defining extensible set of sub-TLVs other than describing the path sub-TLVs. Total number of the path sub-TLVs to describe the path are defined in 1-octet field "No.of Other-STs" just before the Non-NSP sub-TLVs. This field serves as a demarcation for set of ordered NSP sub-TLVs and Non-NSP sub-TLVs. Type 1: Length 0 No value field. Specifies a counter to count number of packets forwarded on this NSPF-ID. Type 2: Length 0 No value field. Specifies a counter to count number of bytes forwarded on this NSPF-ID specified in the network header (e.g. IPv4, IPv6). Type 3: Length 4 bytes, and Value is metric of this path represented through the NSPF-ID. Different nodes can advertise the same NSPF-ID for the same FEC-Prefix with a different set of NSP sub-TLVs and the receiving node MUST consider the lowest metric value (TBD more, what happens when metric is same for two different set of NSP sub-TLVs). 4. Other Considerations Please refer to [I-D.ct-isis-nspfid-for-sr-paths] section 3, 4 and 5. 5. Acknowledgements Thanks to Richard Li, Alex Clemm, Kiran Makhijani and Lin Han for initial discussions on this topic. Earlier versions of draft-ietf-ospf-segment-routing-extensions have a mechanism to advertise EROs through Binding SID. 6. IANA Considerations This document requests the following new TLV in IANA OSPFv2 and OSPFv3 TLV code-point registry. TLV # Name ----- -------------- TBD NSPF ID TLV Chunduri, et al. Expires September 25, 2018 [Page 11] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 This document also requests IANA to create new registries for NSPF ID TLV Flags field, NSPF-ID Type, NSPF-ID Flags, NSP sub-TLVs and Non- NSP sub-TLVs in NSPF ID TLV as described in Section 2 and Section 3. 7. Security Considerations Existing security extensions as described in [RFC2328] and [RFC7684] apply to these segment routing extensions. While OSPF is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPF routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC7474] SHOULD be used. Advertisement of the additional information defined in this document introduces no new security concerns in OSPF protocol. However as this extension is related to SR-MPLS and SRH data planes as defined in [I-D.ietf-spring-segment-routing], those particular data plane security considerations does apply here. 8. References 8.1. Normative References [I-D.ct-isis-nspfid-for-sr-paths] Chunduri, U., Tantsura, J., and Y. Qu, "Usage of Non Shortest Path Forwarding (NSPF) IDs in IS-IS", draft-ct- isis-nspfid-for-sr-paths-01 (work in progress), March 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . 8.2. Informative References [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-01 (work in progress), October 2017. Chunduri, et al. Expires September 25, 2018 [Page 12] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 [I-D.ietf-6man-segment-routing-header] Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-10 (work in progress), March 2018. [I-D.ietf-ospf-ospfv3-lsa-extend] Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- lsa-extend-23 (work in progress), January 2018. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P., Filsfils, C., Previdi, S., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- segment-routing-extensions-11 (work in progress), January 2018. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-24 (work in progress), December 2017. [I-D.ietf-ospf-segment-routing-msd] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling MSD (Maximum SID Depth) using OSPF", draft- ietf-ospf-segment-routing-msd-09 (work in progress), February 2018. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.li-ospf-ospfv3-srv6-extensions] Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, "OSPFv3 Extensions for SRv6", draft-li-ospf- ospfv3-srv6-extensions-01 (work in progress), March 2018. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . Chunduri, et al. Expires September 25, 2018 [Page 13] Internet-DraUsage of Non Shortest Path Forwarding (NSPF) IDs March 2018 [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . Authors' Addresses Uma Chunduri Huawei USA 2330 Central Expressway Santa Clara, CA 95050 USA Email: uma.chunduri@huawei.com Yingzhen Qu Huawei USA 2330 Central Expressway Santa Clara, CA 95050 USA Email: yingzhen.qu@huawei.com Jeff Tantsura Nuage Networks 755 Ravendale Drive Mountain View, CA 94043 USA Email: jefftant.ietf@gmail.com Chunduri, et al. Expires September 25, 2018 [Page 14]