Subject: Re: [Rtg-yang-coord] rtg-cfg hierachy (PLEASE REPLY TO THIS ONE WITH THE CORRECT MAIL ALIASES)

From: Thomas Morin <[email-masked]>
Date: Wed, 18 Feb 2015 12:36:08 +0100

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" <[email-masked]> wrote:
>
>> Hi,
>>
>> "Acee Lindem (acee)" <[email-masked]> 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
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 18 Feb 2015 20:55:21 +0000

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?

This would imply that RIBs are within a routing-instance and that
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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Feb 2015 13:45:25 +0100

Hi Thomas,

I apologize for a late response, I was on holiday last week.

> "global" in revision -03 that followed my review.

Right, but each filter could then be specified for either
"connected-routing-table" or "recipient-routing-table", and if the
'remote' routing table is in a different routing instance, it IMO makes
more sense to have routing tables (RIBs) as global objects
accessible to all routing instances.

In fact, even if RIBs are routing-instance specific, it will still be
possible to access a RIB in a foreign routing instance, it will just be
more laborious - one will have to specify the target routing instance &
RIB. Also, names of RIBs will no more be unique system-wide.

> -05, a few months after my initial comments were address.

Yes, you are right, it seems the immediate motivation for this change
was this review by Martin Bjorklund:

http://www.ietf.org/mail-archive/web/netmod/current/msg06962.html

Thanks, Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Feb 2015 20:31:40 +0100 (CET)

> http://www.ietf.org/mail-archive/web/netmod/current/msg06962.html

I don't really understand what exactly in this review led to that
change?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Feb 2015 20:51:44 +0100

> On 23 Feb 2015, at 20:31, Martin Bjorklund <[email-masked]> wrote:
> 

Last bullet about sec. 5.2:

o  5.2

               list recipient-routing-table {
                 ...
                 leaf name {
                   type leafref {
                     path "/routing/router/routing-tables/"
                        + "routing-table/name";
                   }

  This should also be a relative path.

A relative path would make sense only if the leafref points within the same router (later renamed to routing-instance). Consequently, it would be impossible to pass routes between tables in different routers.

On the other hand, the global path as shown above could lead to ambiguous references, because different routers could have routing-tables with identical names.

I therefore decided to keep the global path but make sure the names of routing tables are globally unique. Having a single list of routing-tables was the most straightforward way to achieve this.

Lada