Hi Andy, > On May 19, 2026, at 5:13 PM, Andy Bierman <[email protected]> wrote: > > > > On Tue, May 19, 2026 at 4:57 PM Jeffrey Haas <[email protected] > <mailto:[email protected]>> wrote: >> For some reason, some of the prior context didn't make it into the thread. >> >> https://github.com/mjethanandani/ietf-bgp-yang/issues/484 >> >> In the current YANG for the neighbor list, the key is the natural key for >> most BGP implementations, "remote-address". This covers the vast majority >> of use cases and is similar to what is done in the RFC 4273 MIB. >> >> The point discussed in prior mails from Maria is that her implementation >> doesn't key BGP peers in that fashion. In our original discussions, we were >> trying to figure out how we might accommodate alternate keys to satisfy the >> use case. >> >> Unfortunately, the key itself as a property of a list can't be deviated. >> So, that option is precluded. >> > > > Where does it say that in RFC 7950? > I think YANG supports this (and I know of some vendors using it) > > deviation /some/path { > deviate replace { > type union { > type inet: ip-address; > type string; > } > } > }
It does not. However, when I ask AI to analyze RFC 7950 on the question of whether a key can be deviated, it comes back with this analysis. RFC 7950 doesn't have a single explicit prose sentence saying "a key cannot be deviated." The restriction is derived implicitly from two places in the spec: Section 7.20.3.2 — The table of allowed deviate substatements does not include key: | config | | default | | mandatory | | max-elements | | min-elements | | must | | type | | unique | | units | Since key does not appear here, a deviation cannot add, replace, or delete the key property of a list. Section 14 (ABNF Grammar) — This is confirmed by the formal grammar, where key-stmt is absent from deviate-add-stmt, deviate-replace-stmt, and deviate-delete-stmt. As a secondary constraint, Section 7.20.3 closes with: "After applying all deviations announced by a server, in any order, the resulting data model MUST still be valid." This means that even targeting a key leaf via deviate not-supported (to suppress it) would be forbidden, since a list missing its key leaf is an invalid data model. For comparison, the only analogous explicit MUST NOT statements about key leaves in the RFC are: Section 7.20.2 (if-feature): "A leaf that is a list key MUST NOT have any 'if-feature' statements." Section 7.21.5 (when): "A leaf that is a list key MUST NOT have a 'when' statement.” There is no equivalent explicit sentence for deviations — it falls out of the grammar and substatement table in §7.20.3.2. > > The interoperability issues should be obvious. > How does the client know what the server accepts (besides ip-address)? > But an old client only sending ip-address should still work, so this is not a > big deal. Thanks for noting the interoperability concerns. Cheers. > > > Andy > >> The discussion, below, explored whether loosening up the type for >> "remote-address" dealt with the situation well enough. While there's some >> flexibility here, it also slightly complicates the semantic of that leaf: In >> config context, it might be whatever is permitted. In operational context, >> it'd return the remote IP address. IETF access protocols permit that so >> it's not out of the question as an answer. But to accommodate for it by >> default in the model, it'd require loosening the base type so much in the >> union that config validation for the common use case becomes very weak. >> >> The most recent observation by Maria is perhaps the simplest answer is to >> split the neighor list key from the remote-address node. By default, it >> could be a leafref (see the issue, above) to the remote-address preserving >> the common use case. Implementations that required additional flexibility >> could override the leaf for the key removing the leafref property and >> replacing it with the appropriate restricted type for that implementation. >> >> Mahesh had some concerns that the form documented in the issue may have >> implementation issues. It'd be good to get clarity whether the pattern in >> the github issue is a viable option. Similarly, examining options for the >> union below is good to get additional clarity on. >> >> Hopefully the BIRD implementers will help confirm this summary. >> >> -- Jeff >> >> >> >> On 5/19/26 19:36, Mahesh Jethanandani wrote: >>> Hi Acee, >>> >>> I had suggested something similar, with a few more guardrails, if not on >>> this thread, then on one of the other threads, but I was told that that was >>> not acceptable. >>> >>> It was something along these lines: >>> >>>> On Apr 18, 2026, at 11:01 AM, Mahesh Jethanandani >>>> <[email protected]> <mailto:[email protected]> wrote: >>>> >>>> An unrestricted string matches anything, including things that also match >>>> inet:ip-address. Union resolution in YANG is ordered — first match wins. >>>> So: >>>> >>>> If string comes before inet:ip-address in the union, it matches everything >>>> and inet:ip-address becomes unreachable. >>>> >>>> If string comes after inet:ip-address, it becomes a catch-all for non-IP >>>> values — which may actually be the intent (e.g., to allow hostnames or >>>> peer names). >>>> >>>> Consider: is "192.0.2.1" (matched as ipv4-address) the same key as >>>> "192.0.2.1" (matched as string)? The canonical form determines equality, >>>> and this could be implementation-dependent. >>>> >>>> But let us take the case that the goal is to allow hostnames alongside IP >>>> addresses. In that case one would use a pattern-restricted string in the >>>> union to avoid overlap: >>>> >>>> type union { >>>> type inet:ip-address; >>>> type string { >>>> pattern '[a-zA-Z][a-zA-Z0-9\-\.]*'; // hostname pattern, won't match >>>> bare IPs >>>> } >>>> } >>>> >>> >>> The point being, whatever forms part of the union has to be able to produce >>> a key that is not overlapping with any other member of union. >>> >>> Cheers. >>> >>>> On May 19, 2026, at 4:17 PM, Acee Lindem <[email protected]> >>>> <mailto:[email protected]> wrote: >>>> >>>> Mahesh - see better suggestion below. Problem solved... >>>> >>>>> On May 19, 2026, at 6:03 PM, Acee Lindem <[email protected]> >>>>> <mailto:[email protected]> wrote: >>>>> >>>>> Hi Mahesh, >>>>> >>>>>> On May 19, 2026, at 4:23 PM, Mahesh Jethanandani >>>>>> <[email protected]> <mailto:[email protected]> wrote: >>>>>> >>>>>> Directing this email to YANG Doctors and NETMOD. >>>>>> >>>>>> This is regarding an ask from the implementors of BIRD, who are trying >>>>>> to implement the IETF BGP YANG module. >>>>> >>>>> It's great that they'd be so brave. >>>>> >>>>> >>>>>> The question before us is, can a key be deviated? Currently, the module >>>>>> defines the list of neighbors as: >>>>>> >>>>>> list neighbor { >>>>>> key "remote-address"; >>>>>> description >>>>>> "List of BGP neighbors configured on the local system, >>>>>> uniquely identified by remote IPv[46] address."; >>>>>> >>>>>> leaf remote-address { >>>>>> type inet:ip-address; >>>>>> description >>>>>> "The remote IP address of this entry's BGP peer."; >>>>>> } >>>>> >>>>> Would "type union" with "net:ip-address" and "string" as the component >>>>> types meet the requirement? >>>> >>>> Actually, it would be even better to avoid the union of unions by >>>> flattening the remote-address type >>>> with component types "inet:ipv4-address", "inet:ipv6-address", and >>>> "string". I believe the problem >>>> is solved. Or, if you don't need the ever-popular zone specification, >>>> "inet:ipv4-address-no-zone" >>>> and "inet:ipv6-address-no-zone". >>>> >>>> Thanks, >>>> Acee >>>> >>>> >>>> >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> >>>>> >>>>> >>>>>> … >>>>>> } >>>>>> >>>>>> The key in this case is ‘remote-address’ and is of type ‘ip-address’. >>>>>> Implementations would like to use a different key, one that has a ’type >>>>>> string’, to allow for any string to be used. A couple of questions come >>>>>> to mind. >>>>>> >>>>>> - Does RFC 7950 permit a leafref key whose target leaf is itself >>>>>> deviated to a different type? >>>>>> - Is there a sanctioned pattern for "implementation-specific key" use >>>>>> cases, since this seems like a general need beyond just BGP. >>>>>> >>>>>> Note that this is an interoperability concern — this isn't just a >>>>>> syntactic question but a semantic one about what a BGP neighbor identity >>>>>> means. >>>>>> >>>>>> The response to some of the questions would suggest how we resolve the >>>>>> issue. One suggestion from Jeff has on what to do is below. Essentially, >>>>>> make the key a leafref, such that the leafref can be deviated. Are there >>>>>> conformance or interoperability implications of this approach that the >>>>>> WG should be aware of before adopting it? >>>>>> >>>>>> >>>>>>> On Apr 16, 2026, at 7:53 AM, Jeffrey Haas <[email protected]> >>>>>>> <mailto:[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>>> On Apr 11, 2026, at 13:27, Maria Matejka <[email protected]> >>>>>>>> <mailto:[email protected]> wrote: >>>>>>>> >>>>>>>> We can not deviate the key, at least nobody around Netmod was able to >>>>>>>> tell me how. We would have to deviate the whole neighbor list, and >>>>>>>> consequentially probably everything which leaf-refs that. Or, we could >>>>>>>> have deviated the remote-address, which works but brings other >>>>>>>> problems with the remote-address suddenly not being a remote-address, >>>>>>>> actually. >>>>>>>> What may work tho, is defining the neighbor key as a separate item >>>>>>>> which would by default be only the remote address, and that item could >>>>>>>> then be deviated / augmented much easier. >>>>>>>> container neighbors { >>>>>>>> list neighbor { >>>>>>>> key "neighbor-key"; >>>>>>>> leaf neighbor-key { >>>>>>>> type leafref { >>>>>>>> path "remote-address"; >>>>>>>> } >>>>>>>> } >>>>>>>> leaf remote-address { >>>>>>>> type inet:ip-address; >>>>>>>> } >>>>>>>> ... >>>>>>>> } >>>>>>>> ... >>>>>>>> } >>>>>> >>>>>> Thanks >>>>>> >>>>>> Mahesh Jethanandani >>>>>> [email protected] <mailto:[email protected]> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> netmod mailing list -- [email protected] <mailto:[email protected]> >>>>>> To unsubscribe send an email to [email protected] >>>>>> <mailto:[email protected]> >>> >>> Mahesh Jethanandani >>> [email protected] <mailto:[email protected]> >>> >>> >>> >>> >>> >>> >> _______________________________________________ >> yang-doctors mailing list -- [email protected] >> <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
