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

["Yingzhen Qu (yiqu)" <[e-mail]>]

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

On 5/31/16, 1:29 PM, "Acee Lindem (acee)" <[e-mail]> wrote:

>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 
>
>On 5/30/16, 8:51 AM, "Ladislav Lhotka" <[e-mail]> wrote:
>
>>"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
>