Re: [netconf] draft-ietf-netconf-udp-notif :: transport source IP/interface/VRF

Hi Ebben,

Yes, I was talking about UDP because I was co-authoring the UDP ones.

In the TCP groupings, VRFs were decided to be out of scope of the documents (for simplicity) and during the NETCONF WG meeting, we had the same feedback for the UDP groupings.

Regarding configuring the transport for YANG-Push (UDP-notif and HTTPS-notif), both transports don’t support VRFs at the transport level, however, both transports augment the subscribed-notifications YANG module which supports VRFs on a subscription basis (https://www.rfc-editor.org/rfc/rfc8639#section-3.3):

     +--rw subscriptions
        +--rw subscription* [id]
           +--rw id
           |       subscription-id
	   ...
           +--rw (notification-message-origin)? {configured}?
           |  +--:(interface-originated)
           |  |  +--rw source-interface?
           |  |          if:interface-ref {interface-designation}?
           |  +--:(address-originated)
           |     +--rw source-vrf?
           |     |       -> /ni:network-instances/network-instance/name
           |     |       {supports-vrf}?
           |     +--rw source-address?
           |             inet:ip-address-no-zone

From this, I understand that we can set the VRF from which the Notification is generated on a subscription level.

Regards,
Alex

> On 20 Mar 2024, at 11:45, Ebben Aries <exa@juniper.net> wrote:
> 
> Thx Alex
> 
> Note, this is not unique to UDP but on a system w/ many interfaces and
> potential VRF mappings, the ability to "pin" a source becomes more
> important.
> 
> Unless such a construct/grouping is already nested underneath a
> VRF/network-instance, an IP address by itself is insufficient for both
> source + destination
> 
> default: eth0/10.1.1.1
> default: lo0/192.168.1.1
> network-instance (1): eth1/10.1.1.1
> network-instance (1): lo1/192.168.1.1
> network-instance (2): eth2/10.1.1.1
> network-instance (2): lo2/192.168.1.1
> 
> Could have any source/destination combination/overlap inter/intra-NI
> that needs to be distinguished
> 
> On 2024-03-20 11:24:26, Alex Huang Feng wrote:
>> [External Email. Be cautious of content]
>> 
>> 
>> Hi Ebben,
>> 
>> Thanks for reaching out.
>> That’s a good point.
>> We can add the local-address (and local-port) in the UDP-notif model so that the operator can configure it optionally.
>> 
>> I will also add this local-address and local-port in the generic udp-client-grouping (draft-ietf-netconf-udp-client-server).
>> 
>> Regards,
>> Alex
>> 
>>> On 19 Mar 2024, at 13:42, Ebben Aries <exa=40juniper.net@dmarc.ietf.org> wrote:
>>> 
>>> Section 3.2 states
>>> 
>>> ---
>>> If Message Publisher ID unicity is not preserved through the
>>> collection domain, the source IP address of the UDP datagram SHOULD be
>>> used in addition to the Message Publisher ID to identify the
>>> information source.
>>> ---
>>> 
>>> It seems for configured "dial-out" transports, we are missing a
>>> definition of the source IP or interface (the latter of which would need
>>> a selection mechanism, prior a VRF reference) which is crucial for
>>> receivers to distinguish (generally an identity that is stable - e.g.
>>> loopback) sources.
>>> 
>>> I've only briefed through this draft and not other transports so this
>>> may very well apply to others as well
>>> 
>>> _______________________________________________
>>> netconf mailing list
>>> netconf@ietf.org
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netconf__;!!NEt6yMaO-gk!Fd_LCibn6pzPiClNoiJ7Sc-VkEdRqQLMWKguMOMhOxdlp7IMLxGVbBN3XKj3aICsuokIOXnHZt9e8XMnBCie-aDmJCHu$