Hi, I have concerns with adopting this document.
As others have mentioned on the list, the concepts of RIB and routing instance
seem to be inverted. But in addition to that, there seem to be two other issues
with the document in its current shape:
1. It's not clear the scope of what's within the Routing Information Base
information model. Specifically, elements defined seem to belong in the FIB and
not the RIB.
2. The document structure seems to have gaps and overlaps, and lacks a compiled
set of definitions of RIB elements.
Please find below some additional questions and observations on the document,
marked with "CMP".
I hope these are clear and useful.
Routing Information Base Info Model
draft-nitinb-i2rs-rib-info-model-01
1. Introduction
The rest of this document is organized as follows. Section 2.1 goes
into the details of what constitutes and can be programmed in a RIB.
Section 5 provides a high-level view of the events and notifications
going from a network device to an external entity, to update the
external entity on asynchronous events. The RIB grammar is specified
in Section 6. Examples of using the RIB grammar are shown in
Section 7.
CMP: What about other Sections? From 2.1 it jumps to Section 5
and not proactive push (from the router) mechanisms. Screen scraping
is error prone (since output can change) and vendor dependent.
CMP: A nit -- the output will change. I think "since the output format can
change" is what's meant.
2.1. RIB definition
A RIB is a logical construct controlled by an external entity. A RIB
contains one or more routing instances. On a network device, a RIB
is uniquely identified by its name. A routing instance can be in
only 1 RIB. A routing instance, in the context of the RIB
information model, is a collection of routing tables, interfaces, and
routing parameters. A routing instance creates a logical slice of
the router and allows different logical slices; across a set of
routers; to communicate with other each.
CMP: I think these set of definitions could use a visual to describe what's a
RIB, routing instance, routing tables and their high-level elements, in
addition to itemized definitions.
Layer 3 Virtual Private
Networks (VPN), Layer 2 VPNs (L2VPN) and Virtual Private Lan Service
(VPLS) can be modeled as routing instances.
CMP: It's not clear to me how an L2VPN or a VPLS can be modeled as routing
instances. Which L3 elements are there in an L2VPN?
Note that modeling a
Layer 2 VPN using a routing instance only models the Layer-3 (RIB)
aspect and does not model any layer-2 information (like ARP) that
might be associated with the L2VPN.
CMP: DOes this mean that ARP should be out of the RIB model?
2.2. Routing tables
A routing table is an entity that contains routes. A routing table
is identified by its name. The name MUST be unique within a RIB.
All routes in a given routing table MUST be of the same type (e.g.
IPv4). Each routing table MUST belong to some routing instance.
CMP: Should you also differentiate, in addition to the AF, by unicast versus
multicast?
Each route table can be optionally associated with a
ENABLE_IP_RPF_CHECK attribute that enables Reverse path forwarding
(RPF) checks on all IP routes in that table. Reverse path forwarding
CMP: Is RPF an attribute of the routing table?
2.3. Route
A route is essentially a match condition and an action following the
match. The match condition specifies the kind of route (IPv4, MPLS,
etc.) and the set of fields to match on. This document specifies the
following match types:
CMP: What is an "MPLS Route" in the context of a routing table?
o IPv4: Match on destination IP in IPv4 header
o IPv6: Match on destination IP in IPv6 header
o MPLS: Match on a MPLS tag
o MAC: Match on ethernet destination addresses
CMP: Is the MAC address a match element within routing? Or what types of
address families and identifiers are input to defining the elements included?
2.4.1. Nexthop types
o Special nexthops - for performing specific well-defined functions
CMP: Are things like the drop/null route fitting here? Are there many different
kinds of specials, or should they be listed explicitly?
6. RIB grammar
<table-family> ::= <IPV4_TABLE_FAMILY> | <IPV6_TABLE_FAMILY> |
<MPLS_TABLE_FAMILY> | <IEEE_MAC_TABLE_FAMILY>
CMP: Why these families?
CMP: Do you need to separate IPv4 in unicast versus multicast? Or are you
modeling a single table with attributes for the uni/multicast?
<ipv4-route> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
CMP: SHould that be "IPv4_ADDRESS" or "IPv4_PREFIX"?
Thanks,
-- Carlos.
On Jul 24, 2013, at 11:55 PM, Alia Atlas <[email protected]> wrote:
> Please review draft-nitinb-i2rs-rib-info-model-01 and comment on whether it
> should be adopted by I2RS. Detailed technical conversation is also most
> welcome.
>
> Authors: Are you aware of any IPR that applies to
> draft-nitinb-i2rs-rib-info-model-01 Is so, has this IPR been disclosed in
> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
> details).
>
> This WG call for adoption will complete on August 12.
>
> Thanks,
> Alia
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
