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" <lho...@nic.cz> wrote: >"Yingzhen Qu (yiqu)" <y...@cisco.com> 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)" <a...@cisco.com> wrote: >> >>>Hi Lada, >>> >>>On 5/27/16, 5:42 AM, "Ladislav Lhotka" <lho...@nic.cz> 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)" <a...@cisco.com> writes: >>>> >>>>> Hi Lada, >>>>> >>>>> >>>>> On 5/23/16, 8:30 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote: >>>>> >>>>>>"Acee Lindem (acee)" <a...@cisco.com> 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
