One document matched: draft-portoles-lisp-eid-mobility-01.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. -->
<?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="exp" docName="draft-portoles-lisp-eid-mobility-01"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="L2/L3 EID Mobility">LISP L2/L3 EID Mobility Using a Unified
Control Plane</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Marc Portoles Comeras" initials="M." surname="Portoles">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<code>95134</code>
<city>San Jose</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>mportole@cisco.com</email>
</address>
</author>
<author fullname="Vrushali Ashtaputre" initials="V." surname="Ashtaputre">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<code>95134</code>
<city>San Jose</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>vrushali@cisco.com</email>
</address>
</author>
<author fullname="Victor Moreno" initials="V." surname="Moreno">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<code>95134</code>
<city>San Jose</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>vimoreno@cisco.com</email>
</address>
</author>
<author fullname="Fabio Maino" initials="F." surname="Maino">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<code>95134</code>
<city>San Jose</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>fmaino@cisco.com</email>
</address>
</author>
<author fullname="Dino Farinacci" initials="D." surname="Farinacci">
<organization>lispers.net</organization>
<address>
<postal>
<street></street>
<code></code>
<city>San Jose</city>
<region>CA</region>
<country>USA</country>
</postal>
<email>farinacci@gmail.com</email>
</address>
</author>
<date day="8" month="October" year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>LISP; L2 Overlay, L3 Overlay</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>The LISP control plane offers the flexibility to support multiple
overlay flavors simultaneously. This document specifies how LISP can be
used to provide control-plane support to deploy a unified L2 and L3
overlay solution, as well as analyzing possible deployment options and
models.</t>
</abstract>
<note 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"></xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document describes the architecture and design options required
to offer a unified L2 and L3 overlay solution with mobility using the
LISP control-plane.</t>
<t>The architecture takes advantage of the flexibility that LISP
provides to simultaneously support different overlay types. While the
LISP specification defines both the data-plane and the control-plane,
this document focuses on the use of the control-plane to provide L2 and
L3 overlay services with mobility. The control plane may be combined
with a data-plane of choice e.g., [LISP], [VXLAN-GPE], or [VXLAN].</t>
<t>The recommendation on whether a flow is sent over the L2 or the L3
overlay is based on whether the traffic is bridged (intra-subnet or
non-IP) or routed (inter-subnet), respectively. This allows treating
both overlays as separate segments, and enables L2-only and L3-only
deployments (and combinations of them) without modifying the
architecture.</t>
<t>The unified solution for L2 and L3 overlays offers the possibility to
extend subnets and routing domains (as required in state-of-art
Datacenter and Enterprise architectures) with mobility support and
traffic optimization.</t>
<t>An important use-case of the unified architecture is that, while most
data centers are complete layer-3 routing domains, legacy applications
either have not converted to IP or still use auto-discovery at layer-2
and assume all nodes in an application cluster belong to the same
subnet. For these applications, the L2-overlay limits the functionality
to where the legacy app lives versus having to extend layer-2 into the
network.</t>
<t>Broadcast, Unknown and Multicast traffic on the overlay are supported
by either replicated unicast, or underlay (RLOC) multicast as specified
in <xref target="RFC6831"></xref> and <xref
target="I-D.ietf-lisp-signal-free-multicast"></xref>.</t>
</section>
<section title="Definition of Terms">
<t>LISP related terms are defined as part of the LISP specification
<xref target="RFC6830"></xref>, notably EID, RLOC, Map-Request, Map-
Reply, Map-Notify, Ingress Tunnel Router (ITR), Egress Tunnel Router
(ETR), Map- Server (MS) and Map-Resolver (MR).</t>
</section>
<section title="Reference System">
<t>The following figure illustrates the reference system used to support
the packet flow description throughout this document. The system
presents 4 sites. Site A and Site D provide access to different subnets
(non-extended), while Site B and Site C extend a common subnet. The xTR
in each one of the sites registers EIDs from the sites with the LISP
Mapping System and provides support to encapsulate overlay (EID) traffic
through the underlay (RLOC space).</t>
<figure anchor="figure_reference"
title="Reference System Architecture with unified L2 and L3 overlays">
<artwork><![CDATA[
,-------------.
(Mapping System )
-+------------+
+--+--+ +-+---+
|MS/MR| |MS/MR|
+-+---+ +-----+
.-._..-._.--._..|._.,.-._.,|-._.-_._.-.._.-.
.-.' '.-.
( L3 Underlay )
( (RLOC Space) )
'.-._.'.-._.'--'._.'.-._.'.-._.'.-._.'.-._.'.-._.-.'
/ | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B ) .' Site C ) .' Site D )
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
:Device 1: :Device 2: :Device 3: :Device 4:
'--------' '--------' '--------' '--------'
IP: 1.0.0.1 IP: 3.0.0.2 IP: 3.0.0.3 IP: 2.0.0.4
MAC: 0:0:3:0:0:2 MAC: 0:0:3:0:0:3
]]></artwork>
</figure>
<t>The recommended selection between the use of L2 and L3 overlays is to
map them to bridged (intra-subnet or non-IP) and routed (inter-subnet)
traffic. The rest of the document follows this recommendation to
describe the packet flows.</t>
<t>However, note that in a different selection approach, intra-subnet
traffic MAY also be sent over the L3 overlay. <xref target="EF"></xref>
specifies the changes needed to send all IP traffic using the L3 overlay
and restricting the use of the L2 overlay to non-IP traffic.</t>
<t>When required, the control plane makes use of two basic types of
EID-to-RLOC mappings associated to end-hosts and in order to support the
unified architecture: <list style="symbols">
<t>EID = <IID, MAC> to RLOC=<IP>. This is used to
support the L2 overlay.</t>
<t>EID = <IID, IP> to RLOC=<IP>. This is the traditional
mapping as defined in the original LISP specification and supports
the L3 overlay.</t>
</list></t>
</section>
<section anchor="MobilityL3" title="L3 Overlays and Mobility Support">
<section title="Reference Architecture and packet flows">
<t>In order to support the packet flow descriptions in this section we
use <xref target="figure_reference"></xref> as reference. This section
uses Sites A and D to describe the flows.</t>
<figure anchor="figure_mobility"
title="Reference Mobility Architecture">
<preamble></preamble>
<artwork><![CDATA[
/ | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B ) .' Site C ) .' Site D )
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
:Device 1: :Device 2: :Device 3: :Device 4:
'--------' '--------' '--------' '--------'
(IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4)
(IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)
]]></artwork>
<postamble></postamble>
</figure>
<section title="Routed Traffic Flow: L3 Overlay use">
<t>Inter-subnet traffic is encapsulated using the L3 overlay. The
process to encapsulate this traffic is the same as described in the
original specification <xref target="RFC6830"></xref>. We describe
the packet flow here for completeness</t>
<t>The following is a sequence example of the unicast packet flow
and the control plane operations when in the topology shown in
Figure 1 End-Device 1, in LISP site A, wants to communicate with
End-Device 4 in LISP site D. Note that both end systems reside in
different subnets. We'll assume that End-Device 1 knows the EID IP
address of End-Device 4 (e.g. it is learned using a DNS service).
<list style="symbols">
<t>End-Device 1 sends an IP packet frame with destination
2.0.0.4 and source 1.0.0.1. As the destination address lies on a
different subnet End-Device 1 sends the packet following its
routing table to ITR A (e.g., it is its default gateway).</t>
<t>ITR A does a L3 lookup in its local map-cache for the
destination IP 2.0.0.4. When the lookup of 2.0.0.4 is a miss,
the ITR sends a Map-request to the mapping database system
looking up for EID=<IID1,2.0.0.4>.</t>
<t>The mapping systems forwards the Map-Request to ETR D, that
has registered the EID-to-RLOC mapping of
EID=<IID1,2.0.0.4>.</t>
<t>ETR D sends a Map-Reply to ITR A that includes the
EID-to-RLOC mapping: EID=<IID1,2.0.0.4> -> RLOC=IP_D,
where IP_D is the locator of ETR D.</t>
<t>ITR A populates the local map-cache with the EID to RLOC
mapping, and encapsulates all subsequent packets with a
destination IP 2.0.0.4 using destination RLOC=IP_D.</t>
</list></t>
</section>
<section title="L3 Mobility Flow">
<t>The support to L3 mobility covers the requirements to allow an
end-host to move from a given site to another and maintain
correspondence with the rest of end-hosts that are connected to the
same L3 routing domain. This support MUST ensure convergence of L3
forwarding (IPv4/IPv6 based) from the old location to the new one
when the host completes its move.</t>
<t>The following is a sequence description of the packet flow when
End-Device 1 in the reference figure roams to site D: <list
style="symbols">
<t>When End-Device 1 is attached or detected in site D, ETR D
sets up the database mapping corresponding to EID=<IID1,
1.0.0.1>. ETR D sends a Map-Register to the mapping system
registering RLOC=IP_D as locator for EID=<IID1, 1.0.0.1>.
Now the mapping system is updated with the new EID-to-RLOC
mapping (location) for End-Device 1.</t>
<t>The Mapping System, after receiving the new registration for
EID=<IID1, 1.0.0.1> sends a Map-Notify to ETR A to inform
it of the move. Then, ETR A removes its local database mapping
information and stops registering EID=<IID1, 1.0.0.1>.</t>
<t>Any ITR or PiTR participating in the L3 overlay
(corresponding to IID1) that were sending traffic to 1.0.0.1
before the migration keep sending traffic to ETR A.</t>
<t>Once ETR A is notified by the Mapping system, when it
receives traffic from an ITR with destination 1.0.0.1, it
generates a Solicit-Map-Request (SMR) back to the ITR (or PiTR)
for EID=<IID1, 1.0.0.1>.</t>
<t>Upon receiving the SMR the ITR invalidates its local map-
cache entry for EID=<IID1, 1.0.0.1> and sends a new
Map-Request for that EID. The Map-Reply includes the new
EID-to-RLOC mapping for End-Device 1 with RLOC=IP_D.</t>
<t>Similarly, once the local database mapping is removed from
ITR A, non-encapsulated packets arriving at ITR A from a local
End-Device and destined to End-Device 1 result in a cache miss,
which triggers sending a Map-Request for EID=<IID1,
1.0.0.1> to populate the map-cache of ITR A.</t>
</list></t>
</section>
</section>
<section title="Implementation Considerations">
<section title="L3 Segmentation">
<t>LISP support of segmentation and multi-tenancy is structured
around the propagation and use of Instance-IDs, and handled as part
of the EID in control plane operations. The encoding is described in
<xref target="I-D.ietf-lisp-lcaf"></xref> and its use in <xref
target="I-D.ietf-lisp-ddt"></xref>.</t>
<t>Instance-IDs can be used to support L3 overlay segmentation, such
as in extended VRFs or multi-VPN overlays. </t>
</section>
<section title="L3 Database-Mappings ">
<t>When an end-host is attached or detected in an ETR that provides
L3-overlay services and mobility, a database Mapping is registered
to the mapping system with the following structure: <list
style="symbols">
<t>The EID 2-tuple (IID, IP) with its binding to a corresponding
ETR locator set (IP RLOC)</t>
</list></t>
<t>The registration of these EIDs MUST follow the LCAF format as
defined in <xref target="I-D.ietf-lisp-lcaf"></xref> and the
specific EID record to be used is illustrated in the following
figure:</t>
<figure>
<artwork><![CDATA[
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D | Rsvd | Map-Version Number | AFI = 16387 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | Rsvd1 | Flags | Type = 2 | IID mask-len |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | 4 + n | Instance-ID... |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | ...Instance-ID | EID-AFI = 1 or 2 |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EID-Prefix (IPv4 or IPv6) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The L3 EID record follows the structure as described in <xref
target="RFC6830"></xref>.</t>
</section>
<section title="LISP Mapping System support">
<t>The interface between the xTRs and the Mapping System is
described in <xref target="RFC6833"></xref> and this document
follows the specification as described there. When available, the
registrations MAY be implemented over a reliable transport as
described in <xref
target="I-D.kouvelas-lisp-map-server-reliable-transport"></xref>.</t>
<t>In order to support system convergence after mobility, when the
Map-Server receives a new registration for a specific EID, it MUST
send a Map-Notify to the entire RLOC set in the site that last
registered this same EID. This Map-Notify is used to track
moved-away state of L3 EIDs as described in <xref
target="l3away"></xref>.</t>
</section>
<section anchor="l3away" title="Using SMRs to Track Moved-Away Hosts">
<t>One of the key elements to support end-host mobility using the
LISP architecture is the Solicit-Map-Request (SMR). This is a
special message by means of which an ETR can request an ITR to send
a new Map-Request for a particular EID record. In essence the SMR
message is used as a signal to indicate a change in mapping
information and it is described with detail in <xref
target="RFC6830"></xref>.</t>
<t>In order to support mobility, an ETR SHALL maintain a list of EID
records for which it has to generate a SMR message whenever it
receives traffic with that EID as destination.</t>
<t>The particular strategy to maintain an Away Table is
implementation specific and it will be typically based on the
strategy to detect the presence of hosts and the use of Map-Notify
messages received from the Map-Server. In essence the table SHOULD
provide support to the following: <list style="symbols">
<t>Keep track of end-hosts that were once connected to an ETR
and have moved away.</t>
<t>Support for L3 EID records, the 2-tuple (IID, IP), for which
a SMR message SHOULD be generated.</t>
</list></t>
</section>
<section title="L3 multicast support">
<t>L3 Multicast traffic on the overlay MAY be supported by either
replicated unicast, or underlay (RLOC) multicast. Specific solutions
to support L3 multicast over LISP controlled overlays are specified
in in <xref target="RFC6831"></xref>, <xref
target="I-D.ietf-lisp-signal-free-multicast"></xref> and <xref
target="I-D.coras-lisp-re"></xref>.</t>
</section>
<section title="Time-to-Live Handling in Data-Plane">
<t>The LISP specification (<xref target="RFC6830"></xref>) describes
how to handle Time-to-Live values of the inner and outer headers
during encapsulation and decapsulation of packets when using the L3
overlay.</t>
</section>
</section>
</section>
<section anchor="MobilityL2" title="L2 Overlays and Mobility Support">
<section title="Reference Architecture and packet flows">
<t>In order to support L2 packet flow descriptions in this section we
use <xref target="figure_reference"></xref> as reference. This section
uses Sites B and C to describe the flows.</t>
<figure anchor="figure_mobility2"
title="Reference Mobility Architecture">
<preamble></preamble>
<artwork><![CDATA[
/ | | \
RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D
+-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+
.| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-.
( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ ) ( +-+--+--+ )
.' Site A ) .' Site B ) .' Site C ) .' Site D )
( 1.0.0.0/24 . ( 3.0.0.0/24 . ( 3.0.0.0/24 . ( 2.0.0.0/24 .
'--'._.'. ) '--'._.'. ) '--'._.'. ) '--'._.'. )
/ '--' | '--' | '--' \ '--'
'--------' '--------' '--------' '--------'
: End : : End : : End : : End :
:Device 1: :Device 2: :Device 3: :Device 4:
'--------' '--------' '--------' '--------'
(IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4)
(IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3)
]]></artwork>
<postamble></postamble>
</figure>
<section anchor="intra" title="Bridged Traffic Flow: L2 Overlay use">
<t>Bridged traffic is encapsulated using the L2 overlay. This
section provides an example of the unicast packet flow and the
control plane operations when in the topology shown in Figure 1, the
End-Device 2 in site B communicates with the End-Device 3 in site C.
In this case we assume that End Device 2, knows the MAC address of
End-Device 3 (e.g., learned through ARP). <list style="symbols">
<t>End-Device 2 sends an Ethernet/IEEE 802 MAC frame with
destination 0:0:3:0:0:3 and source 0:0:3:0:0:2.</t>
<t>ITR B does a L2 lookup in its local map-cache for the
destination MAC 0:0:3:0:0:3. When the lookup of 0:0:3:0:0:3 is a
miss, the ITR sends a Map-Request to the mapping database system
looking up for EID=<IID2,0:0:3:0:0:3>.</t>
<t>The mapping systems forwards the Map-Request to ETR C, that
has registered the EID-to-RLOC mapping for
EID=<IID2,0:0:3:0:0:3>. Alternatively, depending on the
mapping system configuration, a Map-Server which is part of the
mapping database system MAY send a Map-Reply directly to ITR
B.</t>
<t>ETR C sends a Map-Reply to ITR B that includes the
EID-to-RLOC mapping: EID=<IID2, 0:0:3:0:0:3> ->
RLOC=IP_C, where IP_C is the locator of ETR C.</t>
<t>ITR B populates the local map-cache with the EID to RLOC
mapping, and encapsulates all subsequent packets with a
destination MAC 0:0:3:0:0:3 using destination RLOC=IP_C.</t>
</list></t>
</section>
<section title="L2 Mobility Flow">
<t>The support to L2 mobility covers the requirements to allow an
end-host to move from a given site to another and maintain
correspondence with the rest of end-hosts that are connected to the
same L2 domain (e.g. extended VLAN). This support MUST ensure
convergence of L2 forwarding (MAC based) from the old location to
the new one, when the host completes its move.</t>
<t>The following is a sequence description of the packet flow when
End-Device 2 in the figure moves to Site C, which is extending its
own subnet network. <list style="symbols">
<t>When End-Device 2 is attached or detected in site C, ETR C
sets up the database mapping corresponding to EID=<IID2,
0:0:3:0:0:2>. ETR C sends a Map-Register to the mapping
system registering RLOC=IP_B as locator for EID=<IID2,
0:0:3:0:0:2>.</t>
<t>The Mapping System, after receiving the new registration for
EID=<IID1, 0:0:3:0:0:2> sends a Map-Notify to ETR B with
the new locator set (IP_B). ETR B removes then its local
database mapping and stops registering <IID2,
0:0:3:0:0:2>.</t>
<t>Any PiTR or ITR participating in the same L2-overlay
(corresponding to IID2) that was encapsulating traffic to
0:0:3:0:0:2 before the migration continues encapsulating this
traffic to ETR B.</t>
<t>Once ETR B is notified by the Mapping system, when it
receives traffic from an ITR which is destined to 0:0:3:0:0:2,
it will generate a Solicit-Map-Request (SMR) message that is
sent to the ITR for (IID2,0:0:3:0:0:2).</t>
<t>Upon receiving the SMR the ITR sends a new Map-Request for
the EID=<IID2,0:0:3:0:0:2>. As a response ETR B sends a
Map-Reply that includes the new EID-to-RLOC mapping for
<IID2,0:0:3:0:0:2> with RLOC=IP_B. This entry is cached in
the L2 table of the ITR, replacing the previous one, and traffic
is then forwarded to the new location.</t>
</list></t>
<t></t>
</section>
</section>
<section title="Implementation Considerations">
<section title="L2 Segmentation">
<t>As with L3 overlays, LISP support of L2 segmentation is
structured around the propagation and use of Instance-IDs, and
handled as part of the EID in control plane operations. The encoding
is described in <xref target="I-D.ietf-lisp-lcaf"></xref> and its
use in <xref target="I-D.ietf-lisp-ddt"></xref>. Instance-IDs are
unique to a Mapping System and MAY be used to identify the overlay
type (e.g., L2 or L3 overlay).</t>
<t>An Instance-ID can be used for L2 overlay segmentation. An
important aspect of L2 segmentation is the mapping of VLANs to IIDs.
In this case a Bridge Domain (which is the L2 equivalent to a VRF as
a forwarding context) maps to an IID, a VLAN-ID may map 1:1 to a
bridge domain or different VLAN-IDs on different ports may map to a
common Bridge Domain, which in turn maps to an IID in the L2
overlay. When ethernet traffic is double tagged, usually the outer
802.1Q tag will be mapped to a bridge domain on a per port basis,
and the inner 802.1Q tag will remain part of the payload to be
handled by the overlay. The IID should therefore be able to carry
ethernet traffic with or without an 802.1Q header. A port may also
be configured as a trunk and we may chose to take the encapsulated
traffic and map it to a single IID in order to multiplex traffic
from multiple VLANs on a single IID. These are all examples of local
operations that could be effected on VLANs in order to map them to
IIDs, they are provided as examples and are not exhaustive.</t>
</section>
<section title="L2 Database-Mappings">
<t>When an end-host is attached or detected in an ETR that provides
L2-overlay services, a database Mapping is registered to the mapping
system with the following structure: <list style="symbols">
<t>The EID 2-tuple (IID, MAC) with its binding to a locator set
(IP RLOC)</t>
</list></t>
<t>The registration of these EIDs MUST follow the LCAF format as
defined in <xref target="I-D.ietf-lisp-lcaf"></xref> and as
illustrated in the following figure:</t>
<figure>
<artwork><![CDATA[
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D | Rsvd | Map-Version Number | AFI = 16387 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | Rsvd1 | Flags | Type = 2 | IID mask-len |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | 4 + n | Instance-ID... |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | ...Instance-ID | EID-AFI = 6 |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Layer-2 MAC Address ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| ... Layer-2 MAC Address | Priority | Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | M Priority | M Weight | Unused Flags |L|p|R|
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Loc-AFI | Locator.... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| ... Locator
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The L2 EID record follows the structure as described in <xref
target="RFC6830"></xref>.</t>
</section>
<section title="Interface to the LISP Mapping System">
<t>The interface between the xTRs and the Mapping System is
described in <xref target="RFC6833"></xref> and this document
follows the specification as described there. When available, the
registrations MAY be implemented over a reliable transport as
described in <xref
target="I-D.kouvelas-lisp-map-server-reliable-transport"></xref>.</t>
<t>In order to support system convergence after mobility, when the
Map-Server receives a new registration for a specific EID, it MUST
send a Map-Notify to the entire RLOC set in the site that last
registered this same EID. This Map-Notify is used to track
moved-away state of L2 EIDs as described in <xref
target="l2away"></xref>.</t>
</section>
<section anchor="l2away"
title="SMR support to track L2 hosts that moved away">
<t>In order to support mobility, an ETR SHALL maintain a list of EID
records for which it has to generate a SMR message whenever it
receives traffic with that EID as destination.</t>
<t>The particular strategy to maintain a SMR table is implementation
specific. In essence the table SHOULD provide support for the
following: <list style="symbols">
<t>Keep track of end-hosts that were once connected to an ETR
and have moved away.</t>
<t>Support for L2 EID records, the 2-tuple (IID, MAC), for which
a SMR message SHOULD be generated.</t>
</list></t>
</section>
<section anchor="BUM" title="L2 Broadcast and Multicast traffic">
<t>Broadcast and Multicast traffic on the L2-overlay is supported by
either replicated unicast, or underlay (RLOC) multicast.</t>
<t>xTRs that offer L2 overlay services and are part of the same
Instance-ID join a common Multicast Group. When required, this group
allows ITRs to send traffic that needs to be replicated (flooded) to
all ETRs participating in the L2-overlay (e.g., broadcast traffic
within a subnet). When the core network (RLOC space) supports native
multicast ETRs participating in the L2-overlay join a (*,G) group
associated to the Instance-ID.</t>
<t>When multicast is not available in the core network, each xTR
that is part of the same instance-ID SHOULD register a (S,G) entry
to the mapping system using the procedures described in <xref
target="I-D.ietf-lisp-signal-free-multicast"></xref>, where S is
0000-0000-0000/0 and G is ffff-ffff-ffff/48. This strategy allows
and ITR to know which ETRs are part of the L2 overlay and it can
head-end replicate traffic to.</t>
<t>Following the same case, when multicast is not available in the
core network, the procedures in <xref
target="I-D.ietf-lisp-signal-free-multicast"></xref> can be used to
ensure proper distribution of link-local multicast traffic across
xTRs participating in the L2 overlay. In such case, the xTRs SHOULD
join a (S,G) entry with S being 0000-0000-0000/0 and where G is
0100-0000-0000/8.</t>
</section>
<section anchor="UUnicast" title="L2 Unknown Unicast Support">
<t>An ITR attempts to resolve MAC destination misses through the
Mapping System. When the destination host remains undiscovered the
destination is considered an Unknown Unicast.</t>
<t>A Map-Server SHOULD respond to a Map-Request for an undiscovered
host with a Negative Map-Reply with action "Native Forward".
Alternatively the action "Drop" may be used in order to suppress
Unknown Unicast forwarding.</t>
<t>An ITR that receives a Negative Map-Reply with Action "Native
Forward" will handle traffic for the undiscovered host as L2
Broadcast traffic and will be unicast replicated or flooded using
underlay multicast to the rest of ETRs in the Layer-2 overlay.</t>
<t>Upon discovery of a previously unknown unicast MAC EID, a data
triggered SMR for the discovered EID should be sent by the discovery
ETR back to the ITRs that are flooding the unknown unicast traffic.
This would allow ITRs to refresh their caches and stop flooding
unknown unicast traffic as necessary.</t>
</section>
<section title="Time-to-Live Handling in Data-Plane">
<t>When using a L2 overlay and the encapsulated traffic is IP
traffic, the Time-to-Live value of the inner IP header MUST remain
unmodified during encapsulation and decapsulation. Network hops
traversed as part of the L2 overlay SHOULD be hidden to tools like
traceroute and applications that require direct L2 connectivity.</t>
</section>
</section>
<section title="Support to ARP resolution through Mapping System">
<section anchor="arp_flow"
title="Map-Server support to ARP resolution: Packet Flow">
<t>A large majority of applications are IP based and, as a
consequence, end systems are typically provisioned with IP addresses
as well as MAC addresses.</t>
<t>In this case, to limit the flooding of ARP traffic and reduce the
use of multicast in the RLOC network, the LISP mapping system MAY be
used to support ARP resolution at the ITR.</t>
<t>In order to provide this support, ETRs handle and register an
additional EID-to-RLOC mapping as follows, <list style="symbols">
<t>EID-record contents = <IID, IP>, RLOC-record contents
<MAC>.</t>
</list></t>
<t>There is a dedicated IID used for the registration of the ARP
related mappings. Thus, a system with L2 and L3 overlays as well as
ARP mappings would have three IIDs at play. In the spirit of
providing clarity, we will refer to those IIDs as L2-IID, L3-IID and
ARP-IID respectively. By using these definitions, we do not intend
to coin new terminology, nor is there anything special about those
IIDs that would make them differ from the generic definition of an
IID. The types of mappings expected in such a system are summarized
below: </t>
<t><list style="symbols">
<t>EID = <IID1, IP> to RLOC = <IP-RLOC>
(L3-overlay)</t>
<t>EID = <IID2, MAC> to RLOC = <IP-RLOC>
(L2-overlay)</t>
<t>EID = <IID3, IP> to RLOC = <MAC-RLOC> (ARP/ND
mapping)</t>
</list>The following packet flow sequence describes the use of the
LISP Mapping System to support ARP resolution for hosts residing in
a subnet that is extended to multiple sites. Using Figure 1,
End-Device 2 tries to find the MAC address of End-Device 3. Note
that both have IP addresses within the same subnet: <list
style="symbols">
<t>End-Device 2 sends a broadcast ARP message to discover the
MAC address of End-Device 3. The ARP request targets IP
3.0.0.3.</t>
<t>ITR B receives the ARP message, but rather than flooding it
on the overlay network sends a Map-Request to the mapping
database system for EID = <IID2,3.0.0.3>.</t>
<t>When receiving the Map-Request, the Map-Server sends a
Proxy-Map-Reply back to ITR B with the mapping EID =
<IID2,3.0.0.3> -> MAC 0:0:3:0:0:3.</t>
<t>Using this Map-Reply, ITR B sends an ARP-Reply back to
End-Device 2 with the tuple IP 3.0.0.3, MAC 0:0:3:0:0:3.</t>
<t>End-Device 2 learns MAC 0:0:3:0:0:3 from the ARP message and
can now send a L2 traffic to End-Device 3. When this traffic
reaches ITR B is sent over the L2-overlay as described above in
<xref target="intra"></xref>.</t>
</list></t>
<t>This example shows how LISP, by replacing dynamic data plane
learning (such as Flood-and-Learn) can reduce the use of multicast
in the underlay network.</t>
<t>Note that ARP resolution using the Mapping System is a stateful
operation on the ITR. The source IP,MAC tuple coming from the ARP
request have to be stored to generate the ARP-reply when the
Map-Reply is received.</t>
<t>Note that the ITR SHOULD cache the ARP entry. In that case future
ARP-requests can be handled without sending additional
Map-Requests.</t>
</section>
<section title="ARP registrations: MAC as a locator record">
<t>When an end-host is attached or detected in an ETR that provides
L2-overlay services and also supports ARP resolution using the LISP
control-plane, an additional mapping entry is registered to the
mapping system: <list style="symbols">
<t>The EID 2-tuple (IID, IP) and its binding to a corresponding
host MAC address.</t>
</list></t>
<t>In this case both the xTRs and the Mapping System MUST support an
EID-to-RLOC mapping where the MAC address is set as a locator
record.</t>
<t>In order to guarantee compatibility with current implementations
of xTRs, the MAC locator record SHALL be encoded following the
AFI-List LCAF Type defined in <xref
target="I-D.ietf-lisp-lcaf"></xref>. This option would also allow
adding additional attributes to the locator record, while
maintaining compatibility with legacy devices.</t>
<t>This mapping is registered with the Mapping System using the
following EID record structure,</t>
<figure>
<artwork><![CDATA[
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E | Locator Count | EID mask-len | ACT |A| Reserved |
I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D | Rsvd | Map-Version Number | AFI = 16387 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | Rsvd1 | Flags | Type = 2 | IID mask-len |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | 4 + n | Instance-ID... |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | ...Instance-ID | EID-AFI = 1 or 2 |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EID-Prefix (IPv4 or IPv6) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | Unused Flags |L|p|R| AFI = 16387 |
| A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C | Rsvd1 | Flags | Type = 1 | Rsvd2 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | 2 + 6 | AFI = 6 |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Layer-2 MAC Address ... |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| ... Layer-2 MAC Address |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.
]]></artwork>
</figure>
<t>An EID record with a locator record that carries a MAC address
follows the same structure as described in <xref
target="RFC6830"></xref>. However, some fields of the EID record and
the locator record require special consideration: <list
style="hanging">
<t hangText="Locator Count:">This value SHOULD be set to 1.</t>
<t hangText="Instance-ID:">This is the IID used to provide
segmentation of the L2-overlays, L3 overlays and ARP tables.</t>
<t hangText="Priority and Weight:">IP to MAC bindings are one to
one bindings. An ETR SHOULD not register more than one MAC
address in the locator record together with an IP based EID. The
Priority of the MAC address record is set to 255. The Weight
value SHOULD be ignored and the recommendation is to set it to
0.</t>
<t hangText="L bit:">This bit of the locator record SHOULD only
be set to 1 when an ETR is registering its own IP to MAC
binding.</t>
<t hangText="p bit:">This bit of the locator record SHOULD be
set to 0.</t>
<t hangText="R bit:">This bit of the locator record SHOULD be
set to 0.</t>
</list></t>
<t>Note that an IP EID record that carries a MAC address in the
locator record, SHALL be registered with the Proxy Map-Reply bit
set.</t>
</section>
<section title="Implementation Considerations">
<t>While ARP support through the LISP Mapping System fits the LISP
Control-Plane there are a series of considerations to take into
account when providing this feature: <list style="symbols">
<t>As indicated, when and end-host is attached the ETR maintains
and registers a mapping with the binding EID = <IID, IP>
-> RLOC = <MAC>.</t>
<t>ARP support through the LISP Mapping System is OPTIONAL and
the xTRs should allow the possibility to enable or disable the
feature.</t>
<t>When the ARP entry has not been registered, a Map Server
SHOULD send a Negative Map-Reply with action "No Action" as a
response to an ARP based Map Request.</t>
<t>In case the ITR receives a Negative Map-Reply for an ARP
request it should fallback to flooding the ARP packet as any
other L2 Broadcast packet (as described in <xref
target="BUM"></xref>).</t>
<t>When receiving a positive Map-Reply for an ARP based
Map-Request, the ETR MUST recreate the actual ARP Reply,
impersonating the real host. As a consequence, ARP support is a
stateful operation where the ITR needs to store enough
information about the host that generates an ARP request in
order to recreate the ARP Reply.</t>
<t>ARP replies learned from the Mapping System SHOULD be cached
and the information used to reply to subsequent ARP requests to
the same hosts.</t>
</list></t>
</section>
</section>
</section>
<section anchor="Special" title="Optional Deployment Models">
<t>The support of an integrated L2 and L3 overlay solution takes
multiple architectural design options, that depend on the specific
requirements of the deployment environment. While some of the previous
describe specific packet flows and solutions based on the recommended
solution, this section documents OPTIONAL design considerations that
differ from the recommended one but that MAY be required on alternative
deployment environments.</t>
<section anchor="EF" title="IP Forwarding of Intra-subnet Traffic">
<t>As pointed out at the beginning the recommended selection of the L2
and L3 overlays is not the only one possible. In fact, providing L2
extension to some cloud platforms is not always possible and subnets
need to be extended using the L3 overlay.</t>
<t>In order to send all IP traffic (intra- and inter-subnet) through
the L3 overlay the solution MUST change the ARP resolution process
described in <xref target="arp_flow"></xref> to the following one (we
follow again <xref target="figure_reference"></xref> to drive the
example. End-Device 2 queries about End-Device 3): <list
style="symbols">
<t>End-Device 1 sends a broadcast ARP message to discover the MAC
address of 3.0.0.3.</t>
<t>ITR B receives the ARP message and sends a Map-Request to the
Mapping System for EID = <IID1,3.0.0.3>.</t>
<t>In this case, the Map-Request is routed by the Mapping system
infrastructure to ETR C, that will send a Map-Reply back to ITR B
containing the mapping EID = <IID1,3.0.0.3> ->
RLOC=IP_C.</t>
<t>ITR B populates its local cache with the received entry on the
L3 forwarding table. Then, using the cache information it sends a
Proxy ARP-reply with its own MAC (MAC_xTR_B) address to end
End-Device 1.</t>
<t>End-Device 1 learns MAC_ITR_B from the proxy ARP-reply and
sends traffic with destination address 3.0.0.3 and destination
MAC, MAC_xTR_B.</t>
<t>As the destination MAC address is the one from xTR B, when xTR
B receives this traffic it is forwarded using the L3-overlay.</t>
<t>Note that when implementing this solution, when a host that is
local to an ETR moves away, the ETR SHOULD locally send a
Gratuitous ARP with its own MAC address and the IP of the moved
host, to refresh the ARP tables of local hosts and guarantee the
use of the L3 overlay when connecting to the remote host.</t>
</list></t>
<t>It is also important to note that using this strategy to extend
subnets through the L3 overlay but still keeping the L2 overlay for
the rest of traffic MAY lead to flow asymmetries. This MAY be the case
in deployments that filter Gratuitous ARPs, or when moved hosts
continue using actual L2 information collected before a migration.</t>
</section>
<section title="Data-plane Encapsulation Options">
<t>The LISP control-plane offers independence from the data-plane
encapsulation. Any encapsulation format that can carry a 24-bit
instance-ID can be used to provide the unified overlay.</t>
<t>Common encapsulation formats that can be used are [VXLAN-GPE],
[LISP] and [VXLAN]: <list style="symbols">
<t>VXLAN-GPE encap: This encapsulation format is defined in <xref
target="I-D.ietf-nvo3-vxlan-gpe"></xref>. It allows encapsulation
both L2 and L3 packets and the VNI field directly maps to the
Instance-ID used in the control plane. Note that when using this
encapsulation for a unified solution the P-bit is set and the
Next-Protocol field is used (typically with values 0x1 (IPv4) or
0x2 (IPv6) in L3-overlays, and value 0x3 in L2-overlays).</t>
<t>LISP encap: This is the encapsulation format defined in the
original LISP specification <xref target="RFC6830"></xref>. The
encapsulation allows encapsulating both L2 and L3 packets. The
Instance-ID used in the EIDs directly maps to the Instance-ID that
the LISP header carries. At the ETR, after decapsulation, the IID
MAY be used to decide between L2 processing or L3 processing.</t>
<t>VXLAN encap: This is a L2 encapsulation format defined in <xref
target="RFC7348"></xref>. While being a L2 encapsulation it can be
used both for L2 and L3 overlays. The Instance-ID used in LISP
signaling maps to the VNI field of the VXLAN header. Providing L3
overlays using VXLAN generally requires using the ETR MAC address
as destination MAC address of the inner Ethernet header. The
process to learn or derive this ETR MAC address is not included as
part of this document.</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This draft builds on top of two expired drafts that introduced the
concept of LISP L2/L3 overlays (draft-maino-nvo3-lisp-cp and
draft-hertoghs-nvo3-lisp-controlplane-unified). Many thanks to the
combined authors of those drafts, that SHOULD be considered main
contributors of this draft as well: Vina Ermagan, Dino Farinacci, Yves
Hertoghs, Luigi Iannone, Fabio Maino, Victor Moreno, and Michael
Smith.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6830.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6833.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6831.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7348.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kouvelas-lisp-map-server-reliable-transport-02.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-lcaf-16.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-signal-free-multicast-01.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-nvo3-vxlan-gpe-02.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-ddt-08.xml"?>
<?rfc include="http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-coras-lisp-re-08.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:10:00 |