One document matched: draft-jain-mvpn-bgp-sitetype-attribute-00.xml
<?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>
| PAFTECH AB 2003-2026 | 2026-04-24 01:22:36 |