Reshad, Thanks for drawing my attention to this older thread.
It seems the method for addressing the need is understood. I guess my request is to urge Jürgen and the WG to reconsider its avoidance of providing us a common type. Not having multiple people reinvent this particular thing each time seems productive. -- Jeff > On Jan 6, 2022, at 5:02 PM, Reshad Rahman <[email protected]> wrote: > > Jeff, this was brought up a few months ago (see Juergen's response): > https://mailarchive.ietf.org/arch/msg/netmod/cRmDwqarkW2fNc2nS25zrkycQWs/ > <https://mailarchive.ietf.org/arch/msg/netmod/cRmDwqarkW2fNc2nS25zrkycQWs/> > > > > > On Thursday, January 6, 2022, 04:54:22 PM EST, Jeffrey Haas <[email protected]> > wrote: > > > Mahesh suggested I send this suggestion here. > > Several IPv6 routing protocols have circumstances where the only acceptable > address is an ipv6 link-local address. > > The YANG type we have for ipv6 can accommodate ipv6 link local addresses, > however it's overly permissive for some use cases. > > Has the Working Group considered adding a typedef for ipv6 link-local? > > FWIW, the current use case under consideration is operational state for BGP > IPv6 routes conforming to RFC 2545 and related work under consideration in > IDR for link-local only BGP peering. In such circumstances, the BGP nexthop > will contain a component that may only be ipv6 link-local. > > For the BGP YANG module, the edits under consideration will currently use the > ipv6 type. Since the current use case is operational only state, the lack of > the more restrictive type is not considered a blocker. For the future > link-local-only work, configuration state will be needed. > > -- Jeff > > _______________________________________________ > netmod mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
