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; } } } 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. 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] >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
