Subject: [i2rs] rib-data-model and routing-cfg

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 9 Oct 2015 10:13:09 +0200

Hi,

I am sorry for cross-posting but I think it is high time to decide the relationship between the data models in i2rs-rib-data-model and netmod-routing-cfg I-Ds because they clearly target the same management data in a router. I can see three possible scenarios:

1. The i2rs-rib module will be modified to augment ietf-routing/ietf-ipv[46]-unicast-routing.

2. The scope of ietf-routing will be changed so that it would address only host routing and simple routers. The modelling work for advanced routers will be done elsewhere.

3. The work on netmod-routing-cfg will be stopped.

Opinions?

Thanks, Lada

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 9 Oct 2015 13:00:08 +0000

Hi Lada, 
I2RS is not chartered to do the base models. There are other routing
models that reference routing-cfg and even in-progress implementations.

On 10/9/15, 4:13 AM, "netmod on behalf of Ladislav Lhotka"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi,
>
>I am sorry for cross-posting but I think it is high time to decide the
>relationship between the data models in i2rs-rib-data-model and
>netmod-routing-cfg I-Ds because they clearly target the same management
>data in a router. I can see three possible scenarios:
>
>1. The i2rs-rib module will be modified to augment
>ietf-routing/ietf-ipv[46]-unicast-routing.

This would seem to be the obvious choice.

>
>2. The scope of ietf-routing will be changed so that it would address
>only host routing and simple routers. The modelling work for advanced
>routers will be done elsewhere.
>

A fourth option would be for me to take over ownership, move the work to
the RTG WG, and we’d recruit some strong authors/reviewers from operators
and other vendors (involving the ADs in selection).

Thanks,
Acee 

>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 9 Oct 2015 15:39:48 +0200

> On 09 Oct 2015, at 15:00, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Lada, 

Of course, I am aware of them. However, assuming that changes resulting from I2RS operation will be available for inspection as state data to NETCONF/RESTCONF clients, and vice versa, it's important that the those routing data models and I2RS data models remain compatible and coordinated.

A data model for RIBs should IMO be developed simultaneously for both purposes, and common parts implemented as groupings so as to be reusable without copying-and-pasting. 

> This would seem to be the obvious choice.

I agree, and so far it can be done quite easily.

> and other vendors (involving the ADs in selection).

Yes, that's what I meant.

Thanks, Lada

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 9 Oct 2015 15:16:39 -0500

>> and other vendors (involving the ADs in selection).

You mean  i2rs-rib-data-model?

Regards,

Behcet
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 12 Oct 2015 09:58:54 +0200

> On 09 Oct 2015, at 22:16, Behcet Sarikaya <[email-masked]> wrote:
> 

We are talking about a bigger picture, and i2rs-rib-data-model is a part of it.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Oct 2015 15:20:39 +0000

Hi Lada, NETMOD, 

So I think we should move forward this ietf-rtg-cfg so that it can be
augmented and other work can move forward. We are still in disagreement
with respect to routing-instance/interface configuration.

    - We feel the IPv4/IPv6 interfaces should reference the
routing-instance in their config state. This is consistent with
draft-rtgyangdt-rtgwg-device-model-01.txt.
    - You feel that the routing-instance should have a list of leaf-ref’s
to the interface. You believe the leaf-ref provides a level of validation
due to the fact that references can be confined to routing-instance
references. However, heretofore, no models are referencing the interface
leaf-refs in the list.

Other than the Routing YANG Design Team having chosen the first option -
are there any other opinions?

Thanks,
Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Oct 2015 18:30:09 +0200

> On 13 Oct 2015, at 17:20, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Lada, NETMOD, 
> 

True, these models (ietf-isis, for instance) use leafrefs with "if:interface-ref" type. However, such leafrefs are under-constrained because they can be configured to refer to:

- interfaces of any layer, including physical interfaces, VLAN trunks etc.

- interfaces assigned to any routing instance.

