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

[Martin Björklund <[e-mail]>]

Hi,

First of all, I agree that if we were to design this from scratch, I
think we should have a type for just an ip address, and use a second
leaf for the zone (or interface).

"Rob Wilton (rwilton)" <[e-mail]> wrote:
> Hi Martin,
> 
> I have several concerns with this approach:
> 
> (1) I still think that the ip-address type name still ends up being
> non-intuitive

Agreed.

> (especially for zoned IPv4 addresses - I would be
> surprised to find that there is any deployment for these at all).

Maybe, I have no idea.  What I *do* know is that lots of users
(probably most users) of YANG modules are not active in the IETF.

> I.e., the evidence seems to suggest that when engineers think of IP
> addresses, they don't seem to generally think of zoned IP addresses.
> I doubt that any fiddling of the type description is going to change
> that perception, not least when the definition is different for
> OpenConfig and in vendors models and ip-address is widely used in many
> published YANG models.
> 
> (2) It means that clients of YANG models using the ip-address type
> have no idea whether the server will support zones without either
> trying the configuration (which could subsequently become unsupported
> in the future) or requiring an out-of-band discussion with the device
> vendor.  For such as basic type this doesn't seem great.

But this is what we have had for 12 years, and from what I know we
haven't seen any real issues with this.

> (3) For IETF models, does that mean that new models should use
> ip-address-no-zone, and that we should change the approx. 200 usages
> in 40-50 published RFCs?  As mentioned previously, this doesn't seem
> pragmatic, or it will take the best part of a decade to happen.
> During that time the difference between ip-address ,
> ip-address-with-zone, and ip-address-no-zone will probably cause even
> further confusion due to the ambiguity, and differences in
> implementations.

No, the pragmatic solution I propose is to only change the description
of ip-address (and v4/v6) to match current implementations; i.e., make
it clear that an implementation doesn't have to support the optional
zone index.

Not ideal, but this is what is implemented and it seems to work.



/martin



