Re: [netmod] IP address zones in YANG

[tom petch <[e-mail]>]

________________________________________
From: Lsr <[e-mail]> on behalf of Rob Wilton (rwilton) <rwilton=[e-mail]>
Sent: 14 April 2022 13:40
To: [e-mail]
Cc: [e-mail]
Subject: [Lsr] IP address zones in YANG

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?

<tp>

Yes.

See RFC4007.

My take is that there is always a zone associated with an IPv6 address but that it may be omitted when it is the default, which it usually is for global scope addresses.  For link local, it may not be since some link local addresses appear on all links   - e.g. FE80::1 - so when a node has multiple interfaces - the norm for me in datacentres- and the application needs to send a packet over the correct interface - e.g. so that it has the right link layer address to be acceptable to the recipient - then the application, whatever that is that invokes the sending of a packet, must use the correct zone to identify the correct interface.

With only one interface, then it is unlikely to be a concern.  With global scope addresses, it is unlikely to be a concern.  With link local, I always stop and think about zones - IPv6 101!

In passing, I note that VRRP requires a link local address with IPv6; I am wondering if it requires zones in the YANG.

I was unaware of the existence of zones with IPv4 until I came across them in the YANG types but that is my ignorance - they were always there1!

Tom Petch


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