One document matched: draft-xu-src-dst-bgp-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" symrefs="no" ?>
<rfc docName="draft-xu-src-dst-bgp-00" ipr="pre5378Trust200902">
	<front>
		<title abbrev="Source/Destination Routing Using BGP-4">Source/Destination Routing Using BGP-4</title>
		<author initials='M.' surname='Xu' fullname='Mingwei Xu'>
			<organization abbrev='Tsinghua University'>Tsinghua University</organization>
			<address>
				<postal>
	        <street>Department of Computer Science, Tsinghua University</street>
	        <city>Beijing</city>
	        <code>100084</code>
	        <country>P.R. China</country>
	    	</postal>
	    	<phone>+86-10-6278-1572</phone>
	    	<email>xumw@tsinghua.edu.cn</email>
	    </address>
		</author>
		<author initials='S.' surname='Yang' fullname='Shu Yang'>
			<organization abbrev='Tsinghua University'>Graduate School at Shenzhen, Tsinghua University</organization>	
				<address>
				<postal>
	      				  <street>Division of Information Science and Technology</street>
	       				 <city>Shenzhen</city>
	      				  <code>518055</code>
	      				  <country>P.R. China</country>
	    			</postal>
	    				<phone>+86-755-2603-6059</phone>
	    				<email>yang.shu@sz.tsinghua.edu.cn</email>
	   			 </address>
		</author>
		<author initials="J." surname="Wu" fullname="Jianping Wu">
		  <organization abbrev="Tsinghua University">Tsinghua University</organization>
		  <address>
		    <postal>
		      <street>
			Department of Computer Science, Tsinghua University
		      </street>
		      <city>Beijing</city>
		      <code>100084</code>
		      <country>P.R. China</country>
		    </postal>
		    <phone>+86-10-6278-5983</phone>
		    <email>jianping@cernet.edu.cn</email>
		  </address>
		</author>
		<date month="Mar" year="2016" />

		<abstract>
			<t>This document describes the changes necessary for BGP-4 to route traffic from a specified prefix to a specified prefix.
			 </t>
		</abstract>
	</front>

<middle>
<section title="Introduction">
  <t>This specification builds on BGP-4 <xref target="RFC4271"></xref>. It defines the extended NLRI encodings for an appended source 
    prefix, to define routes from a source prefix to a destination prefix. </t>
  <t>Traditionally, routing protocols make routing decisions solely based on destination IP addresses, packets towards
    the same destination will be delivered to the same next hop no matter where they come from. However, considering policy-based
    routing, traffic engineering and security, source information is also important for making routing decisions.</t>
  
  <t>In this document, we extend the NLRI field to support source prefix. This implies not simply routing "to a destination", but routing "to
    that destination AND from a specified source". Traffic within the network could be source/destination routed as well, or could be implicitly or
    explicitly routed from "any prefix", ::/0. </t>

  <section title="Requirements Language">
    <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 <xref target="RFC2119" />.</t>
  </section>
</section>

<section title="Theory of Routing">
  <t>The primary function of BGP is to exchange network reachability information, compute the routes towards destination prefixes, and
    select the best routes according the pre-defined selection rules. BGP-4 can support only those policies which conform to the 
    destination-based forwarding paradigm.</t>
  <t>In this context, the route is qualified by a source prefix. Intrinsically, in traditional routing model, the object being 
    routed to is a destination prefix; in the new routing model, the object being routed might be a destination prefix given that 
    the packet sports a certain source prefix.</t>
  <t>Routes that lack a source prefix match any source prefix (i.e., ::/0), by definition.</t>
</section>

<section title="Extended NLRI Encodings" anchor="format">
<t>In order to carry the source prefix information in an UPDATE message, the existing NLRI encodings are extended by prepending the source prefix.</t>
<t>The NLRI encodings specified in <xref target="RFC4271"></xref> and <xref target="RFC4760"></xref> are extended as following:</t>
    <figure title="Extended NLRI Encodings based on RFC4271 and RFC4760">
      <artwork>
	<![CDATA[
                  +--------------------------------+
                  | Type (4 octets)                |
                  +--------------------------------+
                  | Length (1 octet)               |
                  +--------------------------------+
                  | Prefix (variable)              |
                  +--------------------------------+
	]]>
      </artwork>
    </figure>
<t>and the NLRI encoding specified in <xref target="RFC3107"></xref> is extended as the following:</t>
<figure title="Extended NLRI encodings based on RFC3107">
      <artwork>
	<![CDATA[
                  +--------------------------------+
                  | Type (4 octets)                |
                  +--------------------------------+
                  | Length (1 octet)               |
                  +--------------------------------+
                  | Label (3 octets)               |
                  +--------------------------------+
                  | ...                            |
                  +--------------------------------+
                  | Prefix (variable)              |
                  +--------------------------------+
	]]>
      </artwork>
    </figure>
<t>Type: Assinged by IANA.</t>
<t>Length: Indicates the length in bits of the IP address prefix.</t>
<t>Label: Carrying label information as defined in <xref target="RFC3107"/></t>
<t>Prefix: The Prefix field contains an IP address prefix, followed by enough trailing bits to make the end of the field fall on an octet boundary.</t>
</section>

<section title="Dealing with Ambiguity">
  <t>Ambiguity could happen when there are two routes: A and B, where source prefix of A is more specific than source prefix of B, and destination prefix of 
    B is more specific than destination prefix of A. </t>
  <t>In this context, the matching rule follows that in <xref target="I-D.baker-ipv6-ospf-dst-src-routing"/>, the FIB lookup MUST yield the route with the   
    longest matching destination prefix that also matches the source prefix constraint.  In the event of a tie on the destination prefix, it MUST also match 
    the longest matching source prefix among those options. </t>
</section>

<section title="Src-Dst Capability">
  <t>The capability to carry both source and destination prefixes in BGP udpate messages (src-dst capability) is a new BGP capability <xref target = "RFC5492"/>. The Capability Code for this capability is specified in the IANA. The Capability Length field of this capability is zero.</t>
</section>

<section title = "Compatibility Considerations">
  <t>
    To be compatible with <xref target="I-D.ietf-idr-add-paths"/>, the Type field (defined in Section <xref target="format"/>) should be carefully defined by IANA.
    </t>
  </section>

<section title="Deployment Issues">
  <t>
    Router without src-dst capability should discard the BGP messages with extended NRLI, and it falls back to traditional destination-based routing when this happens.
  </t>
</section>

<section title="Security Considerations">
  <t>
    While source/destination routing could be used as part of a security solution, it could be considered similar to an access list that is managed by and scales with routing.
    </t>
</section>
		
<section title="IANA Considerations">
  <t>
    The Type field in Section <xref target="format"/>, and the new capability code should be defined by IANA. 
  </t>
</section>


</middle>

<back>
	<references title="Normative References">
		<?rfc include="reference.RFC.4271" ?>
		<?rfc include="reference.RFC.5492" ?>
		<?rfc include="reference.RFC.2119" ?>
		<?rfc include="reference.RFC.3107" ?>
		<?rfc include="reference.RFC.4760" ?>
		
	</references>

	<references title="Informative References">
		<?rfc include="reference.I-D.draft-ietf-idr-add-paths-10" ?>
		<?rfc include="reference.I-D.draft-baker-ipv6-ospf-dst-src-routing-03" ?>
	</references>
</back>
</rfc>