[Idr] [e-mail]: questions

[Renato Westphal <[e-mail]>]

Hi all,

I'm currently working on a new BGP implementation [1] and would like to ask
a few questions about the BGP YANG model, in addition to providing some
feedback. I apologize if some of these questions were already asked before,
but I couldn't find anything in the mailing list archives.

1 - Shouldn't the "bgp-adj-rib-common-attr-refs" and
"bgp-loc-rib-common-attr-refs" groupings include a leaf referencing the
"ipv6-ext-communities" attribute set corresponding to the route? Those
groupings already have "community-index", "ext-community-index" and
"large-community-index", but nothing for IPv6 extended communities.

2 - I think there needs to be some clarification on the presence of the
"apply-policy" container on various parts of the model hierarchy. For
instance, if an "import-list" is configured for the ipv4-unicast address
family of a neighbor, and another "import-list" is configured at the
top-level for the same neighbor, should the address-family "import-list"
take precedence, or should they be combined?

Also, what is the purpose of the "apply-policy" container at the routing
instance level, not associated with any neighbor?

3 - The "route-selection-options" container has the following description:
"Configuration and state relating to route selection options".

My understanding is that this container should contain only configuration
options related to the best-path selection algorithm.

However, the following leaves under that container seem more related to
route propagation instead:
* "advertise-inactive-routes": "Advertise inactive routes to external
peers. The default is to only advertise active routes.".
* "enable-aigp": "Flag to enable sending / receiving accumulated IGP
attribute in routing updates".
* "enable-med": "Flag to enable sending/receiving of MED metric attribute
in routing updates".

Maybe I'm being too picky, but the three leaves above differ substantially
from the others in the same container.

4 - The following three leaves appear in the Loc-RIB, Adj-RIB-In and
Adj-RIB-Out: "eligible-route", "ineligible-reason" and "reject-reason".
Shouldn't these leaves be omitted from the Loc-RIB and Adj-RIB-Out lists,
as routes in those tables are presumably valid?

5 -
"/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/bgp:bgp/bgp:neighbors/bgp:neighbor/bgp:afi-safis/bgp:afi-safi/bgp:prefixes/bgp:installed"

The description of this leaf is the following: "The number of advertised
prefixes installed in the Loc-RIB". Wouldn't "received prefixes" be a more
useful counter?

6 -
"/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol/bgp:bgp/bgp:neighbors/bgp:neighbor/bgp:session-state"

Why can't this leaf be "config false" as one would expect? I don't
understand the comment about "notification does not like a non-config
statement".

7 -
"/rt-pol:routing-policy/rt-pol:policy-definitions/rt-pol:policy-definition/rt-pol:statements/rt-pol:statement/rt-pol:conditions/bp:bgp-conditions/bp:as-path-length"

The description of this container says the following: "[snip] The
as-path-length SHALL be calculated and SHALL follow RFC 4271 rules".

I assume by "RFC 4271 rules" the text refers to section 9.1.2.2, where it's
specified that an AS_SET counts as 1 (plus the changes from RFC 5065). To
prevent confusion, it might be good to update the container description to
be more precise.

8 - I think it would be nice if the BGP model augments
"/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" with BGP-specific route
attributes (e.g. AS_PATH), similar to what the OSPF model does.

9 - The term "NOTIFICATION PDU" appears several times in the BGP model,
where "NOTIFICATION message" would be more appropriate.

[1] https://github.com/holo-routing/holo

Best Regards,
-- 
Renato Westphal