idnits 2.17.00 (12 Aug 2021) /tmp/idnits51215/draft-jain-mvpn-bgp-sitetype-attribute-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 15 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 15, 2013) is 3286 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) == Unused Reference: 'RFC2205' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'RFC4875' is defined on line 287, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group P. Jain 3 Internet-Draft G. RemaDevi 4 Intended status: Standards Track J. Kotalwar 5 Expires: November 16, 2013 G. Birajdar 6 Alcatel-Lucent, Inc. 7 J. Zhang 8 Juniper Networks Inc 9 May 15, 2013 11 BGP Extension for MVPN Site-Type Attribute 12 draft-jain-mvpn-bgp-sitetype-attribute-00 14 Abstract 16 This document defines a new BGP attribute in BGP based multicast VPN, 17 that allows a MVPN PE router to inform the rest of MVPN PE routers 18 whether it is a sender site/receiver site and there by avoid all 19 other PEs from setting up P-tunnels to the sender site PE. This 20 would reduce control plane states in the network and allow efficient 21 network bandwidth utilization . 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 16, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. MVPN sender site . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. MVPN Site-type Attribute . . . . . . . . . . . . . . . . . . . 7 65 5. Signaling procedures and usage considerations . . . . . . . . 8 66 5.1. Originating PE Procedures . . . . . . . . . . . . . . . . 8 67 5.2. Receiving PE Procedures . . . . . . . . . . . . . . . . . 8 69 6. Management Considerations . . . . . . . . . . . . . . . . . . 9 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 9.1. IANA Considerations for BGP . . . . . . . . . . . . . . . 12 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC2119 [RFC2119]. 87 When used in lower case, these words convey their typical use in 88 common language, and are not to be interpreted as described in 89 RFC2119 [RFC2119]. 91 1. Introduction 93 RFC 6513 defines sender site and receiver site in MVPN as mentioned 94 below. 96 An MVPN is defined by two sets of sites: the Sender Sites set and the 97 Receiver Sites set, with the following properties: 99 o Hosts within the Sender Sites set could originate multicast 100 traffic for receivers in the Receiver Sites set. 102 o Receivers not in the Receiver Sites set should not be able to 103 receive this traffic. 105 o Hosts within the Receiver Sites set could receive multicast 106 traffic originated by any host in the Sender Sites set 108 o Hosts within the Receiver Sites set should not be able to receive 109 multicast traffic originated by any host that is not in the Sender 110 Sites set 112 With this definition the sender sites does not receive traffic but 113 still can have terminating P-tunnels, which causes traffic in RSVP 114 P2MP I-PMSI tunnel to be forwarded to a sender site from another 115 sender or sender-receiver site which eventually gets dropped at the 116 sender site. The following are the few disadvantages associated with 117 the above approach. 119 o unnecessary RSVP control plane states in the network based 121 o inefficient network resource utilization. 123 This document addresses the above disadvantage by adding a new BGP 124 attribute to the BGP I-PMSI A-D route which will inform other PEs 125 that a site is sender site or receiver site, there by preventing 126 setting up of P-Tunnels to the sender site. 128 2. Terminology 130 Terminology used in this document: 132 Sender PE: PE closest to the Multicast Source (This could be either 133 directly connected to Multicast Source or via some network). 134 P-Tunnel would be originating at this node. This P-Tunnel could be 135 Inclusive or Selective.. 137 Receiver PE: PE Node closest to the Multicast Receiver (This could be 138 either directly connected to Multicast Source or via some network). 139 P-Tunnel would be terminating at this node. 141 Other terminologies are as defined in [RFC6513] and [RFC6514]. 143 3. MVPN sender site 145 MVPN setup with sender site, receiver site and sender-receiver PEs 147 (sender-receiver site) 148 +---+ +-|-+ 149 | | | | 150 (S)+---|PE1|- + .--. .--. +- |PE3|-----+(S) 151 | | \ ( ' '.--. / | | 152 +---+ \.-.' IP-MPLS / +-|-+ 153 sender site 154 ( network ) 155 +---+ / ( .'-' +-|-+ 156 (S)-----| | / '--'. .'. ) \ | | 157 |PE2|-+ '--''--' \ |PE4| 158 | | +-- | | 159 +---+ +-|-+ 160 sender site receiver site 162 As seen in the above diagram, PE1 and PE2 are sender sites,PE3 is 163 sender-receiver and PE4 is receiver site PE1 will have terminating 164 I-PMSI P-Tunnels from PE2 and PE3.PE2 and PE3 will send traffic 165 towards PE1 also through these P-Tunnels. Since PE1 is a sender 166 site, traffic received on the I-PMSI tunnels will be dropped. 168 The P-Tunnel which is setup to PE1 causes unnecessary control plane 169 states in the core network 171 If there is a way to inform PE2 and PE3 that PE1 is a sender site, 172 then these PEs will not originate I-PMSI P-tunnel to PE1 and thus 173 conserving network resources. 175 This document defines a new BGP attribute to be advertised to all PEs 176 in the I-PMSI A-D route, which will inform the site-type of a PE. 178 4. MVPN Site-type Attribute 180 This document defines and uses a new BGP attribute called the "MVPN 181 site-type attribute". This is an optional transitive BGP attribute. 182 The format of this attribute is defined as follows: 184 +-------------------------------+ 185 | Flags (1 octet) | 186 +-------------------------------+ 187 | Site Type (2 octets) | 188 +-------------------------------+ 190 IANA type code ( TBD) 192 Site Type: The field will carry the value of the site type, the value 193 can be one of the following 195 o 00 -- sender receiver site type (Default) 197 o 01 -- sender site 199 o 02 -- receiver site 201 5. Signaling procedures and usage considerations 203 5.1. Originating PE Procedures 205 A MVPN PE originating BGP I-PMSI A-D route will attach MVPN site-type 206 attribute to the route. This attribute is used to inform the route 207 receiving PE if the originating PE is a sender site, receiver site or 208 a sender-receiver site 210 If the attribute is absent in the I-PMSI A-D route the originating PE 211 will be considered as a sender-receiver site 213 If a MVPN PE with existing P-tunnels to other PEs is changed to be a 214 sender site or receiver site, a new I-PMSI A-D route needs to be send 215 with the new MVPN site-type attribute. 217 5.2. Receiving PE Procedures 219 A MVPN PE receiving the I-PMSI A-D route with MVPN site-type 220 attribute performs the below action based on the value of the site- 221 type attribute. 223 o If the site-type attribute in the I-PMSI A-D route is received 224 with value of sender site , then the route receiving PE does not 225 include the PE which originated the I-PMSI A-D route as leaf. 227 o If the site-type attribute in the I-PMSI A-D route is received 228 with value of receiver site, then the route receiving PE includes 229 the PE which originated the I-PMSI A-D route as leaf. 231 o If the site-type attribute in the I-PMSI A-D route is received 232 with value of sender-receiver, then the route receiving PE 233 includes the PE which originated the I-PMSI A-D route as leaf. 235 If the PE receiving the BGP Intra-AD route, already has a P-Tunnel to 236 a given PE and then it receives new I-PMSI A-D Route with site-type 237 attribute as sender site, it must accept the I-PMSI A-D Route and 238 tear down the existing tunnels to the sender PE. 240 If the PE receiving the BGP Intra-AD route has not established 241 P-tunnel to a given PE since it is a sender site and if it receives a 242 new I-PMSI A-D route from the PE without site-type attribute or with 243 site-type attribute as receiver site or sender-receiver site, then it 244 should set up a new P-tunnel to the PE. 246 6. Management Considerations 248 None 250 7. Security Considerations 252 The function described in this document does not create any new 253 security issues for BGP protocol. 255 8. Acknowledgements 257 The authors want to thank Wim Henderickx of Alcatel-Lucent, Inc for 258 significant contribution and feedback. 260 9. IANA Considerations 262 9.1. IANA Considerations for BGP 264 IANA will assign type code for MVPN site-type Attribute Flags TLV, 265 which is carried in BGP I-PMSI Intra-AD route. 267 10. References 269 10.1. Normative References 271 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 272 VPNs", RFC 6513, February 2012. 274 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 275 Encodings and Procedures for Multicast in MPLS/BGP IP 276 VPNs", RFC 6514, February 2012. 278 10.2. Informative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 284 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 285 Functional Specification", RFC 2205, September 1997. 287 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 288 "Extensions to Resource Reservation Protocol - Traffic 289 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 290 Switched Paths (LSPs)", RFC 4875, May 2007. 292 Authors' Addresses 294 Pradeep Jain 295 Alcatel-Lucent, Inc. 296 701 E Middlefield Rd 297 Mountain View, CA 94040 298 USA 300 Email: pradeep.jain@alcatel-lucent.com 302 Geetha RemaDevi 303 Alcatel-Lucent, Inc. 304 701 E Middlefield Rd 305 Mountain View, CA 94040 306 USA 308 Email: geetha.rema_devi@alcatel-lucent.com 310 Jayant Kotalwar 311 Alcatel-Lucent, Inc. 312 701 E Middlefield Rd 313 Mountain View, CA 94040 314 USA 316 Email: Jayant.Kotalwar@alcatel-lucent.com 318 Girish Birajdar 319 Alcatel-Lucent, Inc. 320 701 E Middlefield Rd 321 Mountain View, CA 94040 322 USA 324 Email: girish.birahdar@alcatel-lucent.com 326 Jeffrey Zhang 327 Juniper Networks Inc 328 10 Technology Park Drive 329 Westford,MA 01886 330 USA 332 Email: zzhang@juniper.net