Subject: Re: [netmod] proposed change to ietf-routing

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 2 Mar 2016 17:45:42 +0000

Hi Lada, NETMOD WG members,

There are actually a number of changes that we would like to
see in the ietf-routing model:

- Remove routing-instances since ietf-routing since it will be
  “mounted” at different points in the device hierarchy dependent
  on the device requirements.

- Collapse it into one module supporting different address families
  rather 3 modules (base, IPv4, and IPv6).

- Remove the ND (RFC 4861) Router Advertisement protocol since it
  doesn’t need to be here.

- Support at least the next hop enhancements in
  https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00

- Include at least ECMP in the static route configuration.

- Structure consistent with the operational state recommendation.
  Even w/o having the final recommendation, this model seems to
  branch between config and state at way too high a level.

Thanks,
Acee

On 2/26/16, 8:36 AM, "netmod on behalf of Ladislav Lhotka"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi,
>
>as a part of synchronization of the routing data models that are being
>developed by the NETMOD and RTG working groups, the authors of
>draft-ietf-netmod-routing-cfg propose to remove the routing-instance
>level in the data hierarchy, and leave it to structural-mount/YSDL to
>provide a top level structure.
>
>Schematically, the configuration and state data subtrees of ietf-routing
>would be reduced to something like this:
>
>module: ietf-routing
>   +--ro routing-state
>   |  +--ro router-id?           yang:dotted-quad
>   |  +--ro interfaces
>   |  |  +--ro interface*   if:interface-state-ref
>   |  +--ro routing-protocols
>   |  |  +--ro routing-protocol* [type name]
>   |  |     ...
>   |  +--ro ribs
>   |     +--ro rib* [name]
>   |        ...
>   +--rw routing
>      +--rw router-id?           yang:dotted-quad
>      +--rw description?         string
>      +--rw routing-protocols
>      |  +--rw routing-protocol* [type name]
>      |     ...
>      +--rw ribs
>         +--rw rib* [name]
>	    ...
>
>Are there any objections to this change?
>
>Thanks,
>
>Acee and Lada
> 
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Mar 2016 08:37:21 +0100

Who is 'we'?

/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: Thu, 03 Mar 2016 14:01:40 +0100

>   on the device requirements.

Agreed.

>   rather 3 modules (base, IPv4, and IPv6).

This is possible, but we would have to introduce a mechanism for
implementations supporting only one of them. It seems to me that it is
easier to select modules for base + any combination of address families,
and each family module inserts appropriate stuff to right places - and
there is quite a bunch of them. What you are proposing probably means the
(single) module would have if-features or whens in all those places.

> - Remove the ND (RFC 4861) Router Advertisement protocol since it

Well, RFC 4861 says: "A router MUST allow for the following conceptual
variables to be configured by system management."

So I don't think they can be considered optional. We could perhaps move
them to a submodule so that they don't clutter the main module.

>   https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00

They can be added via augments, and many potential users of the routing
module (hosts and simple routers) don't support them.

> - Include at least ECMP in the static route configuration.

Same as in the previous case: ietf-routing provides a choice node for
next-hops in both RIBs and static routes, and ECMP is explicitly
mentioned as a candidate for augmentation. Why is it such a big a
problem?

>   branch between config and state at way too high a level.

Could you outline the concrete changes that you propose here? The most
significant part of state data in this module is the list of RIBs, and I
don't see any way how it can be bundled with configuration somewhere
deeper in the hierarchy.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 4 Mar 2016 01:48:09 +0000

Hi Lada, 

>(single) module would have if-features or whens in all those places.

Are there planned implementations required YANG models where only IPv4 or
IPv6 are supported? Maybe way off in the future, when you and I are both
sitting on a beach drinking beer there will be IPv6 only products but I
don’t see it happening soon.

>them to a submodule so that they don't clutter the main module.