I believe in all these cases the choice has to be limited to (1) L3 interfaces, and (2) belonging to "own" routing instance. These constraints will have to be checked in server code somehow - I would prefer to have them represented in the data model.

But if nobody shares this concern with me, I am not going to block the document on this issue.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Oct 2015 18:25:19 +0000

On 10/13/15, 12:30 PM, "Ladislav Lhotka" <[email-masked]> wrote:

>True, these models (ietf-isis, for instance) use leafrefs with
>"if:interface-ref" type. However, such leafrefs are under-constrained
>because they can be configured to refer to:
>

Actually, putting the routing-instance reference in the IPv4 and IPv6
interface models (i.e., RFC 7277) constrains the reference to layer 3 more
effectively than the list of leaf-refs.

>- interfaces assigned to any routing instance.

But the list of leaf-refs doesn’t insure an IPv4 interface or IPv6
interface isn’t included by a single routing-instance.

>
>I believe in all these cases the choice has to be limited to (1) L3
>interfaces, and (2) belonging to "own" routing instance. These
>constraints will have to be checked in server code somehow - I would
>prefer to have them represented in the data model.
>

I’d also be interested if anyone shares this concern.

Thanks,
Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 15 Oct 2015 13:25:21 +0200

Hi Acee,

I made the necessary changes in ietf-routing, please see the GitHub
repo:

https://github.com/netmod-wg/routing-cfg

A new leaf "rt:routing-instance" was augmented into interface
configuration, and "rt:interfaces" container in configuration is gone.

Below is the complete new tree.

Will this work?

Lada