> (4) For NMDA models, it means that clients could (but probably never
> will) receive zoned ip addresses back from <operational>.  Further, if
> zoned IP addresses are returned, then they are expected to use
> numerical IDs for the zones, which seem to be effectively opaque to
> the client (other than uniqueness).  Clients seem to have a few
> choices: ignore (error?) on zoned IP addresses, ignore the zone (does
> that make sense), or have additional code to handle a case that for
> 99% of users will probably never happen.  My point being that these is
> also a cost to keeping support for zones in the base ip-address types.
> 
> Regards,
> Rob
> 
> 
> 
> > -----Original Message-----
> > From: Martin Björklund <[e-mail]>
> > Sent: 12 April 2022 08:26
> > To: Rob Wilton (rwilton) <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [netmod] [Lsr] I-D Action:
> > draft-ietf-lsr-ospfv3-extended-lsa-yang-
> > 10.txt
> > 
> > Hi,
> > 
> > Here's another suggestion.  We keep the ip-address pattern as is, but
> > document in the description that implementations do not have to
> > support the optional zone index.  This would essentially document the
> > behavior of most current implementations.  (This is actually what I
> > suggested in the earliest thread on this topic that I could find:
> > https://mailarchive.ietf.org/arch/msg/netmod/KjHGtPqm9D4Q-
> > fRb2hVsf4sPuCU)
> > 
> > 
> > 
> > /martin
> > 
> > 
> > "Rob Wilton \(rwilton\)" <rwilton=[e-mail]> wrote:
> > > Hi all,
> > >
> > > Thanks for the comments on this thread so far.  It would be nice if we
> > > are
> > able to come to some sort of rough consensus to a solution.
> > >
> > > I think that there is consensus that the YANG type ip-address (and the
> > > v4/v6
> > versions) are badly named as the prominent default type name has been
> > given to the unusual variant of including zone information.
> > >
> > > Based on the comments on this thread, it also seems likely to me that
> > > most
> > of the usages of ip-address in YANG RFCs is likely to be wrong, and
> > the
> > intention was that IP addresses without zones was intended.  At a
> > rough
> > count, of the published RFC YANG models at github
> > YangModels/standard/ietf/RFC/ to be:
> > > 	86 uses of ip-address
> > > 	68 uses of ipv4-address
> > > 	66 uses of ipv6-address
> > >
> > > 	1 use of ip-address-no-zone
> > > 	4 uses of ipv4-address-no-zone
> > > 	4 uses of ipv6-address-no-zone
> > >
> > > These types appear in 49 out of the 141 YANG modules published in
> > > RFCs.
> > At a quick guess/check it looks like these 49 YANG modules may appear
> > in 40-
> > 50 RFCs.
> > >
> > > As mentioned previously, it is also worth comparing this to the
> > > OpenConfig
> > YANG modules:
> > > They have redefined ip-address (and v4/v6 variants) to exclude zone
> > information and have defined separate types include zone information.
> > > There are no explicit uses of the "-zoned" variants of OpenConfig IP
> > addresses in the latest OpenConfig github repository.  However,
> > approximately a third of the IP address types are still to the
> > ietf-inet-
> > types.yang rather than openconfig-inet-types.yang, so in theory some
> > of those
> > 58 entries could still intentionally be supporting zoned IP addresses,
> > but I
> > would expect that the vast majority would not.
> > > I do see some strong benefit if this basic type being defined in the
> > > same way
> > in both IETF and OC YANG, and I believe that the OC folks have got the
> > definition right.
> > >
> > > I see that some are arguing that the zone in the ip-address definition
> > > is
> > effectively optional, and implementations are not really obliged to
> > implement
> > it.  I don't find that argument compelling, at least not with the
> > current
> > definition of ip-address in RFC 6991.  I see a clear difference
> > between a type
> > defined with an incomplete regex that may allow some invalid values
> > and a
> > type that is explicitly defined to included additional values in the
> > allowable
> > value space.  Further, I believe that a client just looking at the
> > YANG module
> > could reasonably expect a server that implements a data node using ip-
> > address would be expected to support IP zones, where they are
> > meaningful,
> > or otherwise they should deviate that data node to indicate that they
> > don't
> > conform to the model.
> > >
> > > We also need to be realistic as to what implementations will do.  They
> > > are
> > not going to start writing code to support zones just because they are
> > in the
> > model.  They will mostly reject IP addresses with zone information.
> > Perhaps
> > some will deviate the type to ip-address-no-zone, but probably most
> > won't.
> > >
> > > The option of respinning approx. 40-50 RFCs to fix this doesn't feel
> > > at all
> > appealing.  This would take a significant amount of time/effort and I
> > think
> > that we will struggle to find folks who are willing to do this.
> > Although errata
> > could be used to point out the bug, then can't be used to fix it, all
> > the errata
> > would be "hold for document update" at best.  Further, during the time
> > that
> > it would take us to fix it, it is plausible that more incorrect usages
> > of ip-
> > address will likely occur (but perhaps could be policed via scripted
> > checks/warnings).
> > >
> > >
> > > I still feel the right long-term solution here is to get to a state
> > > where the "ip-
> > address" type means what 99% of people expect it to mean, i.e.,
> > excluding
> > zone information.
> > >
> > > Given the pushback on making a single non-backwards compatible change
> > to the new definition, I want to ask whether the following might be a
> > possible
> > path that gains wider consensus:
> > >
> > > (1) In RFC 6991 bis, I propose that we:
> > > (i) define new ip-address-with-zone types (and v4 and v6 versions) and
> > > keep
> > the -no-zone versions.
> > > (ii) we change the description of "ip-address" to indicate:
> > > - Although the type allows for zone information, many implementations
> > > - are
> > unlikely to accept zone information in most scenarios (i.e., so the
> > description
> > of the type more accurately reflects reality).
> > > - A new ip-address-with-zone type has been introduced to use where zoned
> > IP addresses are required/useful, and models that use ip-address with
> > the
> > intention of supporting zoned IP addresses MUST migrate to
> > ip-address-with-
> > zone.
> > > - In the future (at least 2 years after RFC 6991 bis is published), the
> > expectation is that the definition of ip-address will change to match
> > that of
> > ip-address-no-zone.
> > >
> > > (2) Then in 2 years time, we publish RFC 6991-bis-bis to change the
> > definition of ip-address to match ip-address-no-zone and deprecate the
> > "-no-
> > zone" version at the same time.
> > >
> > > My reasoning as to why to take this path is:
> > > (1) It is a phased migration, nothing breaks, 3rd parties have time to
> > migrate.
> > > (2) It ends up with the right definition (with the added bonus that it
> > > aligns
> > to the OC definition).
> > > (3) It doesn't require us republishing 40+ RFCs.
> > > (4) it hopefully allows us to use YANG versioning to flag this as an
> > > NBC
> > change, along with the other standards to help mitigate this change
> > (import
> > revision-or-derived, YANG packages, schema comparison).
> > >
> > > I would be keen to hear thoughts on whether this could be a workable
> > consensus solution - i.e., specifically, you would be able to live
> > with it.
> > >
> > > Regards,
> > > Rob
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: netmod <[e-mail]> On Behalf Of Randy Presuhn
> > > > Sent: 08 April 2022 18:59
> > > > To: Christian Hopps <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: Re: [netmod] [Lsr] I-D Action:
> > > > draft-ietf-lsr-ospfv3-extended-lsa-
> > > > yang-10.txt
> > > >
> > > > Hi -
> > > >
> > > > On 2022-04-08 5:11 AM, Christian Hopps wrote:
> > > > ..
> > > > > Instead, Acee (I'm not sure I'd call him WG B :) is asserting that
> > > > > *nobody* actually wanted the current type, and it has been misused
> > > > > everywhere and all over. The vast majority of implementations in
> > > > > operation probably can't even handle the actual type (Andy's
> > > > > point). So,
> > > > > Acee is just the messenger of bad news here. Please note that the AD
> > > > > in
> > > > > charge of all this agreed with Acee as well.
> > > >
> > > > That's not the impression one gets from modules like
> > > > https://www.ietf.org/archive/id/draft-ietf-mpls-mldp-yang-10.txt
> > > > which employs both types.  So, regardless of whether one is willing
> > > > to respect YANG's compatibility rules, it's no longer a matter of
> > > > speculation whether a name change would cause actual damage -
> > > > it clearly would.  Furthermore, my recollection is that the
> > > > WG *did* discuss whether the "zonable" property was needed, so
> > > > any argument based on the assertion that "*nobody* actually
> > > > wanted the current type" seems to me to based on a false premise.
> > > >
> > > > Randy
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod