One document matched: draft-ietf-spring-oam-usecase-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-spring-oam-usecase-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
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="SR MPLS monitoring use case">Use case for a scalable and topology aware MPLS
data plane monitoring system</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Ruediger Geib" initials="R." role="editor" surname="Geib">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street>Heinrich Hertz Str. 3-7</street>
<!-- Reorder these if your country does things differently -->
<code>64295</code>
<city>Darmstadt</city>
<region/>
<country>Germany</country>
</postal>
<phone>+49 6151 5812747</phone>
<email>Ruediger.Geib@telekom.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street/>
<!-- Reorder these if your country does things differently -->
<code/>
<city>Brussels</city>
<region/>
<country>Belgium</country>
</postal>
<phone/>
<email>cfilsfil@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709-4987</code>
<country>US</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author initials="N." surname="Kumar" fullname="Nagendra Kumar">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7200 Kit Creek Road</street>
<city>Research Triangle Park</city> <region>NC</region> <code>27709</code>
<country>US</country>
</postal>
<email>naikumar@cisco.com</email>
</address>
</author>
<date month="October" year="2015"/>
<!-- 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>Routing</area>
<workgroup>spring</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>Segment based Routing, OAM, LSP surveillance, MPLS monitoring</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>This document describes features and a use case of a path monitoring
system. Segment based routing enables a scalable and simple method to monitor
data plane liveliness of the complete set of paths belonging to a single domain.
Compared with legacy MPLS ping and path trace, MPLS topology awareness
reduces management and control plane involvement of OAM measurements
while enabling new OAM features.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>It is essential for a network operator to monitor all the forwarding paths
observed by the transported user packets. The monitoring flow
is expected to be forwarded in dataplane in a similar way as user packets. Segment Routing
enables forwarding of packets along pre-defined paths and segments and thus a
Segment Routed monitoring packet can stay in dataplane while passing along one
or more segments to be monitored.</t>
<t>This document describes illustrates use-cases based on data plane path
monitoring capabilities. The use case is limited to a single IGP MPLS domain.</t>
<t>The use case applies to monitoring of LDP LSP's as well as to
monitoring of Segment Routed LSP's. As compared to LDP, Segment Routing
is expected to simplify the use case by enabling MPLS topology detection
based on IGP signaled segments as <xref target="ID.sr-isis">specified by </xref>. Thus a
centralised and MPLS topology aware monitoring unit can be realized in a
Segment Routed domain. This topology awareness can be used
for OAM purposes as described by this use case. The MPLS path monitoring
system described by this document can be realised with pre-Segment based Routing (SR)
technology. Making such a pre-SR MPLS monitoring system aware of a domains
complete MPLS topology requires e.g. management plane access. To
avoid the use of stale MPLS label information, IGP must be monitored
and MPLS topology must be timely aligned with IGP topology.
Obviously, enhancing IGPs to exchange of MPLS topology information as done by SR
significantly simplifies and stabilises such an MPLS path monitoring system.
</t>
<t>This document adopts the terminology and framework described in <xref target="ID.sr-archi"/>.
It further adopts the editorial simplification explained in section 1.2 of
the <xref target="ID.sr-use">segment routing use-cases</xref>.</t>
<t>The use case offers several benefits for network monitoring.
A single centralized monitoring device is able to monitor the
complete set of a domains forwarding paths. Monitoring packets never leave
data plane. MPLS path trace function (whose specification and features
are not part of this use case) is required, if the actual data plane
of a router should be checked against its control plane. SR capabilities
allow to direct MPLS OAM packets from a centralized monitoring system to
any router within a domain whose path should be traced.</t>
<t>In addition to monitoring paths, problem localization is required.
Faults can be localized:</t>
<t><list style="symbols">
<t>by IGP LSA analysis.</t>
<t>correlation between different SR based monitoring probes.</t>
<t>by any MPLS traceroute method (possibly in combination
with SR based path stacks).</t>
</list></t>
<t>Topology awareness is an essential part of link state IGPs. Adding
MPLS topology awareness to an IGP speaking device hence enables a
simple and scalable data plane based monitoring mechanism.</t>
<t>MPLS OAM offers flexible features to recognise an execute data paths of
an MPLS domain. By utilising the ECMP related tool set offered e.g. by
<xref target="RFC4379">RFC 4379</xref>, a segment based routing LSP
monitoring system may:</t>
<t><list style="symbols">
<t>easily detect ECMP functionality and properties of paths at data level.</t>
<t>construct monitoring packets executing desired paths also if ECMP is present.</t>
<t>limit the MPLS label stack of an OAM packet to a minmum of 3 labels.</t>
</list></t>
<t>Alternatively, any path may be executed by building suitable label
stacks. This allows path execution without ECMP awareness.</t>
<t>The MPLS path monitoring system may be a any server residing
at a single interface of the domain to be monitored. It doesn't have to
support any specialised protocol stack, it just should be capable of
understanding the topology and building the probe packet with the right
segment stack. As long as measurement packets return to this or another
interface connecting such a server, the MPLS monitoring servers are the
single entities pushing monitoring packet label stacks. If the depth of
label stacks to be pushed by a path monitoring system (PMS) are of concern for a domain, a
dedicated server based path monitoring architecture allows limiting
monitoring related label stack pushes to these servers.
</t>
<t>First drafts discussing SR OAM requirements and
possible solutions to allow SR usage as described by this document
have been submitted already, see <xref target="ID.sr-4379ext"/> and <xref target="ID.sr-oam_detect"/>.</t>
</section>
<section title="An MPLS topology aware path monitoring system">
<t>An MPLS PMS which is able to learn the IGP LSDB
(including the SID's) is able to execute arbitrary chains of label switched paths.
It can send pure monitoring packets along such a path chain or it can direct
suitable MPLS OAM packets to any node along a path segment. Segment Routing here
is used as a means of adding label stacks and hence transport to standard MPLS OAM
packets, which then detect correspondence of control and data plane of this (or any
other addressed) path. Any node connected to an SR domain is
MPLS topology aware (the node knows all related IP addresses, SR SIDs and MPLS labels).
Thus a PMS connected to an MPLS SR domain just needs to set up a topology data base
for monitoring purposes.
</t>
<t>Let us describe how the PMS constructs a labels stack to transport a packet to
LER i, monitor the path of it to LER j and then receive the packet back.</t>
<t> The PMS may do so by sending packets carrying the following MPLS label
stack infomation:</t>
<t><list style="symbols">
<t>Top Label: a path from PMS to LER i, which is expressed as Node SID of
LER i.</t>
<t>Next Label: the path that needs to be monitored from LER i to LER j.
If this path is a single physical interface (or a bundle of connected
interfaces), it can be expressed by the related AdjSID. If the shortest
path from LER i to LER j is supposed to be monitored, the Node-SID
(LER j) can be used. Another option is to insert a list of segments
expressing the desired path (hop by hop as an extreme case). If
LER i pushes a stack of Labels based on a SR policy decision and this
stack of LSPs is to be monitored, the PMS needs an interface to collect
the information enabling it to address this SR created path.</t>
<t>Next Label or address: the path back to the PMS. Likely, no further
segment/label is required here. Indeed, once the packet reaches LER j,
the 'steering' part of the solution is done and the probe just needs
to return to the PMS. This is best achieved by popping the MPLS stack
and revealing a probe packet with PMS as destination address (note
that in this case, the source and destination addresses could be the
same). If an IP address is applied, no SID/label has to be assigned
to the PMS (if it is a host/server residing in an IP subnet outside
the MPLS domain).</t>
</list></t>
<t>Note: if the PMS is an IP host not connected to the MPLS domain, the
PMS can send its probe with the list of SIDs/Labels onto a suitable
tunnel providing an MPLS access to a router which is part of the monitored
MPLS domain.</t>
</section>
<section title="SR based path monitoring use case illustration">
<section title="Use-case 1 - LSP dataplane monitoring">
<figure anchor="PMS_use_case_1">
<preamble/>
<artwork>
+---+ +----+ +-----+
|PMS| |LSR1|-----|LER i|
+---+ +----+ +-----+
| / \ /
| / \__/
+-----+/ /|
|LER m| / |
+-----+\ / \
\ / \
\+----+ +-----+
|LSR2|-----|LER j|
+----+ +-----+
</artwork>
<postamble>Example of a PMS based LSP dataplane monitoring</postamble>
</figure>
<t>For the sake of simplicity, let's assume that all the nodes are
configured with the same <xref target="ID.sr-archi">SRGB</xref>,
as described by section 1.2 of <xref target="ID.sr-use"/>.</t>
<t>Let's assign the following Node SIDs to the nodes of the figure:
PMS = 10, LER i = 20, LER j = 30.</t>
<t>To be able to work with the smallest possible SR label stack, first
a suitable MPLS OAM method is used to detect the ECMP routed path between
LER i to LER j which is to be monitored (and the required address information
to direct a packet along it). Afterwards the PMS sets up and sends packets to
monitor availability of the detected path. The PMS does this by creating
a measurement packet with the following label stack (top to bottom):
20 - 30 - 10. The packet will only reliably use the monitored path, if the
label and address information used in combination with the MPLS OAM method
of choice is identical to that of the monitoring packet.
</t>
<t>LER m forwards the packet received from the PMS to LSR1. Assuming
Pen-ultimate Hop Popping to be deployed, LSR1 pops the top label and
forwards the packet to LER i. There the top label has a value 30 and
LER i forwards it to LER j. This will be done transmitting the packet
via LSR1 or LSR2. The LSR will again pop the top label. LER j will
forward the packet now carrying the top label 10 to the PMS (and it
will pass a LSR and LER m).</t>
<t>A few observations on the example given in figure 1:</t>
<t><list style="symbols">
<t>The path PMS to LER i must be available. This path must be detectable,
but it is usually sufficient to apply a Shortest Path First algorithm based path.</t>
<t>If ECMP is deployed, it may be desired to measure along both
possible paths which a packet may use between LER i and LER j. To do
so, the MPLS OAM mechanism chosen to detect ECMP must reveal the required
information (an example is a so called tree trace) between LER i and LER j.
This method of dealing with ECMP based load balancing paths requires the
smallest SR label stacks if monitoring of paths is applied
after the tree trace completion.
</t>
<t>The path LER j to PMS to must be available. This path must be
detectable, but it is usually sufficient to apply an SPF based path.</t>
</list></t>
<t>Once the MPLS paths (Node SIDs) and the required information to
deal with ECMP has been detected, the paths of LER i to LER j can
be monitored by the PMS. Monitoring itself does not require MPLS
OAM functionality. All monitoring packets stay on dataplane, hence
path monitoring does no longer require control plane interaction in
any LER or LSR of the domain. To ensure reliable results, the PMS
should be aware of any changes in IGP or MPLS topology. Further
changes in ECMP functionality at LER i will impact results. Either
the PMS should be notified of such changes or they should be limited
to planned maintenance. After a topology change, a suitable MPLS
OAM mechanism may be useful to detect the impact of the change.
</t>
<t>Determining a path to be executed prior to a measurement may also be
done by setting up a label stack including all Node SIDs along that path (if
LSR1 has Node SID 40 in the example and it should be passed between
LER i and LER j, the label stack is 20 - 40 - 30 - 10). The advantage of
this method is, that it does not involve MPLS OAM functionality and it
is independent of ECMP functionalities. The method still is able to monitor
all link combinations of all paths of an MPLS domain. If correct forwarding
along the desired paths has to be checked, some suitable MPLS OAM mechanism may be
applied also in this case.</t>
<t>In theory at least, a single PMS is able to monitor data plane availability
of all LSPs in the domain. The PMS may be a router, but could also be
dedicated monitoring system. If measurement system reliability is an
issue, more than a single PMS may be connected to the MPLS domain.</t>
<t>Monitoring an MPLS domain by a PMS based on SR offers the option of
monitoring complete MPLS domains with little effort and very excellent
scalability. Data plane failure detection by circulating monitoring packets
can be executed at any time. The PMS further could be enabled to
send MPLS OAM packets with the label stacks and address information
identical to those of the monitoring packets to any node of the MPLS domain.
It does not require access to LSR/LER management interfaces or their
control plane to do so.</t>
</section>
<section title="Use-case 2 - Monitoring a remote bundle">
<figure anchor="PMS_use_case_2">
<preamble/>
<artwork>
+---+ _ +--+ +-------+
| | { } | |---991---L1---662---| |
|PMS|--{ }-|R1|---992---L2---663---|R2 (72)|
| | {_} | |---993---L3---664---| |
+---+ +--+ +-------+
</artwork>
<postamble>SR based probing of all the links of a remote bundle</postamble>
</figure>
<t>R1 addresses Lx by the Adjacency SID 99x, while R2 addresses
Lx by the Adjacency SID 66(x+1).</t>
<t>In the above figure, the PMS needs to assess the dataplane availability
of all the links within a remote bundle connected to routers R1 and R2.</t>
<t>The monitoring system retrieves the SID/Label information from the IGP
LSDB and appends the following segment list/label stack: {72, 662, 992, 664}
on its IP probe (whose source and destination addresses are the address
of the PMS).</t>
<t>PMS sends the probe to its connected router. If the connected router
is not SR compliant, a tunneling technique can be used to tunnel the
probe and its MPLS stack to the first SR router. The MPLS/SR domain
then forwards the probe to R2 (72 is the Node SID of R2). R2 forwards
the probe to R1 over link L1 (Adjacency SID 662). R1 forwards the probe
to R2 over link L2 (Adjacency SID 992). R2 forwards the probe to R1
over link L3 (Adjacency SID 664). R1 then forwards the IP probe to PMS
as per classic IP forwarding.</t>
</section>
<section title="Use-Case 3 - Fault localization">
<t>In the previous example, a uni-directional fault on the middle link
in direction of R2 to R1 would be localized by sending the following two probes
with respective segment lists:</t>
<t><list style="symbols">
<t>72, 662, 992, 664</t>
<t>72, 663, 992, 664</t>
</list></t>
<t>The first probe would fail while the second would succeed. Correlation
of the measurements reveals that the only difference is using the Adjacency
SID 662 of the middle link from R1 to R2 in the non successful measurement.
Assuming the second probe has been routed correctly, the fault must have
been occurring in R2 which didn't forward the packet to the interface
identified by its Adjacency SID 662.</t>
</section>
</section>
<section title="Failure Notification from PMS to LERi">
<t>PMS on detecting any failure in the path liveliness may use any out-of-band
mechanism to signal the failure to LER i. This document does not propose any
specific mechanism and operators can choose any existing or new approach.
</t>
<t>Alternately, the Operator may log the failure in local monitoring system and
take necessary action by manual intervention.
</t>
</section>
<section title="Applying SR to monitor LDP paths">
<t>A SR based PMS connected to a MPLS domain consisting of LER and LSR
supporting SR and LDP in parallel in all nodes may use SR paths to
transmit packets to and from start and end points of LDP paths to be
monitored. In the above example, the label stack top to bottom may be
as follows, when sent by the PMS:</t>
<t><list style="symbols">
<t>Top: SR based Node-SID of LER i at LER m.</t>
<t>Next: LDP label identifying the path to LER j at LER i.</t>
<t>Bottom: SR based Node-SID identifying the path to the PMS at
LER j</t>
</list></t>
<t>While the mixed operation shown here still requires the PMS to be aware
of the LER LDP-MPLS topology, the PMS may learn the SR MPLS topology by
IGP and use this information.</t>
</section>
<section title="PMS monitoring of different Segment ID types">
<t>MPLS SR topology awareness should allow the SID to monitor liveliness
of most types of SIDs (this may not be recommendable if a SID identifies
an inter domain interface). </t>
<t>To match control plane information with data plane information, MPLS OAM
functions as defined by e.g. RFC4379 should be enhanced to allow collection
of data relevant to check all relevant types of Segment IDs.</t>
</section>
<section title="Connectivity Verification using PMS">
<t>While the PMS based use cases explained in Section 3 are sufficient to provide
continuity check between LER i and LER j, it may not
help perform connectivity verification. So in some cases like data plane
programming corruption, it is possible that a transit node between LER i and LER j
erroneously removes the top segment ID and forwards a monitoring packet to the PMS
based on the bottom segment ID leading to a falsified path liveliness indication by the
PMS.
</t>
<t>There are various method to perform basic connectivity verification like
intermittently setting the TTL to 1 in bottom label so LER j selectively perform
connectivity verification. Other methods are possible and may be added when
requirements and solutions are specified.
</t>
</section>
<section title="Extensions of related standards helpful for this use case">
<t>The following activities are welcome enhancements supporting this
use case, but they are not part of it:
</t>
<t>RFC4379 functions should be extended to support Flow- and Entropy Label
based ECMP.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>As mentioned in the introduction, a PMS monitoring packet should never
leave the domain where it originated. It therefore should never use stale
MPLS or IGP routing information. Further, assigning different label ranges
for different purposes may be useful. A well known global service level
range may be excluded for utilisation within PMS measurement packets.
These ideas shouldn't start a discussion. They rather should point out,
that such a discussion is required when SR based OAM mechanisms like a
SR are standardised.
</t>
</section>
<section title="Acknowledgement">
<t>The authors would like to thank Nobo Akiya for his contribution. Raik Leipnitz
kindly provided an editorial review.</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.xml"?-->
<?rfc include='reference.RFC.4379'?>
<!-- the following is the minimum to make xml2rfc happy -->
<!--
<reference anchor="min_ref"
<front>
<title>Minimal Reference</title>
<author initials="authInitials" surname="authSurName">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference>
-->
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!-- A reference written by by an organization not a person. -->
<reference anchor="ID.sr-archi">
<front>
<title>Segment Routing Architecture
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2014"/>
</front>
<seriesInfo name="IETF, " value="https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing/"/>
</reference>
<reference anchor="ID.sr-use">
<front>
<title>Segment Routing Use Cases
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IETF, " value="http://datatracker.ietf.org/doc/draft-filsfils-rtgwg-segment-routing-use-cases/"/>
</reference>
<reference anchor="ID.sr-isis">
<front>
<title>IS-IS Extensions for Segment Routing
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2014"/>
</front>
<seriesInfo name="IETF, " value="http://datatracker.ietf.org/doc/draft-previdi-isis-segment-routing-extensions/"/>
</reference>
<reference anchor="ID.sr-4379ext">
<front>
<title>Label Switched Path (LSP) Ping/Trace for Segment
Routing Networks Using MPLS Dataplane
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IETF, " value="http://datatracker.ietf.org/doc/draft-kumar-mpls-spring-lsp-ping/"/>
</reference>
<reference anchor="ID.sr-oam_detect">
<front>
<title>Detecting Multi-Protocol Label Switching (MPLS) Data
Plane Failures in Source Routed LSPs
</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IETF, " value="http://datatracker.ietf.org/doc/draft-kini-spring-mpls-lsp-ping/"/>
</reference>
</references>
<!-- Change Log
v00 2013-10-15 RG Initial version
v01 2013-11-01 RG Included input of Clarence, editorial
changes
v02 2014-07-02 RG Included input of team, text re-arrangements and explanations
v03 2014-10-13 RG Removed solution language, clarified use case features and role
of MPLS OAM as helpful toolset outside of this use case.
Editorial changes.
v04 2015-03-05 RG No changes, no discussion, ready for adoption. Waiting for
progress of the WG administration.
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:33:23 |