module: ietf-interfaces
   +--rw interfaces
   |  +--rw interface* [name]
   |     +--rw name                   string
   |     +--rw description?           string
   |     +--rw type                   identityref
   |     +--rw enabled?               boolean
   |     +--rw ip:ipv4!
   |     |  +--rw ip:enabled?      boolean
   |     |  +--rw ip:forwarding?   boolean
   |     |  +--rw ip:mtu?          uint16
   |     |  +--rw ip:address* [ip]
   |     |  |  +--rw ip:ip               inet:ipv4-address-no-zone
   |     |  |  +--rw (subnet)
   |     |  |     +--:(prefix-length)
   |     |  |        +--rw ip:prefix-length?   uint8
   |     |  +--rw ip:neighbor* [ip]
   |     |     +--rw ip:ip                    inet:ipv4-address-no-zone
   |     |     +--rw ip:link-layer-address    yang:phys-address
   |     +--rw ip:ipv6!
   |     |  +--rw ip:enabled?                        boolean
   |     |  +--rw ip:forwarding?                     boolean
   |     |  +--rw ip:mtu?                            uint32
   |     |  +--rw ip:address* [ip]
   |     |  |  +--rw ip:ip               inet:ipv6-address-no-zone
   |     |  |  +--rw ip:prefix-length    uint8
   |     |  +--rw ip:neighbor* [ip]
   |     |  |  +--rw ip:ip                    inet:ipv6-address-no-zone
   |     |  |  +--rw ip:link-layer-address    yang:phys-address
   |     |  +--rw ip:dup-addr-detect-transmits?      uint32
   |     |  +--rw ip:autoconf
   |     |  |  +--rw ip:create-global-addresses?   boolean
   |     |  +--rw v6ur:ipv6-router-advertisements
   |     |     +--rw v6ur:send-advertisements?    boolean
   |     |     +--rw v6ur:max-rtr-adv-interval?   uint16
   |     |     +--rw v6ur:min-rtr-adv-interval?   uint16
   |     |     +--rw v6ur:managed-flag?           boolean
   |     |     +--rw v6ur:other-config-flag?      boolean
   |     |     +--rw v6ur:link-mtu?               uint32
   |     |     +--rw v6ur:reachable-time?         uint32
   |     |     +--rw v6ur:retrans-timer?          uint32
   |     |     +--rw v6ur:cur-hop-limit?          uint8
   |     |     +--rw v6ur:default-lifetime?       uint16
   |     |     +--rw v6ur:prefix-list
   |     |        +--rw v6ur:prefix* [prefix-spec]
   |     |           +--rw v6ur:prefix-spec           inet:ipv6-prefix
   |     |           +--rw (control-adv-prefixes)?
   |     |              +--:(no-advertise)
   |     |              |  +--rw v6ur:no-advertise?         empty
   |     |              +--:(advertise)
   |     |                 +--rw v6ur:valid-lifetime?       uint32
   |     |                 +--rw v6ur:on-link-flag?         boolean
   |     |                 +--rw v6ur:preferred-lifetime?   uint32
   |     |                 +--rw v6ur:autonomous-flag?      boolean
   |     +--rw rt:routing-instance?   routing-instance-ref
   +--ro interfaces-state
      +--ro interface* [name]
         +--ro name                   string
         +--ro type                   identityref
         +--ro oper-status            enumeration
         +--ro last-change?           yang:date-and-time
         +--ro phys-address?          yang:phys-address
         +--ro higher-layer-if*       interface-state-ref
         +--ro lower-layer-if*        interface-state-ref
         +--ro speed?                 yang:gauge64
         +--ro statistics
         |  +--ro discontinuity-time    yang:date-and-time
         |  +--ro in-octets?            yang:counter64
         |  +--ro in-unicast-pkts?      yang:counter64
         |  +--ro in-broadcast-pkts?    yang:counter64
         |  +--ro in-multicast-pkts?    yang:counter64
         |  +--ro in-discards?          yang:counter32
         |  +--ro in-errors?            yang:counter32
         |  +--ro in-unknown-protos?    yang:counter32
         |  +--ro out-octets?           yang:counter64
         |  +--ro out-unicast-pkts?     yang:counter64
         |  +--ro out-broadcast-pkts?   yang:counter64
         |  +--ro out-multicast-pkts?   yang:counter64
         |  +--ro out-discards?         yang:counter32
         |  +--ro out-errors?           yang:counter32
         +--ro ip:ipv4!
         |  +--ro ip:forwarding?   boolean
         |  +--ro ip:mtu?          uint16
         |  +--ro ip:address* [ip]
         |  |  +--ro ip:ip               inet:ipv4-address-no-zone
         |  |  +--ro (subnet)?
         |  |  |  +--:(prefix-length)
         |  |  |     +--ro ip:prefix-length?   uint8
         |  |  +--ro ip:origin?          ip-address-origin
         |  +--ro ip:neighbor* [ip]
         |     +--ro ip:ip                    inet:ipv4-address-no-zone
         |     +--ro ip:link-layer-address?   yang:phys-address
         |     +--ro ip:origin?               neighbor-origin
         +--ro ip:ipv6!
         |  +--ro ip:forwarding?                     boolean
         |  +--ro ip:mtu?                            uint32
         |  +--ro ip:address* [ip]
         |  |  +--ro ip:ip               inet:ipv6-address-no-zone
         |  |  +--ro ip:prefix-length    uint8
         |  |  +--ro ip:origin?          ip-address-origin
         |  |  +--ro ip:status?          enumeration
         |  +--ro ip:neighbor* [ip]
         |  |  +--ro ip:ip                    inet:ipv6-address-no-zone
         |  |  +--ro ip:link-layer-address?   yang:phys-address
         |  |  +--ro ip:origin?               neighbor-origin
         |  |  +--ro ip:is-router?            empty
         |  |  +--ro ip:state?                enumeration
         |  +--ro v6ur:ipv6-router-advertisements
         |     +--ro v6ur:send-advertisements?    boolean
         |     +--ro v6ur:max-rtr-adv-interval?   uint16
         |     +--ro v6ur:min-rtr-adv-interval?   uint16
         |     +--ro v6ur:managed-flag?           boolean
         |     +--ro v6ur:other-config-flag?      boolean
         |     +--ro v6ur:link-mtu?               uint32
         |     +--ro v6ur:reachable-time?         uint32
         |     +--ro v6ur:retrans-timer?          uint32
         |     +--ro v6ur:cur-hop-limit?          uint8
         |     +--ro v6ur:default-lifetime?       uint16
         |     +--ro v6ur:prefix-list
         |        +--ro v6ur:prefix* [prefix-spec]
         |           +--ro v6ur:prefix-spec           inet:ipv6-prefix
         |           +--ro v6ur:valid-lifetime?       uint32
         |           +--ro v6ur:on-link-flag?         boolean
         |           +--ro v6ur:preferred-lifetime?   uint32
         |           +--ro v6ur:autonomous-flag?      boolean
         +--ro rt:routing-instance?   routing-instance-state-ref