I don’t disagree - but why are they grouped with the main RIB and infra
draft? Router Advertisement should be with the other RFC 4861 protocols.
It is out of place here.

>module (hosts and simple routers) don't support them.

Are there hosts that don’t support at least ECMP?

>mentioned as a candidate for augmentation. Why is it such a big a

It is not but as long as we are changing the model, we might as well
handle the predominant use cases.

>don't see any way how it can be bundled with configuration somewhere

I guess we will discuss this in upstate call next week. However, no matter
what solution we come up with, it seems keeping the derived state closer
to intended/applied config is better.

Thanks, 
Acee

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Mar 2016 11:24:17 +0100

> don’t see it happening soon.

I believe it is the right thing to do, from an architectural point of
view, to support IPv4 only, IPv6 only and dual-stacked implementations.
 
> to intended/applied config is better.

For some definition of 'closer' and 'better'...

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 04 Mar 2016 14:00:22 +0100

> don’t see it happening soon.

Maybe some experts in the embedded area could comment on this, but I
believe in both 6LoWPAN and ZigBee IPv6-only networks are commonplace.

> draft? Router Advertisement should be with the other RFC 4861 protocols.

The idea is that any device that implements ietf-routing is required to
support these configuration variables, which is what 4861 says. With a
mechanism like Andy's packages we would have more flexibility, but for
the time being the best solution seems to be to move RA stuff to a
submodule.

> Are there hosts that don’t support at least ECMP?

I am not sure. If there is consensus that ECMP is really ubiquitous,
then we can add it.

> handle the predominant use cases.

My concern is that other groups may come up with their favourite
cases. Any new stuff increases the likelihood that bugs or inadequacies
will be discovered in the module after it is published, but then it will
be a problem due to the draconian module update rules. So I'd prefer to
keep this module really skinny.

> to intended/applied config is better.

OK.

Lada

---

From: "Yingzhen Qu (yiqu)" <[email-masked]>
Date: Fri, 4 Mar 2016 19:22:52 +0000

Hi Lada,

For ECMP, we can actually define the next-hop as a list, so if there is
only one element in the list it¹s the simple next-hop case, and for ECMP
there are multiple elements in the list. RIB is more complete by adding
ECMP support.

Thanks,
Yingzhen

On 3/4/16, 5:00 AM, "netmod on behalf of Ladislav Lhotka"
<[email-masked] on behalf of [email-masked]> wrote:

>>>>   ³mounted² at different points in the device hierarchy dependent
>> don¹t see it happening soon.
>>
>
>>>>   doesn¹t need to be here.
>> I don¹t disagree - but why are they grouped with the main RIB and infra
>> Are there hosts that don¹t support at least ECMP?
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 4 Mar 2016 21:31:34 +0000

Hi Lada, 

>believe in both 6LoWPAN and ZigBee IPv6-only networks are commonplace.

Okay - I’ve also heard requirements from an SP for access devices with
only IPv6. However, is a separate module required for this?
ietf-yang-types has the type ip-address supporting both AFs. Does
supporting one or the other AF or both need to be enforced with separate
modules? For IPv4, we are going to need to support IPv6 next-hops (refer
to RFC 5549).  

>support these configuration variables, which is what 4861 says.

But it says nothing about the organization of the YANG modules ;^)

> With a

Why wouldn’t RA be in a separate draft with all the other RFC 4861
protocols?

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 07 Mar 2016 14:45:02 +0100

> only IPv6. However, is a separate module required for this?

An IPv6-only system should not have IPv4-related nodes in the schema. As
I wrote, alternatives are

(a) define features for individual address families
(b) include configuration of address families, and then use "when"
statements to control the schema.

We also have to consider other families that may be added, even some
that don't exist yet.

> But it says nothing about the organization of the YANG modules ;^)

No, but currently there is no way to say that if module X is implemented, then
module Y has to be implemented, too.

> Why wouldn’t RA be in a separate draft with all the other RFC 4861

