Hi Randy,
Thanks for summarizing, but I don't really agree with your categorization for
(1) or (3).
My interpretation of ip-address and the related v4/v6 types, based on RFC 7950,
is that implementations MUST allow clients to configure zoned IP addresses to
be fully complaint with the module definition. If a server implementation does
not support zoned ip-addresses then it is expected to use a deviation (e.g., to
replace the type with ip-address-no-zone) to indicate how it does not conform
to the model. I don't see that is being any different than an integer datatype
with a range "1..255" and the server only supporting the client configuring
values in the range "1..100".
The "may include a zone index" in the ip-address definitions relates to the
client when writing a value (or server when returning a value), i.e., they
don't have to always provide zones for all IP addresses. They can leave them
out, and when the zone is left out the "default zone of the device will be
used".
E.g., considering the RFC 6991 and the IP RIB YANG model,
typedef ipv6-address {
type string {
pattern '...'
}
description
"The ipv6-address type represents an IPv6 address in full,
mixed, shortened, and shortened-mixed notation. The IPv6
address may include a zone index, separated by a % sign.
The zone index is used to disambiguate identical address
values. For link-local addresses, the zone index will
typically be the interface index number or the name of an
interface. If the zone index is not present, the default
zone of the device will be used.
The canonical format of IPv6 addresses uses the textual
representation defined in Section 4 of RFC
5952<https://www.rfc-editor.org/rfc/rfc5952#section-4>. The
canonical format for the zone index is the numerical
format as described in Section 11.2 of RFC
4007<https://www.rfc-editor.org/rfc/rfc4007#section-11.2>.";
| | +--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
So, considering the model above, if a link local IP address was provided as the
next-hop-address without a zone, then according to the type definition, that
link-local IP address is associated with the default zone of the device, not
the "outgoing interface" for the next hop! If a zone is returned with a
link-local address (e.g., for a get request) then my expectation is that
servers return the data using the "interface index number" (since that is the
canonical form, this should be returned even if it was configured using an
interface name to identify the zone). Further, as far as I can tell,
"interface index number" isn't really well specified in a YANG management API
and is probably far less meaningful that the interface name in a YANG context.
I presume that this is if-index in RFC 8343 but that doesn't need to be
supported if the server doesn't also support SNMP's if-mib.
I suspect that the reason why ip-address (and the v4/v6) variants haven't
caused any problems in practice is because implementations are mostly wrongly
treating them as ip-address-no-zone, and assuming that the scope information is
being provided by other context (e.g., outgoing-interface in the example
above), or perhaps most operators just configure their devices using global IP
addresses.
Some further comments inline ...
> -----Original Message-----
> From: netmod <netmod-boun...@ietf.org> On Behalf Of Randy Presuhn
> Sent: 15 April 2022 20:25
> To: l...@ietf.org; netmod@ietf.org
> Subject: Re: [netmod] [Lsr] I-D Action:
> draft-ietf-lsr-ospfv3-extended-lsa-yang-
> 10.txt
>
> Hi -
>
> I took a fresh look at RFC 6991, and a couple of things that have
> already been mentioned in this thread bear repetition.
>
> (1) in both the ipv4-address and ipv6-address typdefs, the zone
> is only optionally present. This is made clear both in the
> string patterns as well as the descriptions, which state that
> it "may" be present, and clearly specify how its absence is
> to be understood. Thus it's no surprise that their use has not
> caused any problems. If the definitions go unchanged, there's
> no demonstrated need for any of the existing uses of these typedefs
> to be revised to employ something else, even if other typedefs
> are available that are more precisely targeted.
>
> (2) since both the ipv4-address and ipv6-address typdefs are
> used in the ip-address typedef, which is in turn used in the
> host typedef, any proposal changing the syntax or semantics
> of ipv4-address or ipv6-address needs to deal with the potential
> collateral damage to any module (IETF or otherwise) employing
> ip-address or host.
>
> (3) since the proposed change is to narrow the syntax / semantics
> of a typedef (along with any other typdefs that directly or indirectly
> incorporate that typedef), the consequence for interoperability is
> that some values go from "MAY reject" (such is the nature of Netconf
> servers - well-formedness is not sufficient to guarantee that a server
> will accept an attempt to apply a particular value to a configuration)
> to "MUST reject" (due to the narrowed pattern and description). This is
> where stuff breaks.
I agree that a NETCONF server might reject any config change but rejecting a
zoned IP address provided in an ip-address type still means that the server is
violating the data model. Further, assuming that a link-local IP address
without a zone is associated with an interface rather than the device's default
zone is violating the data model.
>
> (4) since ipv4-address-no-zone is derived from ipv4-address (by
> narrowing the pattern), and ipv6-address-no-zone is likewise
> derived from ipv6-address, the proposed change will also require
> these typedefs to be changed, which will in turn bubble up to
> ip-address-no-zone.
>
> It still makes no sense to me to engage in making such wide-ranging
> changes affecting both specifications and implementations with a real
> risk to interoperability in order to "fix" a non-problem.
As far as I can see it, interoperability is already broken:
* Clients don't really know whether a server is implementing "ip-address"
as the RFC 6991 definition or using the definition of "ip-address-no-zone", and
potentially this could vary for different leaves.
* If servers do support zones then returning the interface index as the
canonical representation of the zone, rather than the interface name, seems
wrong/unhelpful.
* If servers do support clients configuring link-local addresses without a
zone then I suspect that most of them would default to the local interface
scope (presuming the scope is provided/available) and not the "default zone of
the device".
* IETF YANG models widely use ip-address when in many/most cases they
probably mean ip-address-no-zone.
OpenConfig recognized that the based definitions were wrong (i.e., not
intuitive) and fixed them. If we have no way of fixing similar issues in IETF
YANG models and improving them over time then I don't think that leaves us in a
good place.
Regards,
Rob
>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
