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

[Ladislav Lhotka <[e-mail]>]

"Yingzhen Qu (yiqu)" <[e-mail]> 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)" <[e-mail]> wrote:
>
>>Hi Lada, 
>>
>>On 5/27/16, 5:42 AM, "Ladislav Lhotka" <[e-mail]> 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?
>>
>>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)" <[e-mail]> writes:
>>>
>>>> Hi Lada, 
>>>>
>>>>
>>>> On 5/23/16, 8:30 AM, "Ladislav Lhotka" <[e-mail]> wrote:
>>>>
>>>>>"Acee Lindem (acee)" <[e-mail]> 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