One document matched: draft-ietf-bess-virtual-subnet-fib-reduction-04.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-04"
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="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@extremenetworks.com </email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Wim Henderickx" initials="W.H." surname="Henderickx">
<organization>Nokia</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@nokia.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!--
-->
<date year="2016"/>
<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 between 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="RFC7814"/> 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 IPv4 FIB Installation Example">
<artwork><![CDATA[ +----------+
+----+PE/RR(APR)+----+
+------------------+ | +----------+ | +------------------+
|VPN_A:192.0.2.1/24| | | |VPN_A:192.0.2.1/24|
| \ | | | | / |
| +------+ \ ++---+-+ +-+---++/ +------+ |
| |Host A+------_+ PE-1 | | PE-2 +------+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ /+------+ |
| 192.0.2.2/24 | | | | | | 192.0.2.3/24 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+------------------+ | | | | +------------------+
| +--------------------+ |
| |
VRF: V VRF:V
+--------------+---------+--------+------+ +--------------+---------+--------+------+
| Prefix | Nexthop |Protocol|In_FIB| | Prefix | Nexthop |Protocol|In_FIB|
+--------------+---------+--------+------+ +--------------+---------+--------+------+
|192.0.2.1/32 |127.0.0.1| Direct | Yes | |192.0.2.1/32 |127.0.0.1| Direct | Yes |
+--------------+---------+--------+------+ +--------------+---------+--------+------+
|192.0.2.2/32 |192.0.2.2| Direct | Yes | |192.0.2.2/32 | PE-1 | IBGP | No |
+--------------+---------+--------+------+ +--------------+---------+--------+------+
|192.0.2.3/32 | PE-2 | IBGP | No | |192.0.2.3/32 |192.0.2.3| Direct | Yes |
+--------------+---------+--------+------+ +--------------+---------+--------+------+
|192.0.2.0/25 | APR | IBGP | Yes | |192.0.2.0/25 | APR | IBGP | Yes |
+--------------+---------+--------+------+ +--------------+---------+--------+------+
|192.0.2.128/25| APR | IBGP | Yes | |192.0.2.128/25| APR | IBGP | Yes |
+--------------+---------+--------+------+ +--------------+---------+--------+------+
|192.0.2.0/24 |192.0.2.1| Direct | Yes | |192.0.2.0/24 |192.0.2.1| Direct | Yes |
+--------------+---------+--------+------+ +--------------+---------+--------+------+
]]></artwork>
</figure></t>
<t><figure align="center"
title="Figure 2: Selective IPv6 FIB Installation Example">
<artwork><![CDATA[ +----------+
+----+PE/RR(APR)+----+
+--------------------+ | +----------+ | +----------------+
|VPN_A: | | | |VPN_A: |
|2001:db8::1/64 | | | |2001:db8::1/64 |
| \ | | | | / |
| +------+ \ ++---+-+ +-+---++/ +------+ |
| |Host A+------_+ PE-1 | | PE-2 +------+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ /+------+ |
| 2001:db8::2/64 | | | | | | 2001:db8::3/64 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+------------------+ | | | | +------------------+
| +--------------------+ |
| |
VRF: V VRF:V
+----------------+-----------+--------+------+ +----------------+-----------+--------+------+
| Prefix | Nexthop |Protocol|In_FIB| | Prefix | Nexthop |Protocol|In_FIB|
+----------------+-----------+--------+------+ +----------------+-----------+--------+------+
|2001:db8::1/64 | ::1 | Direct | Yes | |2001:db8::1/64 | ::1 | Direct | Yes |
+----------------+-----------+--------+------+ +----------------+-----------+--------+------+
|2001:db8::2/64 |2001:db8::2| Direct | Yes | |2001:db8::2/64 | PE-1 | IBGP | No |
+----------------+-----------+--------+------+ +----------------+-----------+--------+------+
|2001:db8::3/64 | PE-2 | IBGP | No | |2001:db8::3/64 |2001:db8::3| Direct | Yes |
+----------------+-----------+--------+------+ +----------------+-----------+--------+------+
|2001:db8::0/63 | APR | IBGP | Yes | |2001:db8::0/63 | APR | IBGP | Yes |
+----------------+-----------+--------+------+ +----------------+-----------+--------+------+
|2001:db8::128/63| APR | IBGP | Yes | |2001:db8::128/63| APR | IBGP | Yes |
+----------------+-----------+--------+------+ +----------------+-----------+--------+------+
|2001:db8::0/64 |2001:db8::1| Direct | Yes | |2001:db8::0/64 |2001:db8::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 or Figure 2 as an example, the FIB reduction
procedures are described as follows:</t>
<t><list style="numbers">
<t>Multiple more specific prefixes (e.g., 192.0.2.0/25 and
192.0.2.128/25 in IPv4 example, or 2001:db8::0/63 and
2001:db8::128/63 in IPv6 example ) corresponding to an extended
subnet (i.e., 192.0.2.0/24 in IPv4 example, or 2001:db8::0/64 in
IPv6 example) 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 Susan Hares, Yongbing Fan, Robert
Raszuk, Bruno Decraene and Fred Baker 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>Those security considerations as described in <xref
target="RFC7814"/> are applicable to this document. 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.RFC.7814"?>
<!---->
</references>
<references title="Informative References">
<!---->
<?rfc include="reference.I-D.ietf-grow-va"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:39:26 |