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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Jan 2015 01:11:45 +0000

Hi, 

Lada and I have been discussing this issue for some time and were hoping
for some comments from the routing community. The question is basically
whether to have a list of interfaces in routing-instance that reference
the RFC 7223 interfaces:

        container interfaces {
           description
             "Configuration of the routing instance's interfaces.";
           list interface {
             key "name";
             description
               "List of network layer interfaces assigned to the routing
                instance.";
             leaf name {
               type if:interface-ref;
               description
                 "A reference to the name of a configured network layer
                  interface.";
             }
           }
         }

Or to augment the RFC 7223 interfaces to point to the routing-instance.

Thanks,
Acee

On 11/25/14, 8:16 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>Hi,
>
>this issue refers the YANG module "ietf-routing" contained in
>
>http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16
>
>Please indicate your preference or add comments.
>
>***** :R03: assignment of interfaces to routing instances
>      In -16 it is done by including a network-layer interface in the
>      list rt:interface under rt:routing-instance. An advantage of
>      this organization is that the rt:interface list should contain
>      only network layer interfaces for which the assignment makes
>      sense. A drawback is that the assignment is detached from the
>      specification of IP addresses in if:interface.
>
>****** Solution R03-1
>       No change.
>
>****** Solution R03-2
>       Do the assignment of an interface to a routing instance inside
>       the if:interface entry.
>
>-- 
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>_______________________________________________
>Rtg-yang-coord mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Jan 2015 10:31:33 +0100

> On 13 Jan 2015, at 02:11, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi, 
> 

Please see also my earlier mail:

http://www.ietf.org/mail-archive/web/rtg-yang-coord/current/msg00131.html

Thanks, Lada

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 13 Jan 2015 15:11:14 +0000

For the routing-instance to interface relationship, I support the aggregation (or containment) relationship, which means:
1. We can easily navigate to interfaces from a routing-instance.
2. The key attributes in interfaces are unique within the scope of a routing-instance.

The current leafref in routing-instance is not sufficient for the above requirements. The uniqueness of interface name within the scope of a routing-instance is not supported.

My proposal is:
1. Keep the current leafref in routing-instance.
2. Add an attribute routing-instance-ref (type leafref) in interface to point to the name attribute (key) of routing-instance.
3. Make the new routing-instance-ref added above to be part of the key, i.e. create a composite key <name, routing-instance-ref> for interface.

Thanks,

- Xufeng

