idnits 2.17.1 draft-ietf-ccamp-rsvp-node-id-based-hello-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 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 292. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 308), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (March 2006) is 6610 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) == Missing Reference: 'OSPFv3-TE' is mentioned on line 120, but not defined == Missing Reference: 'IS-ISv6-TE' is mentioned on line 121, but not defined == Missing Reference: 'RFC 3209' is mentioned on line 164, but not defined == Missing Reference: 'RFC 3473' is mentioned on line 173, but not defined == Unused Reference: 'RFC2205' is defined on line 201, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 214, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 223, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 226, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 3784 (ref. 'ISIS-TE') (Obsoleted by RFC 5305) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Zafar Ali 2 Internet Draft Reshad Rahman 3 Category: Proposed Standard Danny Prairie 4 Expires: September 2006 Cisco Systems 5 D. Papadimitriou 6 Alcatel 8 March 2006 10 Node ID based RSVP Hello: A Clarification Statement 12 draft-ietf-ccamp-rsvp-node-id-based-hello-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). All Rights Reserved. 40 Abstract 42 Use of Node-ID based RSVP Hello messages is implied in a number of 43 cases, e.g., when data and control plan are separated, and when TE links 44 are unnumbered. Nonetheless, this implied behavior is unclear 45 and this document formalizes use of Node-ID based RSVP Hello session 46 in some scenarios. The procedure described in this document applies 47 to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS 48 (GMPLS) capable nodes. 50 When link level failure detection is performed by some means other 51 than exchanging RSVP Hello messages, use of Node-ID based Hello 52 session is optimal for detecting signaling adjacency failure for 53 Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). The use 54 of Node-ID based Hello session is optimal in the sense that as long as 55 there is IP reachability to the nieghbor (node-id), the signalling 56 adjacency will remain up. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 [RFC2119]. 64 1. Terminology 66 Node-ID: TE Router ID as advertised in the Router Address TLV for 67 OSPF [OSPF-TE] and Traffic Engineering Router ID TLV for ISIS [ISIS- 68 TE]. For IPv6, the Node-ID refers to the Router_IPv6_Address for 69 OSPFv3 [OSPFv3-TE] and the IPv6 TE Router_ID for IS-IS [IS-ISv6-TE]. 71 Node-ID based Hello Session: A Hello session such that local and 72 remote Node-IDs are used in the source and destination fields of the 73 Hello packet, respectively. 75 Interface bounded Hello Session: A Hello session such that local and 76 remote addresses of the interface in question are used in the source 77 and destination fields of the Hello packet, respectively. 79 2. Introduction 81 The RSVP Hello message exchange was introduced in [RFC 3209]. The 82 usage of RSVP Hello has been extended in [RFC 3473] to support RSVP 83 Graceful Restart (GR) procedures. 85 More specifically, [RFC 3473] specifies the use of the RSVP Hello 86 messages for GR procedures for Generalized MPLS (GMPLS). GMPLS 87 introduces the notion of control plane and data plane separation. In 88 other words, in GMPLS networks, the control plane information is 89 carried over a control network whose end-points are IP capable, and 90 which may be physically or logically disjoint from the data bearer 91 links it controls. One of the consequences of separation of data 92 bearer links from control channels is that RSVP Hello messages are 93 not terminated on data bearer links' interfaces even if (some of) 94 those are numbered. Instead RSVP Hello messages are terminated at the 95 control channel (IP-capable) end-points. The latter MAY be identified 96 by the value assigned to the node hosting these control channels i.e. 97 Node-ID. Consequently, the use of RSVP Hello messages for GR 98 applications introduces a need for clarifying the behavior and usage 99 of Node-ID based Hello sessions. 101 Even in the case of packet switching capable end-points, when link 102 failure detection is performed by some means other than RSVP Hello 103 messages (e.g., [BFD]), the use of Node-ID based Hello sessions is 104 also optimal for detection of signaling adjacency failures for GMPLS- 105 /RSVP-TE when there is more than one link between a pair of nodes. 106 Similarly, when all TE links between neighbor nodes are unnumbered, 107 it is implied that the nodes will exchange Node-ID based Hello 108 messages for detection of signaling adjacency failures. This document 109 also clarifies the use of Node-ID based Hello message exchanges when 110 all or a sub-set of TE links are unnumbered. 112 3. Node-ID based RSVP Hello Messages 114 A Node-ID based Hello session is established through the exchange of 115 RSVP Hello messages such that local and remote Node-IDs are 116 respectively used in the source and destination fields of Hello 117 packets. Here, Node-ID refers for IPv4 to the TE router-id as defined 118 in the Router Address TLV for OSPF [OSPF-TE] and the Traffic 119 Engineering router ID TLV for ISIS [ISIS-TE]. For IPv6, the Node-ID 120 refers to the Router_IPv6_Address for OSPFv3 [OSPFv3-TE] and the IPv6 121 TE Router_ID for IS-IS [IS-ISv6-TE]. This section formalizes a 122 procedure for establishing Node-ID based Hello sessions. 124 If a node wishes to establish a Node-ID based RSVP Hello session with 125 its neighbor, it sends a Hello message with its Node-ID in the source 126 IP address field of the Hello packet. Furthermore, the node also puts 127 the neighbor's Node-ID in the destination address field of the IP 128 packet. 130 When a node receives a Hello packet where the destination IP address 131 is its local Node-ID as advertised in the IGP-TE topology, the node 132 MUST use its Node-ID in replying to the Hello message. In other 133 words, nodes MUST ensure that the Node-IDs used in RSVP Hello 134 messages are those derived/contained in the IGP-TE topology. 135 Furthermore, a node can only run one Node-ID based RSVP Hello session 136 per IGP instance (i.e., per Node-ID pair) with its neighbor. 138 Even in the case of packet switching capable end-points, when link 139 failure detection is performed by some means other than exchanging 140 RSVP Hello messages, use of Node-ID based Hello sessions is also 141 optimal in detecting signaling adjacency failures for GMPLS-/RSVP-TE 142 when there is more than one link between a pair of nodes. Similarly, 143 if all interfaces between a pair of nodes are unnumbered, the optimal 144 way to use RSVP to detect signaling adjacency failure is to run Node- 145 ID based Hello sessions. Furthermore, in the case of optical network 146 with single or multiple, numbered or unnumbered control channels, use 147 of Node-ID based Hello messages for detecting signaling adjacency 148 failure is also optimal. Therefore, when link failure detection is 149 performed by some means other than exchanging RSVP Hello messages, or 150 if all interfaces between a pair of nodes are unnumbered, or in GMPLS 151 network with data and control plane separation, a node MUST run Node- 152 ID based Hello sessions for detection of signaling adjacency failure 153 for RSVP-TE. Nonetheless, if it is desirable to distinguish between 154 signaling adjacency and link failures, Node-ID based Hello sessions 155 can co-exist with the exchange of interface bound Hellos messages. 156 Similarly, if a pair of nodes share numbered and unnumbered TE links, 157 Node-ID and interface based Hello sessions can co-exist. 159 4. Backward Compatibility Note 161 The procedure presented in this document is backward compatible with 162 both [RFC3209] and [RFC3473]. 164 Per [RFC 3209], the Hello mechanism is intended for use between 165 immediate neighbors and Hello messages are by default sent between 166 direct RSVP neighbors. This document does not modify this behavior as 167 it uses as "local node_id" the IPv4/IPv6 source address of the 168 sending node and as "remote node_id" the IPv4/IPv6 destination 169 address of the neighbor node. TTL/Hop Limit setting and processing 170 are also left unchanged. 172 Moreover, this document does not modify the use of Hello Processing 173 for State Recovery as defined in Section 9.3 of [RFC 3473] (including 174 definition and processing of the RESTART_CAP object). 176 5. Security Considerations 178 As this document does not modify or extend the RSVP Hello messages 179 exchange between immediate RSVP neighbors, it does not introduce new 180 security considerations. 182 The security considerations pertaining to the original [RFC3209] 183 remain relevant. RSVP message security is described in [RFC2747] and 184 provides Hello message integrity and authentication of the Node-ID 185 ownership. 187 6. Acknowledgements 189 We would like to thank Anca Zamfir, Jean-Louis Le Roux, Arthi 190 Ayyangar and Carol Iturralde for their useful comments and 191 suggestions. 193 7. IANA Considerations 195 This draft makes no requests for IANA action. 197 8. Reference 199 8.1 Normative Reference 201 [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) 202 - Version 1, Functional Specification", RFC 2205, 203 September 1997. 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels," BCP 14, RFC 2119, March 1997. 208 [RFC2747] Baker, F., Lindell B., and Talwar, M., "RSVP 209 Cryptographic Authentication", RFC 2747, January 2000. 211 [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP 212 Tunnels", RFC 3209, December 2001. 214 [RFC3471] Berger, L., et al., Generalized Multi-Protocol Label 215 Switching (GMPLS) Signaling Functional Description, RFC 216 3471, January 2003. 218 [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label 219 Switching (GMPLS) Signaling Resource ReserVation 220 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 221 3473, January 2003. 223 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 224 3667, February 2004. 226 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 227 Technology", BCP 79, RFC 3668, February 2004. 229 8.2 Informative Reference 231 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 232 Extensions to OSPF Version 2", RFC 3630, September 2003. 234 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 235 Engineering", RFC 3784, June 2004. 237 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding 238 Detection", draft-katz-ward-bfd, work in progress. 240 9. Author's Addresses 242 Zafar Ali 243 Cisco Systems Inc. 245 100 South Main St. #200 246 Ann Arbor, MI 48104, USA. 247 Phone: (734) 276-2459 248 Email: zali@cisco.com 250 Reshad Rahman 251 Cisco Systems Inc. 252 2000 Innovation Dr., 253 Kanata, Ontario, K2K 3E8, Canada. 254 Phone: (613)-254-3519 255 Email: rrahman@cisco.com 257 Danny Prairie 258 Cisco Systems Inc. 259 2000 Innovation Dr., 260 Kanata, Ontario, K2K 3E8, Canada. 261 Phone: (613)-254-3519 262 Email: dprairie@cisco.com 264 Dimitri Papadimitriou (Alcatel) 265 Fr. Wellesplein 1, 266 B-2018 Antwerpen, Belgium 267 Phone: +32 3 240-8491 268 Email: dimitri.papadimitriou@alcatel.be 270 Intellectual Property Statement 272 The IETF takes no position regarding the validity or scope of any 273 Intellectual Property Rights or other rights that might be claimed to 274 pertain to the implementation or use of the technology described in 275 this document or the extent to which any license under such rights 276 might or might not be available; nor does it represent that it has 277 made any independent effort to identify any such rights. Information 278 on the procedures with respect to rights in RFC documents can be 279 found in BCP 78 and BCP 79. 281 Copies of IPR disclosures made to the IETF Secretariat and any 282 assurances of licenses to be made available, or the result of an 283 attempt made to obtain a general license or permission for the use of 284 such proprietary rights by implementers or users of this 285 specification can be obtained from the IETF on-line IPR repository at 286 http://www.ietf.org/ipr. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights that may cover technology that may be required to implement 291 this standard. Please address the information to the IETF at 292 ietf-ipr@ietf.org. 294 Disclaimer of Validity 296 This document and the information contained herein are provided on an 297 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 298 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 299 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 300 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 301 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 302 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 304 Copyright Statement 306 Copyright (C) The Internet Society (2006). This document is subject 307 to the rights, licenses and restrictions contained in BCP 78, and 308 except as set forth therein, the authors retain all their rights. 310 Acknowledgment 312 Funding for the RFC Editor function is currently provided by the 313 Internet Society.