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

[Randy Presuhn <[e-mail]>]

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.

Randy

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
>