module: ietf-routing
   +--ro routing-state
   |  +--ro routing-instance* [name]
   |     +--ro name                 string
   |     +--ro type?                identityref
   |     +--ro router-id?           yang:dotted-quad
   |     +--ro interfaces
   |     |  +--ro interface*   if:interface-state-ref
   |     +--ro routing-protocols
   |     |  +--ro routing-protocol* [type name]
   |     |     +--ro type    identityref
   |     |     +--ro name    string
   |     +--ro ribs
   |        +--ro rib* [name]
   |           +--ro name              string
   |           +--ro address-family    identityref
   |           +--ro default-rib?      boolean {multiple-ribs}?
   |           +--ro routes
   |              +--ro route*
   |                 +--ro route-preference?          route-preference
   |                 +--ro next-hop
   |                 |  +--ro (next-hop-options)
   |                 |     +--:(outgoing-interface)
   |                 |     |  +--ro outgoing-interface?      if:interface-state-ref
   |                 |     +--:(special-next-hop)
   |                 |     |  +--ro special-next-hop?        enumeration
   |                 |     +--:(next-hop-address)
   |                 |     |  +--ro v6ur:next-hop-address?   inet:ipv6-address
   |                 |     +--:(next-hop-address)
   |                 |        +--ro v4ur:next-hop-address?   inet:ipv4-address
   |                 +--ro source-protocol            identityref
   |                 +--ro active?                    empty
   |                 +--ro last-updated?              yang:date-and-time
   |                 +--ro v6ur:destination-prefix?   inet:ipv6-prefix
   |                 +--ro v4ur:destination-prefix?   inet:ipv4-prefix
   +--rw routing
      +--rw routing-instance* [name]
         +--rw name                 string
         +--rw type?                identityref
         +--rw enabled?             boolean
         +--rw router-id?           yang:dotted-quad
         +--rw description?         string
         +--rw routing-protocols
         |  +--rw routing-protocol* [type name]
         |     +--rw type             identityref
         |     +--rw name             string
         |     +--rw description?     string
         |     +--rw static-routes
         |        +--rw v6ur:ipv6
         |        |  +--rw v6ur:route* [destination-prefix]
         |        |     +--rw v6ur:destination-prefix    inet:ipv6-prefix
         |        |     +--rw v6ur:description?          string
         |        |     +--rw v6ur:next-hop
         |        |        +--rw (next-hop-options)
         |        |           +--:(outgoing-interface)
         |        |           |  +--rw v6ur:outgoing-interface?   if:interface-ref
         |        |           +--:(special-next-hop)
         |        |           |  +--rw v6ur:special-next-hop?     enumeration
         |        |           +--:(next-hop-address)
         |        |              +--rw v6ur:next-hop-address?     inet:ipv6-address
         |        +--rw v4ur:ipv4
         |           +--rw v4ur:route* [destination-prefix]
         |              +--rw v4ur:destination-prefix    inet:ipv4-prefix
         |              +--rw v4ur:description?          string
         |              +--rw v4ur:next-hop
         |                 +--rw (next-hop-options)
         |                    +--:(outgoing-interface)
         |                    |  +--rw v4ur:outgoing-interface?   if:interface-ref
         |                    +--:(special-next-hop)
         |                    |  +--rw v4ur:special-next-hop?     enumeration
         |                    +--:(next-hop-address)
         |                       +--rw v4ur:next-hop-address?     inet:ipv4-address
         +--rw ribs
            +--rw rib* [name]
               +--rw name              string
               +--rw address-family?   identityref
               +--rw description?      string

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 15 Oct 2015 21:12:16 +0000

