idnits 2.17.1 draft-ietf-pim-mtid-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5294 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) == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-08 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 26, 2010 Cisco Systems, Inc. 7 October 26, 2009 9 PIM Multi-Topology ID (MT-ID) Join-Attribute 11 draft-ietf-pim-mtid-02.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 April 26, 2010. 36 Copyright Notice 38 Copyright (c) 2009 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 in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document introduces a new type of PIM Join Attribute that 50 extends PIM signaling to identify a topology that should be used when 51 constructing a particular multicast distribution tree. 53 Table of Contents 55 1 Specification of Requirements ...................... 3 56 2 Introduction ....................................... 3 57 3 Functional Overview ................................ 3 58 3.1 PIM RPF Topology ................................... 3 59 3.2 PIM MT-ID .......................................... 4 60 3.3 Applicability ...................................... 4 61 4 Protocol Specification of PIM MT-ID ................ 5 62 4.1 PIM MT-ID Hello Option ............................. 5 63 4.2 PIM MT-ID Join Attribute ........................... 5 64 4.2.1 Sending PIM MT-ID Join Attribute ................... 5 65 4.2.2 Receiving PIM MT-ID Join Attribute ................. 6 66 4.2.3 Validating PIM MT-ID Join Attribute ................ 6 67 4.2.4 Conflict Resolution ................................ 6 68 4.2.4.1 Upstream Routers ................................... 7 69 4.2.4.2 Downstream Routers ................................. 7 70 5 Packet Format ...................................... 8 71 5.1 PIM MT-ID Hello Option ............................. 8 72 5.2 PIM MT-ID Join Attribute TLV Format ................ 8 73 6 IANA Considerations ................................ 9 74 7 Security Considerations ............................ 9 75 8 Acknowledgments .................................... 9 76 9 Authors' Addresses ................................. 9 77 10 Normative References ............................... 10 78 11 Informative References ............................. 10 80 1. Specification of Requirements 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Introduction 88 Some unicast protocols, such as OSPF and IS-IS, allow a single 89 network to be viewed as multiple topologies [RFC4915, RFC5120]. This 90 enables PIM to construct multicast distribution trees using separate 91 network paths even when the roots of the trees are the same. 93 This capability can be used to improve the resilience of multicast 94 applications. For instance, a multicast stream can be duplicated and 95 transported using different network layer addresses simultaneously. 96 Assuming that two source trees, (S1, G1) and (S1, G2), are used for 97 the stream. By using MT capable unicast routing protocols and 98 procedures described in this document, it is possible to construct 99 two source trees for (S1, G1) and (S1, G2) in such a way that they do 100 not share any transit network segment. As a result, a single network 101 failure will not cause any loss to the stream. 103 This draft introduces a new type of PIM Join Attribute used to encode 104 the identity of the topology PIM uses for RPF. It is based on 105 [RFC5384], and specifies additional procedures and rules to process 106 the attribute and resolve conflict. 108 3. Functional Overview 110 3.1. PIM RPF Topology 112 PIM RPF topology is a collection of routes used by PIM to perform RPF 113 operation when building shared or source trees. In the rest of the 114 document, PIM RPF topology may be simply referred to as "topology" 115 when there is no ambiguity. 117 In a multi-topology environment, multiple RPF topologies can be 118 created in the same network. A particular source may be reachable in 119 only one of the topologies, or in several of them via different 120 paths. 122 To select the RPF topology for a particular multicast distribution 123 tree, one or more of the following can be done. 125 1. configure a policy that maps a group range to a topology. When 126 RPF information needs to be resolved for the RP or the sources 127 for a group within the range, the RPF lookup takes place in the 128 specified topology. This can be used for PIM-SM/SSM/Bidir. 130 2. configure a policy that maps a source prefix range to a 131 topology. This can be used for PIM-SM and PIM-SSM. 133 3. use the topology identified by the Join Attribute encoding in 134 the received PIM packets. 136 The details of the first two methods are implementation specific and 137 are not discussed in this document. The specification to support the 138 third method is included in this document. 140 3.2. PIM MT-ID 142 For each PIM RPF topology created, a unique numerical ID is assigned. 143 This ID is called PIM MT-ID. PIM MT-ID has the following property, 145 - this value is not required to be the same as the MT-ID used by 146 the unicast routing protocols that contribute routes to the 147 topology. Although in practice, when only one unicast routing 148 protocol (such as OSPF or IS-IS) is used, PIM MT-ID is typically 149 assigned the same value as the IGP topology identifier. 151 - this value must be unique and consistent within the network 152 domain for the same topology 154 - 0 is reserved as the default, and MUST NOT be included in the 155 join attribute encoding. 157 - how to assign a PIM MT-ID to a topology is decided by the network 158 administrator and is outside the scope of this document 160 3.3. Applicability 162 The PIM MT-ID join attribute described in this draft applies to PIM 163 Join/Assert packets used by PIM SM/SSM/Bidir. It is not used in any 164 other PIM packets, such as Prune, Register, Register-Stop, Graft, 165 Graft-ack, DF Election, Candidate-RP, and Bootstrap. As such, it can 166 only be used to build shared or source trees for PIM SM/SSM and PIM- 167 bidir downstream. 169 When this attribute is used in combination with RPF vectors defined 170 in [RFC5496] [ID.ietf-l3vpn-2547bis-mcast], they are processed 171 against the topology identified by the PIM MT-ID attribute. 173 4. Protocol Specification of PIM MT-ID 175 The change to the PIM protocol includes two pieces, PIM MT-ID Hello 176 Option and PIM MT-ID Join Attribute. 178 4.1. PIM MT-ID Hello Option 180 A router MUST include both PIM MT-ID and PIM Join Attribute Hello 181 Option in its PIM Hello packets if it supports functionality 182 described by this document. 184 4.2. PIM MT-ID Join Attribute 186 4.2.1. Sending PIM MT-ID Join Attribute 188 When a PIM router originates a PIM Join/Assert packet, it may choose 189 to encode PIM MT-ID of the topology in which RPF lookup takes place 190 for the corresponding (*,G) or (S,G) entry. The chosen PIM MT-ID MUST 191 be the one decided by local topology selection configuration if it 192 exists, or the one received from downstream routers after conflict 193 resolution procedures are applied. 195 The following are the exceptions, 197 - a router MUST NOT attach the attribute if PIM MT-ID is 0. The 198 value of 0 is ignored on reception. 200 - a router SHOULD NOT do so if the upstream router, or one of the 201 routers on the LAN does not include "PIM Join Attribute" or "PIM 202 MT-ID" option in its Hello packets. 204 - a router SHOULD NOT encode PIM MT-ID for pruned sources. If 205 encoded, the value is ignored. 207 4.2.2. Receiving PIM MT-ID Join Attribute 209 When a PIM router receives a PIM MT-ID join attribute in a 210 Join/Assert packet, it MUST perform the following, 212 - validate the attribute encoding. The detail is described in the 213 next section. 215 - if the join attribute is valid, use the rules described in the 216 section "Conflict Resolution" to determine a PIM MT-ID to use. 218 - use the topology identified by the selected PIM MT-ID to perform 219 RPF lookup for the (*,G)/(S,G) entry unless a different topology 220 is specified by a local configuration. The local configuration 221 always takes precedence. 223 4.2.3. Validating PIM MT-ID Join Attribute 225 An encoded PIM MT-ID join attribute is valid if all of the following 226 conditions are satisfied, 228 - there is at most 1 PIM MT-ID attribute encoded. If there are 229 multiple PIM MT-ID Join Attributes included, only the last one is 230 accepted. 232 - the length field must be 2 and the value must not be 0. 234 If an encoded PIM MT-ID join attribute is deemed invalid, it is 235 silently ignored. The packet is processed as if the attribute were 236 not present. 238 It is important to note that, if the sender is not a PIM neighbor 239 that has included "PIM Join Attribute" or "PIM MT-ID" option in its 240 Hello packets, the encoding may still be considered valid by an 241 implementation. 243 4.2.4. Conflict Resolution 245 Depending on whether a PIM router is an upstream or a downstream 246 router, the action it takes to resolve conflicting PIM MT-ID 247 attributes differs. The detail is described below. 249 4.2.4.1. Upstream Routers 251 If an upstream router has a local configuration that specifies a 252 different topology than that from an incoming Join/Assert packet, 253 including the case PIM MT-ID is not encoded in the incoming packet, 254 it is not considered a conflict. 256 A conflict occurs when a router doesn't have local topology selection 257 policy and it has received different PIM MT-ID from Join packets sent 258 by its downstream routers or Assert packets from another forwarding 259 router on the LAN. 261 It MUST be noted that the MT-ID value being considered for comparison 262 does not include the four reserved bits. That is, only the lower 263 order 12 bits are used in resolving conflicting attributes. 265 - if an upstream router receives different PIM MT-ID attributes 266 from PIM Join packets, it MUST follow the rules specified in 267 [RFC5384] to select one. The PIM MT-ID chosen will be the one 268 encoded for its upstream neighbor. 270 - if an upstream router receives a different PIM MT-ID attribute in 271 an ASSERT packet, it MUST use the tie-breaker rules as specified 272 in [RFC4601] to determine an ASSERT winner. PIM MT-ID is not 273 considered in deciding a winner from Assert process. 275 4.2.4.2. Downstream Routers 277 A conflict is detected by a downstream router when it sees a 278 different PIM MT-ID attribute from other routers on the LAN, 279 regardless of whether the router has local topology selection policy 280 or not. 282 - if a downstream router sees different PIM MT-ID attributes from 283 PIM Join packets, it MUST follow the specification of [RFC4601] 284 as if the attribute did not exist. For example, the router 285 suppresses its own Join packet if a Join for the same (S,G) is 286 seen. 288 The router MUST NOT use the rules specified in [RFC5384] to 289 select a PIM MT-ID from Join packets sent by other downstream 290 routers. 292 - if a downstream router sees its preferred upstream router loses 293 in the ASSERT process, and the ASSERT winner uses a different PIM 294 MT-ID, the downstream router SHOULD still choose the ASSERT 295 winner as the RPF neighbour but it MUST NOT encode PIM MT-ID when 296 sending Join packets to it. 298 5. Packet Format 300 5.1. PIM MT-ID Hello Option 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | OptionType | OptionLength | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | OptionValue | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 - OptionType: to be assigned by IANA. 312 - OptionLength: 8 314 - OptionValue: There is none specified at this moment. 316 5.2. PIM MT-ID Join Attribute TLV Format 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |F|E| Attr Type | Length |R R R R| Value | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 - F bit: 0 Non-transitive Attribute. 326 - E bit: As specified by [RFC5384] 328 - Attr Type: 3. 330 - Length: 2. 332 - R: Reserved bits, 4 in total. 334 - Value: PIM MT-ID, 1 to 4095. Range 2048 to 4095 are for 335 experimental and proprietary use. 337 6. IANA Considerations 339 A new PIM Hello Option type needs to be assigned. 341 A new PIM Join Attribute type needs to be assigned. 3 is proposed for 342 now. 344 7. Security Considerations 346 As a type of PIM Join Attribute, the security considerations 347 described in [RFC5384] apply here. Specifically, malicious alteration 348 of PIM MT-ID may cause the resiliency goals to be violated. 350 8. Acknowledgments 352 The authors would like to thank Eric Rosen, Ice Wijnands, Dino 353 Farinacci, Colby Barth, Les Ginsberg and Dimitri Papadimitriou for 354 their input. 356 9. Authors' Addresses 358 Yiqun Cai 359 Cisco Systems, Inc 360 170 West Tasman Drive 361 San Jose, CA 95134 363 E-mail: ycai@cisco.com 365 Heidi Ou 366 Cisco Systems, Inc 367 170 West Tasman Drive 368 San Jose, CA 95134 370 E-mail: hou@cisco.com 372 10. Normative References 374 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 375 Requirement Levels", RFC 2119, March 1997. 377 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 378 "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol 379 Specification (Revised)", RFC 4601, August 2006. 381 [RFC5384] A. Boers, I. Wijnands, E. Rosen, "The Protocol Independent 382 Multicast (PIM) Join Attribute Format", RFC 5384, November 2008 384 11. Informative References 386 [RFC4915] P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay- 387 Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007. 389 [RFC5120] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology 390 (MT) Routing in Intermediate System to Intermediate Systems (IS- 391 ISs)", RFC 5120, February 2008. 393 [RFC5496] I. Wijnands, A. Boers, E. Rosen, "The Reverse Path 394 Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 396 [ID.ietf-l3vpn-2547bis-mcast] E. Rosen,R Aggarwal, "Multicast in 397 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-08, March 2009