idnits 2.17.1 draft-ietf-pim-mtid-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - the value MUST not be 0. If it is 0, the PIM MT-ID attribute is ignored. Processing of the rest of the Join message, including the current (S,G) or (*,G) entry, continues as if the particular PIM MT-ID attribute weren't present in the packet. -- The document date (January 11, 2011) is 4851 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) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 761 (Obsoleted by RFC 793, RFC 7805) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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: July 11, 2011 Cisco Systems, Inc. 7 January 11, 2011 9 PIM Multi-Topology ID (MT-ID) Join-Attribute 11 draft-ietf-pim-mtid-06.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 11, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Abstract 53 This document introduces a new type of PIM Join Attribute that 54 extends PIM signaling to identify a topology that should be used when 55 constructing a particular multicast distribution tree. 57 Table of Contents 59 1 Specification of Requirements ...................... 3 60 2 Introduction ....................................... 3 61 3 Functional Overview ................................ 3 62 3.1 PIM RPF Topology ................................... 3 63 3.2 PIM MT-ID .......................................... 4 64 3.3 Applicability ...................................... 5 65 4 Protocol Specification of PIM MT-ID ................ 5 66 4.1 PIM MT-ID Hello Option ............................. 5 67 4.2 PIM MT-ID Join Attribute ........................... 5 68 4.2.1 Sending PIM MT-ID Join Attribute ................... 5 69 4.2.2 Receiving PIM MT-ID Join Attribute ................. 6 70 4.2.3 Validating PIM MT-ID Join Attribute ................ 6 71 4.2.4 Conflict Resolution ................................ 7 72 4.2.4.1 Conflict Resolution Rules For Upstream Routers ..... 7 73 4.2.4.2 Conflict Resolution Rules For Downstream Routers ... 8 74 5 Packet Format ...................................... 8 75 5.1 PIM MT-ID Hello Option ............................. 8 76 5.2 PIM MT-ID Join Attribute TLV Format ................ 9 77 6 IANA Considerations ................................ 9 78 7 Security Considerations ............................ 10 79 8 Acknowledgments .................................... 10 80 9 Authors' Addresses ................................. 10 81 10 Normative References ............................... 10 82 11 Informative References ............................. 11 84 1. Specification of Requirements 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Introduction 92 Some unicast protocols, such as OSPF and IS-IS, allow a single 93 network to be viewed as multiple topologies [RFC4915, RFC5120]. This 94 enables PIM to construct multicast distribution trees using separate 95 network paths even when the roots of the trees are the same. 97 This capability can be used to improve the resilience of multicast 98 applications. For instance, a multicast stream can be duplicated and 99 transported using different network layer addresses simultaneously. 100 Assuming that two source trees, (S1, G1) and (S1, G2), are used for 101 the stream. By using MT capable unicast routing protocols and 102 procedures described in this document, it is possible to construct 103 two source trees for (S1, G1) and (S1, G2) in such a way that they do 104 not share any transit network segment. As a result, a single network 105 failure will not cause any loss to the stream. 107 This draft introduces a new type of PIM Join Attribute used to encode 108 the identity of the topology PIM uses for RPF. It is based on 109 [RFC5384], and specifies additional procedures and rules to process 110 the attribute and resolve conflict. The draft does not introduce any 111 change to the RPF check procedure used to verify the incoming 112 interface when a packet is forwarded. As an example to use the 113 capability described by this draft, an application can choose to use 114 group addresses, and/or source addresses, to identify a unique 115 multicast stream. It might further need to perform the functions of 116 splitting and merging. But the detailed processing is beyond the 117 scope of the document. 119 3. Functional Overview 121 3.1. PIM RPF Topology 123 PIM RPF topology is a collection of routes used by PIM to perform RPF 124 operation when building shared or source trees. In the rest of the 125 document, PIM RPF topology may be simply referred to as "topology" 126 when there is no ambiguity. 128 In a multi-topology environment, multiple RPF topologies can be 129 created in the same network. A particular source may be reachable in 130 only one of the topologies, or in several of them via different 131 paths. 133 To select the RPF topology for a particular multicast distribution 134 tree, one or more of the following can be done. 136 1. configure a policy that maps a group range to a topology. When 137 RPF information needs to be resolved for the RP or the sources 138 for a group within the range, the RPF lookup takes place in the 139 specified topology. This can be used for PIM-SM/SSM/Bidir. 141 2. configure a policy that maps a source prefix range to a 142 topology. This can be used for PIM-SM and PIM-SSM. 144 3. use the topology identified by the Join Attribute encoding in 145 the received PIM packets. 147 The details of the first two methods are implementation specific and 148 are not discussed in this document. The specification to support the 149 third method is included in this document. 151 3.2. PIM MT-ID 153 For each PIM RPF topology created, a unique numerical ID is assigned 154 per PIM domain. This ID is called PIM MT-ID. PIM MT-ID has the 155 following property, 157 - it is the path identifier that is used by PIM control plane, but 158 does not function in the forwarding state for a specific 159 topology. The differentiation for topologies on forwarding plane 160 is made by different group addresses, and/or source addresses 161 instead. 163 - this value is not required to be the same as the MT-ID used by 164 the unicast routing protocols that contribute routes to the 165 topology. In practice, when only one unicast routing protocol 166 (such as OSPF or IS-IS) is used, PIM MT-ID is recommended to be 167 assigned using the same value as the IGP topology identifier. 168 This is for the purpose of reducing management overhead and 169 simplifying troubleshooting. 171 - this value must be unique and consistent within the network 172 domain for the same topology. For actual deployment, one should 173 have a means to detect inconsistency of the MT-ID configuration, 174 but the detail of such mechanism is beyond the scope of this 175 document. 177 - 0 is reserved as the default, and MUST NOT be included in the 178 join attribute encoding. 180 - how to assign a PIM MT-ID to a topology is decided by the network 181 administrator and is outside the scope of this document 183 3.3. Applicability 185 The PIM MT-ID join attribute described in this draft applies to PIM 186 Join/Assert packets used by PIM SM/SSM/Bidir. It is not used in any 187 other PIM packets, such as Prune, Register, Register-Stop, Graft, 188 Graft-ack, DF Election, Candidate-RP, and Bootstrap. As such, it can 189 only be used to build shared or source trees for PIM SM/SSM and PIM- 190 bidir downstream. 192 When this attribute is used in combination with RPF vectors defined 193 in [RFC5496] [ID.ietf-l3vpn-2547bis-mcast], they are processed 194 against the topology identified by the PIM MT-ID attribute. 196 4. Protocol Specification of PIM MT-ID 198 The change to the PIM protocol includes two pieces, PIM MT-ID Hello 199 Option and PIM MT-ID Join Attribute. 201 4.1. PIM MT-ID Hello Option 203 A router MUST include both PIM MT-ID and PIM Join Attribute Hello 204 Option in its PIM Hello packets if it supports functionality 205 described by this document. 207 4.2. PIM MT-ID Join Attribute 209 4.2.1. Sending PIM MT-ID Join Attribute 211 When a PIM router originates a PIM Join/Assert packet, it may choose 212 to encode PIM MT-ID of the topology in which RPF lookup takes place 213 for the corresponding (*,G) or (S,G) entry. The chosen PIM MT-ID MUST 214 be the one decided by local topology selection configuration if it 215 exists, or the one received from downstream routers after conflict 216 resolution procedures are applied. 218 The following are the exceptions, 219 - a router MUST NOT attach the attribute if PIM MT-ID is 0. The 220 value of 0 is ignored on reception. 222 - a router SHOULD NOT do so if the upstream router, or any of the 223 routers on the LAN does not include "PIM Join Attribute" or "PIM 224 MT-ID" option in its Hello packets. 226 - a router SHOULD NOT encode PIM MT-ID for pruned sources. If 227 encoded, the value is ignored. 229 4.2.2. Receiving PIM MT-ID Join Attribute 231 When a PIM router receives a PIM MT-ID join attribute in a 232 Join/Assert packet, it MUST perform the following, 234 - validate the attribute encoding. The detail is described in the 235 next section. 237 - if the join attribute is valid, use the rules described in the 238 section "Conflict Resolution" to determine a PIM MT-ID to use. 240 - use the topology identified by the selected PIM MT-ID to perform 241 RPF lookup for the (*,G)/(S,G) entry unless a different topology 242 is specified by a local configuration. The local configuration 243 always takes precedence. 245 4.2.3. Validating PIM MT-ID Join Attribute 247 An upstream router must be known to support this draft in order for a 248 downstream router to include the PIM MT-ID attribute in its Join 249 packets. But an upstream router doesn't need to know if a downstream 250 router supports this draft or not when deciding whether to accept the 251 attribute. Hence, if the Join packet sender doesn't include "PIM Join 252 Attribute" or "PIM MT-ID" options in its Hello packets, the PIM MT-ID 253 attribute in the Join may still be considered valid. This is also in 254 accordance with the "Robustness Principle" outlined in [RFC761]. 256 The following text specifies the detail of the validity check. 258 - there is at most 1 PIM MT-ID attribute encoded. If there are 259 multiple PIM MT-ID Join Attributes included, only the last one is 260 accepted for this particular source. Processing of the rest of 261 the Join message continues. 263 - the length field must be 2. If the length field is not 2, the 264 rest of the Join message, including the current (S,G) or (*,G) 265 entry, MUST be ignored. The group, source and the RP in the Join 266 message that have already been processed SHOULD still be 267 considered valid. 269 - the value MUST not be 0. If it is 0, the PIM MT-ID attribute is 270 ignored. Processing of the rest of the Join message, including 271 the current (S,G) or (*,G) entry, continues as if the particular 272 PIM MT-ID attribute weren't present in the packet. 274 4.2.4. Conflict Resolution 276 The definition of "PIM MT-ID conflict" varies depending on whether it 277 is on an upstream or a downstream router. 279 On an upstream router, a conflict occurs when the router doesn't have 280 local topology selection policy and it has received different PIM 281 MT-ID from Join packets sent by its downstream routers or Assert 282 packets from another forwarding router on the LAN. In another word, 283 if an upstream router has a local configuration that specifies a 284 different topology than that from an incoming Join/Assert packet, 285 including the case PIM MT-ID is not encoded in the incoming packet, 286 it does not apply the conflict resolution procedures. 288 On the other hand,when a downstream router sees a different PIM MT-ID 289 attribute from other routers on the LAN it applies rules to resolve 290 the conflicts regardless of whether the router has local topology 291 selection policy or not. 293 It MUST be noted that the MT-ID value being considered for comparison 294 does not include the four reserved bits. That is, only the lower 295 order 12 bits are used in resolving conflicting attributes. 297 4.2.4.1. Conflict Resolution Rules For Upstream Routers 299 - if an upstream router receives different PIM MT-ID attributes 300 from PIM Join packets, it MUST follow the rules specified in 301 [RFC5384] to select one. The PIM MT-ID chosen will be the one 302 encoded for its upstream neighbor. 304 In order to minimize the chances of potential transient 305 forwarding loops, an upstream router MAY choose to ignore the 306 incoming PIM Join/Prune packets all together if it sees a 307 conflict in PIM MT-ID attributes. This action may also be taken 308 by an upstream router which has locally configured topology 309 selection policy, as an exception to the rules described above. 311 - if an upstream router receives a different PIM MT-ID attribute in 312 an ASSERT packet, it MUST use the tie-breaker rules as specified 313 in [RFC4601] to determine an ASSERT winner. PIM MT-ID is not 314 considered in deciding a winner from Assert process. 316 4.2.4.2. Conflict Resolution Rules For Downstream Routers 318 - if a downstream router sees different PIM MT-ID attributes from 319 PIM Join packets, it MUST follow the specification of [RFC4601] 320 as if the attribute did not exist. For example, the router 321 suppresses its own Join packet if a Join for the same (S,G) is 322 seen. 324 The router MUST NOT use the rules specified in [RFC5384] to 325 select a PIM MT-ID from Join packets sent by other downstream 326 routers. 328 - if a downstream router sees its preferred upstream router loses 329 in the ASSERT process, and the ASSERT winner uses a different PIM 330 MT-ID, the downstream router SHOULD still choose the ASSERT 331 winner as the RPF neighbour but it MUST NOT encode PIM MT-ID when 332 sending Join packets to it. 334 5. Packet Format 336 5.1. PIM MT-ID Hello Option 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | OptionType | OptionLength | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | OptionValue | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 - OptionType: 30. 348 - OptionLength: 8. 350 - OptionValue: There is none specified at this moment. 352 5.2. PIM MT-ID Join Attribute TLV Format 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |F|E| Attr Type | Length |R R R R| Value | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 - F bit: 0 Non-transitive Attribute. 362 - E bit: As specified by [RFC5384]. 364 - Attr Type: 3. 366 - Length: 2. 368 - R: Reserved bits, 4 in total. 370 - Value: PIM MT-ID, 1 to 4095. Range 2048 to 4095 are for 371 experimental and proprietary use. 373 6. IANA Considerations 375 A new PIM Hello Option type, 30, has been assigned for PIM MT-ID 376 Hello Option. The detail is in [HELLO]. 378 A new PIM Join Attribute type needs to be assigned. 3 is proposed for 379 now. 381 7. Security Considerations 383 As a type of PIM Join Attribute, the security considerations 384 described in [RFC5384] apply here. Specifically, malicious alteration 385 of PIM MT-ID may cause the resiliency goals to be violated. 387 8. Acknowledgments 389 The authors would like to thank Eric Rosen, Ice Wijnands, Dino 390 Farinacci, Colby Barth, Les Ginsberg, Dimitri Papadimitriou, Thomas 391 Morin and Hui Liu for their input. 393 9. Authors' Addresses 395 Yiqun Cai 396 Cisco Systems, Inc 397 170 West Tasman Drive 398 San Jose, CA 95134 400 E-mail: ycai@cisco.com 402 Heidi Ou 403 Cisco Systems, Inc 404 170 West Tasman Drive 405 San Jose, CA 95134 407 E-mail: hou@cisco.com 409 10. Normative References 411 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 412 Requirement Levels", RFC 2119, March 1997. 414 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 415 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 416 Specification (Revised)", RFC 4601, August 2006. 418 [RFC5384] A. Boers, I. Wijnands, E. Rosen, "The Protocol Independent 419 Multicast (PIM) Join Attribute Format", RFC 5384, November 2008 421 11. Informative References 423 [RFC761] ISI, "Transmission Control Protocol", RFC 761, January 1980. 425 [RFC4915] P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay- 426 Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. 428 [RFC5120] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology 429 (MT) Routing in Intermediate System to Intermediate Systems (IS- 430 ISs)", RFC 5120, February 2008. 432 [RFC5496] I. Wijnands, A. Boers, E. Rosen, "The Reverse Path 433 Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 435 [HELLO] IANA, "PIM-Hello Options", 436 http://www.iana.org/assignments/pim-parameters/pim- 437 parameters.xhtml#pim-parameters-1 439 [ID.ietf-l3vpn-2547bis-mcast] E. Rosen,R Aggarwal, "Multicast in 440 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10, January 2010