Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Andy Bierman <[e-mail]>]

On Wed, Apr 27, 2022 at 11:04 AM Randy Presuhn <
[e-mail]> wrote:

> Hi -
>
> I think you've just made the argument for taking no action at all.
> I do think that argument is more persuasive than the ones advanced so
> far for changing deployed typedefs, and think the "no action" proposal
> would be a reasonable compromise.
>
>

I think some clarifications in the typedefs count as a change.

It does not appear that a zone index for IPv4 exists anywhere.
If it does then that reference should be added to the typedef.

Almost none of the points found during this email discussion are
documented in the YANG module (e.g, use-cases for ip-address-no-zone).

It seems that ip-address is enough, and represents all possible
variants of an IP address.   Users do not care about typedefs, only
the data nodes that use them.  If the leaf is implemented correctly,
then there is no problem with the typedef.  The "no action" proposal
acknowledges that the typedef pattern is not useful for validation
in all possible scenarios, and the server must insure that the value is
valid for the specific leaf or leaf-list.





> Randy
>

Andy


>
> On 2022-04-27 4:51 AM, Christian Hopps wrote:
> >
> > Speaking as someone who at one point worked for an operator trying to
> > use YANG to actuall configure a large network (services and devices),
> > and also having interacted with the openconfig folks over the years. I
> > find your perspective, if I understand it, that being too "loose" with
> > things will stop actual industry use, contradicts my experience.
> >
> > My experience is that users just want to get work done and don't
> > actually "give a crap" (they often used more colorful language :) about
> > things being 100% perfect when 95% gets the job done. I believe that
> > drove many of the choices that openconfig made in fact. It also drove
> > operators away from the netmod WG as people argued endlessly over things
> > like not changing a typedef to match the actual deployed real world
> > situation, b/c it's theoretically wrong even if it was operationally
> > correct.
> >
> > Personally I think a balance must be struck. I think openconfig went too
> > far down the "just do whatever works" path, and that IETF/netmod has
> > gotten better about being less about something that professors would
> > love, and more about something industry actually finds useful, today.
> >
> > I think Rob is trying to strike that balance (and has been for a while
> > now with his work in this area), and I support him.
> >
> > Thanks,
> > Chris.
> >
> >
> > Randy Presuhn <[e-mail]> writes:
> >
> >> Hi -
> >>
> >> If one accepts your arguments, you've made the case for defining
> >> a new module with typedefs for ipv6-address, etc. with modified
> >> syntax, semantics, and behavioral constraints to fit what has been
> >> deployed, and that modules requiring those perhaps more felicitously-
> >> named typdefs (because at its heart this kerfuffle is about the names)
> >> should import the definitions from there, rather than the existing
> >> module.
> >> That would seem the least disruptive path forward.
> >>
> >> But I get the feeling that you may envision a world of Yang / Netconf
> >> conformance testing that is far more rigorous than current reality,
> >> at least as reported by those actively involved in tool development.
> >> I'm no fan of the laissez-faire spirit of Netconf, but I fear that
> >> tugging a loose strings like this will unravel the whole wad of yarn,
> >> particularly if any expectations remain that it might support
> >> what has traditionally been called configuration management.  What
> >> happens when the next typedef is found that has been implemented
> >> in a manner not totally consistent with its definition?  This seems
> >> a really really really bad precedent to set.
> >>
> >> Randy
> >>
> >> On 2022-04-20 6:18 AM, Rob Wilton (rwilton) wrote:
> >>> 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 <[e-mail]> On Behalf Of Randy Presuhn
> >>>  > Sent: 15 April 2022 20:25
> >>>  > To: [e-mail]; [e-mail]
> >>>  > 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
> >>>  > [e-mail] <mailto:[e-mail]>
> >>>  > https://www.ietf.org/mailman/listinfo/netmod
> >>> <https://www.ietf.org/mailman/listinfo/netmod>
> >>>
> >>
> >> _______________________________________________
> >> Lsr mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/lsr
> >
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>