idnits 2.17.1 draft-zzhang-idr-tunnel-encapsulation-label-stack-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC9012]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 59: '...g in the sub-TLV MUST be pushed onto t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 07, 2021) is 1021 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 idr Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track July 07, 2021 5 Expires: January 8, 2022 7 MPLS Label Stacks in Tunnel Encapsulation Attribute 8 draft-zzhang-idr-tunnel-encapsulation-label-stack-00 10 Abstract 12 [RFC9012] defines an MPLS Label Stack sub-TLV for Tunnel 13 Encapsulation Attribute, and specifies that it is to be pushed BEFORE 14 other labels. This document clarifies the use case for that, and 15 defines a new Tunnel Label Stack sub-TLV for a label stack to be 16 pushed AFTER other labels (e.g., the label embedded in the NLRI for a 17 labeled address family, and/or the stack in an MPLS Label Stack sub- 18 TLV). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 8, 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 [RFC9012] defines an MPLS Label Stack sub-TLV for Tunnel 55 Encapsulation Attribute and specifies that: 57 "If a packet is to be sent through the tunnel identified in a 58 particular TLV, and if that TLV contains an MPLS Label Stack sub-TLV, 59 then the label stack appearing in the sub-TLV MUST be pushed onto the 60 packet before any other labels are pushed onto the packet." 62 Specifically, the label stack in the sub-TLV is to be pushed BEFORE 63 any other labels are pushed. This may sound counter-intuitive, in 64 that if a label stack (e.g. for Segment Routing) is to be used to 65 steer traffic to the tunnel endpoint, the stack should be pushed 66 AFTER other labels (e.g. the label embedded in the NLRI). 68 This document clarifies that it is NOT for steering traffic to but 69 for steering AFTER the tunnel endpoint. Consider the following use 70 case: 72 controller 73 . . 74 . . 75 site1 --- PE1 -------- PE2 --- site2 77 Two sites are connected to two PEs respectively, and traffic steering 78 is desired within each site not just among the PEs. While PE2 could 79 push the label stack used for steering withing site2, there may be 80 situations where PE2 is not a device capable of pushing a large label 81 stack so PE1 is tasked with pushing the label stack that is used 82 after the tunnel end point PE2, within site2. 84 2. Tunnel Label Stack sub-TLV 86 Notice that in the above example, the route update that PE1 receives 87 could be from the controller instead of PE2. The controller may want 88 to steer traffic both withing site2 and between PE1 and PE2, yet 89 RFC9012 currently does not specify how to signal the label stack used 90 to reach the tunnel end point. 92 To be able to signal that, this document defines a new Tunnel Label 93 Stack sub-TLV. It has exactly the same syntax as the existing MPLS 94 Label Stack sub-TLV, but with a semantics that it is pushed AFTER 95 other labels are pushed. 97 3. Security Considerations 99 This document does not introduce any new security issues besides what 100 is already discussed in RFC9012. 102 4. IANA Assignments 104 IANA is requested to assign a new sub-TLV type for "Tunnel Label 105 Stack" from "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, 106 in the 0~127 range. 108 5. Acknowledgements 110 The authors thank Eric Rosen and John Scudder for their valuable 111 comments and suggestions. 113 6. Normative References 115 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 116 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 117 DOI 10.17487/RFC9012, April 2021, 118 . 120 Author's Address 122 Zhaohui Zhang 123 Juniper Networks 125 Email: zzhang@juniper.net