< draft-shaikh-rtgwg-policy-model-00.txt   draft-shaikh-rtgwg-policy-model-01.txt >
Network Working Group A. Shaikh Network Working Group A. Shaikh
Internet-Draft Google Internet-Draft Google
Intended status: Informational R. Shakir Intended status: Informational R. Shakir
Expires: July 27, 2015 BT Expires: January 5, 2016 BT
K. D'Souza K. D'Souza
C. Chase C. Chase
AT&T AT&T
January 23, 2015 July 4, 2015
Routing Policy Configuration Model for Service Provider Networks Routing Policy Configuration Model for Service Provider Networks
draft-shaikh-rtgwg-policy-model-00 draft-shaikh-rtgwg-policy-model-01
Abstract Abstract
This document defines a YANG data model for configuring and managing This document defines a YANG data model for configuring and managing
routing policies in a vendor-neutral way and based on actual routing policies in a vendor-neutral way and based on actual
operational practice. The model provides a generic policy framework operational practice. The model provides a generic policy framework
which can be augmented with protocol-specific policy configuration. which can be augmented with protocol-specific policy configuration.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 27, 2015. This Internet-Draft will expire on January 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
policy module, and an auxiliary module providing additional generic policy module, and an auxiliary module providing additional generic
types. The model has three main parts: types. The model has three main parts:
o A generic framework to express policies as sets of related o A generic framework to express policies as sets of related
conditions and actions. This includes match sets and actions that conditions and actions. This includes match sets and actions that
are useful across many routing protocols. are useful across many routing protocols.
o A structure that allows routing protocol models to add protocol- o A structure that allows routing protocol models to add protocol-
specific policy conditions and actions though YANG augmentations. specific policy conditions and actions though YANG augmentations.
There is a complete example of this for BGP [RFC4271] policies in There is a complete example of this for BGP [RFC4271] policies in
the proposed vendor-neutral BGP data model [BGP-Model]. the proposed vendor-neutral BGP data model
[I-D.shaikh-idr-bgp-model].
o A reusable grouping for attaching import and export rules in the o A reusable grouping for attaching import and export rules in the
context of routing configuration for different protocols, VRFs, context of routing configuration for different protocols, VRFs,
etc. This also enables creation of policy chains and expressing etc. This also enables creation of policy chains and expressing
default policy behavior. default policy behavior.
These modules make use of the standard Internet types, such as IP These modules make use of the standard Internet types, such as IP
addresses, autonomous system numbers, etc., defined in RFC 6991 addresses, autonomous system numbers, etc., defined in RFC 6991
[RFC6991]. [RFC6991].
3. Route policy expression 3. Route policy expression
Policies are expressed as a sequence of top-level policy definitions Policies are expressed as a sequence of top-level policy definitions
each of which consists of a sequence of policy statements. Policy each of which consists of a sequence of policy statements. Policy
statements in turn consist of simple condition-action tuples. statements in turn consist of simple condition-action tuples.
Conditions may include mutiple match or comparison operations, and Conditions may include multiple match or comparison operations, and
similarly, actions may effect multiple changes to route attributes, similarly, actions may effect multiple changes to route attributes,
or indicate a final disposition of accepting or rejecting the route. or indicate a final disposition of accepting or rejecting the route.
This structure is shown below. This structure is shown below.
+--rw routing-policy +--rw routing-policy
+--rw policy-definition* [name] +--rw policy-definitions
+--rw name string +--rw policy-definition* [name]
+--rw statement* [name]
+--rw name string +--rw name string
+--rw conditions! +--rw statements
| ... +--rw statement* [name]
+--rw actions! +--rw name string
... +--rw conditions
| ...
+--rw actions
...
3.1. Policy conditions 3.1. Defined sets for policy matching
The models provides a set of generic sets that can be used for
matching in policy conditions. These sets are applicable across
multiple routing protocols, and may be further augmented by protocol-
specific models which have their own defined sets. The supported
defined sets include:
o prefix sets - define a set of IP prefixes, each with an associated
CIDR netmask range (or exact length)
o neighbor sets - define a set of neighboring nodes by their IP
addresses
o tag set - define a set of generic tag values that can be used in
matches for filtering routes
The model structure for defined sets is shown below.
+--rw routing-policy
+--rw defined-sets
+--rw prefix-sets
| +--rw prefix-set* [prefix-set-name]
| +--rw prefix-set-name string
| +--rw prefix* [ip-prefix masklength-range]
| +--rw ip-prefix inet:ip-prefix
| +--rw masklength-range string
+--rw neighbor-sets
| +--rw neighbor-set* [neighbor-set-name]
| +--rw neighbor-set-name string
| +--rw neighbor* [address]
| +--rw address inet:ip-address
+--rw tag-sets
+--rw tag-set* [tag-set-name]
+--rw tag-set-name string
+--rw tag* [value]
+--rw value pt:tag-type
3.2. Policy conditions
Policy statements consist of a set of conditions and actions (either Policy statements consist of a set of conditions and actions (either
of which may be empty). Conditions are used to match route of which may be empty). Conditions are used to match route
attributes against a defined set (e.g., a prefix set), or to compare attributes against a defined set (e.g., a prefix set), or to compare
attributes against a specific value. attributes against a specific value.
Match conditions may be further modified using the match-set-options Match conditions may be further modified using the match-set-options
configuration which allows operators to change the behavior of a configuration which allows operators to change the behavior of a
match. Three options are supported: match. Three options are supported:
o ALL - match is true only if the given value matches all members of o ALL - match is true only if the given value matches all members of
the set. the set.
o ANY - match is true if the given value matches any member of the o ANY - match is true if the given value matches any member of the
set. set.
o INVERT - match is true if the given value does not match any o INVERT - match is true if the given value does not match any
member of the given set. member of the given set.
Not all options are appropriate for matching against all defined sets
(e.g., match ALL in a prefix set does not make sense). In the model,
a restricted set of match options is used where applicable.
Comparison conditions may similarly use options to change how route Comparison conditions may similarly use options to change how route
attributes should be tested, e.g., for equality or inequality, attributes should be tested, e.g., for equality or inequality,
against a given value. against a given value.
While most policy conditions will be added by individual routing While most policy conditions will be added by individual routing
protocol models via augmentation, this routing policy model includes protocol models via augmentation, this routing policy model includes
several generic match conditions and also the ability to test which several generic match conditions and also the ability to test which
protocol or mechanism installed a route (e.g., BGP, IGP, static, protocol or mechanism installed a route (e.g., BGP, IGP, static,
etc.). The conditions included in the model are shown below. etc.). The conditions included in the model are shown below.
+--rw routing-policy +--rw routing-policy
+--rw policy-definition* [name] +--rw policy-definitions
+--rw statement* [name] +--rw policy-definition* [name]
+--rw conditions! +--rw statements
+--rw call-policy? -> /routing-policy/... +--rw statement* [name]
+--rw match-prefix-set? -> /routing-policy/... +--rw conditions
+--rw match-neighbor-set? -> /routing-policy/... +--rw call-policy?
+--rw match-tag-set? -> /routing-policy/... +--rw match-prefix-set!
+--rw match-set-options? pt:match-set-options-type | +--rw prefix-set?
+--rw install-protocol-eq? identityref | +--rw match-set-options?
+--rw igp-conditions +--rw match-neighbor-set!
| +--rw neighbor-set?
| +--rw match-set-options?
+--rw match-tag-set!
| +--rw tag-set?
| +--rw match-set-options?
+--rw install-protocol-eq?
+--rw igp-conditions
3.2. Policy actions 3.3. Policy actions
When policy conditions are satisfied, policy actions are used to set When policy conditions are satisfied, policy actions are used to set
various attributes of the route being processed, or to indicate the various attributes of the route being processed, or to indicate the
final disposition of the route, i.e., accept or reject. final disposition of the route, i.e., accept or reject.
Similar to policy conditions, the routing policy model includes Similar to policy conditions, the routing policy model includes
generic actions in addition to the basic route disposition actions. generic actions in addition to the basic route disposition actions.
These are shown below. These are shown below.
+--rw routing-policy +--rw routing-policy
+--rw policy-definition* [name] +--rw policy-definitions
+--rw statement* [name] +--rw policy-definition* [name]
+--rw actions! +--rw statements
+--rw accept-route? empty +--rw statement* [name]
+--rw reject-route? empty +--rw actions
+--rw igp-actions +--rw (route-disposition)?
+--rw set-tag? pt:tag-type | +--:(accept-route)
| | +--rw accept-route? empty
| +--:(reject-route)
| +--rw reject-route? empty
+--rw igp-actions
+--rw set-tag? pt:tag-type
3.3. Policy subroutines 3.4. Policy subroutines
Policy 'subroutines' (or nested policies) are supported by allowing Policy 'subroutines' (or nested policies) are supported by allowing
policy statement conditions to reference other policy definitions policy statement conditions to reference other policy definitions
using the call-policy configuration. Called policies apply their using the call-policy configuration. Called policies apply their
conditions and actions before returning to the calling policy conditions and actions before returning to the calling policy
statement and resuming evaluation. The outcome of the called policy statement and resuming evaluation. The outcome of the called policy
affects the evaluation of the calling policy. If the called policy affects the evaluation of the calling policy. If the called policy
results in an accept-route (either explicit or by default), then the results in an accept-route (either explicit or by default), then the
subroutine returns an effective boolean true value to the calling subroutine returns an effective boolean true value to the calling
policy. For the calling policy, this is equivalent to a condition policy. For the calling policy, this is equivalent to a condition
skipping to change at page 6, line 22 skipping to change at page 7, line 27
Routing policy is applied by defining and attaching policy chains in Routing policy is applied by defining and attaching policy chains in
various routing contexts. Policy chains are sequences of policy various routing contexts. Policy chains are sequences of policy
definitions (described in Section 3) that have an associated definitions (described in Section 3) that have an associated
direction (import or export) with respect to the routing context in direction (import or export) with respect to the routing context in
which they are defined. The routing policy model defines an apply- which they are defined. The routing policy model defines an apply-
policy grouping that can be imported and used by other models. As policy grouping that can be imported and used by other models. As
shown below, it allows definition of import and export policy chains, shown below, it allows definition of import and export policy chains,
as well as specifying the default route disposition to be used when as well as specifying the default route disposition to be used when
no policy definition in the chain results in a final decision. no policy definition in the chain results in a final decision.
+--rw apply-policy +--rw apply-policy
+--rw import-policies* -> /rpol:routing-policy/... | +--rw config
+--rw default-import-policy? default-policy-type | | +--rw import-policy*
+--rw export-policies* -> /rpol:routing-policy/... | | +--rw default-import-policy? default-policy-type
+--rw default-export-policy? default-policy-type | | +--rw export-policy*
| | +--rw default-export-policy? default-policy-type
The default policy defined by the model is to reject the route for The default policy defined by the model is to reject the route for
both import and export policies. both import and export policies.
An example of using the apply-policy group in another routing model An example of using the apply-policy group in another routing model
is shown below for BGP. Here, import and export policies are applied is shown below for BGP. Here, import and export policies are applied
in the context of a particular BGP peer group. Note that the policy in the context of a particular BGP peer group. Note that the policy
chains reference policy definitions by name that are defined in the chains reference policy definitions by name that are defined in the
routing policy model. routing policy model.
+--rw peer-group* [group-name] +--rw bgp!
| +--rw group-name string +--rw peer-groups
| +--ro bgp-group-common-state +--rw peer-group* [peer-group-name]
| +--rw description? string +--rw peer-group-name
| +--rw graceful-restart! +--rw config
| | +--rw restart-time? uint16 | +--rw peer-as?
| | +--rw stale-routes-time? decimal64 | +--rw local-as?
| +--rw apply-policy | +--rw peer-type?
| | +--rw import-policies* -> /rpol:routing-policy/... | +--rw auth-password?
| | +--rw default-import-policy? default-policy-type | +--rw remove-private-as?
| | +--rw export-policies* -> /rpol:routing-policy/... | +--rw route-flap-damping?
| | +--rw default-export-policy? default-policy-type | +--rw send-community?
... | +--rw description?
| +--rw peer-group-name?
+--ro state
| +--ro peer-as?
| +--ro local-as?
| +--ro peer-type?
| +--ro auth-password?
| +--ro remove-private-as?
| +--ro route-flap-damping?
| +--ro send-community?
| +--ro description?
| +--ro peer-group-name?
| +--ro total-paths?
| +--ro total-prefixes?
+--rw apply-policy
| +--rw config
| | +--rw import-policy*
| | +--rw default-import-policy?
| | +--rw export-policy*
| | +--rw default-export-policy?
| +--ro state
| +--ro import-policy*
| +--ro default-import-policy?
| +--ro export-policy*
| +--ro default-export-policy?
...
6. Routing protocol-specific policies 6. Routing protocol-specific policies
Routing models that require the ability to apply routing policy may Routing models that require the ability to apply routing policy may
augment the routing policy model with protocol or other specific augment the routing policy model with protocol or other specific
policy configuration. The routing policy model assumes that policy configuration. The routing policy model assumes that
additional defined sets, conditions, and actions may all be added by additional defined sets, conditions, and actions may all be added by
other models. other models.
An example of this is shown below, in which the BGP configuration An example of this is shown below, in which the BGP configuration
model in [BGP-Model] adds new defined sets to match on community model in [I-D.shaikh-idr-bgp-model] adds new defined sets to match on
values or AS paths. The model similarly augments BGP-specific community values or AS paths. The model similarly augments BGP-
conditions and actions into the corresponding sections of the routing specific conditions and actions into the corresponding sections of
policy model. the routing policy model.
+--rw routing-policy +--rw routing-policy
+--rw defined-sets! +--rw defined-sets
+--rw prefix-sets
| +--rw prefix-set* [prefix-set-name] | +--rw prefix-set* [prefix-set-name]
| | +--rw prefix-set-name string | +--rw prefix-set-name
| | +--rw prefix* [address masklength masklength-range] | +--rw prefix* [ip-prefix masklength-range]
| | +--rw address inet:ip-address | +--rw ip-prefix
| | +--rw masklength uint8 | +--rw masklength-range
| | +--rw masklength-range string +--rw neighbor-sets
| +--rw neighbor-set* [neighbor-set-name] | +--rw neighbor-set* [neighbor-set-name]
| | +--rw neighbor-set-name string | +--rw neighbor-set-name
| | +--rw neighbor* [address] | +--rw neighbor* [address]
| | +--rw address inet:ip-address | +--rw address
+--rw tag-sets
| +--rw tag-set* [tag-set-name] | +--rw tag-set* [tag-set-name]
| | +--rw tag-set-name string | +--rw tag-set-name
| | +--rw tag* [value] | +--rw tag* [value]
| | +--rw value pt:tag-type | +--rw value
| +--rw bgp-pol:bgp-defined-sets +--rw bgp-pol:bgp-defined-sets
| +--rw bgp-pol:community-set* [community-set-name] +--rw bgp-pol:community-sets
| | +--rw bgp-pol:community-set-name string | +--rw bgp-pol:community-set* [community-set-name]
| | +--rw bgp-pol:community-members* union | +--rw bgp-pol:community-set-name
| +--rw bgp-pol:ext-community-set* [ext-community-set-name] | +--rw bgp-pol:community-member*
| | +--rw bgp-pol:ext-community-set-name string +--rw bgp-pol:ext-community-sets
| | +--rw bgp-pol:ext-community-members* union | +--rw bgp-pol:ext-community-set* [ext-community-set-name]
| +--rw bgp-pol:as-path-set* [as-path-set-name] | +--rw bgp-pol:ext-community-set-name
| +--rw bgp-pol:as-path-set-name string | +--rw bgp-pol:ext-community-member*
| +--rw bgp-pol:as-path-set-members* string +--rw bgp-pol:as-path-sets
+--rw bgp-pol:as-path-set* [as-path-set-name]
+--rw bgp-pol:as-path-set-name
+--rw bgp-pol:as-path-set-member*
7. Security Considerations 7. Security Considerations
Routing policy configuration has a significant impact on network Routing policy configuration has a significant impact on network
operations, and as such any related model carries potential security operations, and as such any related model carries potential security
risks. risks.
YANG data models are generally designed to be used with the NETCONF YANG data models are generally designed to be used with the NETCONF
protocol over an SSH transport. This provides an authenticated and protocol over an SSH transport. This provides an authenticated and
secure channel over which to transfer configuration and operational secure channel over which to transfer configuration and operational
skipping to change at page 10, line 14 skipping to change at page 12, line 10
definition which applies conditions and actions from the definition which applies conditions and actions from the
referenced policy before returning to the calling policy referenced policy before returning to the calling policy
statement and resuming evaluation. If the called policy statement and resuming evaluation. If the called policy
results in an accept-route (either explicit or by default), then results in an accept-route (either explicit or by default), then
the subroutine returns an effective true value to the calling the subroutine returns an effective true value to the calling
policy. Similarly, a reject-route action returns false. If the policy. Similarly, a reject-route action returns false. If the
subroutine returns true, the calling policy continues to evaluate subroutine returns true, the calling policy continues to evaluate
the remaining conditions (using a modified route if the the remaining conditions (using a modified route if the
subroutine performed any changes to the route)."; subroutine performed any changes to the route).";
revision "2014-11-30" { revision "2015-05-15" {
description description
"Initial revision"; "Initial revision";
reference "TBD"; reference "TBD";
} }
// typedef statements // typedef statements
typedef default-policy-type { typedef default-policy-type {
type enumeration { type enumeration {
enum ACCEPT-ROUTE { enum ACCEPT-ROUTE {
description "default policy to accept the route"; description "default policy to accept the route";
} }
enum REJECT-ROUTE { enum REJECT-ROUTE {
description "default policy to reject the route"; description "default policy to reject the route";
} }
} }
description "type used to specify default route disposition in description "type used to specify default route disposition in
a policy chain"; a policy chain";
} }
identity install-protocol-type {
description
"Base type for protocols which can install prefixes into the
RIB";
}
identity BGP {
base install-protocol-type;
description "BGP";
reference "RFC 4271";
}
identity ISIS {
base install-protocol-type;
description "IS-IS";
reference "ISO/IEC 10589";
}
identity OSPF {
base install-protocol-type;
description "OSPFv2";
reference "RFC 2328";
}
identity OSPF3 {
base install-protocol-type;
description "OSPFv3";
reference "RFC 5340";
}
identity STATIC {
base install-protocol-type;
description "Locally-installed static route";
}
identity DIRECTLY-CONNECTED {
base install-protocol-type;
description "A directly connected route";
}
// grouping statements // grouping statements
grouping generic-defined-sets { grouping generic-defined-sets {
description description
"Data definitions for pre-defined sets of attributes used in "Data definitions for pre-defined sets of attributes used in
policy match conditions. These sets are generic and can policy match conditions. These sets are generic and can
be used in matching conditions in different routing be used in matching conditions in different routing
protocols."; protocols.";
list prefix-set { container prefix-sets {
key prefix-set-name;
description description
"Definitions for prefix sets"; "Enclosing container for defined prefix sets for matching";
leaf prefix-set-name {
type string;
description
"name / label of the prefix set -- this is used to
reference the set in match conditions";
}
list prefix { list prefix-set {
key "address masklength masklength-range"; key prefix-set-name;
description description
"list of prefix expressions that are part of the set"; "List of the defined prefix sets";
leaf address { leaf prefix-set-name {
type inet:ip-address; type string;
mandatory true;
description description
"address portion of the prefix"; "name / label of the prefix set -- this is used to
reference the set in match conditions";
} }
leaf masklength { list prefix {
type uint8 { key "ip-prefix masklength-range";
// simple range covers both ipv4 and ipv6 --
// could separate this into different types
// for IPv4 and IPv6 prefixes
range 0..128;
}
mandatory true;
description description
"masklength for the prefix specification"; "List of prefix expressions that are part of the set";
}
leaf masklength-range { leaf ip-prefix {
type string { type inet:ip-prefix;
// pattern modeled after ietf-inet-types mandatory true;
pattern '(([0-9])|([1-9][0-9])|(1[0-1][0-9])|' description
+ '(12[0-8]))\.\.' "The prefix member in CIDR notation -- while the
+ '(([0-9])|([1-9][0-9])|(1[0-1][0-9])|' prefix may be either IPv4 or IPv6, most
+ '(12[0-8]))'; implementations require all members of the prefix set
to be the same address family. Mixing address types in
the same prefix set is likely to cause an error.";
}
leaf masklength-range {
type string {
pattern '^([0-9]+\.\.[0-9]+)|exact$';
}
description
"Defines a range for the masklength, or 'exact' if
the prefix has an exact length.
Example: 10.3.192.0/21 through 10.3.192.0/24 would be
expressed as prefix: 10.3.192.0/21,
masklength-range: 21..24.
Example: 10.3.192.0/21 would be expressed as
prefix: 10.3.192.0/21,
masklength-range: exact";
} }
description
"Defines an optional range for the masklength. Absence
of the masklength-length implies that the prefix has an
exact masklength given by the masklength parameter.
Example: 10.3.192.0/21 through 10.3.192.0/24 would be
expressed as address: 10.3.192.0, masklength: 21,
masklength-range: 21..24";
} }
} }
} }
list neighbor-set { container neighbor-sets {
key neighbor-set-name;
description description
"Definitions for neighbor sets"; "Enclosing container for defined neighbor sets for matching";
leaf neighbor-set-name { list neighbor-set {
type string; key neighbor-set-name;
description description
"name / label of the neighbor set -- this is used to "Definitions for neighbor sets";
reference the set in match conditions";
}
list neighbor { leaf neighbor-set-name {
key "address"; type string;
description description
"list of addresses that are part of the neighbor set"; "name / label of the neighbor set -- this is used to
reference the set in match conditions";
}
leaf address { list neighbor {
type inet:ip-address; key "address";
description description
"IP address of the neighbor set member"; "list of addresses that are part of the neighbor set";
leaf address {
type inet:ip-address;
description
"IP address of the neighbor set member";
}
} }
} }
} }
list tag-set { container tag-sets {
key tag-set-name;
description description
"Definitions for tag sets"; "Enclosing container for defined tag sets for matching";
leaf tag-set-name { list tag-set {
type string; key tag-set-name;
description description
"name / label of the tag set -- this is used to reference "Definitions for tag sets";
the set in match conditions";
}
list tag { leaf tag-set-name {
key "value"; type string;
description description
"list of tags that are part of the tag set"; "name / label of the tag set -- this is used to reference
the set in match conditions";
}
leaf value { list tag {
type pt:tag-type; key "value";
description description
"Value of the tag set member"; "list of tags that are part of the tag set";
leaf value {
type pt:tag-type;
description
"Value of the tag set member";
}
} }
} }
} }
} }
grouping local-generic-conditions { grouping local-generic-conditions {
description description
"Condition statement definitions for consideration of a local "Condition statement definitions for consideration of a local
characteristic of a route"; characteristic of a route";
leaf install-protocol-eq { leaf install-protocol-eq {
type identityref { type identityref {
base install-protocol-type; base pt:install-protocol-type;
} }
description description
"Condition to check the protocol / method used to install "Condition to check the protocol / method used to install
which installed the route into the local routing table"; which installed the route into the local routing table";
} }
} }
grouping match-set-options-group { grouping match-set-options-group {
description description
"Grouping containing options relating to how a particular set "Grouping containing options relating to how a particular set
should be matched"; should be matched";
leaf match-set-options { leaf match-set-options {
type pt:match-set-options-type; type pt:match-set-options-type;
description description
"Optional parameter that governs the behaviour of the "Optional parameter that governs the behaviour of the
match operation"; match operation";
} }
} }
grouping match-set-options-restricted-group {
description
"Grouping for a restricted set of match operation modifiers";
leaf match-set-options {
type pt:match-set-options-restricted-type;
description
"Optional parameter that governs the behaviour of the
match operation. This leaf only supports matching on ANY
member of the set or inverting the match. Matching on ALL is
not supported)";
}
}
grouping generic-conditions { grouping generic-conditions {
description "Condition statement definitions for checking description "Condition statement definitions for checking
membership in a generic defined set"; membership in a generic defined set";
container match-prefix-set { container match-prefix-set {
presence presence
"The presence of this container indicates that the routes "The presence of this container indicates that the routes
should match the prefix-set referenced."; should match the prefix-set referenced.";
description description
"Match a referenced prefix-set according to the logic "Match a referenced prefix-set according to the logic
defined in the match-set-options leaf"; defined in the match-set-options leaf";
leaf prefix-set { leaf prefix-set {
type leafref { type leafref {
path "/routing-policy/defined-sets/prefix-set" + path "/routing-policy/defined-sets/prefix-sets/" +
"/prefix-set-name"; "prefix-set/prefix-set-name";
require-instance true; //TODO: require-instance should be added when it's
//supported in YANG 1.1
//require-instance true;
} }
description "References a defined prefix set"; description "References a defined prefix set";
} }
uses match-set-options-group; uses match-set-options-restricted-group;
} }
container match-neighbor-set { container match-neighbor-set {
presence presence
"The presence of this container indicates that the routes "The presence of this container indicates that the routes
should match the neighbour set referenced"; should match the neighbour set referenced";
description description
"Match a referenced neighbor set according to the logic "Match a referenced neighbor set according to the logic
defined in the match-set-options-leaf"; defined in the match-set-options-leaf";
leaf neighbor-set { leaf neighbor-set {
type leafref { type leafref {
path "/routing-policy/defined-sets/neighbor-set" + path "/routing-policy/defined-sets/neighbor-sets/" +
"/neighbor-set-name"; "neighbor-set/neighbor-set-name";
require-instance true; //TODO: require-instance should be added when it's
//supported in YANG 1.1
//require-instance true;
} }
description "References a defined neighbor set"; description "References a defined neighbor set";
} }
uses match-set-options-group; uses match-set-options-restricted-group;
} }
container match-tag-set { container match-tag-set {
presence presence
"The presence of this container indicates that the routes "The presence of this container indicates that the routes
should match the tag-set referenced"; should match the tag-set referenced";
description description
"Match a referenced tag set according to the logic defined "Match a referenced tag set according to the logic defined
in the match-options-set leaf"; in the match-options-set leaf";
leaf tag-set { leaf tag-set {
type leafref { type leafref {
path "/routing-policy/defined-sets/tag-set" + path "/routing-policy/defined-sets/tag-sets/tag-set" +
"/tag-set-name"; "/tag-set-name";
require-instance true; //TODO: require-instance should be added when it's
//supported in YANG 1.1
//require-instance true;
} }
description "References a defined tag set"; description "References a defined tag set";
} }
uses match-set-options-group; uses match-set-options-restricted-group;
} }
uses local-generic-conditions; uses local-generic-conditions;
} }
grouping igp-generic-conditions { grouping igp-generic-conditions {
description "grouping for IGP policy conditions"; description "grouping for IGP policy conditions";
} }
grouping igp-conditions { grouping igp-conditions {
description "grouping for IGP-specific policy conditions"; description "grouping for IGP-specific policy conditions";
container igp-conditions { container igp-conditions {
description "Policy conditions for IGP attributes"; description "Policy conditions for IGP attributes";
uses igp-generic-conditions; uses igp-generic-conditions;
} }
} }
grouping generic-actions { grouping generic-actions {
description description
"Definitions for common set of policy action statements that "Definitions for common set of policy action statements that
manage the disposition or control flow of the policy"; manage the disposition or control flow of the policy";
leaf accept-route { choice route-disposition {
type empty; description
description "accepts the route into the routing table"; "Select the final disposition for the route, either
} accept or reject.";
leaf accept-route {
type empty;
description "accepts the route into the routing table";
}
leaf reject-route { leaf reject-route {
type empty; type empty;
description "rejects the route"; description "rejects the route";
}
} }
} }
grouping igp-actions { grouping igp-actions {
description "grouping for IGP-specific policy actions"; description "grouping for IGP-specific policy actions";
container igp-actions { container igp-actions {
description "Actions to set IGP route attributes; these actions description "Actions to set IGP route attributes; these actions
apply to multiple IGPs"; apply to multiple IGPs";
leaf set-tag { leaf set-tag {
type pt:tag-type; type pt:tag-type;
description "set the tag value for OSPF or IS-IS routes"; description
"Set the tag value for OSPF or IS-IS routes.";
} }
} }
} }
container routing-policy { container routing-policy {
description description
"top-level container for all routing policy configuration"; "top-level container for all routing policy configuration";
container defined-sets { container defined-sets {
presence "Container for sets defined for matching in policy
statements";
description description
"Predefined sets of attributes used in policy match "Predefined sets of attributes used in policy match
statements"; statements";
uses generic-defined-sets; uses generic-defined-sets;
// uses bgp-defined-sets; // uses bgp-defined-sets;
// don't see a need for IGP-specific defined sets at this point // don't see a need for IGP-specific defined sets at this point
// e.g., for OSPF, IS-IS, etc. // e.g., for OSPF, IS-IS, etc.
} }
list policy-definition { container policy-definitions {
key name;
description description
"List of top-level policy definitions, keyed by unique "Enclosing container for the list of top-level policy
name. These policy definitions are expected to be definitions";
referenced (by name) in policy chains specified in import/
export configuration statements.";
leaf name { list policy-definition {
type string;
description
"Name of the top-level policy definition -- this name
is used in references to the current policy";
}
list statement {
key name; key name;
// TODO: names of policy statements within a policy defn
// should be optional, however, YANG requires a unique id
// for lists; not sure that a compound key works either;
// need to investigate further.
ordered-by user;
description description
"Policy statements group conditions and actions within "List of top-level policy definitions, keyed by unique
a policy definition. They are evaluated in the order name. These policy definitions are expected to be
specified (see the description of policy evaluation referenced (by name) in policy chains specified in import/
at the top of this module."; export configuration statements.";
leaf name { leaf name {
type string; type string;
description "name of the policy statement"; description
"Name of the top-level policy definition -- this name
is used in references to the current policy";
} }
container conditions { container statements {
presence "conditions"; description
description "Condition statements for this "Enclosing container for policy statements";
policy statement";
leaf call-policy { list statement {
type leafref { key name;
path "/rpol:routing-policy/rpol:policy-definition/" + // TODO: names of policy statements within a policy defn
"rpol:name"; // should be optional, however, YANG requires a unique id
require-instance true; // for lists; not sure that a compound key works either;
} // need to investigate further.
ordered-by user;
description description
"Applies the statements from the specified policy "Policy statements group conditions and actions within
definition and then returns control the current policy a policy definition. They are evaluated in the order
statement. Note that the called policy may itself call specified (see the description of policy evaluation
other policies (subject to implementation limitations). at the top of this module.";
This is intended to provide a policy 'subroutine'
capability. The called policy should contain an leaf name {
explicit or a default route disposition that returns an type string;
effective true (accept-route) or false (reject-route), description "name of the policy statement";
otherwise the behavior may be ambiguous and }
implementation dependent";
container conditions {
description "Condition statements for this
policy statement";
leaf call-policy {
type leafref {
path "/rpol:routing-policy/" +
"rpol:policy-definitions/" +
"rpol:policy-definition/rpol:name";
//TODO: require-instance should be added when it's
//supported in YANG 1.1
//require-instance true;
}
description
"Applies the statements from the specified policy
definition and then returns control the current
policy statement. Note that the called policy may
itself call other policies (subject to
implementation limitations). This is intended to
provide a policy 'subroutine' capability. The
called policy should contain an explicit or a
default route disposition that returns an effective
true (accept-route) or false (reject-route),
otherwise the behavior may be ambiguous and
implementation dependent";
}
uses generic-conditions;
uses igp-conditions;
}
container actions {
description "Action statements for this policy
statement";
uses generic-actions;
uses igp-actions;
}
} }
uses generic-conditions;
uses igp-conditions;
} }
}
}
}
container actions { grouping apply-policy-config {
presence "actions"; description
description "Action statements for this policy "Configuration data for routing policies";
statement";
uses generic-actions; leaf-list import-policy {
uses igp-actions; type leafref {
} path "/rpol:routing-policy/rpol:policy-definitions/" +
"rpol:policy-definition/rpol:name";
//TODO: require-instance should be added when it's
//supported in YANG 1.1
//require-instance true;
} }
ordered-by user;
description
"list of policy names in sequence to be applied on
receiving a routing update in the current context, e.g.,
for the current peer group, neighbor, address family,
etc.";
}
leaf default-import-policy {
type default-policy-type;
default REJECT-ROUTE;
description
"explicitly set a default policy if no policy definition
in the import policy chain is satisfied.";
}
leaf-list export-policy {
type leafref {
path "/rpol:routing-policy/rpol:policy-definitions/" +
"rpol:policy-definition/rpol:name";
//TODO: require-instance should be added when it's
//supported in YANG 1.1
//require-instance true;
}
ordered-by user;
description
"list of policy names in sequence to be applied on
sending a routing update in the current context, e.g.,
for the current peer group, neighbor, address family,
etc.";
}
leaf default-export-policy {
type default-policy-type;
default REJECT-ROUTE;
description
"explicitly set a default policy if no policy definition
in the export policy chain is satisfied.";
} }
} }
grouping apply-policy-state {
description
"Operational state associated with routing policy";
//TODO: identify additional state data beyond the intended
//policy configuration.
}
grouping apply-policy-group { grouping apply-policy-group {
description description
"configuration for applying policies"; "Top level container for routing policy applications. This
grouping is intended to be used in routing models where
needed.";
container apply-policy { container apply-policy {
description description
"Anchor point for routing policies in the configuration. "Anchor point for routing policies in the model.
Import and export policies are with respect to the local Import and export policies are with respect to the local
routing table, i.e., export (send) and import (receive), routing table, i.e., export (send) and import (receive),
depending on the context."; depending on the context.";
leaf-list import-policies { container config {
type leafref {
path "/rpol:routing-policy/rpol:policy-definition" +
"/rpol:name";
require-instance true;
}
ordered-by user;
description description
"list of policy names in sequence to be applied on "Policy configuration data.";
receiving a routing update in the current context, e.g.,
for the current peer group, neighbor, address family,
etc.";
}
leaf default-import-policy { uses apply-policy-config;
type default-policy-type;
default REJECT-ROUTE;
description
"explicitly set a default policy if no policy definition
in the import policy chain is satisfied.";
} }
leaf-list export-policies { container state {
type leafref {
path "/rpol:routing-policy/rpol:policy-definition" +
"/rpol:name";
require-instance true;
}
ordered-by user;
description
"list of policy names in sequence to be applied on
sending a routing update in the current context, e.g.,
for the current peer group, neighbor, address family,
etc.";
}
leaf default-export-policy { config false;
type default-policy-type;
default REJECT-ROUTE;
description description
"explicitly set a default policy if no policy definition "Operational state for routing policy";
in the export policy chain is satisfied.";
uses apply-policy-config;
uses apply-policy-state;
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
9.2. Routing policy types 9.2. Routing policy types
<CODE BEGINS> file policy-types.yang <CODE BEGINS> file policy-types.yang
module policy-types { module policy-types {
skipping to change at page 20, line 14 skipping to change at page 23, line 4
9.2. Routing policy types 9.2. Routing policy types
<CODE BEGINS> file policy-types.yang <CODE BEGINS> file policy-types.yang
module policy-types { module policy-types {
yang-version "1"; yang-version "1";
// namespace // namespace
namespace "http://openconfig.net/yang/policy-types"; namespace "http://openconfig.net/yang/policy-types";
prefix "ptypes"; prefix "ptypes";
// import some basic types // import some basic types
import ietf-inet-types { prefix inet; }
import ietf-yang-types { prefix yang; } import ietf-yang-types { prefix yang; }
// meta // meta
organization organization
"OpenConfig working group"; "OpenConfig working group";
contact contact
"OpenConfig working group "OpenConfig working group
netopenconfig@googlegroups.com"; netopenconfig@googlegroups.com";
description description
"This module contains general data definitions for use in routing "This module contains general data definitions for use in routing
policy. It can be imported by modules that contain protocol- policy. It can be imported by modules that contain protocol-
specific policy conditions and actions."; specific policy conditions and actions.";
revision "2014-11-30" { revision "2015-05-15" {
description description
"Initial revision"; "Initial revision";
reference "TBD"; reference "TBD";
} }
// identity statements // identity statements
identity attribute-comparison { identity attribute-comparison {
description description
"base type for supported comparison operators on route "base type for supported comparison operators on route
skipping to change at page 21, line 36 skipping to change at page 24, line 26
member of the defined set"; member of the defined set";
} }
} }
default ANY; default ANY;
description description
"Options that govern the behavior of a match statement. The "Options that govern the behavior of a match statement. The
default behavior is ANY, i.e., the given value matches any default behavior is ANY, i.e., the given value matches any
of the members of the defined set"; of the members of the defined set";
} }
typedef match-set-options-restricted-type {
type enumeration {
enum ANY {
description "match is true if given value matches any member
of the defined set";
}
enum INVERT {
description "match is true if given value does not match any
member of the defined set";
}
}
default ANY;
description
"Options that govern the behavior of a match statement. The
default behavior is ANY, i.e., the given value matches any
of the members of the defined set. Note this type is a
restricted version of the match-set-options-type.";
//TODO: restriction on enumerated types is only allowed in
//YANG 1.1. Until then, we will require this additional type
}
grouping attribute-compare-operators { grouping attribute-compare-operators {
description "common definitions for comparison operations in description "common definitions for comparison operations in
condition statements"; condition statements";
leaf operator { leaf operator {
type identityref { type identityref {
base attribute-comparison; base attribute-comparison;
} }
description description
"type of comparison to be performed"; "type of comparison to be performed";
skipping to change at page 22, line 20 skipping to change at page 25, line 30
type uint32; type uint32;
type yang:hex-string; type yang:hex-string;
} }
description "type for expressing route tags on a local system, description "type for expressing route tags on a local system,
including IS-IS and OSPF; may be expressed as either decimal or including IS-IS and OSPF; may be expressed as either decimal or
hexidecimal integer"; hexidecimal integer";
reference reference
"RFC 2178 OSPF Version 2 "RFC 2178 OSPF Version 2
RFC 5130 A Policy Control Mechanism in IS-IS Using RFC 5130 A Policy Control Mechanism in IS-IS Using
Administrative Tags"; Administrative Tags";
} }
}
<CODE ENDS>
10. Policy examples
Below we show an example of XML-encoded configuration data using the identity install-protocol-type {
routing policy and BGP models to illustrate both how policies are description
defined, and also how they can be applied. "Base type for protocols which can install prefixes into the
RIB";
}
<routing-policy> identity BGP {
base install-protocol-type;
description "BGP";
reference "RFC 4271";
}
<defined-sets> identity ISIS {
<prefix-set name="prefix-set-A"> base install-protocol-type;
<prefix> description "IS-IS";
<address>A1</address> reference "ISO/IEC 10589";
<masklength>M1</masklength> }
</prefix>
<prefix>
<address>A2</address>
<masklength>M2</masklength>
</prefix>
<prefix>
<address>A3</address>
<masklength>M3</masklength>
</prefix>
</prefix-set>
<tag-set> identity OSPF {
<tag-set-name>cust-tag1</tag-set-name> base install-protocol-type;
<tag value="10" /> description "OSPFv2";
</tag-set> reference "RFC 2328";
}
<community-set name="community-set-A"> identity OSPF3 {
<community-member>C1</community-member> base install-protocol-type;
<community-member>C2</community-member> description "OSPFv3";
<community-member>C3</community-member> reference "RFC 5340";
</community-set> }
<community-set name="community-set-B">
<community-member>C5</community-member>
<community-member>C6</community-member>
<community-member>C7</community-member>
</community-set>
<as-path-set name="as-path-set-A"> identity STATIC {
<as-path-set-member>AS1</as-path-set-member> base install-protocol-type;
<as-path-set-member>AS2</as-path-set-member> description "Locally-installed static route";
<as-path-set-member>ASx</as-path-set-member> }
</as-path-set>
</defined-sets> identity DIRECTLY-CONNECTED {
base install-protocol-type;
description "A directly connected route";
}
<!-- policy 1: identity LOCAL-AGGREGATE {
if community in community-set-A then local-pref = 10 base install-protocol-type;
if origin = IGP then accept route description "Locally defined aggregate route";
--> }
<policy-defintion name="policy 1"> }
<policy-statements> <CODE ENDS>
<statement name="depref-community-A">
<conditions>
<match-community-set>
<community-set>community-set-A</community-set>
</match-community-set>
</conditions>
<actions>
<set-local-pref>10</set-local-pref>
</actions>
</statement>
<statement name="accept-igp">
<conditions>
<origin-eq>IGP</origin-eq>
</conditions>
<actions>
<accept-route />
</actions>
</statement>
</policy-statements>
</policy-defintion>
<!-- policy 2:
if community matches-exactly community-set-B and AS path in as-path-set-A
then reject
-->
<policy-defintion name="policy 2"> 10. Policy examples
<statement name="drop-community-B-aspath-A">
<conditions>
<match-community-set>
<community-set>community-set-B</community-set>
<match-set-options>ALL</match-set-options>
</match-community-set>
<match-as-set>
<as-set>as-path-set-A</as-set>
</match-as-set>
</conditions>
<actions>
<reject-route />
</actions>
</statement>
</policy-defintion>
<!-- policy 3: Below we show an example of XML-encoded configuration data using the
if community matches-exactly community-set-A routing policy and BGP models to illustrate both how policies are
then accept defined, and also how they can be applied. Note that the XML has
--> been simplified for readability.
<policy-definition name="policy 3"> <routing-policy>
<statement name="accept-community-A">
<conditions>
<match-community-set>
<community-set>community-set-A</community-set>
<match-set-options>ALL</match-set-options>
</match-prefix-set>
</conditions>
<actions>
<accept-route />
</actions>
</statement>
</policy-definition>
<!-- policy export-tagged-BGP: <defined-sets>
if route from OSPFv3 and tag=cust-tag1 <prefix-sets>
then accept <prefix-set>
--> <prefix-set-name>prefix-set-A</prefix-set-name>
<prefix>
<ip-prefix>192.0.2.0/24</ip-prefix>
<masklength-range>24..32</masklength-range>
</prefix>
<prefix>
<ip-prefix>10.0.0.0/16</ip-prefix>
<masklength-range>16..32</masklength-range>
</prefix>
<prefix>
<ip-prefix>192.168.0.0/19</ip-prefix>
<masklength-range>19..24</masklength-range>
</prefix>
</prefix-set>
</prefix-sets>
<tag-sets>
<tag-set>
<tag-set-name>cust-tag1</tag-set-name>
<tag>
<value>10</value>
</tag>
</tag-set>
</tag-sets>
</defined-sets>
<policy-definition name="export-tagged-BGP"> <policy-definitions>
<statement> <policy-definition>
<conditions> <name>export-tagged-BGP</name>
<install-protocol-eq>OSPFV3</install-protocol-eq> <statements>
<match-tag-set>cust-tag1</match-tag-set> <statement>
</conditions> <name>term-0</name>
<actions> <conditions>
<accept-route /> <install-protocol-eq>OSPF3</install-protocol-eq>
</actions> <match-tag-set>
</statement> <tag-set>cust-tag1</tag-set>
</policy-definition> </match-tag-set>
</conditions>
<actions>
<accept-route />
</actions>
</statement>
</statements>
</policy-definition>
</policy-definitions>
</routing-policy> </routing-policy>
<!-- import policy chain for BGP neighbor --> <bgp>
<bgp> <global>
<neighbor> <config>
<neighbor-address>172.95.25.2</neighbor-address> <as>65517</as>
<peer-AS>ASY</peer-AS> </config>
<description>regional peer ASY</description> </global>
<peer-type>EXTERNAL</peer-type> <peer-groups>
<advertise-inactive-routes>true</advertise-inactive-routes> <peer-group>
<use-multiple-paths> <peer-group-name>PG1</peer-group-name>
<ebgp> <config>
<maximum-paths>4</maximum-paths> <peer-as>65518</peer-as>
</ebgp> <peer-type>EXTERNAL</peer-type>
</use-multiple-paths> </config>
<import-policies> <apply-policy>
<policyref>policy 2</policyref> <config>
<policyref>policy 3</policyref> <export-policy>export-tagged-BGP</export-policy>
<default-policy>REJECT-ROUTE</default-policy> </config>
</import-policies> </apply-policy>
</neighbor> </peer-group>
</bgp> </peer-groups>
</bgp>
11. References 11. References
11.1. Normative references 11.1. Normative references
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2014. October 2014.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991,
July 2013. July 2013.
[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
2004. 2004.
11.2. Informative references 11.2. Informative references
[BGP-Model] [I-D.shaikh-idr-bgp-model]
"BGP Configuration Model for Service Provider Networks", Shaikh, A., Shakir, R., Patel, K., Hares, S., D'Souza, K.,
January 2015, Bansal, D., Clemm, A., Alex, A., Jethanandani, M., and X.
<https://github.com/YangModels/yang/tree/master/ Liu, "BGP Model for Service Provider Networks", draft-
experimental/openconfig/bgp>. shaikh-idr-bgp-model-02 (work in progress), June 2015.
[I-D.openconfig-netmod-opstate]
Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling
of Operational State Data in YANG", draft-openconfig-
netmod-opstate-00 (work in progress), March 2015.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors are grateful for valuable contributions to this document The authors are grateful for valuable contributions to this document
and the associated models from: Jim Uttaro, Josh George, Vijay Gill, and the associated models from: Ebben Aires, Luyuan Fang, Josh
Ina Minei, Steve Padgett, Ebben Aires, Eric Osborne, Luyuan Fang, George, Acee Lindem, Stephane Litkowski, Ina Minei, Carl Moberg, Eric
Carl Moberg, Stephane Litkowski, and Russ White. Osborne, Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, and Russ
White.
Appendix B. Change summary
B.1. Changes between revisions -00 and -01
The -01 revision of the policy model reflects a number of changes to
the data model based on additional operator, reviewer, and
implementor feedback.
o Modified the apply-policy container to use the pattern for
modeling operational state described in
[I-D.openconfig-netmod-opstate].
o Updated prefix lists to use ip-prefix type and masklength range to
better enable range-checking and validation. Added an 'exact'
option to the masklength range.
o Changed accept / reject route to be within a choice statement.
o Added enclosing containers to lists.
o Minor changes to leaf-lists in defined sets definitions; also to
apply-policy container structure.
o Added second type of match-options set to handle restricted case
of only ANY | INVERT (i.e., without ALL). The restricted
enumerated type is now associated with the appropriate types of
sets.
o Moved install-protocol-type identity to policy-types module.
o Removed require-instance statements from leafrefs pending
availability in YANG 1.1.
o Fixed discrepancies in the example shown in the document, and
simplified the example.
Authors' Addresses Authors' Addresses
Anees Shaikh Anees Shaikh
Google Google
1600 Amphitheatre Pkwy 1600 Amphitheatre Pkwy
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: aashaikh@google.com Email: aashaikh@google.com
 End of changes. 109 change blocks. 
458 lines changed or deleted 617 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/