idnits 2.17.00 (12 Aug 2021) /tmp/idnits20304/draft-ietf-idmr-bgp-mcast-attr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 99 lines == It seems as if not all pages are separated by form feeds - found 6 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MBGP], [BGP-4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (August 1999) is 8308 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: 'PIM-DM' is mentioned on line 79, but not defined == Missing Reference: 'PIM-SM' is mentioned on line 247, but not defined == Missing Reference: 'BGMP' is mentioned on line 247, but not defined == Unused Reference: 'MOSPF' is defined on line 279, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-4' ** Obsolete normative reference: RFC 2283 (ref. 'MBGP') (Obsoleted by RFC 2858) -- Possible downref: Non-RFC (?) normative reference: ref. 'DVMRP' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'MOSPF') ** Obsolete normative reference: RFC 2362 (ref. 'PIMSM') (Obsoleted by RFC 4601, RFC 5059) ** Downref: Normative reference to an Historic RFC: RFC 2189 (ref. 'CBT') -- Possible downref: Non-RFC (?) normative reference: ref. 'PIMDM' == Outdated reference: A later version (-01) exists of draft-ietf-mboned-mix-00 -- Possible downref: Normative reference to a draft: ref. 'MIX' Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDMR Working Group Dave Thaler 3 Internet Engineering Task Force Microsoft 4 INTERNET-DRAFT Brad Cain 5 26 February 1999 Nortel Networks 6 Expires August 1999 8 BGP Attributes for Multicast Tree Construction 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, and 18 its Working Groups. Note that other groups may also distribute working 19 documents as Internet Drafts. 21 Internet Drafts are valid for a maximum of six months and may be 22 updated, replaced, or obsoleted by other documents at any time. It is 23 inappropriate to use Internet Drafts as reference material or to cite 24 them other than as a "work in progress". 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (1999). All Rights Reserved. 33 Abstract 35 The Multiprotocol Extensions for BGP-4 [MBGP] allow Network Layer 36 Reachability Information to contain prefixes used for multicast 37 forwarding. This document defines extensions to BGP-4 [BGP-4] which can 38 be used to annotate such prefixes with information that can be used by 39 multicast routing protocols when constructing trees. 41 Copyright Notice 43 Copyright (C) The Internet Society (1999). All Rights Reserved. 45 1. Introduction 47 The Multiprotocol Extensions for BGP-4 [MBGP] allow Network Layer 48 Reachability Information to contain prefixes used for multicast 49 forwarding. These prefixes may be "come-from" unicast prefixes or 50 multicast "go-to" prefixes (i.e. Class-D addresses). Multicast routing 51 protocols use these prefixes to construct multicast distribution trees. 53 We describe two BGP path attributes that may be used with prefixes used 54 for multicast forwarding. The Forwarder Preference attribute is used by 55 BGP speakers to elect a single forwarder on a multi-access link. The 56 Data Flow Direction attribute describes the "directional" nature of the 57 multicast tree for a given prefix. It may be used by multicast routing 58 protocols which have the ability to construct multiple tree types 59 (unidirectional and bidirectional trees), or to limit which routes can 60 be used by multicast routing protocols which can only construct a single 61 tree type. 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [RFC2119]. 67 2. Forwarder Preference - FWDR_PREF (Type Code XXX): 69 In the case of a multi-access data link layer, multicast packets are 70 sent natively on the link, and require special handling. Specifically, 71 when packets are multicast natively on the link, each packet must only 72 be sent onto the link by a single router, or duplicates will result. 74 In order to reduce the number of duplicates sent on multi-access links, 75 current multicast routing protocols elect a designated forwarder per 76 route or use a data-driven "assert" mechanism. Some protocols (e.g. 77 DVMRP [DVMRP]) elect a designated forwarder per route. A multicast tree 78 branch using that route then uses the designated forwarder on the 79 multi-access link. Other protocols [PIM-DM,PIM-SM] use data-driven 80 mechanisms since they may use route exchange protocols which do not 81 Draft Multicast BGP Attributes February 1999 83 elect a designated forwarder, and run over links with multiple route 84 exchange protocols. However, this mechanism has the disadvantage of 85 periodically generating short bursts of duplicates. 87 The forwarder preference attribute is for multicast routing protocols 88 which use multi-protocol BGP for route selection. This attribute allows 89 a designated forwarder to be elected on a multi-access link. Designated 90 forwarder election only works, however, when full-peering exists on the 91 multi-access link, but this is indeed the case on multicast friendly 92 interconnects [MIX] today. Operation over multi-access links in the 93 absense of full-peering is outside the scope of this document. 95 2.1. FWDR_PREF Details 97 FWDR_PREF is an optional non-transitive attribute for the purpose of 98 electing a single designated forwarder on a multi-access link. 99 FWDR_PREF is used to inform other BGP speakers on the same link of the 100 originating speaker's degree of preference for an advertised route for 101 the purpose of electing a single designated forwarder on a multi-access 102 link. FWDR_PREF is a four-octet non-negative integer with type code of 103 XXX. 105 A BGP speaker MUST include the same FWDR_PREF value on a given route 106 when advertising it to each peer on the same multi-access link. 108 To calculate the designated forwarder for a given route, the higher 109 degree of preference is preferred. 111 3. Data Flow Direction - DIRECTION (Type Code XXX): 113 Multicast routing protocols use a multicast-RIB to construct multicast 114 forwarding trees. Multicast trees may be either uni-directional or bi- 115 directional, source rooted or core rooted. Some multicast routing 116 protocols [PIM-SM,BGMP] can build multiple tree types. The data flow 117 direction attribute may be used to tag a route with a direction for 118 which data is allowed to flow. This may be used for special links (e.g. 119 satellite), or for enforcing policy. The data flow direction attribute 120 is ONLY a route policy attribute. Its use is limited by the multicast 121 routing protocol in use. 123 Uni-directional trees provide aggressive loop prevention using a Reverse 124 Path Forwarding (RPF) check mechanism whereby a specific incoming 125 interface is chosen to accept packets from a destination. Uni- 126 Draft Multicast BGP Attributes February 1999 128 directional trees may provide a coarse grain policy whereby senders may 129 be restricted to only coming from the correct RPF direction. For 130 protocols which support multiple tree types, the data flow direction 131 attribute may be used for tagging a route as uni-directional. This 132 uni-directional route may be used for unidirectional shared trees (i.e. 133 G-RIB route attribute) or for restrictions for non-member senders. 135 High bandwidth, unidirectional transmission to low cost, receiver-only 136 hardware is becoming an emerging network fabric, e.g. broadcast 137 satellite links or some cable links. Such links can result in 138 bidirectional islands connected via unidirectional links. One common 139 solution to preserving dynamic routing is to add a layer between the 140 network interface and the routing software to emulate bi-directional 141 links through tunnels. However, this can result in non-optimal routing, 142 especially since some routing protocols use forward-paths, while others 143 use reverse-paths. 145 3.1. DIRECTION Details 147 DIRECTION is an optional transitive attribute that can be used for the 148 purpose of annotating a route with the direction(s) in which data is 149 allowed to flow. Optionally, for Come-From routes, a register 150 destination may be present. This destination may be used for 151 encapsulating packets when uni-directional trees are constructed. 153 The DIRECTION attribute contains a 1-octet "Data Flow Direction", 154 optionally followed by three fields identifying a register destination 155 if the data flow direction is Come-From-only. The DIRECTION attribute 156 is type code XXX and is encoded as shown below: 158 +-------------------------------------------------------------+ 159 | Data Flow Direction (1 octet) | 160 +-------------------------------------------------------------+ 161 | Address Family Identifier (2 octets) - optional | 162 +-------------------------------------------------------------+ 163 | Length of Register Destination Address (1 octet) - optional | 164 +-------------------------------------------------------------+ 165 | Register Destination Address (variable) - optional | 166 +-------------------------------------------------------------+ 168 The use and the meaning of these fields are as follows: 170 Data Flow Direction (DFD): 1 octet 172 Draft Multicast BGP Attributes February 1999 174 The following values are defined: 176 1 - Go-To. The route is valid only for traffic travelling towards 177 the origin of the route. 179 2 - Come-From. The route is valid only for traffic travelling 180 away from the origin of the route. A register destination is 181 only useful for Come-From routes, as the purpose of the 182 register destination is to provide a Go-To channel where none 183 exists otherwise. 185 3 - Both Go-To and Come-From. The route is valid both for traffic 186 travelling towards and away from the origin of the route. 188 Address Family Identifier: 190 This field carries the identity of the Network Layer protocol 191 associated with the Network Address that follows. Presently 192 defined values for this field are specified in RFC1700 (see the 193 Address Family Numbers section). This field MUST NOT be present 194 unless DFD=2. 196 Length of Next Hop Network Address: 198 A 1 octet field whose value expresses the length of the "Network 199 Address of Register Destination" field as measured in octets. 200 This field MUST NOT be present unless DFD=2. 202 Network Address of Next Hop: 204 A variable length field that contains the Network Address of the 205 router to which encapsulated data packets may be sent. This field 206 MUST NOT be present unless DFD=2. 208 By default, if the DIRECTION attribute is not present, a route can be 209 assumed to be "Both Go-To and Come-From". That is, the path may be 210 assumed to provide bi-directional connectivity. However, it is the tree 211 construction protocol which will ultimately chose the direction of data 212 flow. 214 3.2. Direction Usage 216 When a route is advertised whose next-hop is on the other side of a 217 Draft Multicast BGP Attributes February 1999 219 unidirectional link from the router to which the route is advertised, it 220 should be annotated with the DIRECTION attribute. This can be used, for 221 example, to provide a directional route over a satellite link with one 222 set of attributes, and a separate (less preferred) route over a 223 bidirectional tunnel. This lets traffic travelling in the direction of 224 the physical link prefer to use that link. Traffic travelling in the 225 opposite direction may prefer a separate path, while still being allowed 226 to traverse the tunnel if desired (e.g. if a bidirectional path is 227 required, and the tunnel is the only bidirectional link available). 229 Protocols which construct bidirectional trees [CBT,BGMP] allow data to 230 flow in both directions along tree branches maintained with "Join" and 231 "Prune" messages. Such bidirectional branches MUST follow a route which 232 is "Both Go-To and Come-From" (DFD=3). 234 Several multicast routing protocols [DVMRP,PIMDM,PIMSM] can construct 235 unidirectional source-specific trees by sending "Join" and "Prune" 236 messages along the reverse path towards a source address, with the data 237 flowing in the opposite direction. For this purpose, a Come-From route 238 (DFD=2 or DFD=3) must be used. 240 Similarly, protocols which construct unidirectional shared-trees [PIMSM] 241 send "Join" and "Prune" messages along the reverse path towards a 242 Rendezvous Point (RP) address, with the data flowing in the opposite 243 direction. Again, a Come-From route (DFD=2 or DFD=3) must be used. 244 Some protocols which normally construct bidirectional trees [BGMP] can 245 construct a unidirectional tree if no DFD=3 route exists. 247 Finally, shared-tree protocols [PIM-SM,CBT,BGMP] typically support non- 248 member senders by forwarding data towards an address associated with the 249 root (the RP/core's unicast address in PIM-SM and CBT, or the group 250 address in BGMP). Packets from non-member senders may follow a Go-To 251 route (DFD=1 or DFD=3) until they hit a router on the multicast 252 distribution tree. 254 4. Security Considerations 256 This extension to BGP does not change the underlying security issues. 258 5. References 260 [BGP-4] 261 Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 263 Draft Multicast BGP Attributes February 1999 265 1771, March 1995. 267 [MBGP] 268 Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol 269 Extensions for BGP-4", RFC 2283, February 1998. 271 [RFC2119] 272 Bradner, S., "Key words for use in RFCs to Indicate Requirement 273 Levels", RFC 2119, March 1997. 275 [DVMRP] 276 Pusateri, T., "Distance vector multicast routing protocol", 277 Internet Draft, March 1998. 279 [MOSPF] 280 Moy, J., "Multicast extensions to OSPF", RFC 1584, July 1993. 282 [PIMSM] 283 Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., 284 Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei. 285 "Protocol independent multicast-sparse mode (PIM-SM): Protocol 286 specification", RFC 2362, June 1998. 288 [CBT] 289 Ballardie, A., "Core based trees (CBT version 2) multicast routing: 290 Protocol specification", RFC 2189, September 1997. 292 [PIMDM] 293 Estrin, D., Farinacci, D., Helmy, A., Jacobson, V., and L. Wei, 294 "Protocol independent multicast (PIM), dense mode protocol 295 specification", Internet Draft, May 1997. 297 [MIX] 298 LaMaster, H., Shultz, S., Meylor, J., and D. Meyer, "Multicast- 299 Friendly Internet Exchange (MIX)", Internet Draft, draft-ietf- 300 mboned-mix-00.txt, November 1998. 302 6. Author Information 304 Dave Thaler 305 Microsoft 306 One Microsoft Way 307 Redmond, WA 98052 308 EMail: dthaler@microsoft.com 309 Draft Multicast BGP Attributes February 1999 311 Brad Cain 312 Nortel Networks 313 3 Federal Street 314 Billerica, MA 01821 315 EMail: bcain@baynetworks.com 317 7. Full Copyright Statement 319 Copyright (C) The Internet Society (1999). All Rights Reserved. 321 This document and translations of it may be copied and furnished to 322 others, and derivative works that comment on or otherwise explain it or 323 assist in its implmentation may be prepared, copied, published and 324 distributed, in whole or in part, without restriction of any kind, 325 provided that the above copyright notice and this paragraph are included 326 on all such copies and derivative works. However, this document itself 327 may not be modified in any way, such as by removing the copyright notice 328 or references to the Internet Society or other Internet organizations, 329 except as needed for the purpose of developing Internet standards in 330 which case the procedures for copyrights defined in the Internet 331 languages other than English. 333 The limited permissions granted above are perpetual and will not be 334 revoked by the Internet Society or its successors or assigns. 336 This document and the information contained herein is provided on an "AS 337 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 338 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 339 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 340 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 341 FITNESS FOR A PARTICULAR PURPOSE."