On 19 Nov 2014, at 14:35, Acee Lindem (acee) <[email protected]> wrote:
> Re-adding [email protected] due to popular request. > > On 11/19/14, 7:40 AM, "Martin Bjorklund" <[email protected]> wrote: > >> Ladislav Lhotka <[email protected]> wrote: >>> Hi Acee, >>> >>> please see my comments inline. >>> >>> "Acee Lindem (acee)" <[email protected]> writes: >>> >>>> First, let me explain why I requested that the route-filters be >>>> removed from the model. What I don't like about the route-filters is >>>> that they are merely place-holders placed at a point-of-attachment >>>> which I don't necessarily agree with. Although we may end up with >>>> something similar, these definitions should be in a more complete >>>> routing policy model. Additionally, I believe it is obvious that there >>>> will >>> >>> I don't think the ietf-routing module preempts any further work on a >>> policy model. And if the points-of-attachment turn out to be wrong, we >>> can write a new module - nothing is cast in stone and I expect the >>> module will have to be redone anyway after some experience will have >>> been collected. >> >> But then it doesn't hurt to wait with these "attachment points" until >> at least the first policy model is being written, right? They can >> then either be defined in an update to this model, or in a separate >> model that augments this one. > > My point is that this may set us off in the wrong direction and be a > source of future confusion and debate. If others believe the existing stub > policies are a good start, they should speak up. > > +1 > > >> >> [...] >> >>>> As for the interface list in the routing-instance, I think it is >>>> obvious that one should not define the address space for interface >>>> disjointly from the IPv4/IPv6 interface addresses. That is why I >>>> would recommend augmenting the RFC 7273 objects with a reference >>>> to the routing instance rather having a disjoint interface >>>> list in routing-instance as proposed. >>> >>> It is IMO subjective whether the assignment of interfaces to routing >>> instances should be done in interface configuration or in routing >>> instance configuration. As it is now, the following procedure could work >>> fine: >>> >>> 1. Define routing instances (this has to be done in any case). >>> 2. Assign interfaces to routing instances in routing instance >>> configuration via references to interfaces in the main interface >>> list. >>> 3. Assign addresses to interfaces in main interface configuration. >>> >>> The system then has all information to be able to resolve potential >>> conflicts in IP addresses belonging to different routing instances. >> >> To be very clear, is this what you propose: >> >> augement /if:interfaces/if:interface { >> leaf routing-instance { >> type routing-instance-ref; >> } >> } >> >> ... and remove /routing/routing-instance/interfaces? > > Either here or augment ietf-ip (RFC 7277) in a similar manner. I also > think the definition of the ipv6-router-advertisements should augment the > ipv6 container in ietf-ip rather than on this misplaced list of > interfaces. An advantage of this misplaced list of interfaces is that it is supposed to contain only network layer interfaces whereas if:interface is a flat list that contains interfaces of all layers including those where RAs don’t make sense at all. Lada > > Thanks, > Acee > >> >> I think this would be equivalent to your current model, in the sense >> of *what* you can express. >> >>> Maybe there are some implementation-related issues that I am missing, >>> so I am not against the change you propose but I'd like to know sound >>> reasons before applying it. >> >> I think Acee provided a good reason: >> >>>> one should not define the address space for interface >>>> disjointly from the IPv4/IPv6 interface addresses >> >> >> >> >> /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
