idnits 2.17.1 draft-ietf-ccamp-gmpls-egress-control-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 234. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 2004) is 7166 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: 'BCP78' is defined on line 168, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 171, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (ref. 'BCP78') (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (ref. 'BCP79') (Obsoleted by RFC 3979) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (Movaz Networks) 2 Updates: 3473 3 Category: Standards Track 4 Expiration Date: February 2005 6 August 2004 8 GMPLS Signaling Procedure For Egress Control 10 draft-ietf-ccamp-gmpls-egress-control-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than a "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This note clarifies the procedures for the control of the label used 38 on a output/downstream interface of the egress node of a Label 39 Switched Path (LSP). Such control is also known as "Egress Control". 40 Support for Egress Control is implicit in Generalized Multi-Protocol 41 Label Switching (GMPLS) Signaling. This note is a clarification to 42 the specification of GMPLS Signaling and does not modify GMPLS 43 signaling mechanisms and procedures. 45 1. Background 47 The ability to control the label used on the output/downstream 48 interface of an egress node was one of the early requirements for 49 GMPLS. In the initial GMPLS drafts, this was called "Egress 50 Control". As the GMPLS drafts progressed, the ability to control a 51 label on an egress interface was generalized to support control of a 52 label on any interface. This generalization is seen in Section 6 of 53 [RFC3471] and Section 5.1 of [RFC3473]. In generalizing this 54 functionality, the procedures to support control of a label at the 55 egress were also generalized. While the result was intended to cover 56 egress control, this intention is not clear to all. This note 57 reiterates the procedures to cover control of a label used on an 58 egress output/downstream interface. 60 For context, the following is the text from the GMPLS signaling draft 61 dated June 2000: 63 6. Egress Control 65 The LSR at the head-end of an LSP can control the termination of 66 the LSP by using the ERO. To terminate an LSP on a particular 67 outgoing interface of the egress LSR, the head-end may specify the 68 IP address of that interface as the last element in the ERO, 69 provided that that interface has an associated IP address. 71 There are cases where the use of IP address doesn't provide enough 72 information to uniquely identify the egress termination. One case 73 is when the outgoing interface on the egress LSR is a component 74 link of a link bundle. Another case is when it is desirable to 75 "splice" two LSPs together, i.e., where the tail of the first LSP 76 would be "spliced" into the head of the second LSP. This last 77 case is more likely to be used in the non-PSC classes of links. 79 and 81 6.2. Procedures 83 The Egress Label subobject may appear only as the last subobject 84 in the ERO/ER. Appearance of this subobject anywhere else in the 85 ERO/ER is treated as a "Bad strict node" error. 87 During an LSP setup, when a node processing the ERO/RR performs 88 Next Hop selection finds that the second subobject is an Egress 89 Label Subobject, the node uses the information carried in this 90 subobject to determine the handling of the data received over that 91 LSP. Specifically, if the Link ID field of the subobject is non 92 zero, then this field identifies a specific (outgoing) link of the 93 node that should be used for sending all the data received over 94 the LSP. If the Label field of the subobject is not Implicit NULL 95 label, this field specifies the label that should be used as an 96 outgoing label on the data received over the LSP. 98 Procedures by which an LSR at the head-end of an LSP obtains the 99 information needed to construct the Egress Label subobject are 100 outside the scope of this document. 102 2. Egress Control Procedures 104 This section is intended to complement Section 5.1.1 and 5.2.1 of 105 [RFC3473]. The procedures described in those sections are not 106 modified. This section clarifies procedures related to the label 107 used on an egress output/downstream interface. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2.1. ERO Procedures 115 Egress Control occurs when the node processing an ERO is the egress 116 and the ERO contains one or more subobjects related to the 117 output/downstream interface. In this case, the outgoing/downstream 118 interface is indicated in the ERO as the last listed local interface. 119 Note that an interface may be numbered or unnumbered. 121 To support Egress Control, an egress checks to see if the received 122 ERO contains an outgoing/downstream interface. If it does, the type 123 of the subobject or subobjects following the interface are examined. 124 If the associated LSP is unidirectional, one subobject is examined. 125 Two subobjects are examined for bidirectional LSPs. If the U-bit of 126 the subobject being examined is clear (0), then the value of the 127 label MUST be used for transmitting traffic associated with the LSP 128 on the indicated outgoing/downstream interface. 130 If the U-bit of the subobject being examined is set (1), then the 131 value of the label is used for upstream traffic associated with the 132 bidirectional LSP. Specifically, the label value will be used for 133 the traffic associated with the LSP that will be received on the 134 indicated outgoing/downstream interface. 136 Per [RFC3473], any errors encountered while processing the ERO, 137 including if the listed label(s) are not acceptable or cannot be 138 supported in forwarding, SHOULD result in the generation of a PathErr 139 message with the error code "Routing Error" and error value of "Bad 140 Explicit Route Object" toward the sender. 142 2.2. RRO Procedures 144 In the case where an ERO is used to specify outgoing interface 145 information at the egress and label recording is indicated for the 146 LSP, the egress should include the specified interface information 147 and the specified label or labels in the corresponding RRO. 149 3. Security Considerations 151 This note clarifies procedures defined in [RFC3473], but does not 152 define any new procedures. As such, no new security considerations 153 are introduced. 155 4. IANA Considerations 157 None. 159 5. Acknowledgments 161 Valuable comments and input were received from Adrian Farrel, Alan 162 Kullberg, and Dimitri Papadimitriou. 164 6. References 166 6.1. Normative References 168 [BCP78] Bradner, S., "IETF Rights in Contributions", RFC 3667, 169 February 2004. 171 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 172 Technology", RFC 3668, February 2004. 174 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol 175 Label Switching (GMPLS) Signaling Functional 176 Description", RFC 3471, January 2003. 178 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label 179 Switching (GMPLS) Signaling - Resource ReserVation 180 Protocol-Traffic Engineering (RSVP-TE) Extensions", 181 RFC 3473, January 2003. 183 6.2. Informative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels," RFC 2119. 188 7. Author's Address 190 Lou Berger 191 Movaz Networks, Inc. 192 7926 Jones Branch Drive 193 Suite 615 194 McLean VA, 22102 195 Phone: +1 703 847-1801 196 Email: lberger@movaz.com 198 8. Full Copyright Statement 200 Copyright (C) The Internet Society (2004). This document is subject 201 to the rights, licenses and restrictions contained in BCP 78, and 202 except as set forth therein, the authors retain all their rights. 204 This document and the information contained herein are provided on an 205 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 206 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 207 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 208 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 209 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 210 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 212 9. Intellectual Property 214 The IETF takes no position regarding the validity or scope of any 215 Intellectual Property Rights or other rights that might be claimed to 216 pertain to the implementation or use of the technology described in 217 this document or the extent to which any license under such rights 218 might or might not be available; nor does it represent that it has 219 made any independent effort to identify any such rights. Information 220 on the procedures with respect to rights in RFC documents can be 221 found in BCP 78 and BCP 79. 223 Copies of IPR disclosures made to the IETF Secretariat and any 224 assurances of licenses to be made available, or the result of an 225 attempt made to obtain a general license or permission for the use of 226 such proprietary rights by implementers or users of this 227 specification can be obtained from the IETF on-line IPR repository at 228 http://www.ietf.org/ipr. 230 The IETF invites any interested party to bring to its attention any 231 copyrights, patents or patent applications, or other proprietary 232 rights that may cover technology that may be required to implement 233 this standard. Please address the information to the IETF at ietf- 234 ipr@ietf.org. 236 Generated on: Mon Aug 30 16:16:32 2004