Re: [netconf] New Version Notification for draft-zhou-netconf-multi-stream-originators-06.txt

["Eric Voit (evoit)" <[e-mail]>]

From: Kent Watsen, July 15, 2019 12:34 PM



[CC-ing Eric due to urgent SN issue]





Hi Tianran,



Hmmm, my guess is that pretty much all transports supporting configured 
subscriptions will have the server (i.e., line cards) proactively initiate the 
connections to the notifications-receivers (and not have the receivers 
connecting to the servers).   This is more a macro-observation than a 
draft-mahesh-netconf-https-notif specific thing, though that draft follows 
this pattern too.



[Tianran2]: I am sorry I not quite clear. Here we are talking about the 
dynamic subscription. I conclude there are four potential modes.

1. The linecard runs on server mode. The connections are dynamically set up, 
when the receiver know the subscription decomposition result at run time.

2. The linecard runs on server mode. All the potential connections are set up. 
The receiver only get data dynamically.

3. The linecard runs on client mode. The connections are dynamically set up, 
when the linecard know the subscription decomposition result at run time.

4. The linecard runs on client mode. All the potential connections are set up. 
The linecards send data dynamically.



Yes, this section regards dynamic subscriptions, but the macro-observation is 
that it would be good if dynamic-subscriptions behaved like 
configured-subscriptions and, since configured-subscriptions will most likely 
always have the server initiating the connection, it would be consistent if 
that were true for dynamic-subscriptions too (as opposed to having open 
ports).   Makes sense?



<eric> I think the dynamic subscription case is what several WG members have 
indicated has the most market demand.  With these dynamic subscriptions, there 
has certainly been a desire to match these to the existing transport paradigms 
of NETCONF / RESTCONF.   So I wouldn't suggest changing the overall 
connectivity paradigm of single-stream dynamic subscriptions based on the 
needs multi-line-cards.





 Ah, a "channel" container was added, I didn't see that before.  The draft 
should've defined YANG module to add a "channel" container.  That said, I 
don't think what you're hoping to achieve here is legal/valid YANG (please 
ensure that all examples are validated using e.g., `yanglint`).



[Tianran2]: I did not define a YANG module for this, because this may make the 
this draft depend on draft-mahesh-netconf-https-notif. But I sent the comment 
to the mailing list to suggest draft-mahesh-netconf-https-notif to apply this 
modification.

 <https://mailarchive.ietf.org/arch/msg/netconf/YmIh2l1xGJUq5gYwvrzcwnRphPg> 
https://mailarchive.ietf.org/arch/msg/netconf/YmIh2l1xGJUq5gYwvrzcwnRphPg



Or do you think this draft can define a configuration framework, not include 
the details? So that transport like draft-mahesh-netconf-https-notif can 
augment.



Ah, I recall seeing that message fly by before.  Seems like no one replied, 
too bad.   Really, this is not a something any transport draft (e.g., 
draft-mahesh-netconf-https-notif) should have to specify.  It would have to be 
the SN draft (currently in AUTH48) and likely published before Montreal.  This 
creates quite a problem.  I strongly advise raising this to the SN draft 
authors (specifically Eric Voit, CC-ed) ASAP!



<eric> There have been discussions on whether to add multi-line type card 
augmentations for the basic YANG model.  But to-date, these have been seen as 
future augmentations to be worked through the WG.  (Which we are exploring 
now.)



Based on leaving the AUTH48 work as-is, it seems like Tianran's suggestion 
seems a reasonable approach...  Anything specific to multi-line card 
augmentation should be in draft-zhou-netconf-multi-stream-originator.   And 
then any transports which want to support these multi-line card models can 
refer to the appropriate augmentations.


Eric







Kent // contributor