One document matched: draft-ietf-bess-virtual-subnet-fib-reduction-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-bess-virtual-subnet-fib-reduction-00"
ipr="trust200902">
<front>
<title abbrev="FIB Reduction in Virtual Subnet">FIB Reduction in Virtual
Subnet</title>
<author fullname="Xiaohu Xu" initials="X.X." surname="Xu">
<organization>Huawei</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>xuxiaohu@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Susan Hares" initials="S.H." surname="Hares">
<organization>Individual</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>shares@ndzh.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Yongbing Fan" initials="Y.F." surname="Fan">
<organization>China Telecom</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>fanyb@gsta.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Christian Jacquenet" initials="C.J." surname="Jacquenet">
<organization>Orange</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>christian.jacquenet@orange.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Truman Boyes" initials="T.B." surname="Boyes">
<organization>Bloomberg LP</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>tboyes@bloomberg.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Brendan Fee" initials="B.F." surname="Fee">
<organization>Extreme Networks</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>bfee@enterasys.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Wim Henderickx" initials="W.H." surname="Henderickx">
<organization>Alcatel-Lucent</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>wim.henderickx@alcatel-lucent.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!--
-->
<date year="2015"/>
<abstract>
<t>Virtual Subnet is a BGP/MPLS IP VPN-based subnet extension solution
which is intended for building Layer3 network virtualization overlays
within and/or across data centers. This document describes a mechanism
for reducing the FIB size of PE routers in the Virtual Subnet
context.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Virtual Subnet <xref target="I-D.ietf-l3vpn-virtual-subnet"/> is a
BGP/MPLS IP VPN <xref target="RFC4364"/> -based subnet extension
solution which is intended for building Layer3 network virtualization
overlays within and/or across data centers. In the Virtual Subnet
context, since CE host routes of a given VPN instance need to be
exchanged among PE routers participating in that VPN instance, the
resulting forwarding table (a.k.a. FIB) size of PE routers may become a
big concern in large-scale data center environment where they may need
to install a huge amount of host routes into their forwarding tables. In
some cases where host routes need to be maintained on the control plane,
it needs a method to reduce the FIB size of PE routers without any
change to the RIB and the routing table. Therefore, this document
proposes a very simple mechanism for reducing the FIB size of PE
routers. The basic idea of this mechanism is: Those host routes learnt
from remote PE routers are selectively installed into the FIB while the
remaining routes including local CE host routes are installed into the
FIB by default as before.</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">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="Abbreviations_Terminology" title="Terminology">
<t>This memo makes use of the terms defined in <xref
target="RFC4364"/>.</t>
</section>
<section anchor="dd" title="Solution Description">
<t><figure align="center"
title="Figure 1: Selective FIB Installation Example">
<artwork><![CDATA[ +----------+
+----+PE/RR(APR)+----+
+-----------------+ | +----------+ | +-----------------+
|VPN_A:1.1.1.1/24 | | | |VPN_A:1.1.1.1/24 |
| \ | | | | / |
| +------+ \++---+-+ +-+---++/ +------+ |
| |Host A+------+ PE-1 | | PE-2 +------+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ /+------+ |
| 1.1.1.2/24 | | | | | | 1.1.1.3/24 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+-----------------+ | | | | +-----------------+
| +--------------------+ |
| |
VRF: V VRF:V
+------------+---------+--------+------+ +------------+---------+--------+------+
| Prefix | Nexthop |Protocol|In_FIB| | Prefix | Nexthop |Protocol|In_FIB|
+------------+---------+--------+------+ +------------+---------+--------+------+
| 1.1.1.1/32 |127.0.0.1| Direct | Yes | | 1.1.1.1/32 |127.0.0.1| Direct | Yes |
+------------+---------+--------+------+ +------------+---------+--------+------+
| 1.1.1.2/32 | 1.1.1.2 | Direct | Yes | | 1.1.1.2/32 | PE-1 | IBGP | No |
+------------+---------+--------+------+ +------------+---------+--------+------+
| 1.1.1.3/32 | PE-2 | IBGP | No | | 1.1.1.3/32 | 1.1.1.3 | Direct | Yes |
+------------+---------+--------+------+ +------------+---------+--------+------+
| 1.1.1.0/25 | APR | IBGP | Yes | | 1.1.1.0/25 | APR | IBGP | Yes |
+------------+---------+--------+------+ +------------+---------+--------+------+
|1.1.1.128/25| APR | IBGP | Yes | |1.1.1.128/25| APR | IBGP | Yes |
+------------+---------+--------+------+ +------------+---------+--------+------+
| 1.1.1.0/24 | 1.1.1.1 | Direct | Yes | | 1.1.1.0/24 | 1.1.1.1 | Direct | Yes |
+------------+---------+--------+------+ +------------+---------+--------+------+
]]></artwork>
</figure></t>
<t>To reduce the FIB size of PE routers, the selective FIB installation
concept as described in <xref target="I-D.ietf-grow-va"/> can be
leveraged in the Virtual Subnet context. Take the VPN instance
demonstrated in Figure 1 as an example, the FIB reduction procedures are
described as follows:</t>
<t><list style="numbers">
<t>Multiple more specific prefixes (e.g., 1.1.1.0/25 and
1.1.1.128/25) corresponding to an extended subnet (i.e., 1.1.1.0/24)
are specified as Virtual Prefixes (VPs). Meanwhile, one or more PE
routers (or route reflectors) are configured as Aggregation Point
Routers (APR) for each VP. The APRs for a given VP would install a
null route to that VP while propagating a route to that VP via the
L3VPN signaling.</t>
<t>For a given host route in the routing table which is learnt from
any remote PE router, PE routers which are non-APRs for any VP
covering this host route would not install it into the FIB by
default. In contrast, PE routers (or route reflectors) which are
APRs for any VP covering that host route would install it into the
FIB. If one or more particular remote host routes need to be
installed by non-APR PE routers by default as well for whatever
reasons, the best way to realize such goal is to attach a special
extended communities attribute to those particular host routes
either by originating PE routers or by route reflectors. Upon
receiving any host routes attached with the above extended
communities attribute, non-APR PE routers SHOULD install them by
default.</t>
<t>Upon receiving a packet destined for a given remote CE host, if
no host route for that CE host is found in the FIB, the ingress PE
router would forward the packet to a given APR according to the
longest-matching VP route, which in turn forwards the packet to the
final egress PE router. In this way, the FIB size of those non-APR
PE routers can be greatly reduced at the potential cost of path
stretch.</t>
</list></t>
<t>In order to forward packets destined for remote CE hosts directly to
the final egress PE routers without the potential path stretch penalty,
non-APR PE routers could perform on-demand FIB installation for remote
host routes which are available in the routing table. For example, upon
receiving an ARP request or Neighbor Solicitation (NS) message from a
local CE host, the non-APR PE router would perform a lookup in the
routing table. If a corresponding host route for the target host is
found but not yet installed into the FIB, it would be installed into the
FIB. Another possible way to trigger on-demand FIB installation is as
follows: when receiving a packet whose longest-matching FIB entry is a
particular VP route learnt from any APR, a copy of this packet would be
sent to the control plane while this original packet is forwarded as
normal. The above copy sent to the control plane would trigger a lookup
in the routing table. If a corresponding host route is found but not yet
installed into the FIB, it would be installed into the FIB. To provide
robust protection against DoS attacks on the control plane,
rate-limiting of the above packets sent to the control plane MUST be
enabled. Those FIB entries for remote CE host routes which are on-demand
installed on non-APR PE routers would expire if not used for a certain
period of time.</t>
</section>
<!---->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Robert Raszuk and Bruno Decraene for
their valuable suggestions on this document.</t>
<!---->
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The type value for the Extended Communities Attributes as described
in this doc is required to be allocated by the IANA.</t>
<!---->
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not introduce any new security risk.</t>
<!---->
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
<?rfc include="reference.RFC.4364"?>
<?rfc include="reference.I-D.ietf-l3vpn-virtual-subnet"?>
<!---->
</references>
<references title="Informative References">
<!---->
<?rfc include="reference.I-D.ietf-grow-va"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:42:10 |