<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY I-D.ietf-idr-bgp-open-policy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-idr-bgp-open-policy-01.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" docName="draft-ymbk-idr-isp-border-02" ipr="trust200902">
 <front>

   <title abbrev="Network border definition">New definition of ISP
   internal eBGP border using BGP Roles</title>

   <author fullname="Alexander Azimov" initials="A"
           surname="Azimov">
     <organization>Qrator Labs</organization>
     <address>
       <email>aa@qrator.net</email>
     </address>
   </author>

   <author fullname="Eugene Bogomazov" initials="E"
           surname="Bogomazov">
     <organization>Qrator Labs</organization>
     <address>
       <email>eb@qrator.net</email>
     </address>
   </author>

   <author fullname="Randy Bush" initials="R"
           surname="Bush">
     <organization>Internet Initiative Japan</organization>
     <address>
       <email>randy@psg.com</email>
     </address>
   </author>

   <author fullname="Keyur Patel" initials="K"
           surname="Patel">
     <organization>Arrcus, Inc.</organization>
     <address>
       <email>keyur@arrcus.com</email>
     </address>
   </author>

   <author fullname="Kotikalapudi Sriram" initials="K"
           surname="Sriram">
     <organization>US NIST</organization>
     <address>
       <email>ksriram@nist.gov</email>
     </address>
   </author>

   <date month="November" year="2017"/>

   <keyword>BGP</keyword>
   <keyword>BGP role</keyword>
   <keyword>BGP best path</keyword>
   
   <abstract>
     <t>
       This document proposes a new definition of ISP borders using BGP
       Roles.  It may be used to improve the BGP best path selection
       algorithm for better support of hot-potato routing between
       different internal ASNs of an ISP.  It may also be used to enable
       transmission of local attributes between different internal ASNs
       of an ISP.
     </t>
   </abstract>

   <note title="Requirements Language">
     <t>
       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
       NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
       "OPTIONAL" are to be interpreted as described in <xref
       target="RFC2119">RFC 2119</xref> only when they appear in all
       upper case.  They may also appear in lower or mixed case as
       English words, without normative meaning.
     </t>
   </note>
 </front>

 <middle>
   <section title="Introduction" anchor="intro">
     <t>
       The BGP best path selection algorithm (Section 9.1.2.2 of <xref
       target="RFC4271"/>) has a very clear definition of a network
       border: different ASNs - different networks.  It differs from
       some real world situations when two networks become one business
       entity and want to operate as one network.
     </t>
     <t>
       Today BGP does not provide any robust or automated support for
       such merging networks:
       <list style="symbols">
         <t>There is no support for carrying local attributes through
           this border,</t> 
         <t>Hot-potato routing, implemented by eBGP being preferred to
           iBGP, does not work, and</t>
         <t>Route Leak prevention inside such a united network can not
	   be easily automated.</t> 
       </list>
     </t>
     <t>
       In <xref target="I-D.ietf-idr-bgp-open-policy"/> BGP Roles were
       introduced - a configuration option that strongly enforces
       agreement on real-world peering relations between two BGP
       speakers.  This configuration option can accept values of:
       Peering, Customer, Provider and Internal. These values
       could be used in a new ISP border definition: Internal
       vs. External.  With this definition of network borders, it
       becomes easy to allow robust propagation of local attributes
       between different ASNs of one ISP.  It could be also used to
       improve the hot-potato routing mechanism: where routes learned from
       External BGP connections should be preferred over Internal, even
       those which cross the ISP's internal AS/AS boundary.
     </t>
   </section>

   <section anchor="decision_process" title="Changes in BGP decision process">
     <t>
       To improve hot-potato routing for networks with multiple ASNs we
       propose to insert before d) in Section 9.1.2.2 of <xref
       target="RFC4271"/> next step:
     </t>
     <t>
       If at least one of the candidate routes was received via a BGP
       session with External (Peer, Provider, Customer) role, remove
       from consideration all routes that were received via BGP sessions
       with an Internal role.
     </t>
     <t>
       While this step will improve traffic control for ISPs with
       multiple ASNs it will have no affect on ISPs with single ASN.
     </t>
   </section>

   <section anchor="local_attributes" title="Local Attributes Transmission">
     <t>
       Propagation of local attributes through an ISP's internal AS/AS
       border could be enabled only if both sides set Internal roles in
       their BGP Open negotiation.  Different attributes may still have
       different transmission policy:
       <list style="symbols">
         <t>iOTC attribute from <xref
         target="I-D.ietf-idr-bgp-open-policy"/> MUST be sent to
         enforce route leak prevention,</t>
         <t>LOCAL_PREF attribute MAY be sent, and</t>
         <t>MED attribute MAY be sent without changes.</t>
       </list>
     </t>
   </section>


   <section anchor="IANA" title="IANA Considerations">
   <t>This document has no IANA actions.</t>
   </section>
   </middle>
 

 <back>
   <references title="Normative References">
   &RFC2119;
   &RFC4271;
   &I-D.ietf-idr-bgp-open-policy;
   </references>
  </back>
</rfc>
