Re: [Rtg-yang-coord] issue :R03: assignment of interfaces to routing instances

[Ladislav Lhotka <[e-mail]>]

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

> On 2/24/15, 1:28 PM, "Jeffrey Haas" <[e-mail]> wrote:
>
>>[I'm behind as usual and this may have been discussed already.]
>>
>>On Fri, Feb 13, 2015 at 06:07:11PM +0000, Acee Lindem (acee) wrote:
>>> Independent of the hierarchy, I think an interface should be associated
>>> with one and only routing-instance. I know of no implementation that
>>> allows this (including the use case of separate instances for IPv4 and
>>> IPv6). 
>>
>>While junos does have the interface as part of the routing instance
>>interface hierarchy, you're also correct in that junos enforces that the
>>interface is only associated with one instance.
>>
>>The question is with regard to generic modeling: Should a single unified
>>interface model with the ability to associate the interface with the
>>instance?  Should the instance refer to interfaces?
>>
>>My concern with making the interface model point to associated instances
>>is
>>how we handle versioning for unknown things that we may want to associate
>>that interface with.  The interface model is something we want to be rock
>>solid stable, not something that needs to be revised each time some new
>>instancing mechanism is created.
>
> Since what I¹m suggesting is having rtg-cfg augment the interface model, I
> don¹t understand your concern. Why is the new model having a separate list
> of interfaces any more ³rock solid² than the existing interface to
> reference the associated routing instance?

Acee is right - it is an augment and its data belong to a different
namespace, so it really doesn't affect the interface model. Actually, I
think it would be done the same way (via an augment from another module)
even if we envisioned from the start that the assignment of interfaces
to routing instances will be done inside the interface hierarchy..

My concern regarding the change that Acee proposes is that this schema
extension cannot be made specific so that only a subset of interfaces
(L3) can be assigned to routing instances - at least I don't know how to
do it formally in the data model. The problem has to do with the fact
that interfaces of all layers and types are kept in the same flat list.

>
> My concern is much easier to understand - with existing configuration
> information augmenting the RFC 7223 model and some new subset of
> configuration information augmenting the interface list, we have a
> bifurcated extension model. Independent of which way we decide to

If it is the other way around, one could then argue that the
routing-instance configuration is bifurcated. I think both ways are
possible in principle, and are just a matter of taste, or perhaps legacy
CLI considerations.

> proceed,this issue needs to be addressed lest we have confusion every
> time a new model needs to augment interface configuration.

I agree, we have to make a choice.

Lada

>
> Acee 
>
>
>
>
>>
>>-- Jeff
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C