idnits 2.17.1 draft-rosen-mpls-explicit-null-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2003) is 7436 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) == Unused Reference: 'RFC3032' is defined on line 186, but no explicit reference was found in the text == Unused Reference: 'RFC3270' is defined on line 188, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Eric C. Rosen 2 Internet Draft Cisco Systems, Inc. 3 Expiration Date: June 2004 5 December 2003 7 Removing a Restriction on the use of MPLS Explicit NULL 9 draft-rosen-mpls-explicit-null-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 RFC 3032 defines a reserved label value known as "IPv4 Explicit NULL" 34 and a reserved label value known as "IPv6 Explicit NULL". It states 35 that these label values are only legal at the bottom of the MPLS 36 label stack. This restriction is now removed, so that those label 37 values are legal anywhere in the stack. 39 Contents 41 1 Introduction ......................................... 2 42 2 Detail of Change ..................................... 2 43 3 Reasons for Change ................................... 3 44 4 Acknowledgments ...................................... 5 45 5 References ........................................... 5 46 6 Author's Address ..................................... 5 48 1. Introduction 50 RFC 3032 defines a reserved label value known as "IPv4 Explicit NULL" 51 and a reserved label value known as "IPv6 Explicit NULL". It states 52 that these label values are only legal at the bottom of the MPLS 53 label stack. However, no reason is given for this restriction. 55 It has turned out that in practice there are some situations in which 56 it is useful to send MPLS packets which have Explicit NULL occur 57 other than at that bottom of the label stack. While the intended 58 semantics are obvious enough, the fact that such packets are 59 gratuitously declared by RFC 3032 to be illegal has made it difficult 60 to handle these situations in an interoperable manner. 62 This document updates RFC 3032 by removing the unnecessary 63 restriction, so that the two aforementioned label values are legal 64 anywhere in the label stack. 66 2. Detail of Change 68 RFC 3032 states on page 4: 70 There are several reserved label values: 72 i. A value of 0 represents the "IPv4 Explicit NULL Label". This 73 label value is only legal at the bottom of the label stack. It 74 indicates that the label stack must be popped, and the 75 forwarding of the packet must then be based on the IPv4 header. 77 iii. A value of 2 represents the "IPv6 Explicit NULL Label". This 78 label value is only legal at the bottom of the label stack. 79 It indicates that the label stack must be popped, and the 80 forwarding of the packet must then be based on the IPv6 81 header. 83 Paragraph i is hereby changed to read: 85 i. A value of 0 represents the "IPv4 Explicit NULL Label". This 86 label indicates that the label stack must be popped. If the 87 IPv4 Explicit NULL label was not at the bottom of the label 88 stack, then the forwarding of the packet must then be based on 89 the subsequent label. The IPv4 Explicit NULL label is only 90 legal at the bottom of the label stack if the label stack is 91 immediately followed by an IPv4 header. In this case, the 92 forwarding of the packet must be based on the IPv4 header. 94 Paragraph iii is hereby changed to read: 96 iii. A value of 2 represents the "IPv6 Explicit NULL Label". This 97 label indicates that the label stack must be popped. If the 98 IPv6 Explicit NULL label was not at the bottom of the label 99 stack, then the forwarding of the packet must then be based on 100 the subsequent label. The IPv6 Explicit NULL label is only 101 legal at the bottom of the label stack if the label stack is 102 immediately followed by an IPv6 header. In this case, the 103 forwarding of the packet must be based on the IPv6 header. 105 3. Reasons for Change 107 Restricting Explicit NULL to the bottom of the stack has caused some 108 problems in practice. 110 With this restriction in place, one should not distribute, to a 111 particular label distribution peer, a binding of Explicit NULL to a 112 particular FEC, unless the following condition (call it "Condition 113 L") holds: all MPLS packets received by that peer with an incoming 114 label corresponding to that FEC contain only a single label stack 115 entry. If Explicit NULL is bound to the FEC, but Condition L doesn't 116 hold, the peer is being requested to create illegal packets. None of 117 the MPLS specifications say what the peer is actually supposed to do 118 in this case. This situation is made more troublesome by the facts 119 that, in practice, Condition L rarely holds, and it is not possible 120 in general to determine whether it holds or not. 122 Further, if one is supporting the Pipe Model of RFC3270, there are 123 good reasons to create label stacks in which Explicit NULL is at the 124 top of the label stack, but a non-null label is at the bottom. 126 RFC3270 specifies the procedures for MPLS support of Differentiated 127 Services. In particular, it defines a "Pipe Model", in which 128 (quoting from RFC3270, section 2.6.2): 130 "tunneled packets must convey two meaningful pieces of Diff-Serv 131 information: 133 - the Diff-Serv information which is meaningful to intermediate 134 nodes along the LSP span including the LSP Egress (which we 135 refer to as the 'LSP Diff-Serv Information'). This LSP Diff- 136 Serv Information is not meaningful beyond the LSP Egress: 137 Whether Traffic Conditioning at intermediate nodes on the LSP 138 span affects the LSP Diff-Serv information or not, this updated 139 Diff-Serv information is not considered meaningful beyond the 140 LSP Egress and is ignored. 142 - the Diff-Serv information which is meaningful beyond the LSP 143 Egress (which we refer to as the 'Tunneled Diff-Serv 144 Information'). This information is to be conveyed by the LSP 145 Ingress to the LSP Egress. This Diff-Serv information is not 146 meaningful to the intermediate nodes on the LSP span." 148 When the Pipe Model is in use, it is common practice for the LSP 149 Egress to bind Explicit Null to the tunnel's FEC. The intention is 150 that the LSP Diff-Serv information will be carried in the EXP bits 151 of the Explicit Null label stack entry, and the tunneled Diff-Serv 152 information will be carried in whatever is "below" the Explicit Null 153 label stack entry, i.e., in the IP header DS bits or in the EXP bits 154 of the next entry on the MPLS label stack. 156 Naturally, this practice causes a problem if the Pipe Model LSP is 157 being used to tunnel MPLS packets (i.e., if Condition L does not 158 hold). With strict adherence to RFCs 3031 and 3036, this practice 159 results in an MPLS packet where Explicit NULL is at the top of the 160 label stack, even though it is not the only entry in the label 161 stack. However, RFC 3032 makes this packet illegal. Some 162 implementations simply transmit the illegal packet. Others try to 163 convert it to a legal packet by stripping off the Explicit NULL 164 before transmitting it. However, that breaks the Pipe Model by 165 discarding the LSP Diff-Serv information. 167 Of course the LSP egress is not compelled to bind Explicit NULL to 168 the tunnel's FEC; an ordinary label could be used instead. However, 169 using Explicit NULL enables the egress to determine immediately 170 (i.e., without need for lookup in the Label Information Base) that 171 the further forwarding of the packet is to be determined by whatever 172 is below the label. Avoiding this lookup can have favorable 173 implications on forwarding performance. 175 Removing the restriction that Explicit Null only occur at the bottom 176 of the stack is the simplest way to facilitate the proper operation 177 of the Pipe Model. 179 4. Acknowledgments 181 Thanks to Rahul Aggarwal, Francois LeFaucheur, Yakov Rekhter, and Dan 182 Tappan for their helpful comments. 184 5. References 186 [RFC3032] "MPLS Label Stack Encoding", Rosen, et. al., January 2001 188 [RFC3270] "Multi-Protocol Label Switching (MPLS) Support of 189 Differentiated Services", Le Faucheur, et. al., May 2002 191 6. Author's Address 193 Eric C. Rosen 194 Cisco Systems, Inc. 195 1414 Massachusetts Avenue 196 Boxborough, MA 01719 197 Email: erosen@cisco.com