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

["Acee Lindem (acee)" <[e-mail]>]

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