+YANG Routing Design Team
On 6/7/17, 2:25 AM, "Ladislav Lhotka" <[email protected]> wrote:
>Hi Alex,
>
>in earlier revisions of the ietf-routing module (up to
>draft-ietf-netmod-routing-cfg-17), we had a configuration item
>("recipient-ribs") that allowed for assigning RIBs to routing protocol
>instances. The reason for removing it is summarized in my presentation
>from IETF 92, slides 10 and 11:
>
>https://www.ietf.org/proceedings/92/slides/slides-92-netmod-9.pdf
>
>(and yes, I wasn't a big fan of this change).
>
>Maybe Acee can give additional background.
The RIBs which the control plane protocols populated are normally dictated
by the address family. In the case of multiple topologies, a specific RIB
(as identified by name) will need to be explicitly associated with the
topology in the control plane protocol as opposed to being connected to
the control plane protocol at a higher level.
Thanks,
Acee
>
>Lada
>
>> On 7 Jun 2017, at 01:43, Alex Campbell <[email protected]>
>>wrote:
>>
>> Hi,
>>
>> I noticed that the ietf-routing YANG (published in RFC 8022) allows for
>>multiple instances of each control plane protocol, as well as multiple
>>RIBs per address family.
>> However I don't see any way to associate one with the other. Without
>>additional configuration, protocols will only place their routes in
>>default RIBs.
>> Is it intended that this will be left to vendor-specific modules and/or
>>future standards?
>>
>> Alex
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
