<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (private) -->
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std"
     docName="draft-jain-mvpn-bgp-sitetype-attribute-00"
     ipr="trust200902">
  <front>
    <title abbrev="bgp-extensions-mvpn-site-type-attribute">BGP Extension for MVPN Site-Type Attribute</title>

    <author fullname="Pradeep Jain" initials="P." surname="Jain">
      <organization>Alcatel-Lucent, Inc.</organization>

      <address>
        <postal>
          <street>701 E Middlefield Rd</street>

          <city>Mountain View, CA</city>

          <code>94040</code>

          <country>USA</country>
        </postal>

        <email>pradeep.jain@alcatel-lucent.com</email>
      </address>
    </author>

    <author fullname="Geetha RemaDevi" initials="G." surname="RemaDevi">
      <organization>Alcatel-Lucent, Inc.</organization>

      <address>
        <postal>
          <street>701 E Middlefield Rd</street>

          <city>Mountain View, CA</city>

          <code>94040</code>

          <country>USA</country>
        </postal>

        <email>geetha.rema_devi@alcatel-lucent.com</email>
      </address>
    </author>

    <author fullname="Jayant Kotalwar" initials="J." surname="Kotalwar">
      <organization>Alcatel-Lucent, Inc.</organization>

      <address>
        <postal>
          <street>701 E Middlefield Rd</street>

          <city>Mountain View, CA</city>

          <code>94040</code>

          <country>USA</country>
        </postal>

        <email>Jayant.Kotalwar@alcatel-lucent.com</email>
      </address>
    </author>
	
	<author fullname="Girish Birajdar" initials="G." surname="Birajdar">
      <organization>Alcatel-Lucent, Inc.</organization>

      <address>
        <postal>
          <street>701 E Middlefield Rd</street>

          <city>Mountain View, CA</city>

          <code>94040</code>

          <country>USA</country>
        </postal>

        <email>girish.birahdar@alcatel-lucent.com</email>
      </address>
    </author>
    
	<author fullname="Jeffrey Zhang" initials="J."
            surname="Zhang">
      <organization>Juniper Networks Inc</organization>

      <address>
        <postal>
          <street>10 Technology Park Drive</street>

          <city>Westford,MA</city>

          <code>01886</code>

          <country>USA</country>
        </postal>

        <email>zzhang@juniper.net</email>
      </address>
    </author>

    <date day="15" month="May" year="2013" />

    <area>Multicast VPN</area>

    <workgroup>Networking Working Group</workgroup>

    <abstract>
      <t>This document defines a new BGP attribute in BGP based multicast VPN, that 
   allows a MVPN PE router  to inform  the rest of MVPN PE routers  whether 
   it is a sender site/receiver  site and  there by avoid all other PEs
   from setting up P-tunnels to the sender site PE. This would reduce control plane
   states in the network and allow efficient network bandwidth utilization .</t>
    </abstract>
  </front>

  <middle>
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in RFC2119 <xref
    target="RFC2119" />.</t>

    <t>When used in lower case, these words convey their typical use in common
    language, and are not to be interpreted as described in RFC2119 <xref
    target="RFC2119" />.</t>

    <section title="Introduction">
      <t>RFC 6513 defines sender site and receiver site in MVPN as mentioned below. </t>
      <t>An MVPN is defined by two sets of sites: the Sender Sites set and the
         Receiver Sites set, with the following properties: </t>
      <list style="symbols">
        <t>Hosts within the Sender Sites set could originate multicast
           traffic for receivers in the Receiver Sites set.</t>

        <t>Receivers not in the Receiver Sites set should not be able to
           receive this traffic.</t>
	    <t> Hosts within the Receiver Sites set could receive multicast
            traffic originated by any host in the Sender Sites set</t>
		<t> Hosts within the Receiver Sites set should not be able to receive
            multicast traffic originated by any host that is not in the Sender Sites set</t>
            
      </list>

      <t>  With this definition the sender sites does not receive traffic 
           but still can have terminating P-tunnels, which causes traffic in RSVP P2MP I-PMSI  tunnel to be
           forwarded to a sender site from another sender or sender-receiver site
           which eventually gets dropped at the sender site. The following are the few disadvantages associated with 
           the above approach. </t>
       <list style="symbols">
	     <t>unnecessary RSVP control plane states in the network based  </t>
	     <t>inefficient network resource utilization. </t>
	  </list>
      <t>This document addresses the above disadvantage by adding a new BGP attribute to the BGP  I-PMSI
         A-D route which will inform other PEs that a site is sender site or receiver site,
         there by preventing setting up of P-Tunnels to the sender site.</t>

     
    </section>

    <section title="Terminology">
      <t>Terminology used in this document:</t>

      <t>Sender PE: PE closest to the Multicast Source (This could be either
       directly connected to Multicast Source or via some network).
       P-Tunnel would be originating at this node.  This P-Tunnel could be
       Inclusive or Selective..</t>

      <t>Receiver PE: PE Node closest to the Multicast Receiver (This could be
        either directly connected to Multicast Source or via some network).
        P-Tunnel would be terminating at this node.</t>

      <t>Other terminologies are as defined in [RFC6513] and [RFC6514].</t>


    </section>

    <section title="MVPN sender site ">
      <t>MVPN setup with sender site, receiver site and sender-receiver PEs </t>

 

      <figure>
      <artwork>

		         

                                                                 (sender-receiver site)
                                +---+                            +-|-+
                                |   |                            |   |
                         (S)+---|PE1|- +      .--. .--.       +- |PE3|-----+(S)
                                |   |   \    (    '    '.--. /   |   |
                                +---+    \.-.' IP-MPLS      /    +-|-+
                         sender site
                                        (     network      )    
                                +---+   / (             .'-'     +-|-+
                        (S)-----|   |  /   '--'. .'.    )  \     |   |
                                |PE2|-+        '--''--'     \    |PE4|
                                |   |                        +-- |   |
                                +---+                            +-|-+
                            sender site                      receiver site
                                 
         
      </artwork>
      </figure>

      <t> As seen in the above diagram, PE1 and PE2 are sender sites,PE3 is sender-receiver and PE4 is receiver site
         PE1  will have terminating I-PMSI P-Tunnels from PE2 and PE3.PE2 and PE3 will  send traffic towards PE1 also through these P-Tunnels.
         Since PE1 is a sender site, traffic received on the I-PMSI tunnels  will be dropped.      </t>
      <t> The P-Tunnel which is setup to PE1 causes unnecessary control plane states in the core network   </t>
	  <t> If there is a way to inform PE2 and PE3 that PE1 is a sender site, then these PEs will not originate I-PMSI
       P-tunnel to PE1 and thus conserving network resources. </t>
        
	   
      <t> This document defines a new BGP attribute to be advertised to all PEs in the I-PMSI A-D route,
         which will inform the site-type of a PE.</t>

 
    </section>

    <section title="MVPN Site-type Attribute">
      <t>This document defines and uses a new BGP attribute called the "MVPN site-type
   attribute".  This is an optional transitive BGP attribute.  The
   format of this attribute is defined as follows:</t>
      <figure>
      <artwork>
	  
	     +-------------------------------+
           |       Flags (1 octet)         |
           +-------------------------------+
           |  Site Type (2 octets) |
           +-------------------------------+
      </artwork>
      </figure>
      <t>   IANA type code ( TBD) </t>
      <t>Site Type: The field will carry the value of the site type, the value can be one of the following </t>
       <list style="symbols">
	     <t>00 -- sender receiver site type (Default) </t>
	     <t>01 -- sender site </t>
		 <t>02 -- receiver site </t>
	   </list>
    </section>

    <section title="Signaling procedures and usage considerations">
      <section title="Originating PE Procedures">
        <t>A MVPN PE originating BGP I-PMSI A-D route will attach MVPN site-type attribute
          to the route. This attribute is used to inform the route receiving PE 
          if the originating PE is a sender site, receiver site or a sender-receiver site</t>
        <t> If the attribute is absent in the I-PMSI A-D route the originating PE will be 
         considered  as a sender-receiver site </t>
		<t> If a MVPN PE with existing P-tunnels to other PEs is changed to be a
           sender site or  receiver site, a new I-PMSI A-D route needs to be send 
           with the new MVPN site-type attribute.</t>
      </section>

      <section title="Receiving PE Procedures">
        <t> A MVPN PE receiving the I-PMSI A-D route with MVPN site-type attribute performs
           the below action based on the value of the site-type attribute.</t>
         <list style="symbols">
	      <t>If the site-type attribute in the I-PMSI A-D route is received with value of sender site , then the route receiving PE does not include the PE which originated the I-PMSI A-D route as leaf.</t>
	      <t>If the site-type attribute in the I-PMSI A-D route is received with value of receiver site, then the route receiving PE includes the PE which originated the I-PMSI A-D route as leaf. </t>
		  <t>If the site-type attribute in the I-PMSI A-D route is received with value of sender-receiver, then the route receiving PE includes the PE which originated the I-PMSI A-D route as leaf.  </t>
	     </list>
        <t> If the PE receiving the BGP Intra-AD route, already has a P-Tunnel to a given PE and then it receives new I-PMSI A-D Route with site-type 
           attribute as sender site, it must accept the I-PMSI A-D Route and tear down the existing tunnels to the sender PE.</t>
		<t> If the PE receiving the BGP Intra-AD route has not established P-tunnel to a given PE since it is a sender site and if it receives a new I-PMSI A-D route from the PE without site-type attribute or with site-type
           attribute as receiver site or sender-receiver site, then it should set up a new P-tunnel to the PE.</t>
      </section>
    </section>

    <section title="Management Considerations">
      <t>None</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The function described in this document does not create any new
      security issues for BGP protocol.</t>
    </section>

    <section anchor="Ack" title="Acknowledgements">
      <t>The authors want to thank Wim Henderickx of Alcatel-Lucent, Inc for significant contribution and
   feedback.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <section anchor="RSVP-IANA" title="IANA Considerations for BGP">
        <t>IANA will assign type code for MVPN site-type Attribute Flags TLV, which is carried
        in BGP I-PMSI Intra-AD  route. </t>

      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.6513'?>

      <?rfc include='reference.RFC.6514'?>

    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.2205'?>

      <?rfc include='reference.RFC.4875'?>


    </references>
  </back>
</rfc>
