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