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. > >[...] > >> > 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. 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