Hi Lada, 
I looked at this and I like this simple association. I think we should go
with this - there is one point for discussion.

All,

In routing design team discussions we had augmented
“if:interfaces/if:interface/ip:ipv4” and
“if:interface/if:interface/ip:ipv6” so an interface could be mapped to
different routing-instances for IPv4 and IPv6.

Do we really see associating the same interface with different
routing-instances for IPv4 and IPv6? I can seem to remember the use case
and it does add complexity forever.

Thanks,
Acee

---

From: Rob Shakir <[email-masked]>
Date: Wed, 21 Oct 2015 07:26:49 -0600

On 15 October 2015 at 15:13:38, Acee Lindem (acee) ([email-masked]) wrote:

At least two of the operators for whom I have worked utilise this functionality (providing separate L3VPNs for IPv6 and IPv4) - so in my experience, it is not possible to make this simplification.

r.

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 21 Oct 2015 15:52:30 +0200

> On 21 Oct 2015, at 15:26, Rob Shakir <[email-masked]> wrote:
> 

One option would be to create two virtual interfaces - one for IPv4 VPN and another for IPv6 VPN, and define routing-instance and addresses separately for each.

Lada

---

From: Rob Shakir <[email-masked]>
Date: Wed, 21 Oct 2015 07:58:46 -0600

On 21 October 2015 at 07:52:43, Ladislav Lhotka ([email-masked]) wrote:
One option would be to create two virtual interfaces - one for IPv4 VPN and another for IPv6 VPN, and define routing-instance and addresses separately for each. 
This is only workable if an implementation must support two virtual interfaces that have the same underlying encapsulation (i.e.., they are simply logically separating IPv4 and IPv6), in some implementations, this isn’t the case, and the virtual interfaces must have different encapsulations. 

In openconfig-interfaces, each sub-interface is associated with a single VLAN, so in this case, we would need the network-instance to be specified on a per address-family basis there. There is nothing to stop one having a single leaf at the sub-interface or interface level that is inherited by the other constructs - this is something that I have been considering based on work on the network-instance model that we recently published.

r.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 21 Oct 2015 16:41:39 +0000

I guess in the L3VPN use case, both the IPv4 and IPv6 VPNs are for the same customer (since the interface only goes to one place).

 I’ve been thinking about this for much of the morning and I see, at least, the following options:

          1. Move the reference(s) to routing-instance to “/if:interfaces/if:interface/ip:ipv4”  and “/if:interfaces/if:interface/ip:ipv6”.
          2. Keep the reference at the “/if:interface/if:interface/“ level but make it a container with a more complex structure including the overall reference and feature enabled override references for specific purposes (L2, IPv6, IPv4, etc).
          3. Others?

I like #2 since it is optimized towards the most common use case.

With respect to encapsulation, I don’t understand how they could be different for different AFs unless they are, in fact, different RFC 7223 interfaces. Am I missing something?

Thanks,
Acee

From: Rob Shakir <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 21, 2015 at 9:58 AM
To: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, NETMOD WG <[email-masked]<mailto:[email-masked]>>, Routing YANG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] rib-data-model and routing-cfg

On 21 October 2015 at 07:52:43, Ladislav Lhotka ([email-masked]<mailto:[email-masked]>) wrote:
One option would be to create two virtual interfaces - one for IPv4 VPN and another for IPv6 VPN, and define routing-instance and addresses separately for each.

r.