Subject: Re: [netmod] "A YANG Data Model for Routing Management" Modifications

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 28 May 2016 18:21:36 +0200

On Sat, May 28, 2016 at 02:17:27PM +0000, Acee Lindem (acee) wrote:
> 
> 
> On 5/28/16, 9:31 AM, "Juergen Schoenwaelder"
> <[email-masked]> wrote:
> 
> >On Fri, May 27, 2016 at 09:14:23PM +0000, Acee Lindem (acee) wrote:
> >> Hi Lada, Juergen,
> >> 
> >> On 5/27/16, 1:26 PM, "Juergen Schoenwaelder"
> >> <[email-masked]> wrote:
> >> 
> >> >On Fri, May 27, 2016 at 11:42:08AM +0200, Ladislav Lhotka wrote:
> >> >> Hi Acee,
> >> >> 
> >> >> I have a couple of questions:
> >> >> 
> >> >> 1. I changed "routing-protocol" -> "control-plane-protocol" (this is
> >> >>    already in GitHub). As for identities, I introduced a new base
> >> >>    identity "control-plane-protocol", and derived "routing-protocol"
> >> >>    from it. So the idea is that routing protocols will still use
> >> >>    "routing-protocol" as their base. Is it OK?
> >> 
> >> We would like to have a single list rather than multiple lists. By
> >> generalizing “control-plane-protocols” we have one list per device, LNE,
> >> or NI. That is the goal.
> >> 
> >> >>
> >> >
> >> >So what is a routing protocol and what is a control plane protocol?
> >> 
> >> A routing protocol is a RIB client. A control plane protocol is more
> >> general.
> >
> >A RIB client?
> 
> A protocol that installs routes in one of the AF RIBs.
> 
> 
> > 
> >> >Or
> >> >what turns a control plane protocol into a routing protocol? Will this
> >> >distinction make network management simpler?
> >> 
> >> It will give us a place to put control plane protocols.
> >>
> >
> >I do not see yet why this is the scope of this effort. Perhaps I do not
> >understand what is proposed here:
> >
> >a) a change of the identity routing-protocol
> >
> >b) a change of the container routing-protocols
> >
> >c) a change of the list routing-protocol
> 
> 
> d) All of the above
>

Then this does not make sense to me. You apparently propose to
change

   +--rw routing
   |  +--rw router-id?
   |  +--rw routing-protocols
   |  +--rw routing-protocol* [type name]
   |
   |
   +--rw ribs
      +--rw rib* [name]

to

   +--rw routing
   |  +--rw router-id?
   |  +--rw control-plane-protocols
   |  +--rw control-plane-protocol* [type name]
   |
   |
   +--rw ribs
      +--rw rib* [name]

and I think this is wrong since there are control plane protocols that
have nothing to do with routing and I also do not think the WG is
chartered to provide a model or infrastructure for arbitrary
control-plane data models. Perhaps you propose something else but then
please make it clear what is expected to be changed so that I can
understand.

/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: Mon, 30 May 2016 14:51:21 +0200

"Yingzhen Qu (yiqu)" <[email-masked]> writes:

> Hi Lada,
>
> The ³multi-next-hop² is using the combination of interface and address as
> the list key. I know key can¹t be empty, but for next hop it¹s possible
> that only either interface or address is used. I¹ve been trying to figure
> out a better way to present this, any suggestion?

Optional list keys were proposed for YANG 1.1:

https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-10

The reason that the issue Y09 was eventually rejected was that many
people thought it was a relatively far-reaching change. This means we
are left with the same options as in YANG 1.0, none of them being very
pretty:

- Add a dummy opaque key, e.g.

  list next-hop-entries {
    key id;
    leaf id {
      type uint16;
    }
    unique interface address;
    ...
  }

- Use special value, such as empty string, to indicate that either
  interface or address isn't present. But since inet:ipv[46]-address
  cannot be empty, we would need to define the type of "address" as a
  union of empty string and inet:ipv[46]-address.

Lada

