idnits 2.17.1 draft-ali-ccamp-rsvp-node-id-based-hello-01.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 3979, Section 5, paragraph 2 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 300. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == It seems as if not all pages are separated by form feeds - found 1 form feeds but 7 pages 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 == Line 115 has weird spacing: '...ated on data ...' -- 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 (April 2004) is 7315 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3209' is mentioned on line 105, but not defined == Missing Reference: 'RFC 3473' is mentioned on line 107, but not defined == Unused Reference: 'RFC2205' is defined on line 202, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 209, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-katz-ward-bfd-01 Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Zafar Ali 3 Reshad Rahman 4 Danny Prairie 5 Cisco Systems 6 D. Papadimitriou 7 Alcatel 8 Internet Draft 9 Category: BCP 10 Expires: October 2004 April 2004 12 Node ID based RSVP Hello: A Clarification Statement 13 draft-ali-ccamp-rsvp-node-id-based-hello-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 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 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Use of node-id based RSVP Hello messages is implied in a number of 38 cases, e.g., when data and control plan are separated, when TE links 39 are unnumbered. Furthermore, when link level failure detection is 40 performed by some means other than RSVP Hellos, use of node-id based 41 Hellos is optimal for detecting signaling adjacency failure for RSVP- 42 TE. Nonetheless, this implied behavior is unclear and this document 43 formalizes use of node-id based RSVP Hello sessions as a best current 44 practice (BCP) in some scenarios. 46 Z. Ali, et al. Page 1 4/16/2004 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 50 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 51 this document are to be interpreted as described in RFC 2119 52 [RFC2119]. 54 Routing Area ID Summary 56 (This section to be removed before publication.) 58 SUMMARY 60 This document clarifies use of node-id based RSVP Hellos. 62 WHERE DOES IT FIT IN THE PICTURE OF THE ROUTING AREA WORK? 64 This work fits in the context of [RFC 3209] and [RFC 3473]. 66 WHY IS IT TARGETED AT THIS WG? 68 This document is targeted at ccamp as it clarifies procedures in 69 [RFC 3209] and [RFC 3473], related to use of RSVP-TE Hello protocol. 71 RELATED REFERENCES 73 Please refer to the reference section. 75 Table of Contents 77 1. Terminology....................................................2 78 2. Introduction...................................................3 79 3. Node-id based RSVP Hellos......................................3 80 4. Backward Compatibility Note....................................4 81 5. Security Considerations........................................4 82 6. Acknowledgements...............................................4 83 7. IANA Considerations............................................5 84 8. Reference......................................................5 85 8.1 Normative Reference........................................5 86 8.2 Informative Reference......................................5 87 9. Author's Addresses.............................................5 89 1. Terminology 91 Node-id: Router-id as advertised in the Router Address TLV for OSPF 92 [OSPF-TE] and Traffic Engineering router ID TLV for ISIS [ISIS-TE]. 94 Z. Ali, et al. Page 2 4/16/2004 95 Node-id based Hello Session: A Hello session such that local and 96 remote node-ids are used in the source and destination fields of the 97 Hello packet, respectively. 99 Interface bounded Hello Session: A Hello session such that local and 100 remote addresses of the interface in question are used in the source 101 and destination fields of the Hello packet, respectively. 103 2. Introduction 105 The RSVP Hello message exchange was introduced in [RFC 3209]. The 106 usage of RSVP Hello has been extended in [RFC 3473] to support RSVP 107 Graceful Restart (GR) procedures. Specifically, [RFC 3473] specifies 108 the use of the RSVP Hellos for GR procedures for Generalized MPLS 109 (GMPLS). GMPLS introduces the notion of control plane and data plane 110 separation. In other words, in GMPLS networks, the control plane 111 information is carried over a control network whose end-points are IP 112 capable, and which may be physically or logically disjoint from the 113 data bearer links it controls. One of the consequences of separation 114 of data bearer links from control channels is that RSVP Hellos are 115 not terminated on data bearer links� interfaces even if (some of) 116 those are numbered. Instead RSVP hellos are terminated at the control 117 channel (IP-capable) end-points. The latter MAY be identified by the 118 value assigned to the node hosting these control channels i.e. Node- 119 Id. Consequently, the use of RSVP Hellos for GR applications 120 introduces a need for clarifying the behavior and usage of node-id 121 based Hellos. 123 Even in the case of packet MPLS, when link failure detection is 124 performed by some means other than RSVP Hellos (e.g., [BFD]), the use 125 of node-id based Hellos is also optimal for detection of signaling 126 adjacency failures for RSVP-TE. Similarly, when all TE links between 127 neighbor nodes are unnumbered, it is implied that the nodes will use 128 node-id based Hellos for detection of signaling adjacency failures. 129 This document also clarifies the use of node-id based Hellos when all 130 or a sub-set of TE links are unnumbered. This draft also clarifies 131 use of node-id based Hellos in these scenarios. 133 3. Node-id based RSVP Hellos 135 A node-id based Hello session is established through the exchange of 136 RSVP Hello messages such that local and remote node-ids are 137 respectively used in the source and destination fields of Hello 138 packets. Here, node-id refers to a router-id as defined in the Router 139 Address TLV for OSPF [OSPF-TE] and the Traffic Engineering router ID 140 TLV for ISIS [ISIS-TE]. This section formalizes a procedure for 141 establishing node-id based Hello sessions. 143 Z. Ali, et al. Page 3 4/16/2004 144 If a node wishes to establish a node-id based RSVP Hello session with 145 its neighbor, it sends a Hello message with its node-id in the source 146 IP address field of the Hello packet. Furthermore, the node also puts 147 the neighbor�s node-id in the destination address field of the IP 148 packet. 150 When a node receives a Hello packet where the destination IP address 151 is its local node-id as advertised in the IGP-TE topology, the node 152 MUST use its node-id in replying to the Hello message. In other 153 words, nodes must ensure that the node-ids used in RSVP Hello 154 messages are those derived/contained in the IGP-TE topology. 155 Furthermore, a node can only run one node-id based RSVP Hello session 156 per IGP instance (i.e., per node-id pair) with its neighbor. 158 In the case of packet MPLS, when link failure detection is performed 159 by some means other than RSVP Hellos, use of node-id based Hellos is 160 also optimal in detecting signaling adjacency failures, e.g., for 161 RSVP GR procedure. Similarly, if all interfaces between a pair of 162 nodes are unnumbered, the optimal way to use RSVP to detect signaling 163 adjacency failure is to run node-id based Hellos. Furthermore, in the 164 case of optical network with single or multiple, numbered or 165 unnumbered control channels, use of node-id based Hellos for 166 detecting signaling adjacency failure is also optimal. Therefore, 167 when link failure detection is performed by some means other than 168 RSVP Hellos, or if all interfaces between a pair of nodes are 169 unnumbered, or in GMPLS network with data and control plane 170 separation, a node MUST run node-id based Hellos for detection of 171 signaling adjacency failure for RSVP-TE. Nonetheless, if it is 172 desirable to distinguish between signaling adjacency and link 173 failures, node id based Hellos can co-exist with interface bound 174 Hellos messages. Similarly, if a pair of nodes share numbered and 175 unnumbered TE links, node id and interface based Hellos can co-exist. 177 4. Backward Compatibility Note 179 The procedure presented in this document is backward compatible with 180 both [RFC3209] and [RFC3473]. 182 5. Security Considerations 184 This document does not introduce new security issues. The security 185 considerations pertaining to the original [RFC3209] remain relevant. 187 6. Acknowledgements 189 Z. Ali, et al. Page 4 4/16/2004 190 We would like to thank Anca Zamfir, Jean-Louis Le Roux, Arthi 191 Ayyangar and Carol Iturralde for their useful comments and 192 suggestions. 194 7. IANA Considerations 196 None. 198 8. Reference 200 8.1 Normative Reference 202 [RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1, 203 Functional Specification", RFC 2205, Braden, et al, September 204 1997. 206 [RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al, 207 RFC 3209, December 2001. 209 [RFC3471] Generalized Multi-Protocol Label Switching (GMPLS) 210 Signaling Functional Description, RFC 3471, L. Berger, et al, 211 January 2003. 213 [RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS) 214 Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP- 215 TE) Extensions", RFC 3473, L. Berger, et al, January 2003. 217 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels", 218 RFC 2119, S. Bradner, March 1997. 220 8.2 Informative Reference 222 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 223 Extensions to OSPF Version 2", RFC 3630. 225 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 226 Engineering", draft-ietf-isis-traffic-05.txt (work in progress). 228 [BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection", 229 draft-katz-ward-bfd-01.txt (work in progress). 231 9. Author's Addresses 233 Zafar Ali 234 Cisco Systems Inc. 235 100 South Main St. #200 236 Ann Arbor, MI 48104, USA. 238 Z. Ali, et al. Page 5 4/16/2004 239 Phone: (734) 276-2459 240 Email: zali@cisco.com 242 Reshad Rahman 243 Cisco Systems Inc. 244 2000 Innovation Dr., 245 Kanata, Ontario, K2K 3E8, Canada. 246 Phone: (613)-254-3519 247 Email: dprairie@cisco.com 249 Danny Prairie 250 Cisco Systems Inc. 251 2000 Innovation Dr., 252 Kanata, Ontario, K2K 3E8, Canada. 253 Phone: (613)-254-3519 254 Email: rrahman@cisco.com 256 Dimitri Papadimitriou (Alcatel) 257 Fr. Wellesplein 1, 258 B-2018 Antwerpen, Belgium 259 Phone: +32 3 240-8491 260 Email: dimitri.papadimitriou@alcatel.be 262 Full Copyright Statement 264 Copyright (C) The Internet Society (2004). This document is subject 265 to the rights, licenses and restrictions contained in BCP 78 and 266 except as set forth therein, the authors retain all their rights. 268 This document and the information contained herein are provided on an 269 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 270 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 271 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 272 IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 273 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 274 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 276 Intellectual Property 278 The IETF takes no position regarding the validity or scope of any 279 Intellectual Property Rights or other rights that might be claimed to 280 pertain to the implementation or use of the technology described in 281 this document or the extent to which any license under such rights 282 might or might not be available; nor does it represent that it has 283 made any independent effort to identify any such rights. Information 285 Z. Ali, et al. Page 6 4/16/2004 286 on the procedures with respect to rights in RFC documents can be 287 found in BCP 78 and BCP 79. 289 Copies of IPR disclosures made to the IETF Secretariat and any 290 assurances of licenses to be made available, or the result of an 291 attempt made to obtain a general license or permission for the use of 292 such proprietary rights by implementers or users of this 293 specification can be obtained from the IETF on-line IPR repository at 294 http://www.ietf.org/ipr. 296 The IETF invites any interested party to bring to its attention any 297 copyrights, patents or patent applications, or other proprietary 298 rights that may cover technology that may be required to implement 299 this standard. Please address the information to the IETF at ietf- 300 ipr@ietf.org. 302 Z. Ali, et al. Page 7 4/16/2004