idnits 2.17.1 draft-cai-pim-mtid-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 384. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 27, 2008) is 5652 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: 'ID.pim-join-attributes' is mentioned on line 294, but not defined ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG Yiqun Cai 3 Internet Draft Heidi Ou 4 Intended Status: Proposed Standard 5 Expires: April 27, 2009 Cisco Systems, Inc. 7 October 27, 2008 9 PIM Multi-Topology ID (MT-ID) Join-Attribute 11 draft-cai-pim-mtid-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 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 Abstract 38 This document introduces a new type of PIM Join Attribute that 39 extends PIM signaling to identify a topology that should be used when 40 constructing a particular multicast distribution tree. 42 Table of Contents 44 1 Specification of Requirements ...................... 2 45 2 Introduction ....................................... 2 46 3 Functional Overview ................................ 3 47 3.1 PIM RPF Topology ................................... 3 48 3.2 PIM MT-ID .......................................... 4 49 3.3 Applicability ...................................... 4 50 4 Protocol Specification of PIM MT-ID ................ 4 51 4.1 Sending PIM MT-ID Join Attribute ................... 4 52 4.2 Receiving PIM MT-ID Join Attribute ................. 5 53 4.3 Validating PIM MT-ID Join Attribute ................ 5 54 4.4 Conflict Resolution ................................ 6 55 4.4.1 Upstream Routers ................................... 6 56 4.4.2 Downstream Routers ................................. 6 57 5 PIM MT-ID Join Attribute TLV Format ................ 7 58 6 IANA Considerations ................................ 7 59 7 Security Considerations ............................ 7 60 8 Acknowledgments .................................... 8 61 9 Authors' Addresses ................................. 8 62 10 Normative References ............................... 8 63 11 Informative References ............................. 9 64 12 Full Copyright Statement ........................... 9 65 13 Intellectual Property .............................. 9 67 1. Specification of Requirements 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in [RFC2119]. 73 2. Introduction 75 Some unicast protocols, such as OSPF and IS-IS, allow a single 76 network to be viewed as multiple topologies [RFC4915, RFC5120]. This 77 enables PIM to construct multicast distribution trees using separate 78 network paths even when the roots of the trees are the same. 80 This capability can be used to improve the resilience of multicast 81 applications. For instance, a multicast stream can be duplicated and 82 transported using different network layer addresses simultaneously. 83 Assuming that two source trees, (S1, G1) and (S1, G2), are used for 84 the stream. By using MT capable unicast routing protocols and 85 procedures described in this document, it is possible to construct 86 two source trees for (S1, G1) and (S1, G2) in such a way that they do 87 not share any transit network segment. As a result, a single network 88 failure will not cause any loss to the stream. 90 This draft introduces a new type of PIM Join Attribute used to encode 91 the identity of the topology PIM uses for RPF. It is based on 92 [ID.ietf-pim-join-attributes], and specifies additional procedures 93 and rules to process the attribute and resolve conflict. 95 3. Functional Overview 97 3.1. PIM RPF Topology 99 PIM RPF topology is a collection of routes used by PIM to perform RPF 100 operation when building shared or source trees. In the rest of the 101 document, PIM RPF topology may be simply referred to as "topology" 102 when there is no ambiguity. 104 In a multi-topology environment, multiple RPF topologies can be 105 created in the same network. A particular source may be reachable in 106 only one of the topologies, or in several of them via different 107 paths. 109 To select the RPF topology for a particular multicast distribution 110 tree, one or more of the following can be done. 112 1. configure a policy that maps a group range to a topology. When 113 RPF information needs to be resolved for the RP or the sources 114 for a group within the range, the RPF lookup takes place in the 115 specified topology. This can be used for PIM-SM/SSM/Bidir. 117 2. configure a policy that maps a source prefix range to a 118 topology. This can be used for PIM-SM and PIM-SSM. 120 3. use the topology identified by the Join Attribute encoding in 121 the received PIM packets. 123 The details of the first two methods are implementation specific and 124 are not discussed in this document. The specification to support the 125 third method is included in this document. 127 3.2. PIM MT-ID 129 For each PIM RPF topology created, a unique numerical ID is assigned. 130 This ID is called PIM MT-ID. PIM MT-ID has the following property, 132 - this value is not required to be the same as the MT-ID used by 133 the unicast routing protocols that contribute routes to the 134 topology. Although in practice, when only one unicast routing 135 protocol (such as OSPF or IS-IS) is used, PIM MT-ID is typically 136 assigned the same value as the IGP topology identifier. 138 - this value must be unique and consistent within the network 139 domain for the same topology 141 - 0 is reserved as the default, and MUST NOT be included in the 142 join attribute encoding. 144 - how to assign a PIM MT-ID to a topology is decided by the network 145 administrator and is outside the scope of this document 147 3.3. Applicability 149 The PIM MT-ID join attribute described in this draft applies to PIM 150 Join/Assert packets used by PIM SM/SSM/Bidir. It is not used in any 151 other PIM packets, such as Prune, Register, Register-Stop, Graft, 152 Graft-ack, DF Election, Candidate-RP, and Bootstrap. As such, it can 153 only be used to build shared or source trees for PIM SM/SSM and PIM- 154 bidir downstream. 156 When this attribute is used in combination with RPF vectors defined 157 in [ID.ietf-pim-rpf-vector] [ID.ietf-l3vpn-2547bis-mcast], they are 158 processed against the topology identified by the PIM MT-ID attribute. 160 4. Protocol Specification of PIM MT-ID 162 4.1. Sending PIM MT-ID Join Attribute 164 When a PIM router originates a PIM Join/Assert packet, it may choose 165 to encode PIM MT-ID of the topology in which RPF lookup takes place 166 for the corresponding (*,G) or (S,G) entry. The chosen PIM MT-ID MUST 167 be the one decided by local topology selection configuration if it 168 exists, or the one received from downstream routers after conflict 169 resolution procedures are applied. 171 The following are the exceptions, 173 - a router MUST NOT attach the attribute if PIM MT-ID is 0. The 174 value of 0 is ignored on reception. 176 - a router SHOULD NOT do so if the upstream router, or one of the 177 routers on the LAN does not include "PIM Join Attribute" option 178 in its Hello packets. 180 - a router SHOULD NOT encode PIM MT-ID for pruned sources. If 181 encoded, the value is ignored. 183 4.2. Receiving PIM MT-ID Join Attribute 185 When a PIM router receives a PIM MT-ID join attribute in a 186 Join/Assert packet, it MUST perform the following, 188 - validate the attribute encoding. The detail is described in the 189 next section. 191 - if the join attribute is valid, use the rules described in the 192 section "Conflict Resolution" to determine a PIM MT-ID to use. 194 - use the topology identified by the selected PIM MT-ID to perform 195 RPF lookup for the (*,G)/(S,G) entry unless a different topology 196 is specified by a local configuration. The local configuration 197 always takes precedence. 199 4.3. Validating PIM MT-ID Join Attribute 201 An encoded PIM MT-ID join attribute is valid if all of the following 202 conditions are satisfied, 204 - there is at most 1 PIM MT-ID attribute encoded. 206 - the length field must be 2 and the value must not be 0. 208 If an encoded PIM MT-ID join attribute is deemed invalid, it is 209 ignored and not forwarded further. The packet is processed as if the 210 attribute were not present. 212 It is important to note that, if the sender is not a PIM neighbor 213 that has included "PIM Join Attribute" option in its Hello packets, 214 or if the "F" bit in the encoding is reset, the encoding may still be 215 considered valid by an implementation and is allowed to be forwarded. 217 4.4. Conflict Resolution 219 Depending on whether a PIM router is an upstream or a downstream 220 router, the action it takes to resolve conflicting PIM MT-ID 221 attributes differs. The detail is described below. 223 4.4.1. Upstream Routers 225 If an upstream router has a local configuration that specifies a 226 different topology than that from an incoming Join/Assert packet, 227 including the case PIM MT-ID is not encoded in the incoming packet, 228 it is not considered a conflict. 230 A conflict occurs when a router doesn't have local topology selection 231 policy and it has received different PIM MT-ID from Join packets sent 232 by its downstream routers or Assert packets from another forwarding 233 router on the LAN. 235 - if an upstream router receives different PIM MT-ID attributes 236 from PIM Join packets, it MUST follow the rules specified in 237 [ID.ietf-pim-join-attributes] to select one. The PIM MT-ID 238 chosen will be the one encoded for its upstream neighbor. 240 - if an upstream router receives a different PIM MT-ID attribute in 241 an ASSERT packet, it MUST use the tie-breaker rules as specified 242 in [RFC4601] to determine an ASSERT winner. PIM MT-ID is not 243 considered in deciding a winner from Assert process. 245 4.4.2. Downstream Routers 247 A conflict is detected by a downstream router when it sees a 248 different PIM MT-ID attribute from other routers on the LAN, 249 regardless of whether the router has local topology selection policy 250 or not. 252 - if a downstream router sees different PIM MT-ID attributes from 253 PIM Join packets, it MUST follow the specification of [RFC4601] 254 as if the attribute did not exist. For example, the router 255 suppresses its own Join packet if a Join for the same (S,G) is 256 seen. 258 The router MUST NOT use the rules specified in [ID.ietf-pim- 259 join-attributes] to select a PIM MT-ID from Join packets sent by 260 other downstream routers. 262 - if a downstream router sees its preferred upstream router loses 263 in the ASSERT process, and the ASSERT winner uses a different PIM 264 MT-ID, the downstream router SHOULD still choose the ASSERT 265 winner as the RPF neighbour but it MUST NOT encode PIM MT-ID when 266 sending Join packets to it. 268 5. PIM MT-ID Join Attribute TLV Format 270 0 1 2 3 271 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |F|E| Attr Type | Length | Value | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 - F bit: 1 Transitive Attribute. 278 - E bit: As specified by [ID.ietf-pim-join-attributes] 280 - Attr Type: 3. 282 - Length: 2. 284 - Value: PIM MT-ID, 1 to 65535. 286 6. IANA Considerations 288 A new PIM Join Attribute type needs to be assigned. 3 is proposed for 289 now. 291 7. Security Considerations 293 As a type of PIM Join Attribute, the security considerations 294 described in [ID.pim-join-attributes] apply here. Specifically, 295 malicious alteration of PIM MT-ID may cause the resiliency goals to 296 be violated. 298 8. Acknowledgments 300 The authors would like to thank Eric Rosen, Ice Wijnands, Dino 301 Farinacci, Colby Barth and Les Ginsberg for their input. 303 9. Authors' Addresses 305 Yiqun Cai 306 Cisco Systems, Inc 307 170 West Tasman Drive 308 San Jose, CA 95134 310 E-mail: ycai@cisco.com 312 Heidi Ou 313 Cisco Systems, Inc 314 170 West Tasman Drive 315 San Jose, CA 95134 317 E-mail: hou@cisco.com 319 10. Normative References 321 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 322 Requirement Levels", RFC 2119, March 1997. 324 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 325 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 326 Specification (Revised)", RFC 4601, August 2006. 328 [ID.ietf-pim-join-attributes] A. Boers, I. Wijnands, E. Rosen, "The 329 PIM Join Attribute Format", draft-ietf-pim-join-attributes. 331 11. Informative References 333 [RFC4915] P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay- 334 Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. 336 [RFC5120] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology 337 (MT) Routing in Intermediate System to Intermediate Systems (IS- 338 ISs)", RFC 5120, February 2008. 340 [ID.ietf-pim-rpf-vector] I. Wijnands, A. Boers, E. Rosen, "The RPF 341 Vector TLV", draft-ietf-pim-rpf-vector. 343 [ID.ietf-l3vpn-2547bis-mcast] E. Rosen,R Aggarwal, "Multicast in 344 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast 346 12. Full Copyright Statement 348 Copyright (C) The IETF Trust (2008). 350 This document is subject to the rights, licenses and restrictions 351 contained in BCP 78, and except as set forth therein, the authors 352 retain all their rights. 354 This document and the information contained herein are provided on an 355 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 356 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 357 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 358 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 359 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 360 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 362 13. Intellectual Property 364 The IETF takes no position regarding the validity or scope of any 365 Intellectual Property Rights or other rights that might be claimed to 366 pertain to the implementation or use of the technology described in 367 this document or the extent to which any license under such rights 368 might or might not be available; nor does it represent that it has 369 made any independent effort to identify any such rights. Information 370 on the procedures with respect to rights in RFC documents can be 371 found in BCP 78 and BCP 79. 373 Copies of IPR disclosures made to the IETF Secretariat and any 374 assurances of licenses to be made available, or the result of an 375 attempt made to obtain a general license or permission for the use of 376 such proprietary rights by implementers or users of this 377 specification can be obtained from the IETF on-line IPR repository at 378 http://www.ietf.org/ipr. 380 The IETF invites any interested party to bring to its attention any 381 copyrights, patents or patent applications, or other proprietary 382 rights that may cover technology that may be required to implement 383 this standard. Please address the information to the IETF at 384 ietf-ipr@ietf.org.