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. 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.";
}
…
}
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]
