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.
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]> 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]> wrote:
Mahesh - see better suggestion below. Problem solved...
On May 19, 2026, at 6:03 PM, Acee Lindem <[email protected]> wrote:
Hi Mahesh,
On May 19, 2026, at 4:23 PM, Mahesh Jethanandani
<[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]> wrote:
On Apr 11, 2026, at 13:27, Maria Matejka <[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]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