> -----Original Message-----
> From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of
> Ladislav Lhotka
> Sent: Tuesday, January 13, 2015 4:32 AM
> To: Acee Lindem (acee)
> Cc: [email-masked]
> Subject: Re: [Rtg-yang-coord] issue :R03: assignment of interfaces to routing
> instances
> 
> 
> > Lada and I have been discussing this issue for some time and were
> > hoping for some comments from the routing community. The question is
> > basically whether to have a list of interfaces in routing-instance
> > that reference the RFC 7223 interfaces:
> >
> >        container interfaces {
> >           description

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Jan 2015 17:42:38 +0100

Hi Xufeng,

> On 13 Jan 2015, at 16:11, Xufeng Liu <[email-masked]> wrote:
> 

The data model aims to support different types of routing instances, and it is conceivable that for some types an interface might be allowed to be assigned to more than one routing instance.

However, the draft also says (last paragraph in sec. 5.1) that additional constraints like this uniqueness requirement can be added for a specific routing-instance type.

> 1. Keep the current leafref in routing-instance.

OK.

> 2. Add an attribute routing-instance-ref (type leafref) in interface to point to the name attribute (key) of routing-instance.

This is IMO a good idea, we would then have links in both directions.

> 3. Make the new routing-instance-ref added above to be part of the key, i.e. create a composite key <name, routing-instance-ref> for interface.

This is not possible because:

- the key of the if:interface list cannot be extended by additional components;
 
- if:interface is a flat list that contains interfaces of all layers, but an assignment to a routing-instance makes sense only for L3 interfaces;

- YANG module ietf-interfaces is intended for all kinds of devices, including those that don’t implement ietf-routing.

Thanks, Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Jan 2015 22:27:32 +0100

> This is IMO a good idea, we would then have links in both directions.

I assume this would be config false state data, otherwise we only add
configuration complexity for no real value. And this likely would have
to be a leaf-list.

> - YANG module ietf-interfaces is intended for all kinds of devices, including those that don’t implement ietf-routing.

+1

/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: Wed, 14 Jan 2015 10:37:36 +0100

> On 13 Jan 2015, at 22:27, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Yes, right. I’d propose to configure this assignment under routing-instance and the have the reference(s) to the routing-instance as an (optional) item in if:interface entries (in their state data).

> configuration complexity for no real value. And this likely would have

This depends on whether we conclude that the assignment has to be disjoint or not. I support the latter option, so yes, I’d also prefer to have a leaf-list for this purpose.

Lada

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 14 Jan 2015 15:33:02 +0000

> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Wednesday, January 14, 2015 4:38 AM
> To: Jürgen Schönwälder
> Cc: Xufeng Liu; [email-masked]; Acee Lindem (acee)
> >>> 2. Add an attribute routing-instance-ref (type leafref) in interface to point to
> the name attribute (key) of routing-instance.
> >>
> Yes, right. I’d propose to configure this assignment under routing-instance and
> the have the reference(s) to the routing-instance as an (optional) item in
> if:interface entries (in their state data).
> 
> This depends on whether we conclude that the assignment has to be disjoint or
> not. I support the latter option, so yes, I’d also prefer to have a leaf-list for this
> purpose.
> 
> Lada
> 
> >
> >>> 3. Make the new routing-instance-ref added above to be part of the key, i.e.
> create a composite key <name, routing-instance-ref> for interface.
> >>
> >> - if:interface is a flat list that contains interfaces of all layers,
> >> but an assignment to a routing-instance makes sense only for L3
> >> interfaces;
> >>
[Xufeng] Hi Lada, I acknowledge the difficulties here. However, is there a good way to handle the following case?
	In routing-instance "RI-A", an interface named "IF-1" is already configured.
	In routing-instance "RI-B", I'd like to configure an different interface with the same name "IF-1".
Thanks,
- Xufeng

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Jan 2015 16:54:50 +0100

> 	In routing-instance "RI-B", I'd like to configure an different interface with the same name "IF-1".

In the RFC 7223 interface data model the interface name is used as a
key and hence you can't have two different interfaces with the same
name.

/js

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 14 Jan 2015 15:59:05 +0000

> From: Juergen Schoenwaelder [mailto:[email-masked]]
> Sent: Wednesday, January 14, 2015 10:55 AM
> To: Xufeng Liu
> Cc: Ladislav Lhotka; [email-masked]; Acee Lindem (acee)
> In the RFC 7223 interface data model the interface name is used as a key and
> hence you can't have two different interfaces with the same name.
> 
> /js

[Xufeng] This is the issue that we'd like to solve. We have such a use case.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 Jan 2015 08:05:35 -0800

> [Xufeng] This is the issue that we'd like to solve. We have such a use case.

The interfaces list is for the entire device, and we should not change that.
IMO you are describing an implementation detail, not a use-case.
The format of the name string can be "RI-1/IF-1" for example.
If "IF-1" is not going to be unique, then make up a new arbitrary name.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Jan 2015 17:07:16 +0100

> On 14 Jan 2015, at 16:59, Xufeng Liu <[email-masked]> wrote:
> 
> 
> 

Can you give us more details about this use case? Clearly IP adresses of interfaces belonging to different routing instances can be conflicting but I don’t understand why the interface names need to be the same.

Lada

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 14 Jan 2015 16:26:12 +0000

Andy,

Agree, routing-instance+interface_name would suffice and also meet
existing implementations constrains

Cheers,
Jeff

-----Original Message-----
From: Andy Bierman <[email-masked]>
Date: Wednesday, January 14, 2015 at 8:05 AM
To: Xufeng Liu <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Acee Lindem
(acee)" <[email-masked]>, Juergen Schoenwaelder
<[email-masked]>, Ladislav Lhotka <[email-masked]>
Subject: Re: [Rtg-yang-coord] issue :R03: assignment of interfaces to
routing instances

>>> From: Juergen Schoenwaelder
>>>[mailto:[email-masked]]
>>> > [Xufeng] Hi Lada, I acknowledge the difficulties here. However, is
>>>there a good
>>> way to handle the following case?
>>> >     In routing-instance "RI-B", I'd like to configure an different
>>>interface
>>> with the same name "IF-1".
>>>
>>>key and

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 14 Jan 2015 16:43:29 +0000

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.

Thanks,
- Xufeng

> From: Jeff Tantsura
> Sent: Wednesday, January 14, 2015 11:26 AM
> To: Andy Bierman; Xufeng Liu
> Cc: [email-masked]; Acee Lindem (acee); Juergen Schoenwaelder;
> Ladislav Lhotka
> Agree, routing-instance+interface_name would suffice and also meet existing
> implementations constrains
> 
> Cheers,
> Jeff
> 
> 
> 
> 
> (acee)" <[email-masked]>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> university.de>, Ladislav Lhotka <[email-masked]>
> >>> Subject: Re: [Rtg-yang-coord] issue :R03: assignment of interfaces
> >>>to routing  instances
> >>>
> >>> >     In routing-instance "RI-A", an interface named "IF-1" is
> >>> > already
> >>> configured.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Jan 2015 18:46:55 +0100

> 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

---

From: Christian Hopps <[email-masked]>
Date: Thu, 15 Jan 2015 07:23:29 -0500

Hi,

Looking at a couple models (isis and ospf), they appear to add their own interface lists and then refer back to the routing instance list. If we have a list of interfaces in the routing instance does it make sense for routing protocols to augment the routing-instance list rather than create their own? If not then what other data will be added to the routing instance interface?

Thanks,
Chris.

> On Jan 12, 2015, at 8:11 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi,
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 16 Jan 2015 10:19:16 +0100

Christian Hopps <[email-masked]> writes:

> Hi,
>
> Looking at a couple models (isis and ospf), they appear to add their
> own interface lists and then refer back to the routing instance
> list. If we have a list of interfaces in the routing instance does it
> make sense for routing protocols to augment the routing-instance list
> rather than create their own? If not then what other data will be

I think each protocol instance needs a list of interfaces it runs on.

> added to the routing instance interface?

Currently we have IPv6 RA data there, it is actually another issue we
have to resolve:

http://www.ietf.org/mail-archive/web/rtg-yang-coord/current/msg00132.html

Do you have any suggestion?

Thanks, Lada

---

From: "Russ White" <[email-masked]>
Date: Sun, 18 Jan 2015 08:24:46 -0500

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

How would you plan on "showing" such a pair of interfaces from a potential
CLI? If you switch into a "routing instance mode," then the user is likely
to think of these as different "contexts," and hence having two "devices" on
the same physical box is probably the cleanest solution from the YANG model
perspective. If you add something to the interface name (the routing
instance, or something similar), then the user is already associating that
name with the interface name in a "concatenated" way, so doing the same in
the YANG interface name shouldn't be an issue.

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Sun, 18 Jan 2015 08:31:06 -0500

> > > 2. Add an attribute routing-instance-ref (type leafref) in interface to point
> to the name attribute (key) of routing-instance.
> >

How often would we traverse the link from the interface to the routing instance? I'm trying to think of a use case where you'd be looking at an interface configuration or state, and need to find out which routing instance it's being "included" in, and -- given a single interface can be included in multiple routing instances, how would I know which one I'm actually looking for?

What specific question would I be asking that would cause me to look at this list -- in other words, when would I ask, "what routing instances is this interface included in?"

:-)

Russ

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 19 Jan 2015 09:21:57 +0100

Russ White <[email-masked]> writes:

> How often would we traverse the link from the interface to the routing
> instance? I'm trying to think of a use case where you'd be looking at
> an interface configuration or state, and need to find out which

The link from an interface to routing instance(s) would be only in state data.

> routing instance it's being "included" in, and -- given a single
> interface can be included in multiple routing instances, how would I
> know which one I'm actually looking for?

It will be a leaf-list so you will be able to see all routing instances
in which the interface is included, and hopefully find the one you are
looking for.

>
> What specific question would I be asking that would cause me to look
> at this list -- in other words, when would I ask, "what routing
> instances is this interface included in?"

For example: Which VPN is this interface part of?

Lada