On 10/13/15, 12:30 PM, "Ladislav Lhotka" <lho...@nic.cz> wrote:
> >> On 13 Oct 2015, at 17:20, Acee Lindem (acee) <a...@cisco.com> 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. Actually, putting the routing-instance reference in the IPv4 and IPv6 interface models (i.e., RFC 7277) constrains the reference to layer 3 more effectively than the list of leaf-refs. > >- interfaces assigned to any routing instance. But the list of leaf-refs doesn’t insure an IPv4 interface or IPv6 interface isn’t included by a single 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. I’d also be interested if anyone shares this concern. Thanks, Acee > >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)" >> <netmod-boun...@ietf.org on behalf of a...@cisco.com> 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" >>> <netmod-boun...@ietf.org on behalf of lho...@nic.cz> 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 >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
