Internet DRAFT - draft-hares-i2rs-bgp-compare-yang
draft-hares-i2rs-bgp-compare-yang
I2RS working group S. Hares
Internet-Draft Huawei
Intended status: Standards Track October 27, 2014
Expires: April 30, 2015
Comparison of I2RS and Config BGP Yang Modules
draft-hares-i2rs-bgp-compare-yang-01
Abstract
This document contains a comparison of two BGP yang models: draft-
zhdankin-netmod-bgp-cfg-01 and draft-wang-i2rs-bgp-dm. The yang
model in draft-zhdankin-netmod-bgp-cfg-01 is a model focused on
configuration. The yang model in draft-wang-i2rs-bgp-dm-00 is
focused on the status and ephemeral state changes needed for the I2RS
interface. The conclusion of comparison is that there little overlap
except the definitions of common bgp structures. The draft-wang-
i2rs-bgp-dm-00 is necessary to fulfil a majority of the requirement
drawn from the BGP use cases in the I2RS use cases (draft-i2rs-hares-
usecase-reqs-summary).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Hares Expires April 30, 2015 [Page 1]
Internet-Draft IM for policy October 2014
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
3. BGP Yang Draft Comparison . . . . . . . . . . . . . . . . . . 4
4. Differences between the drafts . . . . . . . . . . . . . . . 4
4.1. Overlap of configuration draft-zhdankin-netmod-bgp-01 . . 7
4.2. Unique configuration for draft-zhdankin-netmod-bgp-01 . . 7
4.3. Unique configuration for draft-wang-bgp-dm-00 . . . . . . 8
5. Comparison of State needed versus BGP requirements . . . . . 9
5.1. BGP-REQ 01 . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. BGP-REQ 02 . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. BGP-REQ 03 . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. BGP-REQ 04 . . . . . . . . . . . . . . . . . . . . . . . 14
5.5. BGP-REQ 05 . . . . . . . . . . . . . . . . . . . . . . . 15
5.6. BGP-REQ 06 . . . . . . . . . . . . . . . . . . . . . . . 16
5.7. BGP-REQ 07 . . . . . . . . . . . . . . . . . . . . . . . 17
5.8. BGP-REQ 08 . . . . . . . . . . . . . . . . . . . . . . . 18
5.9. BGP-REQ 09 . . . . . . . . . . . . . . . . . . . . . . . 19
5.10. BGP-REQ 10 . . . . . . . . . . . . . . . . . . . . . . . 20
5.11. BGP-REQ 11 . . . . . . . . . . . . . . . . . . . . . . . 22
5.12. BGP-REQ 12 . . . . . . . . . . . . . . . . . . . . . . . 22
5.13. BGP-REQ 13 . . . . . . . . . . . . . . . . . . . . . . . 25
5.14. BGP-REQ 14 . . . . . . . . . . . . . . . . . . . . . . . 25
5.15. BGP-REQ 15 . . . . . . . . . . . . . . . . . . . . . . . 27
5.16. BGP-REQ 16 . . . . . . . . . . . . . . . . . . . . . . . 27
5.17. BGP-REQ 17 . . . . . . . . . . . . . . . . . . . . . . . 28
5.18. BGP-REQ 18 . . . . . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. Informative References . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction
The Interface to the Routing System (I2RS) provides read and write
access to the information and state within the routing process within
routing elements. The I2RS client interacts with one or more I2RS
agents to collect information from network routing systems. The
processing of collecting information at the I2RS agent may require
the I2RS Agent to filter certain information, group pieces of
Hares Expires April 30, 2015 [Page 2]
Internet-Draft IM for policy October 2014
information, or perform actions on the I2rs collected information
based on specific I2rs policies.
This draft is a comparison of the following two BGP yang models:
[I-D.zhdankin-netmod-bgp-cfg], and [I-D.wang-i2rs-bgp-dm]. The
comparison provides an overview of the differences, overlaps, and
unique features of each yang model. The analysis also evaluates
whether both models or a single model is necessary to satisfy the
requirements for the BGP use cases found in the
[I-D.hares-i2rs-usecase-reqs-summary].
This draft concludes each of these two drafts focuses on the purpose
each draft was created for (configuration, I2rs status and ephemeral
state). The drafts have little overlap outside common definitions
for some of the BGP functions. Both drafts reference bgp policy
outside the basic structures (Prefix-lists, and policy-groups). Both
drafts have concepts of AFI level and BGP neighbor level features.
The status and ephemeral state found in [I-D.wang-i2rs-bgp-dm] is
necessary to fulfil the BGP use cases found in the
[I-D.hares-i2rs-usecase-reqs-summary]. Configuration knobs in
[I-D.zhdankin-netmod-bgp-cfg] were helpful to support these bgp use
cases, but the lack of state would not allow support of these
features. The recommendation is that the two drafts harmonize the
group structures and continue as two separate drafts for their
original purpose (config and I2RS).
One BGP requirement (BGP-REQ18) requires a re-computation of the
local BGP tables after policies have been modified by the ephemeral
interface. The exact methodology of this re-computation could be
part of ephemeral soft re-configuration. However, the I2RS WG has
not determine how ephemeral state acts. Neither draft has created
mechanism to do the ephemeral state re-configuration which is wise
since both the I2RS WG and netmod WG should develop a joint ephemeral
re-configuration process.
The rest of this draft is the details so those who desire "sounds
bytes" level reading may stop reading now.
2. Definitions and Acronyms
BGP - Border Gateway Protocol version 4
CLI: Command Line Interface
IGP: Interior Gateway Protocol
I2RS: Interface to (2) Routing system.
Hares Expires April 30, 2015 [Page 3]
Internet-Draft IM for policy October 2014
Information Model: An abstract model of a conceptual domain,
independent of a specific implementations or data representation
INSTANCE: Routing Code often has the ability to spin up multiple
copies of itself into virtual machines. Each Routing code
instance or each protocol instance is denoted as Foo_INSTANCE in
the text below.
NETCONF: The Network Configuration Protocol
3. BGP Yang Draft Comparison
The authors of [I-D.zhdankin-netmod-bgp-cfg] focused on the
configuration aspect of BGP (98%+ configuration, 2% status). The
[I-D.wang-i2rs-bgp-dm] is focused on the I2RS need for status with a
small amount of specific I2RS configuration for I2RS needs (95%
status, 2% config). The two drafts can be combined together, but
guidance is needed from the netmod group as the I2RS state is read-
write ephemeral.
Why is draft-wang-bgp-dm-00 mostly focused on routes, statistics, and
state?
The use cases specified in [I-D.hares-i2rs-usecase-reqs-summary]
demonstrate a need for the status found in [I-D.wang-i2rs-bgp-dm]
which includes: bgp-local-rib, bgp-rib-in, bgp-rib-out and all kinds
of statistics and state, such as protocol-status , bgp-rt-state-info,
peer-state-info, max-prefix-rcv-limit, etc. The status is both a the
AFI state and the BGP peer state (within the AFI).
Two versions of [I-D.zhdankin-netmod-bgp-cfg] have been released - a
-00.txt and a -01.txt he second version (-01 version) only updated
references to netmod and states on the yang modules. This draft will
use the -01 version of [I-D.zhdankin-netmod-bgp-cfg],
The [I-D.wang-i2rs-bgp-dm] was released mistakenly as
[I-D.hares-i2rs-bgp-dm]. A few corrections to the status fields were
included in the [I-D.wang-i2rs-bgp-dm]. This draft uses
[I-D.wang-i2rs-bgp-dm] for the comparison.
4. Differences between the drafts
The [I-D.zhdankin-netmod-bgp-cfg] is composed by two parts: BGP
Router Configuration and Prefix Lists. BGP Router Configuration
contains including 3 parts: af-configuration , bgp-neighbors, and
rpki-config (as shown in figure 1).
Hares Expires April 30, 2015 [Page 4]
Internet-Draft IM for policy October 2014
module: bgp
+--rw bgp-router
| +--rw rpki-config
| +--rw af-configuration
| +--rw bgp-neighbors (98% config, 2% state)
+--rw Prefix Lists
+--rw prefix-lists
+--rw prefix-list [prefix-list-name]
+--rw prefix-list-name string
+--rw prefixes
+--rw prefix [seq-nr]
+--rw seq-nr uint16
+--rw prefix-filter
+--rw (ip-address-group)?
| .....
+--rw action actions-enum
+--rw statistics
.....
Figure 1: draft-zhdankin-netmod-bgp-cfg structure
The [I-D.wang-i2rs-bgp-dm] is written with a status structure focus
where manipulation of every concrete route through controlling policy
and BGP attributes in different BGP address families. This does not
contain the rpki-config. These drafts have ~5% overlap in status/
configuration.
module: bgp
+--rw bgp-protocols
| +--rw af-status
| | +--rw bgp-local-rib
| | +--rw bgp-neighbors (2% config, 98% state)
| | | +--rw policy-in
| | | +--rw policy-out
| | | +--rw peer-state
| | | +--rw bgp-rib-in
| | | +--rw-bgp-rib-out
module: ietf-pcim
+--rw Policy-sets
+--rw Policy-groups
+--rw Policy-Rules
Figure 2 draft-i2rs-wang-bgp-dm-00
Hares Expires April 30, 2015 [Page 5]
Internet-Draft IM for policy October 2014
o The focus is status-based based on AFI, but includes local-rib and
BGP neighbor's policy (in and out), peer state, rib-in, and rib-
out.
o prefix list policy being covered inline
([I-D.zhdankin-netmod-bgp-cfg]) versus in the draft-hares-bnp-
im-01 which uses the policy descriptions created by RFC3060,
RFC3460, and other policy work. This methodology is being
utilized by the OpenDaylight Group policy as well.
o Redistribution being done inline ([I-D.zhdankin-netmod-bgp-cfg])
as a configuration. The draft-i2rs-wang-bgp-dm-00 did not
configure af-configuration.
o [I-D.zhdankin-netmod-bgp-cfg] claims to list the aspath path was
well as the prefix configuration, but this section is missing in
the draft. The example is the expression of as-path in draft-
i2rs-wang-bgp-dm-00 is a actually string value of as-path which is
one of attributes in BGP route rather not a Boolean value as used
in [I-D.zhdankin-netmod-bgp-cfg].
o The order of specifying the protocol elements is different in some
cases due to the status versus configuration focus. For example,
limiting maximum prefixes and maximum paths is done in a slightly
different way. A second example is that community and cluster
strings.
Below is an example of the AF-status structure found in draft-bgp-
dm-00
module: bgp-protocol
+--rw bgp-protocol
+--rw bgp-ipv4-uni-instance
| +--rw bgp-local-rib
| +--rw bgp-peer-list
| +--rw bgp-rib-in
| +--rw bgp-rib-out
......
+--rw bgp-evpn-instance
| +--rw bgp-local-rib
| +--rw bgp-peer-list
| +--rw bgp-rib-in
| +--rw bgp-rib-out
figure bgp-3
Hares Expires April 30, 2015 [Page 6]
Internet-Draft IM for policy October 2014
4.1. Overlap of configuration draft-zhdankin-netmod-bgp-01
The draft-zhdankin-netmod-bgp-01 and draft-wang-i2rs-bgp-dm-00 both
contain at the protocol level:
module: bgp
+--rw bgp router [bgp protocol]
+--rw local-as-number? unit32
+--rw local-as-identifier inet:ip-address (zhdankin)
+--rw router-id inet:ip-address (wang)
...
figure bgp-3
The module contains at the peer level the association of a peer with
an AS
[draft-zhdank-netmod-bgp-01]
+--rw bgp-neighbors* [AS-number]
+--rw as-number
+--rw (peer-address-type)?
. . .
+--rw prefix-list prefix-list-ref
+--default-action? enumeration (permit/deny)
[[I-D.wang-i2rs-bgp-dm]]
+--rw bgp-peer-list* [bgp-peer-name]
+--rw peer-session-address?
. . .
+--rw peer-name
+--ro peer-type
+--rw bgp-policy-in policy-set-name
+--rw bgp-policy-out policy-set-name
figure bgp-5
4.2. Unique configuration for draft-zhdankin-netmod-bgp-01
[I-D.zhdankin-netmod-bgp-cfg] contains the unique configuration for
RPKI, AF-configuration and BGP peers. A sample of the unique
configuration for the AF-configuration is:
o cost-communities
o BGP-damping
o route-aggregation - this is policy so we could easily add,
Hares Expires April 30, 2015 [Page 7]
Internet-Draft IM for policy October 2014
o reflector clients
o best external advertisement
o aggregate timer (sending out aggregate times)
o flags to compare router-id as part of bgp bestpath selection
o MED-confederation
o administrative distance (cisco)
o packet forwarding over multiple paths
o allowances for slow peers
o BGP multi-path (ECMP peers)
o external fail-over for peer
o AS confederations
o deterministic MEDs
o Graceful-restart
o BGP AS listener only
o Logging of neighbor changes
o Transport options for BGP
o Removal of private AS
4.3. Unique configuration for draft-wang-bgp-dm-00
The following variables were included in [I-D.hares-i2rs-bgp-dm], but
not in [I-D.zhdankin-netmod-bgp-cfg]:
o protocol-status (ro) - needed for I2RS information
o shutdown protocol - needed if I2RS is to shutdown bgp protocol,
o AFI based local-rib
o BGP-peer-status information - [I-D.zhdankin-netmod-bgp-cfg] has
number of updates, but less status information in the draft.
Hares Expires April 30, 2015 [Page 8]
Internet-Draft IM for policy October 2014
The following pieces are needed by I2RS:
o At instance level, bgp-instance-name, bgp-instance-create (to
create bgp process), bgp-instance-type (to specify what type to
create),
o At AFI level in local rib, bgp_route_create (to add bgp route for
i2rs) and bgp_state_info for status updates.
o At peer level, there must be maximum prefixes per peer (received
and transmit), high water/low water prefix counts, and average
number of prefixes;
o Versions for instance publishing,
o Details on path attributes: ASpath strings, community and extend-
community attribute, cluster lists, aggregation, atomic
aggregator;
o Mechanisms for logging/publishing information
5. Comparison of State needed versus BGP requirements
5.1. BGP-REQ 01
BGP-REQ01 requirement is: I2RS client/agent exchange SHOULD support
the read, write and quick notification of status of the BGP peer
operational state on each router within a given Autonomous System
(AS). This operational status includes the quick notification of
protocol events that proceed a destructive tear-down of BGP session
[I-D.zhdankin-netmod-bgp-cfg] contains the following status related
to each peer's bgp operational state.
module: bgp
+--bgp-router
+ . . .
+--rw bgp-neighbors
+--rw peer-address
| . . .
+--rw bgp-neighbor-state
+--rw bgp-peer-admin-status enumeration
+--rw in-lastupdatetime
Figure bgp-6
Conclusion: [I-D.zhdankin-netmod-bgp-cfg] does not provide support
required by I2RS.
Hares Expires April 30, 2015 [Page 9]
Internet-Draft IM for policy October 2014
[I-D.wang-i2rs-bgp-dm] contains the following status related to each
peer's BGP operational state:
module: bgp
+--bgp-protocol
+ . . .
+rw bgp-ipv4-uni-instance (af-instance)
+--rw bgp-instance-name
| . . .
+--rw bgp-local-rib
| . . .
+--rw bgp-peer-list [bgp-peer-name]
| . . .
| +--rw peer-state-info
| | +--rw peer-current-state? peer-state
| | |--rw peer-last-state? peer-state
| | |--ro peer-down-reason
| | |--ro error code? enumeration
| | | +--ro (sub-error-code-type)?
| | | | +--: (head-error-sub-code)
| | | | +--ro head-error-sub-value? enumeration
| | | | +--: (open-error-sub-code)
| | | | +--ro open-error-sub-value? enumeration
| | | | +--: (update-error-sub-code)
| | | | +--ro-update-error-sub-value? enumeration
| | | | +--: (route-refresh-error-sub-code)
| | | | +--ro-route-refresh-error-sub-value? enumeration
figure bgp-7
Conclusion: [I-D.wang-i2rs-bgp-dm] provides for this requirement.
5.2. BGP-REQ 02
BGP-REQ02 requirement is: "I2RS client SHOULD be able to push BGP
routes with custom cost communities to specific I2RS agents on BGP
routers for insertion in specific BGP Peer(s) to aid Traffic
engineering of data paths. These routes SHOULD be tracked by the
I2RS Agent as specific BGP routes with customer cost communities.
These routes (will/will not) be installed via the RIB-Info."
Status:
[I-D.zhdankin-netmod-bgp-cfg] supports configuration related to
address family control of these features, but it does not have a
route level support. The AFI family configuration is shown in
context below:
Hares Expires April 30, 2015 [Page 10]
Internet-Draft IM for policy October 2014
module: bgp
+--rw bgp-router
| +--rw local-as-number? uint32
| +--rw local-as-identifier? inet:ip-address
| +--rw rpki-config
| | .....
| +--rw af-configuration
| | +--rw ipv4
| | | +--rw mdt
| | | . . .
| | | +--rw multicast
| | | | +--rw bgp
| | | | | +--rw bgp-af-config
| | | | | | . . .
| | | | | | +--rw bestpath
| | | | | | | +--case as-path:
| | | | | | | ignore-as-path boolean
| | | | | | | +--case compare-routerid
| | | | | | | | ignore-routerid boolean
| | | | | | | + case cost-community
| | | | | | | | ignore-cost-community Boolean
| | | | . . .
| | | +--rw unicast
| | | | +--rw bgp
| | | | +--rw bgp-af-config
| | | | | . . .
| | | | | +--rw bestpath
| | | | | | . . .
| | | | | | +--case cost-community
| | | | | | | | ignore-cost-community Boolean
| | | +--rw unicast
| | | | +--rw bgp
| | | | +--rw bgp-af-config
| | | | | . . .
| | | | | +--rw bestpath
| | | | | | . . .
| | | | | | +--case cost-community
| | | | | | | | ignore-cost-community Boolean
(replicated for appropriate AFIs)
Figure bgp-8
Conclusion: This [I-D.zhdankin-netmod-bgp-cfg] does not adequately
support the I2RS BGP REQ02. .
[I-D.wang-i2rs-bgp-dm] does support per-route configuration tagging
of route with customer community in local BGP rib, and per peer
AdjRibIn and adjRibout
Hares Expires April 30, 2015 [Page 11]
Internet-Draft IM for policy October 2014
+--bgp-protocol
+ . . .
+rw bgp-ipv4-uni-instance (af-instance)
+--rw bgp-instance-name
| . . .
+--rw afi
+--rw safi
+--rw bgp-local-rib
| +--rw bgp-route-list* [ipv4-route ipv4-prefix-length]
| | +--rw ipvr-route inet:ipv4-prefix
| | +--rw ipv4-prefix-length uint8
| | +--rw route-type? enumeration
| | +--rw bgp-attribute-list*
| | | +--rw bgp-origin?
| | | . . .
| | | +--rw bgp-extcommattr
| | | | +--rw custom-community
| | | | | +--rw valid boolean
| | | | | +--rw insertion point uint8
| | | | | +--rw community-id uint8
| | | | | +--rw cost-id uint32
| | | | +--rw useextcommsize uint16
| | | | +--rw ulrefcount? uint16
| | | | +--rw excmmattr-value string
| +--rw bgp-peer-list* (bgp-peer-name)
| | . . .
| | +--rw bgp-rib-in
| | | +--rw bgp-rib-in-list* (ipv4 route
| | | | ipvr-prefix-length route-distinguisher)
| | | | +--rw ipv4-route inet_ipv4-prefix
| | | | | +--rw bgp-attribute-list*
| | | | | | . . .
| | | | | | +--rw bgp-extcommattr
| | | | | | | +--rw custom-community
| | | | | | | +--rw valid boolean
| | | | | | | +--rw insertion point uint8
| | | | | | | +--rw community-id uint8
| | | | | | | +--rw cost-id uint32
| | | | | | | +--rw useextcommsize uint16
| | | | | | | +--rw ulrefcount? uint16
| | | | | | | +--rw excmmattr-value string
| | | . . .
| | +--rw bgp-rib-out
| | | +--rw bgp-rib-out-list* (ipv4 route
| | | | ipv4-prefix-length route-distinguisher)
| | | | +--rw ipv4-route inet_ipv4-prefix
| | | | | +--rw bgp-attribute-list*
| | | | | | . . .
Hares Expires April 30, 2015 [Page 12]
Internet-Draft IM for policy October 2014
| | | | | | +--rw bgp-extcommattr
| | | | | | | +--rw custom-community
| | | | | | | +--rw valid boolean
| | | | | | | +--rw insertion point uint8
| | | | | | | +--rw community-id uint8
| | | | | | | +--rw cost-id uint32
| | | | | | | +--rw useextcommsize uint16
| | | | | | | +--rw ulrefcount? uint16
| | | | | | | +--rw excmmattr-value string
Figure bgp-9
Conclusion: [I-D.wang-i2rs-bgp-dm] needed as well as
[I-D.zhdankin-netmod-bgp-cfg].
5.3. BGP-REQ 03
BGP-REQ03 requirement is: "I2RS client SHOULD be able to track via
read or notifications all Traffic engineering changes applied via
I2RS agents to BGP route processes in all routers in a network."
Discussion on Requirement: Traffic engineering changes can include:
ORFs (RFC5291, 5292), flows specifications (RFC5575, draft-ietf-), TE
performance (draft-ietf-idr-te-pm-bgp-01), traffic-engineering state
(draft-ietf-idr-te-lsp-distribution), and route target filtering.
Additional input needs to be obtained from the i2rs WG on what
constitutes traffic engineering.
Status:
[I-D.zhdankin-netmod-bgp-cfg] has the following potential
configuration support:
o on most af configurations: af-bgp_config container supports
allowing the following features: add-path, best-external,
aggregation timer, damping, propagating dmz-link-bw, and
redistributing iBGP routes into IGP.
o af rtfilters - AFI for rtfilters.
These features do not provide any of the traffic engineering input.
[I-D.wang-i2rs-bgp-dm]: has per route status tracking for the local-
rib associated with each afi, and the virtual bgp AdjRibIn and BGP
AdjRibOut for each peer. Each route has a route type that include
route types for all valid NLRIs which includes: ipv4, ipv6, labeled
ipv4, labeled ipv6, flows, link-state (ls) data, evpn, mvpn, vpls,
l2vpn-singaling-nlri, rt-constraint, pw-route.
Hares Expires April 30, 2015 [Page 13]
Internet-Draft IM for policy October 2014
+--bgp-protocol
+ . . .
+rw bgp-ipv4-uni-instance (af-instance)
+--rw bgp-instance-name
| . . .
+--rw afi
+--rw safi
+--rw bgp-local-rib
| +--rw bgp-route-list* [ipv4-route ipv4-prefix-length]
| | +--rw ipvr-route inet:ipv4-prefix
| | +--rw ipv4-prefix-length uint8
| | +--rw route-type? enumeration
| | +--rw route-admin-distance uint16
| | ....
| | +--rw bgp-attribute-list*
| | | +--rw bgp-origin?
Figure bgp-10
What needs to be added: Once the I2RS WG specifies what traffic
engineering flags to watch on the BGP routes at AFI local-rib level
or the BGP-peer routes (AdjRibIn, AdjRibOut), then the
[I-D.wang-i2rs-bgp-dm] can be augmented.
If the I2RS WG specifies configurations for traffic engineering at
the AFI or BGP-peer level, these ephemeral status will either need to
be added to draft-want-i2rs-bgp-dm-00 status or the peer.
5.4. BGP-REQ 04
BGP-REQ04 requirement is: "I2RS Agents SHOULD support identification
of routers as BGP ASBRs, PE routers, and IBGP routers."
[I-D.zhdankin-netmod-bgp-cfg]: No status provides a summation of the
BGP roles a BGP routing instance. The BGP-neighbor structure does
not provide a role structure.
[I-D.wang-i2rs-bgp-dm]:
Hares Expires April 30, 2015 [Page 14]
Internet-Draft IM for policy October 2014
module: bgp-protocol
+--rw bgp-protocol
+--rw router-id? inet:ip-address
+--rw as-number? uint32
+ . . .
+--ro bgp-role? enumeration
+--rw af instance
| +--rw bgp-local-rib
| . . .
| +--rw bgp-peer-list* [bgp-peer-name]
| | +--rw bgp peer-session
| | +--rw bgp-peer-name
| | +--bgp-peer-type? enumeration
Figure bgp-11
The enumeration for bgp-role is asbr, pe, ibgp,rr where the role is a
bit mask indicating that one or more peer has this role on the
protocol instance.
The enumeration for bgp-peer-type is asbr, ibgp, rr, rr-client, pe,
ce, bgp-vendor-types;
Conclusion: [I-D.wang-i2rs-bgp-dm] supports BGP-REQ 04
5.5. BGP-REQ 05
BGP-REQ05 is: I2RS client-agent SHOULD support writing traffic flow
specifications to I2RS Agents that will install them in associated
BGP ASBRs and the PE routers.
Status: BGP-REQ05 is the ability to read the roles within a bgp
protocol instances at protocol level and at peer level, and to write
routes with traffic flow specifications to AFI database and
(optionally) bgp-peer AdjRibOut.
BGP-REQ 4 showed that the [I-D.wang-i2rs-bgp-dm] supports the
identification of BGP ASBR and PE routers at a peer level. It also
has a quick summary of the roles of BGP routers at the protocol
level. [I-D.wang-i2rs-bgp-dm] specifies a a route-type variable
within each route in the AFI local-rib or the BGP Peers routes
(AdjRibIn, AdjRibOut), and this route-type includes a enumeration
variable for flows.
[I-D.wang-i2rs-bgp-dm]
Hares Expires April 30, 2015 [Page 15]
Internet-Draft IM for policy October 2014
module: bgp protocol
+--bgp-protocol
+ . . .
+rw bgp-ipv4-uni-instance (af-instance)
+--rw bgp-instance-name
| . . .
+--rw afi
+--rw safi
+--rw bgp-local-rib
| +--rw bgp-route-list* [ipv4-route ipv4-prefix-length]
| | +--rw ipv4-route inet:ipv4-prefix
| | +--rw ipv4-prefix-length uint8
| | +--rw route-type? enumeration
Figure bgp-12
Conclusion: [I-D.wang-i2rs-bgp-dm] supports BGP-REQ-05.
5.6. BGP-REQ 06
BGP-REQ06 requirement is: "I2RS Client SHOULD be able to track flow
specifications installed within a IBGP Cloud within an AS via reads
of BGP Flow Specification information in I2RS Agent, or via
notifications from I2RS agent."
Status: As section 3.5.5 on BGP-REQ04 shows [I-D.wang-i2rs-bgp-dm]
supports the tracking of flow-specification routes associated with
the local-rib for a AFI or a BGP Peer.
[I-D.wang-i2rs-bgp-dm]:
Hares Expires April 30, 2015 [Page 16]
Internet-Draft IM for policy October 2014
module: bgp protocol
+--bgp-protocol
+ . . .
+rw bgp-ipv4-uni-instance (af-instance)
+--rw bgp-instance-name
| . . .
| +--rw bgp-local-rib
| | +--rw bgp-rib-in-list* (ipv4 route ipv4-prefix-length
| | | +--rw ipv4-route inet:ipv4-prefix
| | | +--rw ipv4-prefix-length uint8
| | | +--rw route-type? enumeration
| | . . .
| +--rw bgp-peer-list* (bgp-peer-name)
| | +--rw bgp-peer-session addres
| | +--rw bgp-peer-name
| | +--rw bgp-peer-type
| | +--rw bgp-rib-in
| | | +--rw bgp-rib-in-list* (ipv4 route ipv4-prefix-length
| | | | +--rw ipv4-route inet:ipv4-prefix
| | | | +--rw ipv4-prefix-length uint8
| | | | +--rw route-type? enumeration
Figure bgp-13
5.7. BGP-REQ 07
BGP-REQ07 requirement is: I2RS client-agent exchange SHOULD support
the I2RS client being able to prioritize and control BGP's
announcement of flow specifications after status information reading
BGP ASBR and PE router's capacity. BGP ASBRs and PE routers
functions within a router MAY forward traffic flow specifications
received from EBGP speakers to I2RS agents, so the I2RS Agent SHOULD
be able to send these flow specifications from EBGP sources to a
client in response to a read or notification.
Discussion: The I2RS WG needs to provide additional input on what
status information is key to track for the BGP ASBR and PE router's
capacity.
Status:
[I-D.zhdankin-netmod-bgp-cfg] has prefix-lists which can allow or
deny prefixes based on the NLRI family. This feature allows the
control of routes via the flow specification NLRI. However peer
status does not provide an easy way to detect BGP ASBR or PE status,
or the number of routes.
Hares Expires April 30, 2015 [Page 17]
Internet-Draft IM for policy October 2014
[I-D.wang-i2rs-bgp-dm] has the ability to specify flexible policy via
policy-sets for inbound and outbound policy that can filter based on
prefix or any match sequence within the route and peer. This draft
also provides a data model that tracks track which peers are ASBR and
PEs at the peer level via bgp-peer-type and at the protocol level via
bgp-role (as described above). This draft also specifies
administrative distance on route structures in the per AFI bgp-local-
rib or in the peers routes per AFI.
module: bgp protocol
+--bgp-protocol
+ . . .
+rw bgp-ipv4-uni-instance (af-instance)
+--rw bgp-instance-name
| . . .
| +--rw bgp-local-rib
| | +--rw bgp-rib-in-list* (ipv4 route ipv4-prefix-length
| | | +--rw ipv4-route inet:ipv4-prefix
| | | +--rw ipv4-prefix-length uint8
| | | +--rw route-type? enumeration
| | | +--rw route-admin-distance uint32
| | | +--rw route-rpki-origin-validity
| | | | +--rw rt-rpki-origin-valid Boolean
| | | | +--rw rt-rpki-ref rpki-validity-ref
figure bgp-14
5.8. BGP-REQ 08
BGP-REQ08 requirement is: "I2RS Client SHOULD be able to read BGP
route filter information from I2RS Agents associated with legacy BGP
routers, and write filter information via the I2RS agent to be
installed in BGP RR. The I2RS Agent SHOULD be able to install these
routes in the BGP RR, and engage a BGP protocol action to push these
routers to ASBR and PE routers."
Discussion: The router filter information is determined to be the
prefix-filters or policy-filters associated with BGP routes found in
the AFI based bgp-local-rib or peer's structures (AdjRibIn,
AdjRibout).
Status:
[I-D.zhdankin-netmod-bgp-cfg] has prefix-lists which can allow or
deny prefixes based on the NLRI. This yang model does not provide an
easy way to detect peers as taking on the BGP RR, ABSR, and PE. (See
section 3.3 and yang model for the prefix-list descriptions).
Hares Expires April 30, 2015 [Page 18]
Internet-Draft IM for policy October 2014
[I-D.wang-i2rs-bgp-dm] has the ability to specify flexible policy via
policy-groups or policy sets for inbound and outbound policy that can
filter based on prefix or any match sequence within the route and
peer. This draft also provides a data model that tracks track which
peers are ASBR, PEs, and RR at the peer level via bgp-peer-type and
at the protocol level via bgp-role. (Please see draft-ietf-i2rs-
hares-bnp-info-model and draft-itef-hares-i2rs-bnp-dm for full
description).
5.9. BGP-REQ 09
BGP-REQ09: I2RS client(s) SHOULD be able to request the I2RS agent to
read BGP routes with all BGP parameters that influence BGP best path
decision, and write appropriate changes to the BGP Routes to BGP and
to the RIB-Info in order to manipulate BGP routes.
Discussion: Best-path is considered when policy evaluation is the
same. The best path could be considered based on origin-as, as-path,
router-id, cost-community. igp-metric, med-confed, missing-as-med,
rpki-origin validity. This requirement needs to be refined to
specify an initial set of BGP parameters that influence BGP best path
decisions.
Status:
[I-D.zhdankin-netmod-bgp-cfg] configures the parameters that
influence BGP bestpath decisions. However, this draft does not
provide these parameters within each bgp-route.
[I-D.wang-i2rs-bgp-dm] provides the per route status on origin-as,
as-path, router-id, cost-community, igp-metric, MED, and rpki-origin
validity. This route status is on the AFI level local-rib and the
per peer routes (AdjRibIn, AdjRibOut).
Hares Expires April 30, 2015 [Page 19]
Internet-Draft IM for policy October 2014
module: bgp protocol
+--bgp-protocol
+ . . .
+rw bgp-ipv4-uni-instance (af-instance)
+--rw bgp-instance-name
| . . .
| +--rw bgp-local-rib
| | +--rw bgp-rib-in-list* (ipv4 route ipv4-prefix-length
| | | +--rw ipv4-route inet:ipv4-prefix
| | | +--rw ipv4-prefix-length uint8
| | | +--rw route-type? enumeration
| | | +--rw route-admin-distance uint32
| | | +--rw route-rpki-origin-validity
| | | | +--rw rt-rpki-origin-valid Boolean
| | | | +--rw rt-rpki-ref rpki-validity-ref
figure bgp-15
5.10. BGP-REQ 10
BGP-REQ10 requirement is: I2RS client SHOULD be able instruct the
I2RS agent(s) to notify the I2RS client when the BGP processes on an
associated routing system observe a route change to a specific set of
IP Prefixes and associated prefixes. Route changes include: 1)
prefixes being announced or withdrawn, 2) prefixes being suppressed
due to flap damping, or 3) prefixes using an alternate best-path for
a given IP Prefix. The I2RS agent should be able to notify the
client via publish or subscribe mechanism.
Discussion: RFC5277 indicates that a netconf-filter looks for
specific data value and data item. Therefore, the I2RS client must
specify the whether the data is in the AFI based local-rib or the BGP
(AdjRibIn, AdjRibOut) and the specific values. The specific values
indicated by BGP-REQ-10 are prefixes with: announce flags, withdrawn
flags, flap-dampened suppression flags, on-best-path-external or
rejected due to best-path external. This comparison assumes the
RFC5277 paths can be made to work for the ephemeral storage.
Sorting of these filters into critical or normal status requests is
not considered in this comparison as adding this upon a non-existent
definition of ephemeral services seems futile.
[I-D.zhdankin-netmod-bgp-cfg] configures the parameters that
influence BGP bestpath decisions or flap damping. However, this
draft does not provide these parameters within each bgp-route.
[I-D.wang-i2rs-bgp-dm]:
Hares Expires April 30, 2015 [Page 20]
Internet-Draft IM for policy October 2014
+--rw ipv4-route inet:ipv4-prefix
+--rw ipv4-prefix-length uint8
+--rw bgp-route-type? enumeration
+--rw bgp-attribute-list
...
+--ro bgp-rt-state-in
+--ro rib-current-state? rib-state-def
+--ro rib-last-state? rib-state-def
+--ro rib-rejected-reason? enumeration
+--ro not-preferred-reason? enumeration
. . .
typedef rib-state-def {
type enumeration {
enum "active";
enum "in-active";
enum "primary";
enum "backup";
enum "suppressed (flap dampened)"
enum "suppressed non-flap dampen"
enum "active on alternate best path"
}
Leaf not-preferred-reason {
Type enumeration {
enum "peer-address";
enum "router-id";
enum "cluster-list-length";
enum "igp-metric";
enum "peer-type";
enum "origin";
enum "weight-or-preferred-value";
enum "local-preference";
enum "route-type";
enum "as-path-length";
enum "med";
enum "flap-dampened route"; [new]
enum "not-this-path-prefix-uses-alternate-best-path"; [new]
enum "overlapping-route-marked-to-remove"; [new] (BGP-REQ17)
}
Figure bgp 16
Conclusion: [I-D.wang-i2rs-bgp-dm] status is needed for this BGP-
REQ10.
Hares Expires April 30, 2015 [Page 21]
Internet-Draft IM for policy October 2014
5.11. BGP-REQ 11
BGP-REQ11 requirement is the "I2RS client SHOULD be able to read BGP
route information from BGP routers on routes in received but rejected
from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN, but
not selected as best path, and on route not sent to IBGP peers (due
to non-selection)."
Discussion: As discussed in BGP-REQ10, RFC5277 indicates that a
netconf-filter looks for specific data value and data item.
Therefore, the I2RS client must specify the whether the data is in
the AFI based local-rib, or the BGP (AdjRibIn, AdjRibOut) and the
specific values
Status:
[I-D.zhdankin-netmod-bgp-cfg] configures policy that indicates what
routes are filtered, but it does not provide the status parameter on
each BGP route.
[I-D.wang-i2rs-bgp-dm]: Shows that the status can be tracked in the
AFI based bgp local-rib and the per AFI per peer AdjRibIn and AdjRib
out.
Conclusion: [I-D.wang-i2rs-bgp-dm] status is needed for BGP-REQ10.
5.12. BGP-REQ 12
BGP-REQ12 requirement is: the "I2RS client SHOULD be able to request
the I2RS agent to read installed BGP Policies."
Discussion: BGP policies can be inbound filters, ACLs, or route maps.
Three yang drafts take different approaches to the filters: draft-
bogdanovic-netmod-acl-model-02, [I-D.zhdankin-netmod-bgp-cfg], and
draft-hares-2rs-bnp-dm-01.
The draft-bogdanovic-netmod-acl-model-02 takes the approach of
extending the firewall ACLs, and suggests that proprietary methods be
used to extend this to the ranges needed for BGP policy. The index
to the ACLS is the rule-name. For a single prefix accept/deny the
generic ACL policy may be sufficient. Prefix ranges or the ability
to set custom cost communities or other extended communities must use
a proprietary vendor's model.
The [I-D.zhdankin-netmod-bgp-cfg] (10/1/2014) suggests prefix-list
matches that should provide prefix matches an index of route ID
number (uint16). The prefix matches can be either ip-address,
prefix, host address, or prefix-range. The only actions taken are
Hares Expires April 30, 2015 [Page 22]
Internet-Draft IM for policy October 2014
accept or deny the prefix. The usage statistics contains only the
"hit count" for the usage of the prefix mask.
The [I-D.wang-i2rs-bgp-dm] (10/23/2014) provides a policy link to the
Basic Network Policy (draft-hares-i2rs-bnp-info-model/draft-hares-
i2rs-bnp-dm-01) which provides ordered list of policy rules that can
provide sequences of match, actions (accept/deny, set variable, and
modify). A group of these policy rules is called a policy group
which can be named.
This model uses the policy definitions concept is also found in the
Policy Core Information Model (PCIM) (RFC3060) and the Quality of
Service QoS) Policy Information Model (QPIM)(RFC3644) and policy
based routing. ACL-based policy (draft-bogdanovic-netmod-acl-model-
02), and prefix-list policy (accept/deny) can be one of the policy
rule extensions. The [I-D.zhdankin-netmod-bgp-cfg] can provide a
second policy rule extension.
The section below provides the specific modeling parameters for each
draft.
draft-bogdanovic-netmod-acl-model-02
+--rw access-list-entry* [rule-name]
+--rw rule-name string
+--rw matches
| +--rw (ace-type)?
| | +--:(ace-ip)
| | | +--rw source-port-range
| | | | +--rw lower-port inet:port-number
| | | | +--rw upper-port? inet:port-number
| | +--rw destination-port-range
| | | | +--rw lower-port inet:port-number
| | | | +--rw upper-port? inet:port-number
| | | +--rw dscp? inet:dscp
| | | +--rw ip-protocol? uint8
| | | +--rw (ace-ip-version)?
| | | +--:(ace-ipv4)
| | | | +--rw destination-ipv4-address?
inet:ipv4-prefix
| | | | +--rw source-ipv4-address?
inet:ipv4-prefix
| | | +--:(ace-ipv6)
| | | +--rw destination-ipv6-address?
inet:ipv6-prefix
| | | +--rw source-ipv6-address?
inet:ipv6-prefix
| | | +--rw flow-label? inet:ipv6-flow-label
Hares Expires April 30, 2015 [Page 23]
Internet-Draft IM for policy October 2014
| | +--:(ace-eth)
| | +--rw destination-mac-address?
yang:mac-address
| | +--rw destination-mac-address-mask?
yang:mac-address
| | +--rw source-mac-address?
yang:mac-address
| | +--rw source-mac-address-mask?
yang:mac-address
| +--rw input-interface? string
| +--rw absolute
| +--rw start? yang:date-and-time
| +--rw end? yang:date-and-time
| +--rw active? boolean
| +--rw actions
| +--rw (packet-handling)?
| +--:(deny)
| | +--rw deny? empty
| +--:(permit)
| +--rw permit? empty
+--ro ace-oper-data
+--ro match-counter? ietf:counter64
Figure bgp-17
[I-D.zhdankin-netmod-bgp-cfg] (10/1/2014)
+--rw prefix-lists
+--rw prefix-list [prefix-list-name]
+--rw prefix-list-name string
+--rw prefixes
+--rw prefix [seq-nr]
+--rw seq-nr uint16
+--rw prefix-filter
+--rw (ip-address-group)?
| (cases
+--rw action actions-enum
+--rw statistics
..
Figure bgp-18
[I-D.wang-i2rs-bgp-dm]
Hares Expires April 30, 2015 [Page 24]
Internet-Draft IM for policy October 2014
module: bgp_protocol
+--rw bgp-protocol
+ af config
+--rw bgp-policy-in policy-group-ref
+--rw bgp-policy-out policy-group-ref
Figure bgp-19
draft-bnp-i2rs-bnp-dm-00
(To be Completed after bnp drafts)
Figure bgp-20
5.13. BGP-REQ 13
BGP-REQ13 requirement is: the "I2RS client SHOULD be able to instruct
the I2RS Agent to write BGP Policies into the running BGP protocols
and into the BGP configurations."
Discussion: BGP-REQ 13 indicates that the policy changes supported by
BGP-REQ 12 must be able to operate in the running configuration. The
I2RS and netmod groups are discussing the definition of ephemeral.
Two definitions are being discussed - patch and pull-up configuration
as described below:
running = config + ephemeral patches [patch]
running = config (copy) + ephemeral additions (pull-up)
Either definition implies that the I2RS changes can alter the policy
based on the bgp configuration and I2rs model.
The writing of changes from I2RS to the configuration was
specifically ignored. Writing of specific configuration options from
the ephemeral store to the running configuration can initially be
done by the I2RS client writing via the configuration interface to
the datastore.
Data models needed: The Policy data models for filter or filter and
action are the same as in BGP-REQ13.
5.14. BGP-REQ 14
BGP-REQ14 requirement is: the "I2RS client-agent SHOULD be able to
read BGP statistics associated with Peer, and to receive
notifications when certain statistics have exceeded limits. An
example of one of these protocol statistics is the max-prefix limit."
Hares Expires April 30, 2015 [Page 25]
Internet-Draft IM for policy October 2014
Discussion: BGP-REQ01 examines the peer connectivity state. BGP-
REQ14 examines BGP peer statistics. [I-D.zhdankin-netmod-bgp-cfg]
provides statistics on the number of updates received or sent, but it
does not have statistics on the max-prefix exceeded. It does provide
a limit for maximum-prefix per peer.
[I-D.wang-i2rs-bgp-dm] has statistics on the number of updates
received or sent, number of routes received or sent plus maximum
prefix high-water and low-water. This draft also has the limits
copied into the status fields for easy reading.
[I-D.zhdankin-netmod-bgp-cfg] (10/1/2014)
module: bgp
+ ....
+--rw bgp-neighbors
| +--rw bgp-neighbor [as-number]
| +--rw as-number uint32
| +--rw (peer-address-type)?
| | .....
| +--rw prefix-list? prefix-list-ref
| +--rw default-action? actions-enum
| +--rw af-specific-config
| +--ro bgp-neighbor-state
| | +--ro bgp-peer-admin-status;
| +--ro bgp-neighbor-statistics
| | +--ro nr-in-updates
| | +--rw nr-out-updates
[I-D.wang-i2rs-bgp-dm]
Hares Expires April 30, 2015 [Page 26]
Internet-Draft IM for policy October 2014
| +--rw bgp-peer-list* [bgp-peer-name]
| +--rw peer-session-address
| | +--rw local-ipv4-address? inet:ipv4-prefix
| | +--rw remote-ipv4-address? inet:ipv4-prefix
| +--rw bgp-peer-name string
| +--ro bgp-peer-type? enumeration
| +--ro bgp-peer-create? enumeration
| +--rw bgp-policy-in policy-group-ref
| +--rw bgp-policy-out policy-group-ref
| +--rw peer-state-info
| | +--ro peer-current-state? peer-stat
| | +--ro peer-last-state? peer-state
| | +--ro peer-down-reason
| | | +--ro error-code? enumeration
| | | +--ro sub-error-code
| | | | ...
| | +--ro peer-transmit-update-cnt? uint64
| | +--ro peer-recived-update-cnt uint64
| | +--ro peer-received-route-cnt? uint64
| | +--ro peer-send-route-cnt? uint64
| | +--rw max-prefix-rcv-limit? uint64
| | +--rw max-prefix-xmt-limit? uint64
| | +--ro peer-prefix-high? uint64
| | +--ro peer-prefix-low? uint64
Conclusion: Full support of BGP-REQ 14 requires the
[I-D.wang-i2rs-bgp-dm] draft.
5.15. BGP-REQ 15
BGP-REQ15 requirement is: the "I2RS client via the I2RS agent MUST
have the ability to read the loc-RIB-In BGP table that gets all the
routes that the CE has provided to a PE router."
Discussion: The [I-D.zhdankin-netmod-bgp-cfg] provides no indication
of a local-rib or a local-RIB-in associated with a BGP peer. The
[I-D.wang-i2rs-bgp-dm] provides a local-rib per AFI, and a local-RIB-
IN (AdjRIBIn and AdjRIBOut) associated with each peer. The route
table format is presented in figure bgp-9.
Conclusion: [I-D.wang-i2rs-bgp-dm] is necessary for this requirement.
5.16. BGP-REQ 16
BGP-REQ16 requirement is: the "I2RS client via the I2RS agent MUST
have the ability to install destination based routes in the local RIB
of the PE devices. This must include the ability to supply the
destination prefix (NLRI), a table identifier, a route preference, a
Hares Expires April 30, 2015 [Page 27]
Internet-Draft IM for policy October 2014
route metric, a next-hop tunnel through which traffic would be
carried."
Discussion: If this refers to the I2RS LOC-RIB, then both drafts have
policy which could redistribute I2RS routes.
If BGP-REQ 16 refers to a BGP local-rib per AFI and the bgp-peer
based bgp-rib-in (AdjRibIn) and bgp-rib-out (AdjRibOut). As this
previous discussion indicates, the [I-D.zhdankin-netmod-bgp-cfg] does
not have a local rib-in.
The document [I-D.wang-i2rs-bgp-dm] describes a per AFI bgp local-rib
and the per peer bgp-rib-in (AdjRIBIn) and bgp-rib-out (AdjRibOut).
The routes in these RIBs fall under a table identifier structure and
have a destination prefix (NLRI), route administrative preference,
route local-reference, and a next-hop. However,
[I-D.wang-i2rs-bgp-dm] does not have a tunnel based definition for
the next-hop. This would need to be added.
Conclusion: Additions to [I-D.wang-i2rs-bgp-dm] may need to be made
to fulfill this requirement.
5.17. BGP-REQ 17
BGP-REQ17 requirement is: the "I2RS client via the I2RS agent SHOULD
have the ability to read the loc-RIB-in BGP table to discover
overlapping routes, and determine which may be safely marked for
removal."
Discussion: As discussed in BGP-REQ15 and BGP-REQ16, draft
[I-D.zhdankin-netmod-bgp-cfg] does not have a local-RIB-In BGP table.
[I-D.wang-i2rs-bgp-dm] has a BGP local-rib per AFI and a per BGP Peer
bgp-rib-in. As described in BGP REQ10, this each route may set a
"remove overlapping route" status flag.
Conclusion: [I-D.wang-i2rs-bgp-dm] supports BGP-REQ 17.
5.18. BGP-REQ 18
BGP-REQ18 requirement is the "I2RS client via the I2RS Agent SHOULD
have the ability to modify filtering rules and initiate a re-
computation of the local BGP table through those policies to cause
specific routes to be marked for removal at the outbound eBGP edge."
Discussion: This feature requires that I2RS should be able to do a
re-computation of policies. This re-computation of policies is part
of a soft-reconfig which [I-D.zhdankin-netmod-bgp-cfg] allows by
Hares Expires April 30, 2015 [Page 28]
Internet-Draft IM for policy October 2014
configuration. However, the I2RS client will need a parameter to be
set to do a reconfigure.
Neither [I-D.zhdankin-netmod-bgp-cfg] or [I-D.wang-i2rs-bgp-dm] have
this feature.
Conclusion: This feature needs to be added to final model
6. IANA Considerations
This draft includes no request to IANA.
7. Security Considerations
TBD
8. Informative References
[I-D.bogdanovic-netmod-acl-model]
Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair,
"Network Access Control List (ACL) YANG Data Model",
draft-bogdanovic-netmod-acl-model-02 (work in progress),
October 2014.
[I-D.hares-i2rs-bgp-dm]
Wang, L., Hares, S., and S. Zhuang, "An I2RS BGP Data
Modell", draft-hares-i2rs-bgp-dm-00 (work in progress),
October 2014.
[I-D.hares-i2rs-info-model-service-topo]
Hares, S., Wu, W., and X. Guan, "An Information model for
service topology", draft-hares-i2rs-info-model-service-
topo-01 (work in progress), July 2014.
[I-D.hares-i2rs-usecase-reqs-summary]
Hares, S., "Summary of I2RS Use Case Requirements", draft-
hares-i2rs-usecase-reqs-summary-00 (work in progress),
July 2014.
[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-05 (work in
progress), July 2014.
Hares Expires April 30, 2015 [Page 29]
Internet-Draft IM for policy October 2014
[I-D.ietf-i2rs-rib-info-model]
Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
Information Base Info Model", draft-ietf-i2rs-rib-info-
model-03 (work in progress), May 2014.
[I-D.wang-i2rs-bgp-dm]
Wang, L., Hares, S., and S. Zhuang, "An I2RS BGP Data
Modell", draft-wang-i2rs-bgp-dm-00 (work in progress),
October 2014.
[I-D.zhdankin-netmod-bgp-cfg]
Alex, A., Patel, K., and A. Clemm, "Yang Data Model for
BGP Protocol", draft-zhdankin-netmod-bgp-cfg-01 (work in
progress), October 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
"Policy Core Information Model -- Version 1
Specification", RFC 3060, February 2001.
[RFC3460] Moore, B., "Policy Core Information Model (PCIM)
Extensions", RFC 3460, January 2003.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
Moore, "Policy Quality of Service (QoS) Information
Model", RFC 3644, November 2003.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
Author's Address
Susan Hares
Huawei
7453 Hickory Hill
Saline, MI 48176
USA
Email: shares@ndzh.com
Hares Expires April 30, 2015 [Page 30]
