One document matched: draft-xia-sfc-yang-oam-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-xia-sfc-yang-oam-04" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="SFC OAM YANG Model">YANG Data Model for SFC Operations,
Administration, and Maintenance (OAM)</title>
<author fullname="Liang Xia" initials="L" surname="Xia">
<organization abbrev="Huawei">Huawei Technologies,Co.,Ltd</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<street/>
<city>Nanjing</city>
<region/>
<code>210012</code>
<country>China</country>
</postal>
<email>frank.xialiang@huawei.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<author fullname="Deepak Kumar" initials="D." surname="Kumar">
<organization abbrev="Cisco">Cisco Systems</organization>
<address>
<postal>
<street>510 McCarthy Blvd Milpitas,</street>
<street/>
<city>CA</city>
<region/>
<code>95035</code>
<country>USA</country>
</postal>
<email>dekumar@cisco.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M" surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street>Rennes 35000</street>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Zitao Wang" initials="Z." surname="Wang">
<organization abbrev="Huawei">Huawei Technologies,Co.,Ltd</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<street/>
<city>Nanjing</city>
<region/>
<code>210012</code>
<country>China</country>
</postal>
<email>wangzitao@huawei.com</email>
</address>
</author>
<date year="2015"/>
<area>Routing Area</area>
<workgroup>Network Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>SFC YANG OAM</keyword>
<abstract>
<t>This document defines YANG data model for Service Function Chaining
(SFC Operations, Administration, and Maintenance (OAM). It extends from
the basic YANG data model for Layer independent OAM Management defined
in [I-D.ietf-lime-yang-oam-model] with SFC technology specifics. It
includes SFC OAM related configuration, state, and RPC information
data.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>YANG [RFC6020] is a data modeling language used to model
configuration and state data manipulated by the Network Configuration
Protocol (NETCONF) [RFC6241], NETCONF remote procedure calls (RPC), and
NETCONF notifications. This document defines the YANG data model for
Service Function Chaining (SFC) OAM [I-D.ietf-sfc-oam-framework]. The
SFC OAM YANG module involves the OAM configuration, RPCs and
notifications, etc.</t>
<t>Currently, [I-D.ietf-lime-yang-oam-model] proposes a basic YANG data
model for Layer independent OAM Management that can be applied to
various OAM technologies. SFC OAM YANG data model can be defined by
directly extending the basic model with SFC technology specifics. It can
bring some obvious benefits such as unified format, reusable parts, and
correlation of defects, faults, network failure at the specific
layer.</t>
<t>In addition, various components in the SFC technology specific YANG
data model defined in [I-D.penno-sfc-yang] can be directly reused in
this draft to define the SFC OAM YANG data model.</t>
<t>Note that SFC OAM mechanisms are not yet defined or standardized
although some of the basic concepts and functions (e.g., fault
detection, fault localization, performance measurement, etc) may be
similar to traditional OAM mechanisms. This draft should get alignment
with the latest development SFC OAM mechanisms.</t>
</section>
<section title="Conventions and Terminology">
<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"/>.</t>
<t>The following terms are defined in [RFC6241] and are not redefined
here:</t>
<t><list style="symbols">
<t>client</t>
<t>configuration data</t>
<t>server</t>
<t>state data</t>
</list></t>
<t>The following terms are defined in [RFC6020] and are not redefined
here:</t>
<t><list style="symbols">
<t>augment</t>
<t>data model</t>
<t>data node</t>
</list></t>
<t>The terminology for describing YANG data models is found in
[RFC6020].</t>
<t>The following notations are used within the data tree and carry the
meaning as noted below.</t>
<t>Each node is printed as:<figure>
<artwork>
<status> <flags> <name> <opts> <type>
<status> is one of:
+ for current
x for deprecated
o for obsolete
<flags> is one of:
rw for configuration data
ro for non-configuration data
-x for rpcs
-n for notifications
<name> is the name of the node</artwork>
</figure></t>
<t>If the node is augmented into the tree from another module, its name
is printed as <prefix>:<name>. <figure>
<artwork><opts> is one of:
? for an optional leaf or choice
! for a presence container
* for a leaf-list or list
[<keys>] for a list's keys
<type> is the name of the type for leafs and leaf-lists</artwork>
</figure></t>
<t>In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.</t>
<section title="Terminologies">
<t><list style="hanging">
<t hangText="MP">Maintenance Point [8021Q]</t>
<t hangText="MEP">Maintenance End Point [8021Q] [RFC6371]</t>
<t hangText="MIP">Maintenance Intermediate Point [8021Q]
[RFC6371]</t>
<t hangText="MEG">Maintenance Entity Group [Y1731] [RFC6371]</t>
<t hangText="ME">Maintenance Entity [Y.1731] [RFC6371]</t>
<t hangText="MD">Maintenance Domain [8021Q]</t>
<t hangText="OAM">Operations, Administration, and Maintenance
[RFC6291]</t>
<t hangText="LIME">Layer Independent OAM Management
[I-D.ietf-lime-yang-oam- model]</t>
<t hangText="SF">Service Function [I-D.penno-sfc-yang]</t>
<t hangText="SFC">Service Function Chaining
[I-D.penno-sfc-yang]</t>
<t hangText="SFF">Service Function Forwarder
[I-D.penno-sfc-yang]</t>
<t hangText="TRILL">Transparent Interconnection of Lots of Links
[RFC6325]</t>
<t hangText="RPC">Remote Process Call</t>
</list></t>
</section>
</section>
<section title="Architecture of OAM YANG Model and Relationship to SFC OAM">
<t>Layer independent OAM YANG model [I-D.ietf-lime-yang-oam-model] is
used as the basis for all the other OAM YANG models. This allows users
to span across OAM tools of different technologies through a uniform
API. The following Figure depicts the relationship of SFC OAM YANG model
to the Layer Independent OAM YANG Model. <figure
title="Relationship of SFC OAM YANG model to Layer independent OAM YANG model">
<artwork>
+-+-+-+-+-+
| gen |
|OAM YANG |
+-+-+-+-+-+
|
O
|
+-----------+----------+----------+----------+--------------+
| | | | | |
+-+-+-+-++ +-+-++--++ +-+-+++-++ +-+--+--++ +-+-+++-++ +-+-+-+-++
| TRILL | | NVO3 | | MPLS | | IP | | SFC |. . .| foo |
|OAM YANG| |OAM YANG| |OAM YANG| |OAM YANG| |OAM YANG| |OAM YANG|
+-+-+-+-++ +-+-++--++ +-+-++--++ +-+-++--++ +-+-++--++ +-+-+-+-++
| | | | | |
| +-+-++--++ +-+-++--++ | +-+-++--++ +-+-+-+-++
| | NVO3 | | MPLS | | | SFC |. . .| foo |
| |sub tech| |sub tech| | |sub tech| |sub tech|
| +-+-++--++ +-+-++--++ | +-+-++--++ +-+-+-+-++
| | | | | |
| | | | | |
+--------------------------------------------------------------+
| Uniform API |
+--------------------------------------------------------------+
</artwork>
</figure></t>
</section>
<section title="SFC Extensions to LIME YANG Model">
<t>A new Technology parameter of SFC is defined here for the purpose of
identifying the SFC specific YANG model extension:</t>
<figure title="SFC identity type">
<artwork> identity SFC {
base goam:technology-types;
description
"SFC type";
}</artwork>
</figure>
<t>Only when the Technology parameter is set to the "SFC" value, the SFC
specific extensions are applied.</t>
<section title="MEP Address">
<t>In SFC, either the SF on service function layer or SF/SFF on SFC
forwarding layer can be MEP/MIP. A MEP/MIP cannot be identified
without specifying service function path. Therefore the MEP/MIP
address can only be identified by SF/SFF address plus service function
path id. In [I-D.ietf-lime-yang-oam-model], MEP/MIP address is defined
using a combination of choice and case statement. We augment this to
include SFC specific SF/SFF address plus service function path id.
<figure title="Augment SFC MEP address">
<artwork> augment
"/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:mp-
address" {
case sf-mep-address {
description
"Service function (or service function forwarder) address plus
service function path id to identify one SFC MEP. A SFC MP can
be a service function or service function forwarder!"
leaf sf-mep-ref {
when "/goam:domains/goam:domain/goam:technology='sfc'";
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
when "/goam:domains/goam:domain/goam:technology='sfc'";
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
description
"Service function forwarder address plus service function path
id identify one SFC MEP. A SFC MP can be a service function or
service function forwarder!"
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}</artwork>
</figure></t>
</section>
<section title="Connectivity-Context">
<t>In SFC, connectivity-context is the service function path id. [I-
D.ietf-lime-yang-oam-model] defines a placeholder for
connectivity-context. This allows other technologies to easily augment
that to include technology specific extensions. The snippet below
depicts an example of augmenting connectivity-context to include the
SFC connectivity- context.</t>
<figure title="Augment SFC Connectivity-Context">
<artwork>augment "/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:
connectivity-context" {
case connectivity-context-sfc {
leaf connectivity-context-sfp {
type sfc-sfp:service-function-path-ref;
}
}
}</artwork>
</figure>
</section>
<section title="SFC Layer For RPC - Path Discovery">
<t>Path Discovery is used to discover the path that specific service
traverses in the network. For SFC, it can be used on both service
function layer and SFC forwarding layer depending on what is the
desired degree of path information.</t>
<figure title="Augment SFC SFC-layer for Path Discovery">
<artwork> typedef SFC-layer {
type enumeration {
enum "Service function layer" {
value 0;
}
enum "SFC forwarding layer" {
value 1;
}
}
}
augment "/goam-rpc:path-discovery/goam-rpc:input" {
description
"Adding SFC specific items on the input";
leaf path-discovery-layer {
type SFC-layer;
description
"Identifying which SFC layer to run path discovery";
}
}</artwork>
</figure>
</section>
</section>
<section title="SFC OAM YANG Data Hierarchy">
<t>The complete data hierarchy related to the SFC OAM YANG model is
presented below. </t>
<figure title="Data hierarchy of SFC OAM">
<artwork>module: ietf-sfc-oam
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:connectivity-context:
+--:(connectivity-context-sfc)
+--rw connectivity-context-sfp? sfc-sfp:service-function-path-ref
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:mp-address:
+--:(sf-mep-address)
| +--rw sf-mep-ref? sfc-sf:service-function-ref
| +--rw sfp-mep-ref? sfc-sfp:service-function-path-ref
+--:(sff-mep-address)
+--rw sff-mep-ref? sfc-sff:service-function-forwarder-ref
+--rw sfp-mep-ref? sfc-sfp:service-function-path-ref
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam:de
stination-mep-address/goam:mp-address:
+--:(sf-mep-address)
| +--rw sf-mep-ref? sfc-sf:service-function-ref
| +--rw sfp-mep-ref? sfc-sfp:service-function-path-ref
+--:(sff-mep-address)
+--rw sff-mep-ref? sfc-sff:service-function-forwarder-ref
+--rw sfp-mep-ref? sfc-sfp:service-function-path-ref
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam:co
nnectivity-context:
+--:(connectivity-context-sfc)
+--rw connectivity-context-sfp? sfc-sfp:service-function-path-ref
augment /goam:continuity-check/goam:input/goam:destination-mp/goam:mp-address:
+--:(sf-mep-address)
| +--ro sf-mep-ref? sfc-sf:service-function-ref
| +--ro sfp-mep-ref? sfc-sfp:service-function-path-ref
+--:(sff-mep-address)
+--ro sff-mep-ref? sfc-sff:service-function-forwarder-ref
+--ro sfp-mep-ref? sfc-sfp:service-function-path-ref
augment /goam:continuity-verification/goam:input/goam:destination-mp/goam:mp-add
ress:
+--:(sf-mep-address)
| +--ro sf-mep-ref? sfc-sf:service-function-ref
| +--ro sfp-mep-ref? sfc-sfp:service-function-path-ref
+--:(sff-mep-address)
+--ro sff-mep-ref? sfc-sff:service-function-forwarder-ref
+--ro sfp-mep-ref? sfc-sfp:service-function-path-ref
augment /goam:path-discovery/goam:input:
+--ro path-discovery-layer? SFC-layer
augment /goam:path-discovery/goam:input/goam:destination-mp/goam:mp-address:
+--:(sf-mep-address)
| +--ro sf-mep-ref? sfc-sf:service-function-ref
| +--ro sfp-mep-ref? sfc-sfp:service-function-path-ref
+--:(sff-mep-address)
+--ro sff-mep-ref? sfc-sff:service-function-forwarder-ref
+--ro sfp-mep-ref? sfc-sfp:service-function-path-ref
augment /goam:path-discovery/goam:output/goam:response/goam:destination-mp/goam:
mp-address:
+--:(sf-mep-address)
| +--ro sf-mep-ref? sfc-sf:service-function-ref
| +--ro sfp-mep-ref? sfc-sfp:service-function-path-ref
+--:(sff-mep-address)
+--ro sff-mep-ref? sfc-sff:service-function-forwarder-ref
+--ro sfp-mep-ref? sfc-sfp:service-function-path-ref
</artwork>
</figure>
</section>
<section title="SFC OAM YANG Module">
<t><figure>
<artwork><CODE BEGINS> file "ietf-sfc-oam@2015-11-26.yang"
module ietf-sfc-oam {
namespace "urn:huawei:params:xml:ns:yang:sfc-oam";
prefix sfcoam;
import ietf-gen-oam {
prefix goam;
}
import service-function {
prefix sfc-sf;
}
import service-function-path {
prefix sfc-sfp;
}
import service-function-forwarder {
prefix sfc-sff;
}
revision "2015-11-26" {
description
"Initial revision";
}
identity sfc {
base goam:technology-types;
description
"sfc type";
}
typedef SFC-layer {
type enumeration {
enum "Service function layer" {
value 0;
}
enum "SFC forwarding layer" {
value 1;
}
}
}
augment
"/goam:domains/goam:domain/goam:MAs/goam:MA"
+"/goam:connectivity-context" {
case connectivity-context-sfc {
leaf connectivity-context-sfp {
type sfc-sfp:service-function-path-ref;
}
}
}
augment
"/goam:domains/goam:domain/goam:MAs"
+"/goam:MA/goam:MEP/goam:mp-address" {
case sf-mep-address {
description
"Service function (or service function forwarder) address plus
service function path id to identify one SFC MEP. A SFC MP can be a
service function or service function forwarder!";
leaf sf-mep-ref {
when "/goam:domains/goam:domain/goam:technology='sfc'";
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
when "/goam:domains/goam:domain/goam:technology='sfc'";
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
description
"Service function address plus service function path id to
identify one SFC MEP. A SFC MP can be a service function or service
function forwarder!";
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}
augment
"/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session"
+"/goam:destination-mep-address/goam:mp-address" {
case sf-mep-address {
leaf sf-mep-ref {
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}
augment
"/goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP"
+"/goam:session/goam:connectivity-context" {
case connectivity-context-sfc {
leaf connectivity-context-sfp {
type sfc-sfp:service-function-path-ref;
}
}
}
//SFC extension of contiuity-check part
/*
augment "/goam:continuity-check/goam:input"
+"/goam:source-mep/goam:mp-address" {
case sf-mep-address {
leaf sf-mep-ref {
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}*/
augment "/goam:continuity-check/goam:input"
+"/goam:destination-mp/goam:mp-address" {
case sf-mep-address {
leaf sf-mep-ref {
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}
//SFC extension of connectity-verification part
/*
augment "/goam:connectivity-verification"
+"/goam:input/goam:source-mep/goam:mp-address" {
case sf-mep-address {
leaf sf-mep-ref {
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}*/
augment "/goam:connectivity-verification"
+"/goam:input/goam:destination-mp/goam:mp-address" {
case sf-mep-address {
leaf sf-mep-ref {
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}
//SFC extension of path-discovery part
augment "/goam:path-discovery/goam:input" {
description
"adds SFC specific items on the input";
leaf path-discovery-layer {
type SFC-layer;
description
"Identifying which SFC layer to run path discovery";
}
}
/*augment "/goam:path-discovery/goam:input"
+"/goam:source-mep/goam:mp-address" {
case sf-mep-address {
leaf sf-mep-ref {
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}*/
augment "/goam:path-discovery/goam:input"
+"/goam:destination-mp/goam:mp-address" {
case sf-mep-address {
leaf sf-mep-ref {
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}
augment "/goam:path-discovery/goam:output"
+"/goam:response/goam:destination-mp/goam:mp-address" {
case sf-mep-address {
leaf sf-mep-ref {
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}
//SFC extension of performance-measurement part
/*
augment "/goam-rpc:initiated-performance-measurement/goam-
rpc:input/goam-rpc:source-mep/goam-rpc:mp-address" {
case sf-mep-address {
leaf sf-mep-ref {
type sfc-sf:service-function-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
case sff-mep-address {
leaf sff-mep-ref {
type sfc-sff:service-function-forwarder-ref;
}
leaf sfp-mep-ref {
type sfc-sfp:service-function-path-ref;
}
}
}*/
}
<CODE ENDS></artwork>
</figure></t>
</section>
<section title="Security Considerations">
<t>TBD.</t>
</section>
<section title="IANA Considerations">
<t>TBD.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<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 RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="IEEE.802.1Q-2011">
<front>
<title>Media Access Control (MAC) Bridges and Virtual Bridged Local
Area Networks</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date month="August" year="2011"/>
</front>
<seriesInfo name="IEEE" value="Standard 802.1Q"/>
</reference>
<?rfc include="reference.RFC.2234.xml" ?>
</references>
<references title="Informative References">
<reference anchor="Y.1731">
<front>
<title>OAM functions and mechanisms for Ethernet based
networks</title>
<author>
<organization/>
</author>
<date month="July" year="2011"/>
</front>
<seriesInfo name="ITU" value="G.8013/Y.1731"/>
</reference>
<?rfc include="reference.RFC.6291"?>
<?rfc include="reference.I-D.ietf-lime-yang-oam-model"?>
<?rfc include="reference.I-D.ietf-sfc-oam-framework"?>
<?rfc include="reference.I-D.penno-sfc-yang"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:46:29 |