Re: [Rtg-yang-coord] [netmod] High Level Comments on draft-ietf-netmod-rtg-cfg-16.txt

["Acee Lindem (acee)" <[e-mail]>]

Re-adding [e-mail] due to popular request.

On 11/19/14, 7:40 AM, "Martin Bjorklund" <[e-mail]> wrote:

>Ladislav Lhotka <[e-mail]> wrote:
>> Hi Acee,
>> 
>> please see my comments inline.
>> 
>> "Acee Lindem (acee)" <[e-mail]> 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