Re: [Rtg-yang-coord] rtg-cfg hierachy (Indentation in hierarchy corrected)

[Ladislav Lhotka <[e-mail]>]

"Acee Lindem (acee)" <[e-mail]> writes:

> Thanks Thomas for the clarification.
>
> I’d like to then suggest we change the rtg-cfg model hierarchy to reflect
> what most routing device implementations.
> There is a RIB (you can call it a default-RIB if you like) for every
> Address Family (AF). Multiple RIBs per AF is not widely implemented and I
> don’t see it becoming more prevalent. Hence, I agree it should be a
> feature. The one implementation I’m familiar with is multiple topology
> routing (e.g., RFC 4915), where RIB corresponds to a FIB that is selected
> based on packet marking. Does anyone have any other examples?

Another example could be a separate RIB for RPF, to be used e.g. by PIM.

>
> This would imply that RIBs are within a routing-instance and that

It seems (Junos experts, please confirm) that in Junos user-defined
routing tables can be specified both globally and per routing-instance:

http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/export-rib-edit-routing-options.html

>From the viewpoint of the data model, I think it is generally easier for
an implementation to restrict access to each RIB to a single routing
instance than allow different routing instances to share a RIB, if each
RIB would have to be inside a routing instance.


Lada

> routing-protocols within the routing-instance can operate on these RIBs.
> There is no requirement connect RIBs to routing-protocols or to form
> connections between RIBs.
>
> This would give us a high-level hierarchy of:
>
> rw routing-instance* [name]
>       |  +--rw address-family
>       |  |  |--rw default-rib* [address-family]
>       |  |  +--rw non-default-ribs (feature)
>       |  +--rw routing-protocols
>       |     +―--rw routing-protocol* [type name]
>
> I intensionally left out the interfaces since I don’t like some models
> augmenting or referencing the ietf-interface list and others augmenting or
> referencing the list in our rtg-cfg draft.
>
> Thanks,
> Acee
>
>
>
>
> On 2/18/15, 6:36 AM, "Thomas Morin" <[e-mail]> wrote:
>
>>Hi Acee, Lada,
>>
>>It seems that my comment that you quote was more related to filters than
>>to routing tables, and indeed, *filters* were moved from "router" to
>>"global" in revision -03 that followed my review.
>>
>>Additionally, Lada, you say that based on my comments "in rev. -03 the
>>list of RIBs (then called "routing-table") was the moved out of the
>>routing instance (then called "router") and became global.". But if I
>>look at -03, "routing-table" is still a child of "router".  The change
>>to make "routing-table" global was made in -05.
>>
>>I guess you need to find out what was the motivation for the change in
>>-05, a few months after my initial comments were address.
>>
>>Best,
>>
>>-Thomas
>>
>>
>>
>>
>>
>>2015-02-13, Acee Lindem (acee):
>>>
>>> Hi Lada, Thomas,
>>>
>>> On 2/13/15, 5:10 AM, "Ladislav Lhotka" <[e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> "Acee Lindem (acee)" <[e-mail]> writes:
>>>>
>>>>> Hi Thomas,
>>>>>
>>>>> It is my understanding that the RIBs were moved out of the
>>>>> routing-instance in response to your comment that a RIB would need to
>>>>>be
>>>>> attached to multiple routing instances. I don¹t agree with this
>>>>> model. I
>>>>
>>>> Acee refers to this comment that Thomas made in his review of
>>>> draft-ietf-netmod-routing-cfg-02 on 2012-03-23:
>>>>
>>>> "Allowing multiple "routers" is a good starting point for using these
>>>> specs in the context of RFC4364 (MPLS/BGP IP VPNs). However, if I
>>>> understand correctly Yang syntax, the way the filters are defined would
>>>> not work in the context of RFC4364, where a BGP routing instance in the
>>>> master "router" exports selected routes in each of the routing table of
>>>> each VPN (VRF).  The VRF also export routes to the master instance."
>>>>
>>>> And indeed, in rev. -03 the list of RIBs (then called "routing-table")
>>>> was the moved out of the routing instance (then called "router") and
>>>> became global.
>>>
>>> Then do you agree to move the RIBs back into the routing-instance? Both
>>> the BGP YANG drafts model L3VPN definitions under the corresponding
>>> address family in BGP.
>>>
>>> http://www.ietf.org/id/draft-shaikh-idr-bgp-model-00.txt
>>> http://www.ietf.org/id/draft-zhdankin-idr-bgp-cfg-00.txt
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>>>
>>>> Lada
>>>>
>>>>> believe that a routing instance implies a VRF, virtual router or
>>>>> something
>>>>> in between and that a RIB should be associated with one and only one
>>>>> routing instance. Additionally, I feel that RIBs are basically passive
>>>>> entities with respect to import/export of routes between RIBs in the
>>>>> same
>>>>> or other routing-instances. Rather, all import/export is under the
>>>>> control
>>>>> of a routing-protocol. For example, this would be handled by a BGP
>>>>> routing-protocol instance for L3VPNs.
>>>>>
>>>>> I¹d like to get the opinions of others on this fundamental aspect of
>>>>>the
>>>>> rtg-cfg model.
>>>>>
>>>>> Thanks,
>>>>> Acee
>>>>>
>>>>>
>>>>
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>
>
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C