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

[Martin Bjorklund <[e-mail]>]

"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?

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

> Additionally, we’d need a constraint that enforces the fact that both
> interface and address cannot be “unspecified”.

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


/martin



> 
> 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
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod