draft-ietf-i2rs-pkt-eca-data-model-01.txt		draft-ietf-i2rs-pkt-eca-data-model-02.txt
	I2RS working group S. Hares		I2RS working group S. Hares
	Internet-Draft Q. Wu		Internet-Draft Q. Wu
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: January 2, 2017 R. White		Expires: April 8, 2017 R. White
	Ericsson		Ericsson
	July 1, 2016		October 5, 2016
	Filter-Based Packet Forwarding ECA Policy		Filter-Based Packet Forwarding ECA Policy
	draft-ietf-i2rs-pkt-eca-data-model-01.txt		draft-ietf-i2rs-pkt-eca-data-model-02.txt
	Abstract		Abstract
	This document describes the yang data model for packet forwarding		This document describes the yang data model for packet forwarding
	policy that filters received packets and forwards (or drops) the		policy that filters received packets and forwards (or drops) the
	packets. Prior to forwarding the packets out other interfaces, some		packets. Prior to forwarding the packets out other interfaces, some
	of the fields in the packets may be modified. If one considers the		of the fields in the packets may be modified. If one considers the
	packet reception an event, this packet policy is a minimalistic		packet reception an event, this packet policy is a minimalistic
	Event-Match Condition-Action policy. This policy controls forwarding		Event-Match Condition-Action policy. This policy controls forwarding
	of packets received by a routing device on one or more interfaces on		of packets received by a routing device on one or more interfaces on
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 January 2, 2017.		This Internet-Draft will expire on April 8, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3		1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 3
	1.2. Antecedents this Policy in IETF . . . . . . . . . . . . . 3		1.2. Antecedents this Policy in IETF . . . . . . . . . . . . . 4
	2. Generic Route Filters/Policy Overview . . . . . . . . . . . . 4		2. Generic Route Filters/Policy Overview . . . . . . . . . . . . 4
	3. BNP Rule Groups . . . . . . . . . . . . . . . . . . . . . . . 5		3. BNP Rule Groups . . . . . . . . . . . . . . . . . . . . . . . 5
	4. BNP Generic Info Model in High Level Yang . . . . . . . . . . 7		4. Packet ECA (event-condition-action) Filter Model in High
	5. i2rs-eca-policy Yang module . . . . . . . . . . . . . . . . . 11		Level Yang . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41		4.1. modules included . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 41		4.2. top level description . . . . . . . . . . . . . . . . . . 8
	8. Informative References . . . . . . . . . . . . . . . . . . . 42		4.3. Conditional filters . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42		4.3.1. Event Match Filters . . . . . . . . . . . . . . . . . 11
			4.3.2. ECA Packet Condition Matches . . . . . . . . . . . . 12
			4.4. ECA Packet Actions . . . . . . . . . . . . . . . . . . . 19
			4.5. Policy Conflict Resolution strategies . . . . . . . . . . 22
			4.6. External Data . . . . . . . . . . . . . . . . . . . . . . 22
			5. i2rs-eca-policy Yang module . . . . . . . . . . . . . . . . . 23
			6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 54
			8. Informative References . . . . . . . . . . . . . . . . . . . 54
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
	1. Introduction		1. Introduction
	This document describes the yang data model for packet forwarding		This document describes the yang data model for packet forwarding
	policy that filters received packets and forwards (or drops) the		policy that filters received packets and forwards (or drops) the
	packets. Prior to forwarding the packets out other interfaces, some		packets. Prior to forwarding the packets out other interfaces, some
	of the fields in the packets may be modified. If one considers the		of the fields in the packets may be modified. If one considers the
	reception of a packet as an event, this minimalistic Event-Match		reception of a packet as an event, this minimalistic Event-Match
	Condition-Action policy. If one considers the reception of packets		Condition-Action policy. If one considers the reception of packets
	containing Layer 1 to Layer 4 + application data a single packet,		containing Layer 1 to Layer 4 + application data a single packet,
	then this minimalistic policy can be called a packet-only ECA policy.		then this minimalistic policy can be called a packet-only ECA policy.
	This document will use the term packet-only ECA policy for this model		This document will use the term packet-only ECA policy for this model
	utilizing the term "packet" in this fashion.		utilizing the term "packet" in this fashion.
	This packet-only ECA policy data model supports an ordered list of		This packet-only ECA policy data model supports an ordered list of
	ECA policy rules where each policy rule has a name. The match		ECA policy rules where each policy rule has a name. The match
	condition filters include matches on		condition filters include matches on
	o packet headers for layer 1 to layer 4,
			o content of packet headers for layer 1 to layer 4,
	o application protocol data and headers,		o application protocol data and headers,
	o interfaces the packet was received on,		o interfaces the packet was received on,
	o time packet was received, and		o time packet was received, and
	o size of packet.		o size of packet.
	The actions include packet modify actions and forwarding options.		The actions include packet modify actions and forwarding options.
	skipping to change at page 3, line 31 ¶		skipping to change at page 3, line 40 ¶
	The forwardingng actions allow forwardsing the packet via interfaces,		The forwardingng actions allow forwardsing the packet via interfaces,
	tunnels, next-hops, or dropping the packet. setting things within		tunnels, next-hops, or dropping the packet. setting things within
	the packet at Layer 2 (L2) to layer 4 (L4) plus overlay or		the packet at Layer 2 (L2) to layer 4 (L4) plus overlay or
	application data.		application data.
	The first section of this draft contains an overview of the policy		The first section of this draft contains an overview of the policy
	structure. The second provides a high-level yang module. The third		structure. The second provides a high-level yang module. The third
	contains the yang module.		contains the yang module.
			The high-level yang and the actual yang are not aligned. This is an
			interim-release of this document.
	1.1. Definitions and Acronyms		1.1. Definitions and Acronyms
	INSTANCE: Routing Code often has the ability to spin up multiple		INSTANCE: Routing Code often has the ability to spin up multiple
	copies of itself into virtual machines. Each Routing code		copies of itself into virtual machines. Each Routing code
	instance or each protocol instance is denoted as Foo_INSTANCE in		instance or each protocol instance is denoted as Foo_INSTANCE in
	the text below.		the text below.
	NETCONF: The Network Configuration Protocol		NETCONF: The Network Configuration Protocol
	PCIM - Policy Core Information Model		PCIM - Policy Core Information Model
	RESTconf - http programmatic protocol to access yang modules		RESTconf - http programmatic protocol to access yang modules
	1.2. Antecedents this Policy in IETF		1.2. Antecedents this Policy in IETF
	Antecedents to this generic policy are the generic policy work done		Antecedents to this generic policy are the generic policy work done
	in PCIM WG. The PCIM work contains a Policy Core Information Model		in PCIM WG. The PCIM work contains a Policy Core Information Model
	(PCIM) [RFC3060], Policy Core Informational Model Extensions		(PCIM) [RFC3060], Policy Core Informational Model Extensions
	[RFC3460] and the Quality of Service (QoS) Policy Information Model		[RFC3460] and the Quality of Service (QoS) Policy Information Model
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 28 ¶
	groups, but could be expanded to include sets of groups in the		groups, but could be expanded to include sets of groups in the
	future.		future.
	2. Generic Route Filters/Policy Overview		2. Generic Route Filters/Policy Overview
	This generic policy model represents filter or routing policies as		This generic policy model represents filter or routing policies as
	rules and groups of rules.		rules and groups of rules.
	The basic concept are:		The basic concept are:
	Rule Group		Policy set:
	A rule group is is an ordered set of rules .		Policy set is a set of policies
			Policy:
			A policy is a is an ordered set of rules .
	Rule		Rule
	A Rule is represented by the semantics "If Condition then Action".		A Rule is represented by the semantics "If Condition then Action".
	A Rule may have a priority assigned to it.		A Rule may have a priority assigned to it.
	+-----------+ +------------+		+-------------+
	|Rule Group | | Rule Group |		| Policy Set |
	+-----------+ +------------+		+-^---------^-+
	^ ^		| |
	| |		| |
	| |		+---------+ +---------+
	+--------^-------+ +-------^-------+		| policy | | rules |-=========||
	| Rule | | Rule |		+---------+ +---------+ ||
	+----------------+ +---------------+		^ ||
	: :		| ||
	: :		+-|----------+ ||
	......: :.....		| rule-list | ||
	: :		+------------+ ||
	+---------V---------+ +-V-------------+		^ ^ ||
	| Rule Condition | | Rule Action |		| | ||
	+-------------------+ +---------------+		| | ||
	: : : : : :		+-----^---+ +-----^--+ +---^-------+ ||
	.....: . :..... .....: . :.....		| Rule |==| Rule |==| Rule |==||
	: : : : : :		+---------+ +--------+ +-:------:---+
	+----V---+ +---V----+ +--V---+ +-V------++--V-----++--V---+		: :
	| Match | | match | |match | | Action || action ||action|		+-----------:+ +-:----------+
	|Operator| |Variable| |Value | |Operator||Variable|| Value|		| cfg-rule | | cfg rule |
	+--------+ +--------+ +------+ +--------++--------++------+		| conditions | | Actions |
			+--:-:-------+ +:---:-:--:--+
			: : : : : :.................
			:...............: : : : :......... :
			: : ......: : : :
			: : : : : :
			+:-------+ +-------V--+ +-V------+ +-V-----+ +-V-----+ +--V----+
			| Rule | | Rule | |eca- | |eca- | |eca- | |eca- |
			| event | | Condition| |ingress-| |fwd- | |egress-| |qos- | ...
			| match | | match | |actions | |actions| |actions| |actions|
			+--------+ +--:---:---+ +--------+ +-------+ +-------+ +-------+
			: :
			:........: :
			: :
			+----V----+ +-----V---------+
			|eca-event| | eca-condition |
			| -match | | -match |
			+---------+ +---------------+
	Figure 1: ECA rule structure		Figure 1: ECA rule structure
	3. BNP Rule Groups		3. BNP Rule Groups
	The pkt ECA policy is an order set of pkt-ECA policy rules. The		The pkt ECA policy is a policy whihc is an order set of pkt-ECA
	rules assume the event is the reception of a packet on the machine on		policy rules. The rules assume the event is the reception of a
	a set of interfaces. This policy is associated with a set of		packet on the machine on a set of interfaces. This policy is
	interfaces on a routing device (physical or virtual).		associated with a set of interfaces on a routing device (physical or
			virtual).
	A Rule group allows for the easy combination of rules for management		A Policy allows for the easy combination of rules for management
	stations or users. A Rule group has the following elements:		stations or users. A policy has the following elements:
	o name that identifies the grouping of policy rules		o name that identifies the grouping of policy rules
	o module reference - reference to a yang module(s) in the yang		o module reference - reference to a yang module(s) in the yang
	module library that this group of policy writes policy to		module library that this group of policy writes policy to
	o list of rules		o list of rules
	Rule groups may have multiple policy groups at specific orders. For		A policy group may have rulies at different order levels. For
	example, policy gorup 1 could have three policy rules at rule order 1		example, policy group 1 could have three policy rules at rule order 1
	and four policy rules at rule order 5.		and four policy rules at rule order 5.
	The rule has the following elements: name, order, status, priority,		The rule has the following elements: name, order, status, priority,
	reference cnt, and match condition, and action as shown as shown in		reference cnt, and match condition, and action as shown as shown in
	figure 2. The order indicates the order of the rule within the the		figure 2. The order indicates the order of the rule within the the
	complete list. The status of the rule is (active, inactive). The		complete list. The status of the rule is (active, inactive). The
	priority is the priority within a specific order of policy/filter		priority is the priority within a specific order of policy/filter
	rules. A reference count (refcnt) indicates the number of entities		rules. A reference count (refcnt) indicates the number of entities
	(E.g. network modules) using this policy. The generic rule match-		(E.g. network modules) using this policy. The generic rule match-
	action conditions have match operator, a match variable and a match		action conditions have match operator, a match variable and a match
	value. The rule actions have an action operator, action variable,		value. The rule actions have an action operator, action variable,
	and an action value.		and an action value.
	Rules can exist with the same rule order and same priority. Rules		Rules can exist with the same rule order and same priority. Rules
	with the same rule order and same priority are not guaranteed to be		with the same rule order and same priority are not guaranteed to be
	at any specific ordering. The order number and priority have		at any specific ordering. The order number and priority have
	sufficient depth that administrators who wish order can specify it.		sufficient depth that administrators who wish order can specify it.
	Figure 2 - Rule Group
	+--------------------------------------+
	| Rule Group |
	+--------------------------------------+
	* * *
	| | |
	| | |
	| | |
	+------+ +-------------------+
	| Name | | Rule_list |
	| | | |
	+------+ +------|------------+
	+----------------|-----------------------------+
	| rule |
	|-|------|----------|-----------|------------|-+
	| | | | |
	+---|--+ +-|----+ +---|-------+ +-|------+ +-------+
	| Name | |rule | | ECA | |rule | |ref-cnt|
	+------+ |order | | match | |priority| +-------+
	|number| |qos-actions| +--------+
	+------+ |fwd-actions|
	+-----------+
	The generic match conditions are specific to a particular layer are		The generic match conditions are specific to a particular layer are
	refined by matches to a specific layer (as figure 3 shows), and		refined by matches to a specific layer (as figure 2 shows), and
	figure 5's high-level yang defines. The general actions may be		figure 5's high-level yang defines. The general actions may be
	generic actions that are specific to a particular layer (L1, L2, L3,		generic actions that are specific to a particular layer (L1, L2, L3,
	service layer) or time of day or packet size. The qos actions can be		service layer) or time of day or packet size. The qos actions can be
	setting fields in the packet at any layer (L1-L4, service) or		setting fields in the packet at any layer (L1-L4, service) or
	encapsulating or decapsulating the packet at a layer. The fwd-		encapsulating or decapsulating the packet at a layer. The fwd-
	actions are forwarding functions that forward on an interface or to a		actions are forwarding functions that forward on an interface or to a
	next-hop. The rule status is the operational status per rule.		next-hop. The rule status is the operational status per rule.
	Figure 3		+-----------------+
	+-------------+		| eca-pkt-matches |
	| Match |		+-------|---------+
	| Condition |
	+-------|-----+
	|		|
	+-------------+-|-----------+-----------+		+-------------+-|-----------+-----------+
	| | | |		| | | |
	V V V V		V V V V
	............ ............ ............ ...........		............ ............ ............ ...........
	: L1 : : L2 : : L3 : : Service : . . .		: L1 : : L2 : : L3 : : Service : . . .
	: match : : match : : match : : match :		: match : : match : : match : : match :
	'''''''''''' '''''''''''' '''''''''''' '''''''''''		'''''''''''' '''''''''''' '''''''''''' '''''''''''
	4. BNP Generic Info Model in High Level Yang		Figure 2 match logic
	Below is the high level inclusion		4. Packet ECA (event-condition-action) Filter Model in High Level Yang
			The description of packet event-condition-action data model include:
			module included in module
			top level diagram
			4.1. modules included
			Below is the high level module inclusions.
	Figure 5
	module:pkt-eca-policy		module:pkt-eca-policy
	import ietf-inet-types {prefix "inet"}		import ietf-inet-types {prefix "inet"}
	import ietf-interface {prefix "if"}		import ietf-interface {prefix "if"}
	import ietf-i2rs-rib {prefix "i2rs-rib"}		import ietf-i2rs-rib {prefix "i2rs-rib"}
	import ietf-interfaces {		import ietf-interfaces {
	prefix "if";		prefix "if";
	}		}
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	//rfc6991		//rfc6991
	}		}
	import ietf-i2rs-rib {		import ietf-i2rs-rib {
	prefix "i2rs-rib";		prefix "i2rs-rib";
			Figure 3 - high level inclusion
			4.2. top level description
	Below is the high level yang diagram		Below is the high level yang diagram
	module ietf-pkt-eca-policy		module ietf-pkt-eca-policy
	+--rw pkt-eca-policy-cfg		+--rw pkt-eca-policy-cfg
	| +--rw pkt-eca-policy-set		| +--rw pkt-eca-policy-set
	| +--rw groups* [group-name]		| +--rw policies* [policy-name]
	| | +--rw group-name string		| | +--rw policy-name string
	| | +--rw vrf-name string		| | +--rw vrf-name string
	| | +--rw address-family		| | +--rw address-family
	| | +--rw group-rule-list* [rule-name]		| | +--rw rule-list* [rule-name]
	| | | +--rw rule-name		| | | +--rw rule-name
	| | | +--rw rule-order-id		| | | +--rw rule-order-id uint16
	| | | +--rw default-action-id integer		| | | +--rw default-action-id integer
	| | | +--rw default-resolution-strategy-id integer		| | | +--rw default-resolution-strategy-id integer
	| +--rw rules* [order-id rule-name]		| +--rw rules* [order-id rule-name]
	| +--rw order-id		| +--rw order-id uint16
	| +--rw rule-name		| +--rw rule-name string
	| +--rw cfg-rule-conditions [cfgr-cnd-id]		| +--rw policy-name string
	| | +--rw cfgr-cnd-id integer		| +--rw cfg-rule-conditions [rule-cnd-id]
	| | +--rw eca-event-match		| | +--rw rule-cnd-id uint32
	| | | +--rw time-event-match*		| | +--rw support
	| | | | .. (time of day)		| | | +--rw event-matches boolean
			| | | +--rw pkt-matches boolean
			| | | +--rw usr-context-matches boolean
			| | +--rw eca-events-match* [rule-event-id]
			| | | +--rw rule-event-it uint16
			| | | | ... time-event match (see below)
	| | +--rw eca-condition-match		| | +--rw eca-condition-match
	| | | +--rw eca-pkt-matches*		| | | +--rw eca-pkt-matches* [pkt-match-id]
	| | | | ... (L1-L4 matches)		| | | | ...(see packet matches below)
	| | | +--rw eca-user-matches*		| | | | ... (address, packet header, packet payload)
	| | | | (user, schedule, region, target,		| | | +--rw eca-user-context-matches* [usr-match-id]
	| | | | state, direction)		| | | | ... (see user context match below)
	| +--rw cfg-rule-actions [cfgr-action-id]		| +--rw cfg-rule-actions [cfgr-action-id]
	| | +--rw cfgr-action-id		| | +--rw cfgr-action-id
	| | +--rw eca-actions* [action-id]		| | +--rw eca-actions* [action-id]
	| | | +--rw action-id uint32		| | | +--rw action-id uint32
	| | | +--rw eca-ingress-act*		| | | +--rw eca-ingress-actions*
	| | | | ... (permit, deny, mirror)		| | | | ... (permit, deny, mirror)
	| | | +--rw eca-fwd-actions*		| | | +--rw eca-fwd-actions*
	| | | | ... (invoke, tunnel encap, fwd)		| | | | ... (invoke, tunnel encap, fwd)
	| | | +--rw eca-egress-act*		| | | +--rw eca-egress-acttions*
	| | | | .. .		| | | | .. .
	| | | +--rw eca-qos-actions*		| | | +--rw eca-qos-actions*
	| | | | ...		| | | | ...
	| | | +--rw eca-security-actions*		| | | +--rw eca-security-actions*
	| +--rw pc-resolution-strategies* [strategy-id]		| +--rw policy-conflict-resolution* [strategy-id]
	| | +--rw strategy-id integer		| | +--rw strategy-id integer
	| | +--rw filter-strategy identityref		| | +--rw filter-strategy identityref
	| | | .. FMR, ADTP, Longest-match		| | | .. FMR, ADTP, Longest-match
	| | +--rw global-strategy identityref		| | +--rw global-strategy identityref
	| | +--rw mandatory-strategy identityref		| | +--rw mandatory-strategy identityref
	| | +--rw local-strategy identityref		| | +--rw local-strategy identityref
	| | +--rw resolution-fcn uint32		| | +--rw resolution-fcn uint32
	| | +--rw resolution-value uint32		| | +--rw resolution-value uint32
	| | +--rw resolution-info string		| | +--rw resolution-info string
	| | +--rw associated-ext-data*		| | +--rw associated-ext-data*
	| | | +--rw ext-data-id integer		| | | +--rw ext-data-id integer
	| +--rw cfg-external-data* [cfg-ext-data-id]		| +--rw cfg-external-data* [cfg-ext-data-id]
	| | +--rw cfg-ext-data-id integer		| | +--rw cfg-ext-data-id integer
	| | +--rw data-type integer		| | +--rw data-type integer
	| | +--rw priority uint64		| | +--rw priority uint64
	| | | uses external-data-forms		| | | uses external-data-forms
	| | ... (other external data)		| | ... (other external data)
	+--rw pkt-eca-policy-opstate		+--rw pkt-eca-policy-opstate
	+--rw pkt-eca-opstate		+--rw pkt-eca-opstate
	+--rw groups* [group-name]		+--rw policies-opstat* [policy-name]
	| +--rw rules-installed;		| +--rw rules-installed;
	| +--rw rules_status* [rule-name]		| +--rw rules_opstat* [rule-name]
	| +--rw strategy-used [strategy-id]		| +--rw strategy-used [strategy-id]
	| +--rw
	+--rw rule-group-link* [rule-name]
	| +--rw group-name
	+--rw rules_opstate* [rule-order rule-name]		+--rw rules_opstate* [rule-order rule-name]
	| +--rw status		| +--rw status
	| +--rw rule-inactive-reason		| +--rw rule-inactive-reason
	| +--rw rule-install-reason		| +--rw rule-install-reason
	| +--rw rule-installer		| +--rw rule-installer
	| +--rw refcnt		| +--rw refcnt
	+--rw rules_op-stats* [rule-order rule-name]		+--rw rules_pktstats* [rule-order rule-name]
	| +--rw pkts-matched		| +--rw pkts-matched
	| +--rw pkts-modified		| +--rw pkts-modified
	| +--rw pkts-forward		| +--rw pkts-forward
	+--rw op-external-data [op-ext-data-id]		+--rw op-external-data [op-ext-data-id]
	| +--rw op-ext-data-id integer		| +--rw op-ext-data-id integer
	| +--rw type identityref		| +--rw type identityref
	| +--rw installed-priority integer		| +--rw installed-priority integer
	| | (other details on external data )		| | (other details on external data )
			figure 4 - high-level yang for policy set
	The three levels of policy are expressed as:		The three levels of policy are expressed as:
	Config Policy definitions		Config Policy definitions
	=======================================		=======================================
	Policy level: pkt-eca-policy-set		Policy level: pkt-eca-policy-set
	group level: pkt-eca-policy-set:groups		group level: pkt-eca-policy-set:policies
	rule level: pkt-eca-policy-set:rules		rule level: pkt-eca-policy-set:rules
	external id: pkt-eca-policy-set:cfg-external-data		external id: pkt-eca-policy-set:cfg-external-data
	Operational State for Policy		Operational State for Policy
	=======================================		=======================================
	Policy level: pkt-eca-policy-opstate		Policy level: pkt-eca-policy-opstate
	group level: pkt-eca-opstate:groups		group level: pkt-eca-opstate:policies-opstat*
	group-rule: pkt-eca-opstate:rule-group-link*		rule level: pkt-eca-opstate:rules_opstat*
	rule level: pkt-eca_opstate:rules_opstate*		pkt-eca-opstate:rules-pktstat*
	pkt-eca_op-stats		external id: pkt-eca-opstate:op-external-data*
	figure		figure 5
			4.3. Conditional filters
			The condition filters in the packet eca policy module included the
			following:
			o event filters - time as an augment to reception of a packet.
			o conditional matches on packet content or user-related content
			The sections below provide the high-level yang for these sections of
			hte model.
	The filter matches struture is shown below
	module:i2rs-pkt-eca-policy		module:i2rs-pkt-eca-policy
	+--rw pkt-eca-policy-cfg		.....
	| +--rw pkt-eca-policy-set		+--rw pkt-eca-policy-cfg
	| +--rw groups* [group-name]		| +--rw pkt-eca-policy-set
	| | ...		| +--rw pkt-eca-policy-set
	| +--rw rules [order-id rule-name]		| | ...
	| +--rw eca-matches		| +--rw rules* [order-id rule-name]
	| | | +--case: interface-match		| +--rw order-id uint16
	| | | +--case: L1-header-match		| +--rw rule-name string
	| | | +--case: L2-header-match		| +--rw policy-name string
	| | | +--case: L3-header-match		| +--rw cfg-rule-conditions [rule-cnd-id]
	| | | +--case: L4-header-match		| | +--rw rule-cnd-id integer
	| | | +--case: Service-header-match		| | +--rw eca-events-match* [rule-event-id]
	| | | +--case: packet-size		| | | +--rw rule-event-it uint16
	| | | +--case: time-of-day		| | | | ... time-event match (see below)
			| | +--rw eca-condition-match
			| | | +--rw eca-pkt-matches* [pkt-match-id]
			| | | | ... (see L1-L4 matches below)
			| | | +--rw eca-usr-context-matches* [usr-match-id]
			| | | | (user, schedule, region, target,
			| | | | state, direction)
	module:i2rs-pkt-eca-policy		Figure 6
			4.3.1. Event Match Filters
			The default event is the event of receiving a packet. In addition,
			the events allow a time-event match. Time events are provided as a
			list which includes specific times or ranges of time.
			| +--rw pkt-eca-policy-set
			| +--rw pkt-eca-policy-set
			| | ...
			| +--rw rules* [order-id rule-name]
			| +--rw order-id uint16
			| +--rw rule-name string
			| +--rw policy-name string
			| +--rw cfg-rule-conditions [rule-cnd-id]
			| | +--rw rule-cnd-id uint32
			| | +--rw support
			| | | +--rw event-matches boolean
			| | | +--rw pkt-matches boolean
			| | | +--rw usr-context-matches boolean
			| | +--rw eca-events-match* [rule-event-id]
			| | | +--rw rule-event-it uint16
			| | | +--rw time-type identityref
			| | | +--(one-time)
			| | | | +--rw event-time yang:date-and-time
			| | | +--(range-time)
			| | | +--rw event-start-time yang:date-and-time
			| | | +--rw event-end-time yang:date-and-time
			figure 7
			4.3.2. ECA Packet Condition Matches
			The ECA condition matches are packet matches (eca)
			4.3.2.1. Packet-match filter list (eca-pkt-match*)
			The packet match content filters include: address filters and packet
			header content filters, and packet payload filters.
			module:i2rs-pkt-eca-policy
			+--pkt-eca-policy-set
			+--rw rules* [order-id rule-name]
			| |....
			| +--rw cfg-rule-conditions [rule-cnd-id]
			| | +--rw rule-cnd-id uint32
			| | +--rw support
			| | | +--rw event-matches boolean
			| | | +--rw pkt-matches boolean
			| | | +--rw usr-context-matches boolean
			| | +--rw eca-event-match
			| | | ...
			| | +--rw eca-condition-match
			| | +--rw eca-pkt-matches* [pkt-match-id]
			| | | +--rw packet-match-id uint16
			| | | +--rw packet-match-type identityref
			| | | +--(packet-match-type)?
			| | | | +--:(address-pkt-match)
			| | | | | ...
			| | | | +--:(layer-pkt-match)
			| | | | | ...
			| | | | +--:(payload-pkt-match)
			| | | | | ...
			| | +--rw eca-user-matches [user-match-id]
			Figure 8
			4.3.2.1.1. Match filters for addresses in packet
			The address matches match the L3, mpls, MAC and interface address
			scope. Figure x shows this match
			+--rw eca-pkt-matches* [pkt-match-id]
			| +--rw packet-match-id uint16
			| +--rw eca-pkt-match-type identityref
			| +--address-scope?
			| | +--:(route-type)
			| | | +--: (ipv4)
			| | | | ... src, dest, src-dest
			| | | +--: (ipv6)
			| | | | ... src, dest, src-dest
			| | | +--: (mpls)
			| | | | ... 32 bit label
			| | | +--: (mac)
			| | | | ... src, dest, src-dest
			| | | +--: (interface-route)
			| | | | .... interface
			Figure 9
			4.3.2.1.2. Packet header matches
			The packet header matches match interface, L1-L4 headers, service
			chain headers, and packet size. The L1 header expected to be a null
			match except if there is an advanced L1 technology such as l1 with a
			L1 identifier that can be detected in the packet. Figure x shows
			these matches.
			| +--rw (layer-type)
			| | +--:(interface-match-type)
			| | | |...
			| | +--:(L1-header-match)
			| | | |...
			| | +--:(L2-header-match)
			| | | +--(802.1Q)
			| | | |....
			| | | +--(802.11)
			| | | | ...
			| | | +--(802.15)
			| | | | ...
			| | | +--(NVGRE)
			| | | | ...
			| | | +--(VXLAN)
			| | | | ...
			| | | +--(MPLS )
			| | | | ..
			| | +--:(L3-header-match)
			| | | +--(l3-ipv4-header)
			| | | | ...
			| | | +--(l3-ipv6-header)
			| | | | ...
			| | | +--(l3-gre-header)
			| | | | ...
			| | +--: L4-header-match
			| | | +--(l4-tcp-header)
			| | | | ...
			| | | +--(l4-udp-header)
			| | | | ...
			| | | +--(l4-sctp-header)
			| | | | ...
			| | | +--: Service-header-match
			| | | +--(sf-chain-meta-match)
			| | | ...
			| | | +--(sf-path-meta-match)
			| | | ..
			| | +--:(packet-size)
			| | +--l1-size-match uint32
			| | +--l2-size-match uint32
			| | +--l3-size-match uint32
			| | +--l4-size-mtach uint32
			| | +--service-meta-size uint32
			| | +--leaf service-meta-payload uint32
			| +---rw packet
			Figure 10
			4.3.2.1.3. Payload matches
			The payload information is a stream of bytes to be found in the
			packet payload beyond the L4 or service-path header. The structure
			of this data is simply a list of byte strings as figure x shows.
			| | |....
			| | +--rw eca-pkt-matches* [pkt-match-id]
			| | | +--rw packet-match-id uint16
			| | | +--rw packet-match-type identityref
			| | | +--(packet-match-type)?
			| | | | +--:(address-pkt-match)
			| | | | | ...
			| | | | +--:(layer-pkt-match)
			| | | | | ...
			| | | | +--:(payload-pkt-match)
			| | | | | +--rw packet-payload *[packet-payload-id]
			| | | | | +--rw packet-payload-id uint16
			| | | | | +--rw payload-match-bytes uint16
			| | | | | +--rw packet-payload string
			Figure 11
			4.3.2.2. Matches on User Context
			The match on user context allows filtering for a packet plus a filter
			related to a user.
			Since not all I2RS routers are access routers, the support for
			matches has a flag for user filter. It is expected that core routers
			may not support contextual matching.
			One example of user filters is for is parental controls. During
			school hours, the teenager Joe is restrict from certain web sites
			from September 1 while Joe is at at school. This "school" filter is
			an example of a period filter which has a start time (8:00am) and end
			time (3:30pm), which is valid beginning September 1, 2016. This
			filter applies only to the region of school networks. The filter
			looks for specific entertainment (e.g. YouTube) web sites, social-
			media (e.g. facebook), and gaming sites. This block is for their
			mobile phone and tablet, but not the computer that says at home.
			The following is the components
			o user identifier (name, tenant id, virtual network),
			o schedule for the user filter (once or periodic, time range (start/
			end), and weekly validity check),
			o region this filter is valid.
			o targeted services, applications, devices, and state.
			module:i2rs-pkt-eca-policy
			.....
			+--rw pkt-eca-policy-cfg
			| +--rw pkt-eca-policy-set
			| +--rw pkt-eca-policy-set
			| | ...
			| +--rw rules* [order-id rule-name]
			| +--rw order-id uint16
			| +--rw rule-name string
			| +--rw policy-name string
			| +--rw cfg-rule-conditions [rule-cnd-id]
			| | +--rw rule-cnd-id uint32
			| | | ...
			| | +--rw eca-event-match* [rule-event-id]
			| | | ..
			| | +--rw eca-pkt-matches* [pkt-match-id]
			| | | ....
			| | +--rw eca-usr-context-matches* [usr-match-id]
			| | | +--rw user* [user-id]
			| | | | +--rw user-id uint32
			| | | | +--rw user-name string
			| | | | +--rw user-type identityref
			| | | | | +--(user-type)?
			| | | | | | +--:(tenant)
			| | | | | | | +--rw tenant-id uint16
			| | | | | | +--:(vn-id)
			| | | | | | | +--rw vn-id uint16
			| | | +--rw schedule* [schedule-name]
			| | | | .....
			| | | +--rw target
			| | | | +--rw protocol
			| | | | | ... (UDP, TCP, ICMP, ICMPv6, IP, IPv6)
			| | | | +--rw transport-ports
			| | | | | +--rw src-port inet:port-number
			| | | | | +--rw dest-port intent:port-number
			| | | | +--service [service-name]
			| | | | |...
			| | | | +--rw application
			| | | | |...
			| | | | +--rw device
			| | | | | ..
			Figure 12
			Schedule filters allow a time for the filter. Continuing our
			parental control filters for school, the schedule an be a list of
			weekly filters for Monday-Friday of the school week. The first
			filter (School-Monday) would have a of start time of 8:00am GMT
			September 5, 2016 an end time of 4:00pm GMT September 5, 2016. The
			schedule type woudl be weekly. The validity-until time would be
			December 20, 2016. The region impacted by this schedule would be
			AS20999 which is the service provider of the school's network.
			+--rw pkt-eca-policy-cfg
			| +--rw pkt-eca-policy-set
			| +--rw pkt-eca-policy-set
			| | ...
			| +--rw rules* [order-id rule-name]
			| +--rw order-id uint16
			| +--rw rule-name string
			| +--rw policy-name string
			| +--rw cfg-rule-conditions [rule-cnd-id]
			| | +--rw rule-cnd-id uint32
			| | +--rw eca-usr-context-matches* [usr-match-id]
			| | | +--rw schedule* [schedule-name]
			| | | | +--rw schedule-name
			| | | | +--rw schedule-type identityref /* one-time, weekly, 2 weeks, monthly */
			| | | | +--rw start-type? yang:date-and-time
			| | | | +--rw end-type? yang:date-and-time
			| | | | +--rw validity-until yang:date-and-time /* valid until */
			| | | +--rw region *[as-4byte]
			| | | | +--rw as-4byte uint32 /* region */
			figure 13
			The target for this service filtering is specified by protocols,
			applications, and devices. The figure below shows the filtering for
			a target protocol and port number or an application.
			+--rw pkt-eca-policy-cfg
			| +--rw pkt-eca-policy-set
			| +--rw pkt-eca-policy-set
			| | ...
			| +--rw rules* [order-id rule-name]
			| +--rw order-id uint16
			| +--rw rule-name string
			| +--rw policy-name string
			| +--rw cfg-rule-conditions [rule-cnd-id]
			| | +--rw rule-cnd-id uint32
			| | +--rw eca-usr-context-matches* [usr-match-id]
			| | | +--rw target
			| | | | +--rw service* [svc-id svc-name]
			| | | | | +--rw svc-id uint16
			| | | | | +--rw svc-name string
			| | | | | +--rw protocol-support
			| | | | | | +--rw TCP boolean
			| | | | | | +--rw UDP boolean
			| | | | | | +--rw ICMP boolean
			| | | | | | +--rw ICMPv6 boolean
			| | | | | | +--rw IP boolean
			| | | | | +--rw src-port? inet:port-number
			| | | | | +--rw dest-port? inet_port-number
			| | | | +--rw application* [app-name]
			| | | | | +--rw app-name string
			| | | | | +--rw app-id uint16
			| | | | | +--rw app-category
			| | | | | /* business, educational, internet */
			| | | | | +--rw app-subcategory
			| | | | | /* finance, email, game, social-net, web */
			| | | | | +--rw app-data-transmission
			| | | | | /* client-server, web-brower, p2p, network */
			| | | | | +--rw app-risk-level
			| | | | | /* exploitable, evasive, data-lost, malware-vehicle, tun
			| | | | +--rw device
			| | | | | +--rw pc boolean
			| | | | | +--rw mobile-phone boolean
			| | | | | +--rw tablet boolean
			| | | | | +--rw voip-phone boolean
			Figure 14
			4.4. ECA Packet Actions
			The packet actions list includes ingress actions,egress actions, Qos
			actions that modify the packet, and security actions. The High level
			Yang that shows where the action fit is in figure 15, and the details
			are shown in figure 16. The QoS actions per header is shown in
			figure 17.
			module ietf-pkt-eca-policy
	+--rw pkt-eca-policy-cfg		+--rw pkt-eca-policy-cfg
	| +--rw pkt-eca-policy-set		| +--rw pkt-eca-policy-set
	| +--rw groups* [group-name]		| +--rw policies* [policy-name]
	| | ...		| | +--rw policy-name string
			| | +--rw vrf-name string
			| | +--rw address-family
			| | +--rw rule-list* [rule-name]
			| | | +--rw rule-name
			| | | +--rw rule-order-id uint16
			| | | +--rw default-action-id integer
			| | | +--rw default-resolution-strategy-id integer
	| +--rw rules* [order-id rule-name]		| +--rw rules* [order-id rule-name]
	| +--rw eca-matches		| +--rw order-id uint16
	| | . . .		| +--rw rule-name string
	| +--rw ecq-qos-actions		| +--rw cfg-rule-conditions [rule-cnd-id]
	| | +--rw cnt-actions		| | ...
			| +--rw cfg-rule-actions* [cfgr-action-id]
			| | +--rw cfgr-action-id
			| | +--rw eca-actions* [action-id]
			| | | +--rw action-id uint32
			| | | +--rw eca-ingress-actions
			| | | | ... (permit, deny, mirror)
			| | | +--rw eca-fwd-actions*
			| | | | ... (invoke, tunnel encap, fwd)
			| | | +--rw eca-egress-actions*
			| | | | ()
			| | | +--rw eca-qos-actions*
			| | | | ...
			| | | +--rw eca-security-actions*
			Figure 15
			This figure shows the details for each action section (ingress,
			egress, qos, and security).
			| +--rw eca-ingress-actions
			| | +--rw num-fwd-actions
			| | +--rw fwd-actions
			| | | +--rw permit boolean
			| | | +--rw mirror boolean
			| | | +--rw interface-fwd ip:interface-ref
			| | | +--uses i2rs:rib-nexthop
			| | | +--uses ip-next-fwd;
			| +--rw eca-egress-actions
			| | +--rw packet-rate uint32
			| | +--rw byte-rate uint32
			| | +--rw tunnel-encap boolean
			| | +--rw exit-fwding boolean
			| | +--rw interface-egress ip:interface-ref
			| | +--uses i2rs:rib-nexthop
			| | +--uses ip-next-fwd;
			| +--rw eca-qos-actions
			| | ... (see figure x below )
			| +--rw eca-security
			|
			| | +--rw security-action-type identityref
			| | +--(security-action-type)?
			| | +--:(content-security-action) ANYXML
			| | | ...
			| | +--:(attack-mitigation-type) ANYXML
			| | | ..
			| | +--:(single-packet-type) ANYXML
			figure 16 - forwarding
			> The QOS actions modify the headers are shown below.
			| +--rw ecq-qos-actions
			| | +--rw cnt-actions uint8 /* modifying actions */
	| | +--rw mod-actions		| | +--rw mod-actions
	| | | +--case interface-actions		| | | +--case interface-actions
			| | | | ..
	| | | +--case L1-action		| | | +--case L1-action
			| | | | ..
	| | | +--case L2-action		| | | +--case L2-action
			| | | | ..
	| | | +--case L3-action		| | | +--case L3-action
			| | | | ..
	| | | +--case L4-action		| | | +--case L4-action
			| | | | ..
	| | | +--case service-action		| | | +--case service-action
	| +--rw eca-fwd-actions		| | | | ..
	| | +--rw num-fwd-actions
	| | +--rw fwd-actions		Figure 17
	| | | +--rw interface interface-ref
	| | | +--rw next-hop rib-nexthop-ref		4.5. Policy Conflict Resolution strategies
	| | | +--rw route-attributes
	| | | +--rw rib-route-attributes-ref		Some policies within the filter-base policy will conflict. For
	| | | +--rw fb-std-drop		example, a global strategy may conflict with a local node strategy.
			This portion of the filter-based data model provides this support.
			| +--rw pc-resolution-strategies* [strategy-id]
			| | +--rw strategy-id integer
			| | +--rw pc-resolution-supported boolean
			| | +--rw filter-strategy identityref
			| | | .. FMR, ADTP, Longest-match
			| | +--rw global-strategy identityref
			| | +--rw mandatory-strategy identityref
			| | +--rw local-strategy identityref
			| | +--rw resolution-fcn uint32
			| | +--rw resolution-value uint32
			| | +--rw resolution-info string
			| | +--rw associated-ext-data*
			| | | +--rw ext-data-id integer
			Figure 18
			4.6. External Data
			External data may be used to set the policy.
			| +--rw cfg-external-data* [cfg-ext-data-id]
			| | +--rw cfg-ext-data-id integer
			| | +--rw data-type integer
			| | +--rw priority uint64
			| | +--rw external-data-forms anyxml /* mount point */
			Figure 19
	5. i2rs-eca-policy Yang module		5. i2rs-eca-policy Yang module
	<CODE BEGINS> file "ietf-pkt-eca-policy@2016-02-09.yang"		<CODE BEGINS> file "ietf-pkt-eca-policy@2016-02-09.yang"
	module ietf-pkt-eca-policy {		module ietf-pkt-eca-policy {
	namespace "urn:ietf:params:xml:ns:yang:ietf-pkt-eca-policy";		namespace "urn:ietf:params:xml:ns:yang:ietf-pkt-eca-policy";
	// replace with iana namespace when assigned		// replace with iana namespace when assigned
	prefix "pkt-eca-policy";		prefix "pkt-eca-policy";
	import ietf-routing {		import ietf-routing {
	skipping to change at page 42, line 7 ¶		skipping to change at page 54, line 19 ¶
	These I2RS filters operate dynamically at same level as currently		These I2RS filters operate dynamically at same level as currently
	deployed configured filter-based RIBs to filter, change, and forward		deployed configured filter-based RIBs to filter, change, and forward
	traffic. The dynamic nature of this protocol requires that I2RS		traffic. The dynamic nature of this protocol requires that I2RS
	Filters track the installer of group information and rules.		Filters track the installer of group information and rules.
	This section will be augmented after a discussion with security		This section will be augmented after a discussion with security
	experts.		experts.
	8. Informative References		8. Informative References
	[I-D.ietf-i2rs-architecture]
	Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
	Nadeau, "An Architecture for the Interface to the Routing
	System", draft-ietf-i2rs-architecture-15 (work in
	progress), April 2016.
	[I-D.ietf-i2rs-rib-info-model]		[I-D.ietf-i2rs-rib-info-model]
	Bahadur, N., Kini, S., and J. Medved, "Routing Information		Bahadur, N., Kini, S., and J. Medved, "Routing Information
	Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work		Base Info Model", draft-ietf-i2rs-rib-info-model-09 (work
	in progress), October 2015.		in progress), July 2016.
	[I-D.ietf-netconf-restconf]		[I-D.ietf-netconf-restconf]
	Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", draft-ietf-netconf-restconf-14 (work in		Protocol", draft-ietf-netconf-restconf-17 (work in
	progress), June 2016.		progress), September 2016.
	[I-D.ietf-netmod-acl-model]		[I-D.ietf-netmod-acl-model]
	Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,		Bogdanovic, D., Koushik, K., Huang, L., and D. Blair,
	"Network Access Control List (ACL) YANG Data Model",		"Network Access Control List (ACL) YANG Data Model",
	draft-ietf-netmod-acl-model-07 (work in progress), March		draft-ietf-netmod-acl-model-08 (work in progress), July
	2016.		2016.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,		[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
	"Policy Core Information Model -- Version 1		"Policy Core Information Model -- Version 1
	Specification", RFC 3060, DOI 10.17487/RFC3060, February		Specification", RFC 3060, DOI 10.17487/RFC3060, February
	skipping to change at page 42, line 48 ¶		skipping to change at page 55, line 5 ¶
	[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM)		[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM)
	Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003,		Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003,
	<http://www.rfc-editor.org/info/rfc3460>.		<http://www.rfc-editor.org/info/rfc3460>.
	[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.		[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
	Moore, "Policy Quality of Service (QoS) Information		Moore, "Policy Quality of Service (QoS) Information
	Model", RFC 3644, DOI 10.17487/RFC3644, November 2003,		Model", RFC 3644, DOI 10.17487/RFC3644, November 2003,
	<http://www.rfc-editor.org/info/rfc3644>.		<http://www.rfc-editor.org/info/rfc3644>.
			[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
			Nadeau, "An Architecture for the Interface to the Routing
			System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
			<http://www.rfc-editor.org/info/rfc7921>.
	Authors' Addresses		Authors' Addresses
	Susan Hares		Susan Hares
	Huawei		Huawei
	7453 Hickory Hill		7453 Hickory Hill
	Saline, MI 48176		Saline, MI 48176
	USA		USA
	Email: shares@ndzh.com		Email: shares@ndzh.com
	Qin Wu		Qin Wu
	Huawei		Huawei
End of changes. 56 change blocks.
	150 lines changed or deleted		616 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/