idnits 2.17.1 draft-venaas-bier-pfm-sd-00.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 -- The document date (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-bier-mld-01 == Outdated reference: A later version (-12) exists of draft-ietf-bier-pim-signaling-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft IJ. Wijnands 4 Intended status: Experimental M. Mishra 5 Expires: April 25, 2019 Cisco Systems, Inc. 6 M. Sivakumar 7 Juniper Networks 8 October 22, 2018 10 PIM Flooding Mechanism and Source Discovery for BIER 11 draft-venaas-bier-pfm-sd-00 13 Abstract 15 PIM Flooding Mechanism and Source Discovery (PFM-SD) is a mechanism 16 for source discovery within a PIM domain. PIM signaling over BIER 17 has been defined, allowing for BIER to interoperate with PIM. This 18 document defines PFM-SD over BIER, such that PFM-SD can be used by 19 PIM in a PIM domain to discover sources that are reachable via BIER. 20 Also, this document provides PFM-SD extensions to discover the BIER 21 ingress router closest to the source. This can be used by BIER 22 overlays, such as PIM signaling over BIER, to determine which router 23 to signal. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 25, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 61 2. PFM over BIER . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. PFM Ingress BIER Router TLV . . . . . . . . . . . . . . . . . 3 63 4. Group Source Holdtime Metric TLV . . . . . . . . . . . . . . 4 64 5. BIER signaling enhancements . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 PIM Flooding Mechanism (PFM) and Source Discovery (SD) [RFC8364] 75 provides a generic flooding mechanism for distributing information 76 throughout a PIM domain. In particular it allows for source 77 discovery. There are various deployment scenarios where PIM and BIER 78 need to co-exist. For instance, consider migration scenarios where a 79 few routers in a PIM domain are upgraded to support BIER. In that 80 case, one may use PIM Signaling Through BIER Core 81 [I-D.ietf-bier-pim-signaling], allowing PIM to build trees passing 82 through the BIER routers. This document defines PFM over BIER. This 83 allows PFM to pass through the BIER routers, allowing PFM to be used 84 in the PIM domain. 86 One challenge with PIM signaling over BIER 87 [I-D.ietf-bier-pim-signaling] is to determine which BIER router is 88 closest to the source. A number of options are discussed in that 89 document. This document provides an alternative solution for 90 discovering which BIER router to signal. It may also be used with 91 other signaling mechanisms such as IGMP/MLD [I-D.ietf-bier-mld]. 92 This is achieved by introducing two new PFM TLVs. When a BIER router 93 forwards a PFM message into BIER, it adds a new TLV specifying the 94 BIER sub-domain, its BFR-ID and its BIER prefix. Also, any Group 95 Source Holdtime TLVs, defined in [RFC8364], are replaced with new 96 TLVs that include the router's cost of reaching the sources. 98 1.1. Conventions Used in This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2. PFM over BIER 106 When a BIER enabled router accepts a PFM message from a PIM neighbor 107 according to [RFC8364], it SHOULD in addition to the forwarding 108 defined in [RFC8364], also send a copy to all BIER routers (an 109 implementation SHOULD allow the set of BIER routers to send PFM 110 messages to, to be configured). 112 When a router receives a BIER encapsulated PFM message, it MUST 113 process the message according to [RFC8364], except there is no 114 requirement for the message to come from a PIM neighbor, and there is 115 no RPF check. The message MUST be forwarded out on the PIM 116 interfaces according to [RFC8364]. It MAY also be BIER forwarded, if 117 the router acts as a border router between BIER domains. 119 3. PFM Ingress BIER Router TLV 121 When a router is forwarding a PFM message into a BIER domain, it MUST 122 add this TLV. If the TLV is already present, all occurrences should 123 be removed. This TLV encodes the BIER prefix, sub-domain ID and BFR- 124 ID of the router. This TLV SHOULD only be present within the BIER 125 domain. When a router receives a PFM message with this TLV, all 126 occurrences of the TLV SHOULD be removed. If the router is 127 forwarding the message into a new BIER domain, it should add a new 128 TLV with its own prefix, sub-domain ID and BFR-ID. A PFM message is 129 expected to have at most one such TLV. A router MUST NOT add more 130 than one such TLV. When forwarding a PFM message, the TLV in the 131 received message MUST be removed from the forwarded message. 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 |0| Type = TBD | Length | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Sub-domain-id | Reserved | BFR-id | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | BFR-prefix (4 or 16 octets) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 0: The Transitive bit is set to 0. 145 Type: Type is TBD. 147 Length: The length of the value in octets. 149 Sub-domain-id: The ID of the sub-domain that this PFM is forwarded 150 into. The length is 1 octet. 152 Reserved: MUST be set to 0, and ignored when received. The length 153 is 1 octet. 155 BFR-id: The BFR-id of the router that added this TLV in the sub- 156 domain specified. The length is 2 octets. 158 BFR-prefix: The BFR-prefix of the router that added this TLV in the 159 sub-domain specified. This length is 4 octets for IPv4 and 16 160 octets for IPv6. 162 4. Group Source Holdtime Metric TLV 164 When a router forwards a PFM message into a BIER domain, it should 165 replace all Group Source Holdtime TLVs defined in [RFC8364] with the 166 Group Source Holdtime Metric TLVs defined here. They are the same, 167 except here we also add metric preference and metric. The metric 168 preference and metric MUST be set to this router's metric and 169 preference to reach the specified source. If the source is not 170 reachable, the TLV MUST be omitted. This TLV is used together with 171 the PFM Ingress BIER Router TLV is used to indicate the ingress 172 router's cost of reaching the source. 174 When a router receives a message containing this TLV, it SHOULD store 175 this information, but it MUST NOT forward these TLVs. If forwarding 176 into another BIER domain, the metric preference and metric MUST be 177 updated with this router's cost of reaching the source. If 178 forwarding into a PIM domain, all the TLVs SHOULD be replaced with 179 Group Source Holdtime TLVs as defined in [RFC8364]. The same 180 information is used, except that the metric preference and metric are 181 left out. One could potentially make use of the metric in a PIM 182 domain as well, but it is not clear whether this is useful, and the 183 PIM routers may not support this TLV. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 |0| Type = TBD | Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Group Address (Encoded-Group format) | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Src Count | Src Holdtime | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Src Address 1 (Encoded-Unicast format) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Metric Preference 1 | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Metric 1 | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Src Address 2 (Encoded-Unicast format) | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Metric Preference 2 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Metric 2 | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | . | 207 | . | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Src Address m (Encoded-Unicast format) | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Metric Preference m | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Metric m | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 0: The Transitive bit is set to 0. 218 Type: Type is TBD. 220 Length: The length of the value in octets. 222 Group Address: The group that sources are to be announced for. The 223 format for this address is given in the Encoded-Group format in 224 [RFC7761]. 226 Src Count: The number of source addresses that are included. 228 Src Holdtime: The Holdtime (in seconds) for the included source(s). 230 Src Address: The source address for the corresponding group. The 231 format for these addresses is given in the Encoded-Unicast address 232 in [RFC7761]. 234 Metric Preference: Preference value assigned to the unicast routing 235 protocol that provided the route to the source. 237 Metric: The unicast routing table metric associated with the route 238 used to reach the source. The metric is in units applicable to 239 the unicast routing protocol used. 241 5. BIER signaling enhancements 243 A BIER border router SHOULD cache all the Group Source Holdtime 244 Metric TLVs it receives, along with the respective PFM Ingress BIER 245 Router TLV. This allows the router to determine which sources are 246 active, and which BIER border router is closest to the source. The 247 sub-domain ID, BFR-id and BFR-prefix in the TLV provide the necessary 248 information for use by signaling mechanisms such as 249 [I-D.ietf-bier-pim-signaling] to signal the preferred ingress router. 250 It may also be used by [I-D.ietf-bier-mld]. IGMP/MLD reports would 251 generally be sent to all BIER routers as it is not known which 252 sources are active and which routers can reach them. But by using 253 the enhancements in this document, a source-specific report can be 254 sent to the router closest to the source. Also a group report might 255 be set to the set of routers that are closest to the sources for that 256 group. This reduces the amount of receiver state on the BIER 257 routers, and also the amount of messages each routers needs to 258 process. 260 6. Security Considerations 262 TBD 264 7. IANA Considerations 266 This document defines two new PFM TLVs that needs to be assigned from 267 the "PIM Flooding Mechanism Message Types" registry. 269 8. References 271 8.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 279 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 280 Multicast - Sparse Mode (PIM-SM): Protocol Specification 281 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 282 2016, . 284 [RFC8364] Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM 285 Flooding Mechanism (PFM) and Source Discovery (SD)", 286 RFC 8364, DOI 10.17487/RFC8364, March 2018, 287 . 289 8.2. Informative References 291 [I-D.ietf-bier-mld] 292 Pfister, P., Wijnands, I., Venaas, S., Wang, C., Zhang, 293 Z., and M. Stenberg, "BIER Ingress Multicast Flow Overlay 294 using Multicast Listener Discovery Protocols", draft-ietf- 295 bier-mld-01 (work in progress), June 2018. 297 [I-D.ietf-bier-pim-signaling] 298 Bidgoli, H., Dolganow, A., Kotalwar, J., Xu, F., mishra, 299 m., and Z. Zhang, "PIM Signaling Through BIER Core", 300 draft-ietf-bier-pim-signaling-04 (work in progress), 301 October 2018. 303 Authors' Addresses 305 Stig Venaas 306 Cisco Systems, Inc. 307 Tasman Drive 308 San Jose CA 95134 309 USA 311 Email: stig@cisco.com 313 IJsbrand Wijnands 314 Cisco Systems, Inc. 315 De kleetlaan 6a 316 Diegem 1831 317 Belgium 319 Email: ice@cisco.com 320 Mankamana Mishra 321 Cisco Systems, Inc. 322 Tasman Drive 323 San Jose CA 95134 324 USA 326 Email: mankamis@cisco.com 328 Mahesh Sivakumar 329 Juniper Networks 330 1133 Innovation Way 331 Sunnyvale CA 94089 332 USA 334 Email: sivakumar.mahesh@gmail.com