| Network Working Group | Z. Wang |
| Internet-Draft | L. Xia |
| Intended status: Standards Track | Huawei |
| Expires: May 31, 2016 | D. Kumar |
| Cisco | |
| Q. Wu | |
| Huawei | |
| November 28, 2015 |
LIME base model extension for BFD Support
draft-wang-yang-bfd-oam-06
This document discusses how LIME base model is applied to BFD and present an example of YANG Data model for BFD support. The YANG Model presented in this document extends the technology independent YANG model for OAM with BFD technology specifics.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 31, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[draft-ietf-bfd-yang] defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). This document discusses how LIME base model is applied to BFD and present an example of YANG Data model for BFD support. The YANG Model example presented in this document extends the Generic YANG model for OAM defined in [I-D.ietf-lime-yang-oam- model]. The YANG model example uses the grouping defined in the BFD model [draft-ietf-bfd-yang]. The groupings contain the basic BFD session parameters for applications to use.
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].
The following terms are defined in [RFC6241] and are not redefined here:
The following terms are defined in [RFC6020] and are not redefined here:
The terminology for describing YANG data models is found in [RFC6020].
A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is as follows:
<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
Each node is printed as:
<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
If the node is augmented into the tree from another module, its name is printed as <prefix>:<name>.
+-+-+-+-+-+
| Layer |
|independent
|OAM YANG |
+-+-+-+-+-+
|
O
|
+--------------------------------------------------+
| | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| TRILL | | NVO3 | | BFD |. .| foo |
|OAM YANG | |OAM YANG | |OAM YANG | |OAM YANG |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| | | |
+----------------------------------------------------+
| Uniform API |
+----------------------------------------------------+
Relationship of BFD OAM YANG model to technology independent OAM YANG model
Both BFD model and LIME model can be developed as generic model. LIME model can be extended for BFD to provide consistent configuration, representaion and reporting. Therefore LIME model extension for BFD can be viewed as a BFD application. The consistent configuration and representation can be met by extending LIME configuration structure while the consistent reporting and representation can be met by extending LIME RPC structure or Notification Structure. Generic YANG model for OAM defined in [I-D.ietf-lime-yang-oam-model] can also be 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 BFD OAM YANG model to the Layer Independent OAM YANG Model.
MD level configuration parameters are management information which can be inherited in the BFD model and set by LIME base model as default values. For example domain name can be set to area-ID in the BFD case. In addition, at the Maintenance Domain level, domain data node at root level can be augmented with technology type and sub-technology type.
No BFD technology type has been defined in the LIME base model. Therefore a technology type extension is required in the BFD OAM model. The technology type "bfd" is defined as an identity that augments the base "technology-types" defined in the LIME base model:
In BFD, since different encapsulation types such as IP/UDP Encapsulation, PW-ACH encapsulation can be employed.
In lime-bfd-extension yang data model, we define an identity: "technology-sub-type" to further identify the encapsulation types within the BFD. And based on it, we also define four identity encapsulation types:
In MD level, we define a sub-technology leaf with an identityref type which base on the technology-sub-type:
augment "/goam:domains/goam:domain/" {
leaf sub-technology{
type identityref {
base technology-sub-type;
}
}
}
MA level configuration parameters (e.g., MA Name)are management information which can be inherited in the BFD model and set by LIME base model as default values. One example of MA Name is Tunnel Name or LAG Name. In addition, at the Maintenance Association(MA) level, MA data node at the second level can be augmented with connectivity-context extension.
In BFD context-id is a 32bit local discriminator. The LIME base model defines a placeholder for context-id. This allows other technologies to easily augment that to include technology specific extensions. The snippet below depicts an example of augmenting context-id to include local discriminator.
augment "/goam:domains/goam:domain/goam:MAs/goam:MA
/goam:connectivity-context"
{
case connectivity-context-bfd {
leaf local-discriminator {
type local-discriminator;
}
}
}
In BFD, the MEP address is either an IPv4 or IPV6 address. MEP-ID is either a 2 octet unsigned integer value or a variable length label value. In the LIME base model, MEP-ID is defined as a variable length label value and the same definition can be used for BFD with no further modification. In addition, at the Maintenance Association Endpoint(MEP) level, MEP data node at the third level can be augmented with Session extension and interface extension.
At the Session level, Session data node at the fouth level can be augmented with 3 interval parameters and 2 TTL parameters. The Session Configuration extension should reuse grouping defined in [draft-ietf-bfd-yang] for session related parameters. In [draft-ietf-bfd-yang], source and destination address in the bfd-session-cfg can be corresponding to Session configuration extension as source MEP and destination MEP.
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session: +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval uint32 | | +--rw required-min-rx-interval uint32 | +--:(single-interval) | +--rw min-interval uint32 augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session: +--rw tx-ttl? ttl +--rw rx-ttl ttl
At the Interface level, interface data node at the fifth level can be augmented with the same parameters defined in per-interface configuration of [draft-ietf-bfd-yang]. Interface configuration extension should reuse grouping defined in [draft-ietf-bfd-yang] for interface related parameters.
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam: outgoing-interface:
+--rw local-multiplier? multiplier
+--rw (interval-config-type)?
| +--:(tx-rx-intervals)
| | +--rw desired-min-tx-interval uint32
| | +--rw required-min-rx-interval uint32
| +--:(single-interval)
| +--rw min-interval uint32
+--rw demand-enabled? boolean
+--rw enable-authentication? boolean
+--rw authentication-parms {bfd-authentication}?
| +--rw key-chain-name? string
| +--rw algorithm? bfd-auth-algorithm
+--rw desired-min-echo-tx-interval? uint32
+--rw required-min-echo-rx-interval? uint32
[GENYANGOAM] defines a notification model which abstracts defects notification in a technology independent manner.However what BFD is required is state change notification, therefore a new notification definition can be specified to meet BFD requirement. The new notification defintion should reuse groupings defined in [draft-ietf-bfd-yang] for state change related parameters.
notifications:
+---n state-change-notification
+--ro local-discriminator? uint32
+--ro remote-discriminator? uint32
+--ro new-state? enumeration
+--ro state-change-reason? string
+--ro time-in-previous-state? string
+--ro dest-addr? inet:ip-address
+--ro source-addr? inet:ip-address
+--ro session-cookie? leafref
+--ro technology-sub-type? identityref
+--ro interface? leafref
+--ro echo-enabled? boolean
In this state-change-notification, technology-sub-type is used to identify whether the notification is for single hop or multi-hop or other types.
module: lime-bfd-extension
augment /goam:domains/goam:domain/goam:MAs/goam:MA:
+--rw technology-sub-type? identityref
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session:
+--rw on-demand-enable? boolean
+--rw local-multiplier? uint8
+--rw bfd-tx-rx-interval
| +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32
+--rw enable-authentication? boolean
+--rw bfd-authentication {bfd-authentication}?
+--rw key-chain-name? string
+--rw algorithm? enumeration
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session:
+--rw tx-ttl? uint8
+--rw rx-ttl? uint8
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam:connectivity-context:
+--:(connectivity-context-bfd)
+--rw local-discriminator? uint32
+--rw remote-discriminator? uint32
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam:outgoing-interface:
+--rw on-demand-enable? boolean
+--rw local-multiplier? uint8
+--rw bfd-tx-rx-interval
| +--rw desired-min-tx-interval? uint32
| +--rw required-min-rx-interval? uint32
+--rw enable-authentication? boolean
+--rw bfd-authentication {bfd-authentication}?
| +--rw key-chain-name? string
| +--rw algorithm? enumeration
+--rw desired-min-echo-tx-interval? uint32
+--rw required-min-echo-rx-interval? uint32
notifications:
+---n state-change-notification
+--ro local-discriminator? uint32
+--ro remote-discriminator? uint32
+--ro new-state? enumeration
+--ro state-change-reason? string
+--ro time-in-previous-state? string
+--ro dest-addr? inet:ip-address
+--ro source-addr? inet:ip-address
+--ro session-cookie? leafref
+--ro technology-sub-type? identityref
+--ro interface? leafref
+--ro echo-enabled? boolean
Data hierarchy of BFD OAM
The complete data hierarchy related to the OAM YANG model is presented below.
<CODE BEGINS> file "ietf-lime-bfd-extension.yang"
module ietf-lime-bfd-extension{
namespace
"urn:ietf:params:xml:ns:yang:ietf-lime-bfd-extension";
prefix limebfd;
import ietf-gen-oam {
prefix goam;
}
import ietf-bfd {
prefix bfd;
}
import ietf-interfaces {
prefix if;
}
organization
"IETF BFD Working Group";
contact
"WG List: <mailto:bfd@ietf.org>
Editor:";
description
"This YANG Model extends the technology independent
YANG model for OAM with BFD technology specifics.";
revision 2014-08-30 {
description
"Initial revision.";
reference "";
}
identity bfd{
base goam:technology-types;
description
"bfd type";
}
identity technology-sub-type {
description
"certain implementations such as bfd can have different
encapsulation types such as ip/udp, pw-ach and so on.
Instead of defining separate models for each
encapsulation, we define a technology sub-type to
further identify different encapsulations. Technology
sub-type is associated at the MA level";
}
identity technology-sub-type-sh-udp {
base technology-sub-type;
description
"technology sub-type is single
hop with IP/UDP encapsulation";
}
identity technology-sub-type-mh-udp {
base technology-sub-type;
description
"technology sub-type is multiple
hop with IP/UDP encapsulation";
}
identity technology-sub-type-sh-ach {
base technology-sub-type;
description
"technology sub-type is single
hop with PW-ACH encapsulation";
}
identity technology-sub-type-mh-ach {
base technology-sub-type;
description
"technology sub-type is multiple hop
with PW-ACH encapsulation";
}
grouping tx-rx-ttl{
description
"bfd tx ttl";
leaf tx-ttl{
type uint8;
description
"tx ttl.";
}
leaf rx-ttl{
type uint8;
description
"rx ttl.";
}
}
feature bfd-authentication {
description "BFD authentication supported";
}
augment "/goam:domains/goam:domain/goam:MAs/goam:MA"{
when "goam:technology = 'bfd'"
{description
"when goam:technology = bfd.";}
leaf technology-sub-type {
type identityref {
base technology-sub-type;
}
description
"technology sub-type such as
single hop udp, multiple hop udp,
single hop ach, multiple hop ach.";
}
description
"augment the MA with bfd parameters.";
}
augment "/goam:domains/goam:domain/goam:MAs/goam:MA"
+"/goam:MEP/goam:session"{
when "goam:technology = 'bfd'"
{description
"when goam:technology = bfd.";}
leaf admin-down {
type boolean;
default false;
description
"Is the BFD session administratively down";
}
uses bfd:bfd-grouping-common-cfg-parms;
description
"augment the session with bfd parameters.";
}
augment "/goam:domains/goam:domain/goam:MAs/goam:MA"
+"/goam:MEP/goam:session"{
when "technology-sub-type = 'technology-sub-type-mh-udp'
or 'technology-sub-type-mh-ach'"{
description
"when technology sub type = techonlogy sub type mh udp
or technology sub type = technology-sub-type-mh-ach.";
}
uses tx-rx-ttl;
description
"augment the session with bfd parameters.";
}
augment "/goam:domains/goam:domain/goam:MAs/goam:MA"
+"/goam:MEP/goam:session/goam:connectivity-context"{
when "goam:technology = 'bfd'"{
description
"when goam:techolgoy =bfd.";}
case connectivity-context-bfd {
leaf local-discriminator {
type uint32;
description
"local discriminator";
}
leaf remote-discriminator{
type uint32;
description
"remote-discriminator";
}
}
description
"augment the connectivity-context with
bfd parameters.";
}
augment "/goam:domains/goam:domain/goam:MAs/goam:MA"
+"/goam:MEP/goam:session/goam:outgoing-interface"{
when "technology-sub-type = 'technology-sub-type-sh-udp'
or 'technology-sub-type-sh-ach'"{
description
"when technology-sub-type = 'technology-sub-type-sh-udp'
or 'technology-sub-type-sh-ach.";
}
uses bfd:bfd-grouping-common-cfg-parms;
uses bfd:bfd-grouping-echo-cfg-parms;
description
"augment the outgoing interface with bfd parameters.";
}
notification state-change-notification
{
uses bfd:bfd-notification-parms;
leaf interface {
type if:interface-ref;
description "Interface to which this BFD session belongs to";
}
leaf echo-enabled {
type boolean;
description "Was echo enabled for BFD";
}
description
"state change notification.";
}
}
<CODE ENDS>
TBD.
TBD.
| [I-D.tissa-lime-yang-oam-model] | Senevirathne, T., Finn, N., Kumar, D., Salam, S., Wu, Q. and Z. Wang, "Generic YANG Data Model for Operations, Administration, and Maintenance (OAM)", Internet-Draft draft-tissa-lime-yang-oam-model-06, August 2015. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. |
| [RFC5880] | Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010. |
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010. |
| [RFC6241] | Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011. |
| [RFC7331] | Nadeau, T., Ali, Z. and N. Akiya, "Bidirectional Forwarding Detection (BFD) Management Information Base", RFC 7331, DOI 10.17487/RFC7331, August 2014. |