>
> If there is anything I can help with the modification, please let me know.
>
> Thanks,
> Yingzhen
>
> On 5/27/16, 4:14 AM, "Acee Lindem (acee)" <[email-masked]> wrote:
>
>>Hi Lada, 
>>
>>On 5/27/16, 5:42 AM, "Ladislav Lhotka" <[email-masked]> wrote:
>>
>>>Hi Acee,
>>>
>>Yes - as long as there is a single list. I¹ll pull the source today.
>>
>>>
>>>2. We could define identities for route types but I am still not
>>>   convinced that route-type should be added to ietf-routing because
>>>   then we can't limit the set of types for each protocol, so that, for
>>>   example, OSPF routes could carry IS-IS Level [12] routes.
>>
>>Do you mean that OSPF would install the wrong type of route? I would see
>>this as a bug but not something the model itself should enforce.
>>
>>Note that OSPF can ³carry² any type of route if it is imported into OSPF
>>and advertised as an AS External route.
>>
>>>
>>>3. The "multi-next-hop" case in rib-extend-01 uses interface and address
>>>   as keys. This means that for every next-hop *both* parameters have to
>>>   be given. Is it really intended?
>>
>>No - either or both must be specified but both are not required. I¹ll
>>leave this to you YANG experts.
>>
>>Thanks,
>>Acee
>>
>>
>>
>>>
>>>Thanks, Lada
>>>
>>>"Acee Lindem (acee)" <[email-masked]> writes:
>>>
>>>> Hi Lada, 
>>>>
>>>>
>>>> On 5/23/16, 8:30 AM, "Ladislav Lhotka" <[email-masked]> wrote:
>>>>
>>>>>"Acee Lindem (acee)" <[email-masked]> writes:
>>>>>
>>>>>> Hi Lada, 
>>>>>>
>>>>>> I thought I go through the impetus for the changes I discussed in my
>>>>>>last
>>>>>> E-mail. I believe we should make these changes and then freeze the
>>>>>> specification other than possible modifications based on the
>>>>>>consensus
>>>>>>for
>>>>>> the NETMOD operational state direction.
>>>>>
>>>>>I agree.
>>>>>
>>>>>>
>>>>>> The request to merge draft
>>>>>> https://www.ietf.org/id/draft-acee-rtgwg-yang-rib-extend-01.txt is
>>>>>>based
>>>>>> on the comments we received in the RTG WG meeting at IETF 95. The
>>>>>> consensus in the room was that the proposed next-hop additions were
>>>>>>pretty
>>>>>> standard in a networking device supporting routing. We were careful
>>>>>>not
>>>>>>to
>>>>>> include any MPLS or other tunneling technologies. If you feel that
>>>>>>some
>>>>>>of
>>>>>> these are not applicable to hosts, we could make them features.
>>>>>
>>>>>I don't think that many home routers support these features either
>>>>>(except ECMP). I still think they should be added as augments, and, as
>>>>>you know, ietf-routing was previously modified to enable it. Another
>>>>>advantage of doing so is that it will be more future-proof: it will be
>>>>>easier to replace their definitions with something else, which may be
>>>>>impossible if they are an integral part of ietf-routing, because of the
>>>>>rigid rules for updating published YANG modules.
>>>>
>>>> Lou and I had a lengthy discussion on this and we agreed that the base
>>>> should support ECMP and a metric per-path (like Linux).
>>>>
>>>> I also think we could route-type and tag to the operational state as
>>>>long
>>>> as they have default value of ³unspecified² and ³none² respectively.
>>>>This
>>>> would address the E-mail Helen Chen sent to NETMOD today.
>>>>
>>>> As for configuration of the tag and the backup path, we can keep these
>>>>as
>>>> augmentations. 
>>>>
>>>>>
>>>>>>
>>>>>> The request to change the name of routing-protocols to
>>>>>> control-plane-protocols is in support of
>>>>>> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-04.txt.
>>>>>>This
>>>>>> informative model was always had a control-plane-protocols list. If
>>>>>>we
>>>>>> don¹t put a standards-based control-plane-protocols list here, we
>>>>>>will
>>>>>> need to have one list for routing-protocols (i.e., RIB clients) and
>>>>>> another list for non-RIB clients. While the name is somewhat more
>>>>>>general
>>>>>> than the scope of routing-cfg, it seems like a very good trade-off to
>>>>>>put
>>>>>> it here rather than have two lists and have to move protocols between
>>>>>> lists if they suddenly add a capability that allows the protocol to
>>>>>>modify
>>>>>> the RIB.
>>>>>
>>>>>I don't mind changing the name, but I was a bit concerned that this may
>>>>>induce other changes, e.g. in the definition of RIBs. Lou already told
>>>>>me it was not the case, so we can change the name.
>>>>
>>>>
>>>> Great. 
>>>>
>>>> Thanks,
>>>> Acee 
>>>>
>>>>
>>>>>
>>>>>Lada
>>>>>
>>>>>>
>>>>>> If you are amenable to these modifications, we can confirm them on
>>>>>>the
>>>>>> NETMOD list. 
>>>>>>
>>>>>> Thanks,
>>>>>> Acee 
>>>>>>
>>>>>
>>>>>-- 
>>>>>Ladislav Lhotka, CZ.NIC Labs
>>>>>PGP Key ID: E74E8C0C
>>>>
>>>
>>>-- 
>>>Ladislav Lhotka, CZ.NIC Labs
>>>PGP Key ID: E74E8C0C
>>
>

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 31 May 2016 20:29:16 +0000

Hi Lada, 
If we can’t get YANG to do what we need, can we just support a choice with
a special value of “unspecified” for the interface and address?
Additionally, we’d need a constraint that enforces the fact that both
interface and address cannot be “unspecified”.

Thanks,
Acee

---

From: "Yingzhen Qu (yiqu)" <[email-masked]>
Date: Tue, 31 May 2016 20:56:01 +0000

Since “multi-next-hop” is a list and we need a key for a list, even choice
doesn’t work here. I’m thinking maybe we can use “0.0.0.0” for empty ip
address and “NULL” for empty interface, but it doesn’t look pretty anyway.
Especially the interface should be a reference, and it can’t be “NULL”.

Thanks,
Yingzhen

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 31 May 2016 23:02:41 +0200 (CEST)

> a special value of “unspecified” for the interface and address?

Yes, you can make these keys be unions of interface-ref and an enum
'unspecified', and an ip-address and enum 'unspecified'.

> interface and address cannot be “unspecified”.

   must 'key1 != "unspecified" or key2 != "unspecified"';

/martin

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jun 2016 08:39:18 +0200

>    must 'key1 != "unspecified" or key2 != "unspecified"';

Does this not mean you can't have an interface named 'unspecified'
anymore? Perhaps we should have disallowed zero-length string values
for /interfaces/interface/name and then we would have a handy value
to be used in situations like this?

/js