> On 13 Oct 2015, at 17:20, Acee Lindem (acee) <[email protected]> wrote: > > Hi Lada, NETMOD, > > So I think we should move forward this ietf-rtg-cfg so that it can be > augmented and other work can move forward. We are still in disagreement > with respect to routing-instance/interface configuration. > > - We feel the IPv4/IPv6 interfaces should reference the > routing-instance in their config state. This is consistent with > draft-rtgyangdt-rtgwg-device-model-01.txt. > - You feel that the routing-instance should have a list of leaf-ref’s > to the interface. You believe the leaf-ref provides a level of validation > due to the fact that references can be confined to routing-instance > references. However, heretofore, no models are referencing the interface > leaf-refs in the list.
True, these models (ietf-isis, for instance) use leafrefs with "if:interface-ref" type. However, such leafrefs are under-constrained because they can be configured to refer to: - interfaces of any layer, including physical interfaces, VLAN trunks etc. - interfaces assigned to any routing instance. I believe in all these cases the choice has to be limited to (1) L3 interfaces, and (2) belonging to "own" routing instance. These constraints will have to be checked in server code somehow - I would prefer to have them represented in the data model. But if nobody shares this concern with me, I am not going to block the document on this issue. Lada > > Other than the Routing YANG Design Team having chosen the first option - > are there any other opinions? > > Thanks, > Acee > > On 10/9/15, 9:00 AM, "netmod on behalf of Acee Lindem (acee)" > <[email protected] on behalf of [email protected]> wrote: > >> Hi Lada, >> I2RS is not chartered to do the base models. There are other routing >> models that reference routing-cfg and even in-progress implementations. >> >> On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka" >> <[email protected] on behalf of [email protected]> wrote: >> >>> Hi, >>> >>> I am sorry for cross-posting but I think it is high time to decide the >>> relationship between the data models in i2rs-rib-data-model and >>> netmod-routing-cfg I-Ds because they clearly target the same management >>> data in a router. I can see three possible scenarios: >>> >>> 1. The i2rs-rib module will be modified to augment >>> ietf-routing/ietf-ipv[46]-unicast-routing. >> >> This would seem to be the obvious choice. >> >>> >>> 2. The scope of ietf-routing will be changed so that it would address >>> only host routing and simple routers. The modelling work for advanced >>> routers will be done elsewhere. >>> >>> 3. The work on netmod-routing-cfg will be stopped. >> >> A fourth option would be for me to take over ownership, move the work to >> the RTG WG, and we’d recruit some strong authors/reviewers from operators >> and other vendors (involving the ADs in selection). >> >> Thanks, >> Acee >> >> >>> >>> Opinions? >>> >>> Thanks, Lada >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
