One document matched: draft-hares-i2rs-bgp-compare-yang-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3060.xml">
<!ENTITY RFC3460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3460.xml">
<!ENTITY RFC3644 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3644.xml">
<!ENTITY RFC5511 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5511.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.atlas-i2rs-policy-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-i2rs-policy-framework.xml">
<!ENTITY I-D.hares-i2rs-usecase-reqs-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-usecase-reqs-summary.xml">
<!ENTITY I-D.white-i2rs-use-case SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.white-i2rs-use-case.xml">
<!ENTITY I-D.hares-i2rs-bgp-im SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-bgp-im.xml">
<!ENTITY I-D.hares-i2rs-info-model-service-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-service-topo.xml">
<!ENTITY I-D.bogdanovic-netmod-acl-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bogdanovic-netmod-acl-model.xml">
<!ENTITY I-D.zhdankin-netmod-bgp-cfg SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.zhdankin-netmod-bgp-cfg.xml">
<!ENTITY I-D.hares-i2rs-pbr-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-pbr-im.xml">
<!ENTITY I-D.hares-i2rs-bgp-dm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-hares-i2rs-bgp-dm-00.xml">
<!ENTITY I-D.wang-i2rs-bgp-dm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wang-i2rs-bgp-dm.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-i2rs-bgp-compare-yang-01" ipr="trust200902">
<front>
<title abbrev="IM for policy">Comparison of I2RS and Config BGP Yang Modules </title>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<date year="2014" />
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t>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).
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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 information, or
perform actions on the I2rs collected information based on specific
I2rs policies.</t>
<t>
This draft is a comparison of the following two BGP yang models:
<xref target="I-D.zhdankin-netmod-bgp-cfg"></xref>, and
<xref target="I-D.wang-i2rs-bgp-dm"></xref>. 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 <xref target="I-D.hares-i2rs-usecase-reqs-summary"></xref>.
</t>
<t>
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 <xref target="I-D.wang-i2rs-bgp-dm"></xref>
is necessary to fulfil the BGP use cases found in
the <xref target="I-D.hares-i2rs-usecase-reqs-summary"></xref>. Configuration knobs
in <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> 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).
</t>
<t>
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.
</t>
<t>
The rest of this draft is the details so those who desire "sounds bytes" level reading may
stop reading now.
</t>
</section>
<section title="Definitions and Acronyms">
<t><list>
<t>BGP - Border Gateway Protocol version 4 </t>
<t>CLI: Command Line Interface</t>
<t>IGP: Interior Gateway Protocol</t>
<t> I2RS: Interface to (2) Routing system. </t>
<t>Information Model: An abstract model of a conceptual domain,
independent of a specific implementations or data representation</t>
<t>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. </t>
<t>NETCONF: The Network Configuration Protocol</t>
</list></t>
</section>
<section title="BGP Yang Draft Comparison">
<t>The authors of <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref>
focused on the configuration aspect of BGP
(98%+ configuration, 2% status).
The <xref target="I-D.wang-i2rs-bgp-dm"></xref> 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.
</t>
<t> Why is draft-wang-bgp-dm-00 mostly focused on routes, statistics, and state? </t>
<t> The use cases specified in <xref target="I-D.hares-i2rs-usecase-reqs-summary"></xref>
demonstrate a need for the status found in <xref target="I-D.wang-i2rs-bgp-dm"></xref>
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).
</t>
<t> Two versions of <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> 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 <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref>,
</t>
<t> The <xref target="I-D.wang-i2rs-bgp-dm"></xref> was released mistakenly as
<xref target="I-D.hares-i2rs-bgp-dm"></xref>. A few corrections to the status fields were included
in the <xref target="I-D.wang-i2rs-bgp-dm"></xref>. This draft uses
<xref target="I-D.wang-i2rs-bgp-dm"></xref> for the comparison.
</t>
</section>
<section title="Differences between the drafts">
<t>
The <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> 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).
</t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
<t>
The <xref target="I-D.wang-i2rs-bgp-dm"></xref> 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.
</t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
<list style="symbols">
<t>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.
</t>
<t>prefix list policy being covered inline (<xref target="I-D.zhdankin-netmod-bgp-cfg"></xref>) 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.
</t>
<t>Redistribution being done inline (<xref target="I-D.zhdankin-netmod-bgp-cfg"></xref>) as a configuration. The draft-i2rs-wang-bgp-dm-00
did not configure af-configuration.
</t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> 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 <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref>.
</t>
<t>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.
</t>
</list>
Below is an example of the AF-status structure found in draft-bgp-dm-00
</t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
<section title="Overlap of configuration draft-zhdankin-netmod-bgp-01">
<t>The draft-zhdankin-netmod-bgp-01 and draft-wang-i2rs-bgp-dm-00 both contain at the protocol level: </t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
<t>The module contains at the peer level the association of a peer with an AS</t>
<t>[draft-zhdank-netmod-bgp-01] </t>
<t>
<figure>
<artwork>
+--rw bgp-neighbors* [AS-number]
+--rw as-number
+--rw (peer-address-type)?
. . .
+--rw prefix-list prefix-list-ref
+--default-action? enumeration (permit/deny)
</artwork>
</figure>
</t>
<t>[<xref target="I-D.wang-i2rs-bgp-dm"></xref>] </t>
<t>
<figure>
<artwork>
+--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
</artwork>
</figure>
</t>
</section>
<section title="Unique configuration for draft-zhdankin-netmod-bgp-01">
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> contains the unique configuration for RPKI, AF-configuration and BGP peers. A sample of the unique configuration for the AF-configuration is:
<list style="symbols">
<t>cost-communities</t>
<t>BGP-damping </t>
<t>route-aggregation - this is policy so we could easily add, </t>
<t>reflector clients</t>
<t>best external advertisement </t>
<t>aggregate timer (sending out aggregate times) </t>
<t>flags to compare router-id as part of bgp bestpath selection</t>
<t>MED-confederation </t>
<t>administrative distance (cisco) </t>
<t>packet forwarding over multiple paths</t>
<t>allowances for slow peers</t>
<t>BGP multi-path (ECMP peers)</t>
<t>external fail-over for peer </t>
<t>AS confederations </t>
<t>deterministic MEDs </t>
<t>Graceful-restart </t>
<t>BGP AS listener only </t>
<t>Logging of neighbor changes </t>
<t>Transport options for BGP </t>
<t>Removal of private AS </t>
</list>
</t>
</section>
<section title="Unique configuration for draft-wang-bgp-dm-00">
<t>The following variables were included in <xref target="I-D.hares-i2rs-bgp-dm"></xref>, but not in <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref>:
<list style="symbols">
<t>protocol-status (ro) - needed for I2RS information </t>
<t>shutdown protocol - needed if I2RS is to shutdown bgp protocol,</t>
<t>AFI based local-rib </t>
<t>BGP-peer-status information - <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> has number of updates, but less status information in the draft. </t>
</list>
The following pieces are needed by I2RS:
<list style="symbols">
<t>At instance level, bgp-instance-name, bgp-instance-create (to create bgp process), bgp-instance-type (to specify what type to create),</t>
<t>At AFI level in local rib, bgp_route_create (to add bgp route for i2rs) and bgp_state_info for status updates. </t>
<t>At peer level, there must be maximum prefixes per peer (received and transmit), high water/low water prefix counts, and average number of prefixes;</t>
<t>Versions for instance publishing,</t>
<t>Details on path attributes: ASpath strings, community and extend-community attribute, cluster lists, aggregation, atomic aggregator;</t>
<t>Mechanisms for logging/publishing information</t>
</list>
</t>
</section>
</section>
<section title="Comparison of State needed versus BGP requirements">
<section title="BGP-REQ 01 ">
<t>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</t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> contains the following status related to each peer's bgp operational state. </t>
<t>module: bgp </t>
<t>
<figure>
<artwork>
+--bgp-router
+ . . .
+--rw bgp-neighbors
+--rw peer-address
| . . .
+--rw bgp-neighbor-state
+--rw bgp-peer-admin-status enumeration
+--rw in-lastupdatetime
Figure bgp-6
</artwork>
</figure>
</t>
<t>Conclusion: <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> does not provide support required by I2RS. </t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref> contains the following status related to each peer's BGP operational state:</t>
<t>module: bgp </t>
<t>
<figure>
<artwork>
+--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
</artwork>
</figure>
</t>
<t>Conclusion: <xref target="I-D.wang-i2rs-bgp-dm"></xref> provides for this requirement. </t>
</section>
<section title="BGP-REQ 02">
<t>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."</t>
<t>Status: </t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> 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: </t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
<t>Conclusion: This <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> does not adequately support the I2RS BGP REQ02. . </t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref> does support per-route configuration tagging of route with customer community in local BGP rib, and per peer AdjRibIn and adjRibout
</t>
<t>
<figure>
<artwork>
+--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*
| | | | | | . . .
| | | | | | +--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
</artwork>
</figure>
</t>
<t>Conclusion: <xref target="I-D.wang-i2rs-bgp-dm"></xref> needed as well as <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref>. </t>
</section>
<section title="BGP-REQ 03">
<t>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."</t>
<t>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. </t>
<t>Status: </t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> has the following potential configuration support:
<list style="symbols">
<t>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.
</t>
<t>af rtfilters - AFI for rtfilters.
</t>
</list>
</t>
<t>These features do not provide any of the traffic engineering input. </t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref>: 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.
</t>
<t>
<figure>
<artwork>
+--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
</artwork>
</figure>
</t>
<t>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 <xref target="I-D.wang-i2rs-bgp-dm"></xref> can be augmented. </t>
<t>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. </t>
</section>
<section title="BGP-REQ 04">
<t>BGP-REQ04 requirement is: "I2RS Agents SHOULD support identification of routers as BGP ASBRs, PE routers, and IBGP routers."</t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref>: No status provides a summation of the BGP roles a BGP routing instance. The BGP-neighbor structure does not provide a role structure. </t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref>: </t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
<t>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.
</t>
<t>The enumeration for bgp-peer-type is asbr, ibgp, rr, rr-client, pe, ce, bgp-vendor-types;
</t>
<t>Conclusion: <xref target="I-D.wang-i2rs-bgp-dm"></xref> supports BGP-REQ 04 </t>
</section>
<section title="BGP-REQ 05">
<t>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.</t>
<t>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. </t>
<t>BGP-REQ 4 showed that the <xref target="I-D.wang-i2rs-bgp-dm"></xref> 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. <xref target="I-D.wang-i2rs-bgp-dm"></xref> 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. </t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref></t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
<t>Conclusion: <xref target="I-D.wang-i2rs-bgp-dm"></xref> supports BGP-REQ-05. </t>
</section>
<section title="BGP-REQ 06">
<t>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."</t>
<t>Status: As section 3.5.5 on BGP-REQ04 shows <xref target="I-D.wang-i2rs-bgp-dm"></xref> supports the tracking of flow-specification routes associated with the local-rib for a AFI or a BGP Peer.
</t>
<t> <xref target="I-D.wang-i2rs-bgp-dm"></xref>: </t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
</section>
<section title="BGP-REQ 07">
<t>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.</t>
<t>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. </t>
<t>Status:</t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> 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. </t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref> 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. </t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
</section>
<section title="BGP-REQ 08">
<t>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." </t>
<t>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). </t>
<t>Status:</t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> 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). </t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref> 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). </t>
</section>
<section title="BGP-REQ 09">
<t>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. </t>
<t>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. </t>
<t>Status:</t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> configures the parameters that influence BGP bestpath decisions. However, this draft does not provide these parameters within each bgp-route. </t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref> 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). </t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
</section>
<section title="BGP-REQ 10">
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> configures the parameters that influence BGP bestpath decisions or flap damping. However, this draft does not provide these parameters within each bgp-route.
</t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref>:
</t>
<t>
<figure>
<artwork>
+--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
</artwork>
</figure>
</t>
<t>Conclusion: <xref target="I-D.wang-i2rs-bgp-dm"></xref> status is needed for this BGP-REQ10.
</t>
</section>
<section title="BGP-REQ 11">
<t>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)."
</t>
<t>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
</t>
<t>Status:
</t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> configures policy that indicates what routes are filtered, but it does not provide the status parameter on each BGP route.
</t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref>: Shows that the status can be tracked in the AFI based bgp local-rib and the per AFI per peer AdjRibIn and AdjRib out.
</t>
<t>Conclusion: <xref target="I-D.wang-i2rs-bgp-dm"></xref> status is needed for BGP-REQ10.
</t>
</section>
<section title="BGP-REQ 12">
<t>BGP-REQ12 requirement is: the "I2RS client SHOULD be able to request the I2RS agent to read installed BGP Policies."
</t>
<t>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, <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref>, and draft-hares-2rs-bnp-dm-01.
</t>
<t>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.
</t>
<t>The <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> (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 accept or deny the prefix. The usage statistics contains only the "hit count" for the usage of the prefix mask.
</t>
<t>The <xref target="I-D.wang-i2rs-bgp-dm"></xref> (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.
</t>
<t>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 <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> can provide a second policy rule extension.
</t>
<t>The section below provides the specific modeling parameters for each draft.
</t>
<t>draft-bogdanovic-netmod-acl-model-02
</t>
<t>
<figure>
<artwork>
+--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
| | +--:(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
</artwork>
</figure>
</t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> (10/1/2014)
</t>
<t>
<figure>
<artwork>
+--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
</artwork>
</figure>
</t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref>
</t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
<t>draft-bnp-i2rs-bnp-dm-00
</t>
<t>(To be Completed after bnp drafts)
</t>
<t>Figure bgp-20
</t>
</section>
<section title="BGP-REQ 13">
<t>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."
</t>
<t>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:
</t>
<t> running = config + ephemeral patches [patch]
</t>
<t> running = config (copy) + ephemeral additions (pull-up)
</t>
<t>Either definition implies that the I2RS changes can alter the policy based on the bgp configuration and I2rs model.
</t>
<t>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.
</t>
<t>Data models needed: The Policy data models for filter or filter and action are the same as in BGP-REQ13.
</t>
</section>
<section title="BGP-REQ 14">
<t>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."
</t>
<t>Discussion: BGP-REQ01 examines the peer connectivity state. BGP-REQ14 examines BGP peer statistics. <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> 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.
</t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref> 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.
</t>
<t><xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> (10/1/2014)
</t>
<t>
<figure>
<artwork>
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
</artwork>
</figure>
</t>
<t><xref target="I-D.wang-i2rs-bgp-dm"></xref>
</t>
<t>
<figure>
<artwork>
| +--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
</artwork>
</figure>
</t>
<t>Conclusion: Full support of BGP-REQ 14 requires the <xref target="I-D.wang-i2rs-bgp-dm"></xref> draft.
</t>
</section>
<section title="BGP-REQ 15">
<t>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."
</t>
<t>Discussion: The <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> provides no indication of a local-rib or a local-RIB-in associated with a BGP peer. The <xref target="I-D.wang-i2rs-bgp-dm"></xref> 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.
</t>
<t>Conclusion: <xref target="I-D.wang-i2rs-bgp-dm"></xref> is necessary for this requirement.
</t>
</section>
<section title="BGP-REQ 16">
<t>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 route metric, a next-hop tunnel through which traffic would be carried."
</t>
<t>Discussion: If this refers to the I2RS LOC-RIB, then both drafts have policy which could redistribute I2RS routes.
</t>
<t>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 <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> does not have a local rib-in.
</t>
<t>The document <xref target="I-D.wang-i2rs-bgp-dm"></xref> 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, <xref target="I-D.wang-i2rs-bgp-dm"></xref> does not have a tunnel based definition for the next-hop. This would need to be added.
</t>
<t>Conclusion: Additions to <xref target="I-D.wang-i2rs-bgp-dm"></xref> may need to be made to fulfill this requirement.
</t>
</section>
<section title="BGP-REQ 17">
<t>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."
</t>
<t>Discussion: As discussed in BGP-REQ15 and BGP-REQ16, draft <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> does not have a local-RIB-In BGP table. <xref target="I-D.wang-i2rs-bgp-dm"></xref> 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.
</t>
<t>Conclusion: <xref target="I-D.wang-i2rs-bgp-dm"></xref> supports BGP-REQ 17.
</t>
</section>
<section title="BGP-REQ 18">
<t>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."
</t>
<t>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 <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> allows by configuration. However, the I2RS client will need a parameter to be set to do a reconfigure.
</t>
<t>Neither <xref target="I-D.zhdankin-netmod-bgp-cfg"></xref> or <xref target="I-D.wang-i2rs-bgp-dm"></xref> have this feature.
</t>
<t>Conclusion: This feature needs to be added to final model
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft includes no request to IANA.</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Informative References">
&RFC2119;
&RFC3060;
&RFC3460;
&RFC3644;
&RFC5511;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-info-model;
&I-D.hares-i2rs-usecase-reqs-summary;
&I-D.hares-i2rs-bgp-dm;
&I-D.wang-i2rs-bgp-dm;
&I-D.hares-i2rs-info-model-service-topo;
&I-D.bogdanovic-netmod-acl-model;
&I-D.zhdankin-netmod-bgp-cfg;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:22:39 |