Spinning off part of the discussion into a separate thread, but keeping lsr
cc'ed on the discussion.
I'm trying to get a better understand of how and where zoned IP addresses
should be used in YANG data models.
RFC 4007 defines zones for IPv6 addresses, but not for IPv4. Even though RFC
6991 bis has support for a zoned IPv4 address, I'm struggling to see where
zoned IPv4 addresses would ever really be used. Does anyone know of any usage
or deployments anywhere?
For IPv6, my understanding is that the use of the zone is to add the extra
interface context for IPv6 link-local addresses. Is there any use of zones
outside of this interface context?
The current definition of ipv6-address type and the ip-address nodes in
ietf-ip.yang seem to make zoned IP addresses hard to use. The canonical zone
definition in RFC 6991 is for an (presumably unique) numeric zone identifier,
but in the YANG management layer it is unclear to me how one maps from this
numeric id back to the interface name (e.g., for a client to construct a
suitable zoned IP address in configuration). ietf-ip.yang uses
ipv6-address-no-zone for interface IP addresses so it isn't possible to get the
zone id associated with the link local address. This feels underspecified to
me to tie these together and make this work robustly.
I also have a general question about what is the best way of modelling this in
YANG. Using a zoned ip address is one choice to link an IP address and
interface together. Another choice is to have a separate leaf to scope an IP
address to a specific interface, wherever that is appropriate and required.
E.g., considering the IP RIB YANG model,
| | +--rw v6ur:ipv6
| | +--rw v6ur:route* [destination-prefix]
| | +--rw v6ur:destination-prefix
| | | inet:ipv6-prefix
| | +--rw v6ur:description? string
| | +--rw v6ur:next-hop
| | +--rw (v6ur:next-hop-options)
| | +--:(v6ur:simple-next-hop)
| | | +--rw v6ur:outgoing-interface?
| | | | if:interface-ref
| | | +--rw v6ur:next-hop-address?
| | | inet:ipv6-address
Given that an outgoing-interface is already provided then it seems that using a
zoned IP address as a next hop address here would potentially be confusing, or
at least not required because it is effectively already scoped to the
outgoing-interface anyway? It seems like it provides redundant information.
Considering another arbitrary protocol YANG module RFC, this time TWAMP, rfc
8913, it seems that some of the ip-address fields in the model could in theory
support link local addresses (e.g., the test-session ones), but it is unclear
to me whether that was ever the intent, or whether that even makes sense. For
the other uses of IP addresses that identify a client or server, it feels like
using link local addresses is much less compelling. Modelling these all with
the same type seems confusing.
| +--rw test-session-request* [name]
| +--rw name string
| +--rw sender-ip? inet:ip-address
| +--rw sender-udp-port? union
| +--rw reflector-ip inet:ip-address
| +--rw reflector-udp-port? inet:port-number
| +--rw timeout? uint64
| +--rw padding-length? uint32
| +--rw test-packet-dscp? inet:dscp
| +--rw start-time? uint64
| +--rw repeat? uint32
| +--rw repeat-interval? uint32
| +--rw pm-reg-list* [pm-index]
| | +--rw pm-index uint16
| +--ro state? test-session-state
| +--ro sid? string
E.g., I guess that you could use a zoned IP address for the reflector-ip, but I
suspect that most implementations would not anticipate/support this. It feels
to me that a cleaner way of modelling this would be to not use a zoned IP
address type at all and have a separate egress-interface if:-interface-ref
(perhaps under an if-feature, to enable and indicate support for test sessions
over link-local addresses).
My overriding concern here, if we don't change/fix the ip-address type, is that
we will end up with a set of YANG models that:
1. Models this behaviour in different ways for different protocols/features.
2. Are entirely ambiguous to clients and implementations as to whether it
makes sense to support zoned IP addresses and/or whether zoned link-local
addresses are supported for each leaf.
3. We are creating models for a hypothetical use case rather than how these
protocols are actually being deployed/implemented today. I.e., I am more
concerned about getting IETF YANG modules usable for the 99% use case than the
1% use case.
Regards,
Rob
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
