Jeff, I agree. On the previous thread no-one on NETMOD showed interest in a
common type, I should have CCed a few routing WGs...
Regards,Reshad.
On Thursday, January 6, 2022, 05:07:07 PM EST, Jeffrey Haas
<[email protected]> wrote:
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/
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]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod