On Tue, May 19, 2026 at 5:56 PM Mahesh Jethanandani <[email protected]> wrote:
> 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]> 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. > > I am not suggesting that the key-stmt be changed. In module example-bgp-dev.yang (for the server implementation) deviation /path/to/neighbor/remote-address { deviate replace { type union { type inet_ip-address; type string; } } The type of the leaf is changed, not the key to the list. Andy 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."; > } > > > 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]> <[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]> >> <[email protected]> wrote: >> >> Mahesh - see better suggestion below. Problem solved... >> >> On May 19, 2026, at 6:03 PM, Acee Lindem <[email protected]> >> <[email protected]> wrote: >> >> Hi Mahesh, >> >> On May 19, 2026, at 4:23 PM, Mahesh Jethanandani >> <[email protected]> <[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]> >> <[email protected]> wrote: >> >> >> On Apr 11, 2026, at 13:27, Maria Matejka <[email protected]> >> <[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] >> >> >> >> >> >> >> _______________________________________________ >> netmod mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> >> >> Mahesh Jethanandani >> [email protected] >> >> >> >> >> >> >> _______________________________________________ >> yang-doctors mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > > > Mahesh Jethanandani > [email protected] > > > > > > >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
