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

[Ladislav Lhotka <[e-mail]>]

On 19 Nov 2014, at 14:35, Acee Lindem (acee) <[e-mail]> wrote:

> 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.
> 
> 

+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