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