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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 12 Feb 2015 23:09:42 +0000

I believe the fact that we are having trouble resolving this is that the
model is wrong. I would propose the following:

   1. Remove the interface list completely from rtf-cfg configuration.
   2. Augment the RFC 7223 to include a reference to a routing-instance.
An interface should be part of one and only one routing-instance.
   3. Provide a list of interfaces in the operational state in the rtg-cfg
model. 

One reason I'm proposing this change is that I believe a routing-instance
implies an IPv4/IPv6 address space and the interfaces list MUST NOT be
disjoint from the assigned addresses (refer to RFC 7277). If you want to
have a list of interfaces in the routing-instance, you should deprecate
RFC 7277 or, at least, say that it only applies to the default instance.

In all fairness, Lada disagrees with me on this point and wants the
flexibility of associating an interface with multiple routing-instances.
Additionally, he feels that the list inside the routing-instance will
facilitate better interface selection checking. I don¹t see the latter as
an issue as the same checking could be applied when an attempt is made to
augment the RFC 7223 interface.

Thanks,
Acee 

On 1/14/15, 12:46 PM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>On Wed, Jan 14, 2015 at 04:43:29PM +0000, Xufeng Liu wrote:
>> Hi Andy,
>> 
>> The concatenated string format is actually what we plan to do. However,
>>to me, it is more like a hack than an engineered solution. The model
>>fails to capture such a relationship properly.
>>
>
>If your interface names are no unique, I would assume that you will
>face other issues as well. For example, one may use an interface name
>to disambiguate link-local addresses. I am not sure how that works if
>your interface name is not unique.
>
>/js
>
>-- 
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Feb 2015 11:25:58 +0100

> model is wrong. I would propose the following:

I don't agree the model is wrong. In fact, I belive in Junos CLI it is
done exactly the same way, e.g.

  set interface fe-0/0/2 unit 0 family inet address 6.6.6.5/24

  set routing-instances blue-vr interface fe-0/0/2.0

(IP address is configured in the interface subtree, and an interface is
assigned to a VRF in the routing-instance subtree).

I believe the troubles we are having are due to the different logic in
the CLIs of the two major routing platforms.

Lada

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 13 Feb 2015 17:45:33 +0000

>the CLIs of the two major routing platforms.

Does it show up as a separate list in the JUNOS gated-like configuration
hierarchy? If they do configure the IPv4/IPv6 addresses disjoint from the
routing -instance instances imply the corresponding IPv4/IPv6 address
space and the RIBs, I still don’t like the inconsistency.

The previous product I worked on, IPOS, had the interfaces in
routing-instance but the routing-instance interface included all the layer
3 definition including the IP/IPv6 addresses (i.e., the RFC 7277
definitions). 

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 13 Feb 2015 18:07:11 +0000

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

Thanks,
Acee 

On 2/13/15, 12:45 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

>_______________________________________________
>Rtg-yang-coord mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 14 Feb 2015 12:49:11 +0100

> with one and only routing-instance. I know of no implementation that

We've been there, too. In revision -02, we had this definition ("router"
later became "routing-instance"):

list router {
    key "name";
    unique "interfaces/interface/name";
    ...
}

The role of the "unique" statement was to restrict the assignment of
interfaces exactly as you write.

But then we had a discussion in the NETMOD mailing list about whether
such a unique statement is legal or not:

http://www.ietf.org/mail-archive/web/netmod/current/msg06386.html

While I still think there is nothing wrong with that unique statement,
it was eventually removed for the "ietf-routing" module.

> allows this (including the use case of separate instances for IPv4 and

This is not necessarily true. In my data model for the BIRD routing
daemon

(https://gitlab.labs.nic.cz/labs/yang-tools/tree/master/data-models/bird)

I am using special types of routing-instances "bird-ipv4" and
"bird-ipv6", and the same interface can be in both instances. This is
because BIRD has to be compiled separately with support for IPv4 and
IPv6, and each routing-instance then corresponds to one BIRD process.

Yes, such an implementation is somewhat peculiar and needn't serve as a
model. On the other hand, I don't see any reason why overlapping
interface assignments should be made illegal for *all* types of routing
instances.

I assume the data model for routing instances of the type "VRF" will
state that assignments of interfaces to routing instances have to be
disjoint, and the draft explicitly states such an additional constraint
is allowed (last paragraph in sec. 5.1). Isn't this sufficient?

Lada

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 24 Feb 2015 13:28:59 -0500

[I'm behind as usual and this may have been discussed already.]

> allows this (including the use case of separate instances for IPv4 and

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.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 26 Feb 2015 01:56:51 +0000

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

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 proceed,
this issue needs to be addressed lest we have confusion every time a new
model needs to augment interface configuration.

Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Feb 2015 09:43:37 +0100

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

> 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