Internet-Draft MPLS Inspection MSD March 2023
Liu Expires 7 September 2023 [Page]
Workgroup:
LSR
Internet-Draft:
draft-liu-lsr-mpls-inspection-msd-00
Published:
Intended Status:
Standards Track
Expires:
Author:
Y. Liu
ZTE

Signaling Base MPLS Inspection MSD

Abstract

This document defines a new type of MSD, Base MPLS Inspection MSD, and the mechanism to signal this MSD using IGP and BGP-LS.

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 7 September 2023.

Table of Contents

1. Introduction

[I-D.ietf-mpls-mna-fwk] specifies an architectural framework for the MPLS Network Actions (MNA) technologies. MNA technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions.

[I-D.ietf-mpls-mna-hdr] defines the MPLS Network Action sub-stack(NAS) solution for carrying Network Actions and Ancillary Data in the label stack. The node adding an NAS to the label stack will need to place a copy of the NAS where it can be read by the relevant nodes. A node that pushes a NAS onto the label stack is responsible for determining that all nodes that should process the NAS will have the NAS within its Maximum MPLS Stack Inspection depth. A node should use signaling to determine this.

On the other hand, even if the MNA framework is not followed, as long as there're scenarios where every transit node is required to inspect beyond the top of stack, the requirement to obtain the maximum inspection depth of the nodes along the LSP exists.

Maximum SID Depth (MSD)[RFC8491] is originally introduced for SR-MPLS to express the number of SIDs supported by a node or a link on a node. In a non-SR MPLS network, MSD defines the maximum label depth.

This document defines a new type of MSD, Base MPLS Inspection MSD, and the mechanism to signal this MSD using IGP and BGP-LS.

2. Conventions Used in This Document

2.1. 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] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2.2. Abbreviations

MNA: MPLS Network Actions

NAS: Network Action sub-stack

EL: Entropy Label

ERLD: Entropy Readable Label Depth

3. Base MPLS Inspection MSD

The Base MPLS Inspection MSD is defined as the maximum number of labels a router can read in an MPLS packet received on its incoming interface(s) (starting from the top of the stack).

The Base MPLS Inspection MSD MAY be used by ingress LSRs to determine the position of the NAS, and whether it's necessary to insert multiple NAS at different positions in the label stack. When the label stack are determined by a centralized controller, the MSD of each intermediate LSR SHOULD be sent to the controller.

With Base MPLS Inspection MSD, application/network action-specified MSD analogous to ERLD-MSD[RFC9088] [RFC9089] MAY not needed. For example, a node can signal certain network action capability and the Base MPLS Inspection MSD to indicate that it can process this network action within the MSD.

4. Advertising Base MPLS Inspection MSD Using IS-IS

A new MSD-Type [RFC8491], called Base MPLS Inspection MSD, is defined. The MSD-Type code is to be assigned by IANA. The MSD-Value field is set to the maximum number of labels a router can read in the range between 0 to 255. The scope of the advertisement depends on the application.

If a router has multiple interfaces with different capabilities of reading the maximum label stack depth, the router MUST advertise the smallest value found across all its interfaces.

The absence of Base MPLS Inspection MSD advertisements indicates only that the advertising node does not support advertisement of this capability.

If the Base MPLS Inspection MSD type is received in the Link MSD sub-TLV, it MUST be ignored.

5. Advertising Base MPLS Inspection MSD Using OSPF

The Base MPLS Inspection MSD is advertised in a Node MSD TLV [RFC8476] using the same MSD-Type code as defined in section 4.

If a router has multiple interfaces with different capabilities of reading the maximum label stack depth, the router MUST advertise the smallest value found across all its interfaces.

The absence of Base MPLS Inspection MSD advertisements indicates only that the advertising node does not support advertisement of this capability.

If the Base MPLS Inspection MSD type is received in the Link MSD sub-TLV, it MUST be ignored.

6. Signaling Base MPLS Inspection MSD in BGP-LS

The IS-IS and OSPF extensions defined in this document can be advertised via BGP-LS (distribution of Link-State and TE information using BGP) [RFC7752] using existing BGP-LS TLVs.

The Base MPLS Inspection MSD is advertised using the Node MSD TLV as defined in [RFC8814].

7. Security Considerations

This document specifies the ability to advertise additional node capabilities using IS-IS, OSPF and BGP-LS. As such, the security considerations as described in [RFC5340], [RFC7684], [RFC7752], [RFC7770], [RFC7794], [RFC7981], [RFC8476], [RFC8491], [RFC8662], [RFC8814], [RFC9085] are applicable to this document.

Incorrectly setting of the ERLD value may lead to poor or no execution of the network action.

8. IANA Considerations

This document requests the following allocation from IANA:

Type TBA in the IGP MSD-Types registry is requested to be assigned for the Base MPLS Inspection MSD.

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5340]
Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, , <https://www.rfc-editor.org/info/rfc5340>.
[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, , <https://www.rfc-editor.org/info/rfc7684>.
[RFC7752]
Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, , <https://www.rfc-editor.org/info/rfc7752>.
[RFC7770]
Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, , <https://www.rfc-editor.org/info/rfc7770>.
[RFC7794]
Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, , <https://www.rfc-editor.org/info/rfc7794>.
[RFC7981]
Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, , <https://www.rfc-editor.org/info/rfc7981>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8476]
Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, , <https://www.rfc-editor.org/info/rfc8476>.
[RFC8491]
Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, , <https://www.rfc-editor.org/info/rfc8491>.
[RFC8662]
Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., Shakir, R., and J. Tantsura, "Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels", RFC 8662, DOI 10.17487/RFC8662, , <https://www.rfc-editor.org/info/rfc8662>.
[RFC8814]
Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., and N. Triantafillis, "Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State", RFC 8814, DOI 10.17487/RFC8814, , <https://www.rfc-editor.org/info/rfc8814>.
[RFC9085]
Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, H., and M. Chen, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing", RFC 9085, DOI 10.17487/RFC9085, , <https://www.rfc-editor.org/info/rfc9085>.

9.2. Informative References

[I-D.ietf-mpls-mna-fwk]
Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS Network Actions Framework", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-fwk-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-fwk-02>.
[I-D.ietf-mpls-mna-hdr]
Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K. Kompella, "MPLS Network Action (MNA) Sub-Stack Solution", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-hdr-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-mna-hdr-00>.
[RFC9088]
Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., and M. Bocci, "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS", RFC 9088, DOI 10.17487/RFC9088, , <https://www.rfc-editor.org/info/rfc9088>.
[RFC9089]
Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., and M. Bocci, "Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF", RFC 9089, DOI 10.17487/RFC9089, , <https://www.rfc-editor.org/info/rfc9089>.

Author's Address

Yao Liu
ZTE
Nanjing
China