It could, and we could hope that some mechanism will be established later for
specifying module dependencies and prerequisites. It's IMO needed
anyway.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Mar 2016 00:54:07 +0000

Hi Lada, 

>statements to control the schema.

We have the ip-address type that supports both… Couldn’t we use this type
and have the server simply return an error if a route is configured for an
unsupported address family? Should the ietf-yang-types module be
re-published with ip-address removed?

I guess don’t see this as a major point.

>We also have to consider other families that may be added, even some

Agreed. These can be added through augmentation.

>specifying module dependencies and prerequisites. It's IMO needed

ARP and ACLs are also needed anyway, that doesn’t mean they need to be
included in this draft.

Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Mar 2016 01:23:50 +0000

> On Mar 7, 2016, at 7:54 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hi Lada, 
> 

The thing about the static route definition for IPv4 and IPv6 is that their RIBs will have pretty much the same structure other than differences in address type. For other AFs, there may be other differences as well. For every augmentation, we’re essentially doubling the specification effort. 

Thanks,
Acee

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Mar 2016 07:47:19 +0100

> The thing about the static route definition for IPv4 and IPv6 is that their RIBs will have pretty much the same structure other than differences in address type. For other AFs, there may be other d…

One benefit of having separate augmentations is that the data types
are tighter. For example, the data model does not allow an IPv6 next
hop for an IPv4 prefix, i.e., you can't mess up address families since
the data model forces a clear separation (and generic validation will
catch that in contrast to having the runtime catching inconsistent
address family data).

How much that matters likely can be debated. But somehow it feels like
keeping things separate allows for independent evolution, which may
proof to be very handy in the future. I kind of liked Lada's approach
to maintain the architectural separation in the data model.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 08 Mar 2016 07:55:37 +0100 (CET)

> to maintain the architectural separation in the data model.

I agree.  I think the model is more clear this way.  I guess I don't
understand why Acee wants to have a single module?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 08 Mar 2016 08:36:48 +0100

> there are multiple elements in the list. RIB is more complete by adding

We already had ECMP nexthops in rev. 16 (look for "multipath-entry"):

https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16

They were removed along with other fancy next-hops in the interest of
finishing this data model soon/ever. I still think ECMP can be easily
added via augments, but if there is consensus that ECMP is really
ubiquitous, we can put that stuff back, perhaps conditionally using a
feature (as it was in rev. 16).

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Mar 2016 11:07:56 +0000

On 3/8/16, 1:47 AM, "[email-masked]"
<[email-masked]> wrote:

>> The thing about the static route definition for IPv4 and IPv6 is that
>>their RIBs will have pretty much the same structure other than
>>differences in address type. For other AFs, there may be other
>>differences as well. For every augmentation, we’re essentially doubling
>>the specification effort.
>>
>

Actually this is supported on the data center product that I work on (see
RFC 5549). However, I agree mixing AFs will not be the norm.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Mar 2016 11:08:55 +0000

>understand why Acee wants to have a single module?

I was trying to eliminate the effort of updating both modules with the
exact same augmentations. However, I guess I’m ready to relent on this
point. 

Thanks,
Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 8 Mar 2016 12:35:41 +0100

> On 08 Mar 2016, at 12:08, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> 

OK, thanks. Do we want to post another revision before IETF 95? If so, we should probably do most preparations this week because I will be on vacation next week.

Lada

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 8 Mar 2016 15:20:50 +0000

On 3/8/16, 6:35 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>OK, thanks. Do we want to post another revision before IETF 95? If so, we
>should probably do most preparations this week because I will be on
>vacation next week.

I think we should at least try and get the structural changes posted
before IETF 95. We can meet on next hops at IETF 95.

Thanks,
Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 8 Mar 2016 16:36:26 +0100

> On 08 Mar 2016, at 16:20, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> 

OK, so let's do it.

Thanks, Lada