One document matched: draft-jain-nvo3-vxlan-ping-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Fred Baker (private) -->
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-jain-nvo3-vxlan-ping-00"
ipr="trust200902">
<front>
<title abbrev="Detecting VXLAN Segment Failure">Detecting VXLAN Segment Failure</title>
<author fullname="Pradeep Jain" initials="P." surname="Jain">
<organization>Nuage Networks </organization>
<address>
<postal>
<street>755 Ravendale Drive</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>USA</country>
</postal>
<email>pradeep@nuagenetworks.net</email>
</address>
</author>
<author fullname="Kanwar Singh" initials="K." surname="Singh">
<organization>Nuage Networks</organization>
<address>
<postal>
<street>755 Ravendale Drive</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>USA</country>
</postal>
<email>kanwar@nuagenetworks.net</email>
</address>
</author>
<author fullname="Florin Balus" initials="F." surname="Balus">
<organization>Nuage Networks</organization>
<address>
<postal>
<street>755 Ravendale Drive</street>
<city>Mountain View, CA</city>
<code>94043</code>
<country>USA</country>
</postal>
<email>florin@nuagenetworks.net</email>
</address>
</author>
<author fullname="Wim Henderickx" initials="W." surname="Henderickx">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Copernicuslaan 50</street>
<city>Antwerp</city>
<code>2018</code>
<country>Belgium</country>
</postal>
<email>wim.henderickx@alcatel-lucent.be</email>
</address>
</author>
<author fullname="Vinay Bannai" initials="V." surname="Bannai">
<organization>PayPal</organization>
<address>
<postal>
<street>2211 N. First St,</street>
<city>San Jose</city>
<code>95131</code>
<country>USA</country>
</postal>
<email>vbannai@paypal.com</email>
</address>
</author>
<date day="06" month="June" year="2013" />
<area>Internet Area</area>
<workgroup>NVO3</workgroup>
<abstract>
<t>This proposal describes a mechanism that can be used to detect
Data Path Failures and sanity of VXLAN Control and Data Plane for a given VXLAN Segment.
This document defines the following: </t>
<list style="symbols">
<t>Information carried in a VXLAN "Echo Request", and</t>
<t>"Echo Reply" for the purposes of fault detection and isolation,
and mechanisms for reliably sending the Echo Request and reply.</t>
</list>
</abstract>
</front>
<middle>
<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 RFC2119 <xref
target="RFC2119" />.</t>
<t>When used in lower case, these words convey their typical use in common
language, and are not to be interpreted as described in RFC2119 <xref
target="RFC2119" />.</t>
<section title="Introduction">
<t>VXLAN <xref target="I-D.draft-mahalingam-dutt-dcops-vxlan" />is a
tunneling mechanism to overlay Layer 2 networks on top of Layer 3 networks.
In most cases the end point of the tunnel (VTEP) is intended to be at the
edge of the network, typically connecting an access switch to an IP transport
network. The access switch could be a physical or a virtual switch located
within the hypervisor on the server which is connected to End System which
is a VM. </t>
<t>This document describes a mechanism that can be used to detect Data Plane
failures and sanity of VXLAN Control and Data Plane for a given VXLAN Segment.</t>
<t>There proposal describes: </t>
<list style="symbols">
<t>Information carried in VXLAN "Echo Request",</t>
<t>Information carried in VXLAN "Echo Reply", and</t>
<t>the mechanism to transport the "Echo Request" and "Echo Reply". </t>
</list>
<t>The proposal defines the information to check correct operation of the Data Plane,
as well as a mechanism to verify the Data Plane against the Control Plane for a given
VXLAN Segment.</t>
<t>Its is important consideration in this proposal to carry VXLAN Echo Request along
same data path that normal VXLAN Packets would traverse.</t>
<t>The tenants VM(s) are not aware of the Virtualization Overlays and as such the
need for the verification of the Data Path MUST solely rest with the Cloud Provider.
The use cases where the Tenant VM(s) need to be aware of the Data Plane failures is beyond
the scope of this document.
</t>
</section>
<section title="Terminology">
<t>Terminology used in this document:</t>
<t>VXLAN: Virtual eXtensible Local Area Network.</t>
<t>VTEP: VXLAN Tunnel End Point.</t>
<t>VM: Virtual Machine.</t>
<t> VNI: VXLAN Network Identifier (or VXLAN Segment ID)</t>
<t> NVE: Network Virtulalized Edge </t>
<t>End System: Could be VM etc. - System whose data is expected to go over
VXLAN Segment.</t>
<t>Other terminologies are as defined in
<xref target="I-D.draft-mahalingam-dutt-dcops-vxlan" />.
</t>
</section>
<section title="Need for VXLAN Ping">
<t>When a VXLAN Segment fails to deliver user traffic, there is a need to provide a
tool that would enable users, as Cloud Providers to detect such failures, and a mechanism to
isolate faults. It may also be desirable to test the data path before mapping End System
traffic to the VXLAN Segment.</t>
<t> The basic idea is to facilitate following verifications:-</t>
<list style="symbols">
<t>Packets that are expected to go over a particular VXLAN Segment actually ends up going over the
correct VXLAN Segment to the correct VXLAN Terminating VTEP.</t>
<t>To verify the correct value of VXLAN VN-ID is programmed at Originating and
Terminating VXLAN VTEP(s) for a given VXLAN Segment.</t>
</list>
<t>
To facilitate verification of the above requirements, this document proposes sending of a Packet
(called an "VXLAN Echo Request") along the same data path as other
Packets belonging to this Segment. VXLAN Echo Request also carries
information about the VXLAN Segment whose Data Path is to be verified. This
Echo Request is forwarded just like any other End System Data Packet belonging to
that VXLAN Segment, as it contains the same VXLAN Encapsulation as regular
End System's data which uses the given VXLAN Segment. </t>
<t> On receiving VXLAN Echo Request at the end of the VXLAN Segment, it is sent to the
Control Plane of the Terminating VTEP, which in-turn would respond with VXLAN Echo Reply.</t>
<figure>
<artwork>
+------- L3 Network ------+
| |
| Tunnel Overlay |
+------------+---------+ +---------+------------+
| +----------+-------+ | | +---------+--------+ |
| | Overlay Module | | | | Overlay Module | |
NVE1 | | +-----------+ | | | | +-----------+ | | NVE2
| | | OAM Module| | | | | | OAM Module| | |
| | +-----------+ | | | | +-----------+ | |
| +------------------+ | | +------------------+ |
+----+------------+----+ +----+-----------+-----+
| | | |
-------+------------+-----------------+-----------+-------
| | | |
| | | |
Tenant Systems Tenant Systems
Fig 1
</artwork>
</figure>
<t>As depicted in Fig 1, VXLAN OAM Module SHOULD reside at NVE device and Echo Request and Reply SHOULD
be handled at the NVE.</t>
</section>
<section title="Packet Format">
<t> VXLAN Echo Request/Reply is a IPv4 UDP Packet. Following is the format of VXLAN Echo Packet:</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return Subcode|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Sent (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Received (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs ... |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<texttable style="headers">
<preamble>The Message Type is one of the following:-</preamble>
<ttcol>Value</ttcol>
<ttcol>What it means</ttcol>
<c>1</c>
<c>VXLAN Echo Request</c>
<c>2</c>
<c>VXLAN Echo Reply</c>
</texttable>
<texttable style="headers">
<preamble>Reply Mode Values:-</preamble>
<ttcol>Value</ttcol>
<ttcol>What it means</ttcol>
<c>1</c>
<c>Do not reply</c>
<c>2</c>
<c>Reply via an IPv4/IPv6 UDP Packet</c>
</texttable>
<t> VXLAN Echo Request with 1 (Do not reply) in the Reply Mode field
may be used for one-way connectivity tests; the receiving node may
log gaps in the Sequence Numbers and/or maintain delay/jitter
statistics. For normal operation VXLAN Echo Request would have 2 (Reply via an
IPv4 UDP Packet) in the Reply Mode field.
</t>
<t> The Originator's Handle is filled in by the Originator, and returned
unchanged by the receiver in the Echo Reply (if any). There value used for
this field can be implementation dependent, this MAY be used by the Originator for
matching up requests with replies.</t>
<t>
The Sequence Number is assigned by the sender of the VXLAN echo
request and can be (for example) used to detect missed replies.</t>
<t>
The TimeStamp Sent is the time-of-day (in seconds and microseconds,
according to the sender's clock) in NTP format [NTP] when the VXLAN
Echo Request is sent. The TimeStamp Received in an Echo Reply is the
time-of-day (according to the receiver's clock) in NTP format that
the corresponding Echo Request was received.</t>
<t>
TLVs (Type-Length-Value tuples) have the following format:</t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
Types are defined below; Length is the length of the Value field in
octets. The Value field depends on the Type; it is zero padded to
align to a 4-octet boundary.
</t>
<t> Example of the TLV for VXLAN ping is as follows. </t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (VXLAN ping) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN VNI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV if Sender Address is IPv4
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (VXLAN ping) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN VNI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Sender Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV if Sender Address is IPv6
</artwork>
</figure>
</section>
<section title="Return Codes">
<t>
Sender MUST always set the Return Code set to zero. The receiver can set
it to one of the values listed below when replying back to Echo-Request.</t>
<texttable style="headers">
<preamble>Following are the Return Codes (Suggested):-</preamble>
<ttcol>Value</ttcol>
<ttcol>What it means</ttcol>
<c>0</c>
<c>No return code</c>
<c>1</c>
<c>Malformed Echo Request Received</c>
<c>2</c>
<c>No VN-ID Present</c>
<c>3</c>
<c>Return-Code-OK</c>
</texttable>
</section>
<section title="Procedure for VXLAN Ping">
<t>
VXLAN Echo Request is used to test Data Plane and its view of Control Plane for
particular VXLAN Segment. The VXLAN Segment to be verified is identified by the
"VN-ID". For the Data Plane verification, the complete VXLAN Echo Request Packet
would be encapsulated with the VXLAN header of the given VXLAN Segment. For control
plane's view of the given VXLAN Segment at the Terminating VTEP, the TLV will
be encoded under Echo Request Packet, to identify presence of given VXLAN Segment.</t>
<t>
When VXLAN Echo Request is received, the Terminating VTEP is expected to
verify the consistency of the Control Plane and Data Plane for the VXLAN Segment
identified by the VN-ID.
</t>
<section title="Sending VXLAN Echo Request">
<t>
Inner Ethernet Header for the VXLAN Echo Request Packet should have the Destination
Mac set to 00-00-5E-90-XX-XX (to be assigned IANA); the Source Mac is set to Mac Address
of the Originating VTEP. In the payload portion of this VXLAN Frame. The IP header
is set as follows: the source IP Address is a routable Address of the sender;
the destination IP Address is a (randomly chosen) IPv4 Address from
the range 127/8, IPv6 addresses are chosen from the range 0:0:0:0:0:FFFF:127/104.
The IP TTL is set to 255. The UDP header is set as follows:
the source UDP port is chosen by the sender. It is desired to choose the Source UDP port so
as to exercise the entropy for ECMP/load balancing across the VXLAN Overlay, and it left to
the implementation; the destination UDP port is set to xxxx
(assigned by IANA for VXLAN Echo Requests). The rest of the Echo Request is encoded as
define in above section "Packet Format", VN-ID in the TLV for Echo Request MUST
be same as the VN-ID for the VXLAN Segment. The IPv4 Sender Address is set to the
Address of Originating VTEP's IP Address.
The VXLAN Router Alert option
<xref target="I-D.draft-singh-nvo3-vxlan-router-alert" /> MUST be set in the VXLAN
header as shown below.
A VXLAN Echo Request is sent encapsulated with the VXLAN header corresponding to
the VXLAN Segment being tested.</t>
<figure>
<artwork>
VXLAN Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|R|R|RA| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RA: Router Alter Bit (Proposed)
</artwork>
</figure>
<t> The sender chooses a Originator's Handle and a Sequence Number. When
sending subsequent VXLAN Echo Requests, the sender SHOULD increment
the Sequence Number by 1.</t>
<t>The TimeStamp Sent is set to the time-of-day (in seconds and
microseconds) that the Echo Request is sent. The TimeStamp Received
is set to zero. Also, the Reply Mode must be set to the desired reply mode.
The Return Code and Subcode are set to zero.</t>
</section>
<section title="Receiving VXLAN Echo Request">
<t>At the Terminating VTEP, sending VXLAN Echo Request to the Control Plane is triggered by one
of the following Packet processing exceptions: VXLAN Router Alert option,
<xref target="I-D.draft-singh-nvo3-vxlan-router-alert" /> the Inner Destination MAC Address of
00-00-5E-90-XX-XX as defined in above section, and the Destination IP Address in the 127/8 Address range
for IPv4 Address, or 0:0:0:0:0:FFFF:127/104 for IPv6 Address.
The Control Plane further identifies the VXLAN Echo Request by UDP destination port xxxx.</t>
<t> Once the VXLAN Echo Request Packed is identified at Control Plane, it is processed as follows:-</t>
<list style="symbols">
<t> General Packet sanity is verified. If the Packet is not well-
formed, VTEP SHOULD send VXLAN Echo Reply with the Return Code
set to "Malformed Echo Request received" and the Subcode to zero.
The header fields Originator's Handle, Sequence Number, and Timestamp
Sent are not examined, but are included in the VXLAN Echo Reply message</t>
<t> VNI Validation:
If there is no entry for VN-ID, it indicates that there could be a transient or permanent disconnect
between Control Plane and data palne and VTEP needs to report an error with Return Code of "No VN-ID Present"
and a Return Subcode of Zero.
If the mapping exists then send VXLAN Echo Reply with a Return Code of "Return-Code-OK",
and a Return Subcode of Zero. The procedures for sending the Echo Reply are
found in subsection below section.</t>
</list>
</section>
<section title="Sending VXLAN Echo Reply">
<t>VXLAN Echo Reply is a UDP Packet. It MUST ONLY be sent in response
to VXLAN Echo Request. The Source IP Address is a routable Address
of the replier; the source port is the well-known UDP port for VXLAN
ping. The Destination IP Address and UDP port are copied from the
Source IP Address and UDP port of the Echo Request. The IP TTL is
set to 255.</t>
<t>The format of the Echo Reply is the same as the Echo Request. The
Originator Handle, the Sequence Number, and TimeStamp Sent are copied
from the Echo Request; the TimeStamp Received is set to the time-of-
day that the Echo Request is received (note that this information is
most useful if the time-of-day clocks on the requester and the
replier are synchronized).The replier MUST fill in the Return Code and Subcode,
as determined in the previous subsection.</t>
</section>
<section title="Receiving VXLAN Echo Reply">
<t> An Originating VTEP should only receive VXLAN Echo Reply in response to an
VXLAN Echo Request that it sent. Thus, on receipt of VXLAN echo
reply, Originating VTEP should parse the Packet to ensure that it is well-formed,
then attempt to match up the Echo Reply with an Echo Request that it
had previously sent, using the destination UDP port and the Originator
Handle. If no match is found, then VTEP should drop the Echo Reply Packet;
otherwise, it checks the Sequence Number to see if it matches.
</t>
</section>
</section>
<section title="Security Considerations">
<t> TBD </t>
</section>
<section title="Management Considerations">
<t>None</t>
</section>
<section anchor="Ack" title="Acknowledgements">
<t>
This document is the outcome of many discussions among many people,
including Diego Garcia Del Rio, Saurabh Shrivastava and Suresh Boddapati
of Nuage Networks and Jorge Rabadan of Alcatel-Lucent, Inc.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>Action-1: This specification reserves a IANA UDP Port Number to be used when sending
the VXLAN Echo Request Packet.</t>
<t> Action-2: This specification reserves a IANA Ethernet unicast
Address for VXLAN Exception handling. This Address needs to be reserved
from the block. "IANA Ethernet Address block - Unicast Use"</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="I-D.draft-mahalingam-dutt-dcops-vxlan">
<front>
<title>VXLAN: A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks</title>
<author fullname="Mallik Mahalingam" initials="M" surname="Mahalingam">
<organization></organization>
</author>
<author fullname="Dinesh G. Dutt" initials="D" surname="Dutt">
<organization></organization>
</author>
<author fullname="Puneet Agarwal" initials="P" surname="Agarwal">
<organization></organization>
</author>
<author fullname="Lawrence Kreeger" initials="L" surname="Kreeger">
<organization></organization>
</author>
<author fullname="T. Sridhar" initials="T" surname="Sridhar">
<organization></organization>
</author>
<author fullname="Mike Bursell" initials="M" surname="Bursell">
<organization></organization>
</author>
<author fullname="Chris Wright" initials="C" surname="Wright">
<organization></organization>
</author>
<date day="08" month="May" year="2013" />
<abstract>
<t>.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.draft-lasserre-nvo3-framework">
<front>
<title>Framework for DC Network Virtualization</title>
<author fullname="Marc Lasserre" initials="M" surname="Lasserre">
<organization></organization>
</author>
<author fullname="Florin Balus" initials="F" surname="Balus">
<organization></organization>
</author>
<author fullname="Thomas Morin" initials="T" surname="Morin">
<organization></organization>
</author>
<author fullname="Nabil Bitar" initials="N" surname="Bitar">
<organization></organization>
</author>
<author fullname="Yakov Rekhter" initials="Y" surname="Rekhter">
<organization></organization>
</author>
<date day="15" month="September" year="2011" />
<abstract>
<t>.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.draft-singh-nvo3-vxlan-router-alert">
<front>
<title>VxLAN Router Alert Option</title>
<author fullname="Kanwar Singh" initials="K" surname="Singh">
<organization></organization>
</author>
<author fullname="Pradeep Jain" initials="P" surname="Jain">
<organization></organization>
</author>
<author fullname="Florin Balus" initials="F" surname="Balus">
<organization></organization>
</author>
<author fullname="Wim Henderickx" initials="W" surname="Henderickx">
<organization></organization>
</author>
<date day="24" month="May" year="2013" />
<abstract>
<t>.</t>
</abstract>
</front>
</reference>
<!--
<reference anchor="I-D.draft-lasserre-nvo3-framework">
<seriesInfo name="Internet-Draft"
value="draft-lasserre-nvo3-framework-03" />
<format target="http://tools.ietf.org/id/draft-lasserre-nvo3-framework-03"
type="TXT" />
<author fullname="Marc Lasserre" initials="M" surname="Lasserre">
<organization></organization>
</author>
<author fullname="Florin Balus" initials="F" surname="Balus">
<organization></organization>
</author>
<author fullname="Thomas Morin" initials="T" surname="Morin">
<organization></organization>
</author>
<author fullname="Nabil Bitar" initials="N" surname="Bitar">
<organization></organization>
</author>
<author fullname="Yakov Rekhter" initials="Y" surname="Rekhter">
<organization></organization>
</author>
</reference>
-->
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4379'?>
<?rfc include='reference.RFC.4330'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:42:55 |