Subject: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 15 Nov 2017 03:43:25 +0000

In the WG session tomorrow, I am hoping to get "hum feedback" on:

draft-ietf-netconf-subscribed-notifications

https://github.com/netconf-wg/rfc5277bis/issues/4

The two choices and their issues exposed during the two week review on "Can Transport vary across different receivers of a single configured subscription?" are:

(1) Yes, Transport can vary by receiver

*        Fewer subscriptions (scale benefit)

*        Can convert transport without requiring an application to learn a multiple subscription ids

*        No duplication of content during transport conversion.

*        (Potential confusion in allowing transport to vary, but encoding not to vary?)

(2) No, only one Transport across all subscriptions

*        Simpler model

*        But applications may need to create and track multiple subscription-ids for the same content.

*        Temporary duplication of content streams during transport change.

The current draft does (1).

Thanks,

Eric

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 15 Nov 2017 13:00:59 +0800

While I see no real need for different protocols for the same
transport, I also any real reason to restrict this. I would vote
for the draft to leave this to the implementations. Unless we have
a good reason why make a stand pro or contra?

IMHO if we or an implementation allows transport conversion it is
still not guaranteed that no notifications are lost or duplicated.

In case 2) will we would need to enforce the common transport in
the model.

regards Balazs

On 2017-11-15 11:43, Eric Voit (evoit)
wrote:

In the WG session tomorrow, I am hoping
to get “hum feedback” on:

The two choices and their issues exposed
during the two week review on “Can Transport vary across
different receivers of a single configured subscription?” are:

·
Fewer subscriptions
(scale benefit)

·
Can convert transport
without requiring an application to learn a multiple
subscription ids

·
No duplication of
content during transport conversion.

·
(Potential confusion in
allowing transport to vary, but encoding not to vary?)

(2) No, only one Transport across all
subscriptions

·
Simpler model

·
But applications may
need to create and track multiple subscription-ids for the
same content.

·
Temporary duplication
of content streams during transport change.

Thanks,

Eric

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 15 Nov 2017 06:37:10 +0000

Hi Balazs,

From: Balazs Lengyel, November 15, 2017 12:01 AM

While I see no real need for different protocols for the same transport, I also any real reason to restrict this. I would vote for the draft to leave this to the implementations. Unless we have a good reason why make a stand pro or contra?

Let me try to reframe to make sure I have your points right...

As the question is only for configured subscriptions, some transport must be defined.  Otherwise the path to the receiver cannot be established.  If we leave it to the implementation, it would make more sense to allow for the configuration of transport on a per-receiver basis.  This way either method can be supported.  I.e., it looks like favors option (1).

IMHO if we or an implementation allows transport conversion it is still not guaranteed that no notifications are lost or duplicated.

If there is a single subscription, there are mechanisms available to address potential sources of duplication.  An example would be the "previous-notification-id" from draft-ietf-netconf-notification-messages.  With two subscriptions, there will be no such constructs, and duplication by definition will occur when both are configured.  So this also seems to favor option (1).

In case 2) will we would need to enforce the common transport in the model.

Yes.  Enforcing (2) would move the transport under the subscription rather than under the receiver.  This would preclude (1).   As your point above is that we shouldn't artificially constrain things here, this seems to be a vote for (1) over (2).

Thanks,

Eric

regards Balazs

On 2017-11-15 11:43, Eric Voit (evoit) wrote:

*        Simpler model

Thanks,

Eric

Netconf mailing list

[email-masked]<mailto:[email-masked]>

--

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Nov 2017 11:03:11 +0100 (CET)

> The current draft does (1).

Actually, the github issue lists 3 options, but here you just list 2.

I think the point is that in the term "Transport", we need to include
both protocol and encoding (in the case the protocol supports multiple
encodings).

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 15 Nov 2017 15:37:09 +0000

Hi Martin,

> From: Martin Bjorklund [mailto:[email-masked]]
>
> > The two choices and their issues exposed during the two week review on
> "Can Transport vary across different receivers of a single configured
> subscription?" are:
> >
> >
> >

In reviewing tomorrow's slides with Mahesh, he preferred 2 options.   And as varying the encoding by receiver seems unlikely in implementation, there is little reason to socialize this unlikely variant before the whole WG.   Since as your opinion was either both encoding and transport or neither encoding and transport vary by receiver, the more likely of your primary ask is supported.  

> I think the point is that in the term "Transport", we need to include both
> protocol and encoding (in the case the protocol supports multiple
> encodings).

While most likely the case for NETCONF and RESTCONF, Tianran's draft-ietf-netconf-udp-pub-channel shows that there can be encoding variation by transports .   It Therefore it seems better to let them both vary independently.  .

Eric

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Nov 2017 16:42:47 +0100 (CET)

"Eric Voit (evoit)" <[email-masked]> wrote:
> In reviewing tomorrow's slides with Mahesh, he preferred 2 options.
> And as varying the encoding by receiver seems unlikely in
> implementation

Why is this unlikely?  Suppose I have two receivers for the same
subscription, one wants NETCONF/XML and the other RESTCONF/JSON.  Is
that unlikely?

> , there is little reason to socialize this unlikely variant before
> the whole WG.   Since as your opinion was either both encoding and
> transport or neither encoding and transport vary by receiver, the
> more likely of your primary ask is supported.
> 
>  
> While most likely the case for NETCONF and RESTCONF, Tianran's
> draft-ietf-netconf-udp-pub-channel shows that there can be encoding
> variation by transports .   It Therefore it seems better to let them
> both vary independently.

Not sure I understand what you mean.  To be clear, do you think the
"encoding" leaf should stay where it is, or be moved down to the
receiver, as a sibling to "protocol"?

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 15 Nov 2017 21:53:28 +0000

Adding Einar as he had some strong opinions on this a few years ago when we were setting the model...

> From: Martin Bjorklund, November 15, 2017 10:43 AM
> 
> > > "Can Transport vary across different receivers of a single
> > > configured subscription?" are:
> > > >
> > > >
> > > >
> > > > *        Can convert transport without requiring an application to learn
> a
> > > multiple subscription ids
> > > >
> > > > *        (Potential confusion in allowing transport to vary, but encoding
> not
> > > to vary?)
> > > >
> > > >
> > > >

Einar's belief was that a publisher implementation would be unlikely to service a single subscription into multiple encodings.   If such a condition existed, it would be far easier to create two subscriptions.  This also would have fewer error conditions.
 
> > transport or neither encoding and transport vary by receiver, the more
> > likely of your primary ask is supported.
> >
> >
> > > I think the point is that in the term "Transport", we need to
> > > include both protocol and encoding (in the case the protocol
> > > supports multiple encodings).
> >
> "encoding" leaf should stay where it is, or be moved down to the receiver,
> as a sibling to "protocol"?

Encoding leaf should stay where it is.   Your previous ask was to put encoding and transport and the same level. There is an option proposed in the slides which does that.

Eric

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 15 Nov 2017 23:06:56 +0000

Martin,

As yet, we have no practical use cases where we would have a single configured subscription with multiple receivers who wish to receive the data in different formats. Thus supporting this seems like an unnecessary complexity for platforms, and one which potentially impacts optimisations that we already use in some platform implementations (e.g. sending the same encoded PDU to multiple receivers, relieving the platform of encoding the same data multiple ways).

Of course, if a client really wants to have the same data sent to multiple receivers but in different formats, they can do this — just provision separate subscriptions with the same filter.

All-in-all, I don’t see any benefit in making the base model support this, only downsides, so do you have any specific use cases in mind where this would be a benefit? So far in the use cases we have looked at in SP, DC, enterprise and IoT we have not seen any requirement to support this, but we have seen the need for multiple receivers (e.g. to support HA/redundancy approaches). As such, I would be reluctant to add this to the draft at this stage when the functionality can be achieved already if absolutely necessary.

Cheers,

Einar

> On 15 Nov 2017, at 21:53, Eric Voit (evoit) <[email-masked]> wrote:
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Nov 2017 08:53:31 +0100 (CET)

Hi,

Note that the issue is that the current model has:

      +--rw subscription* [identifier]
         ...
         +--rw encoding
         ...
         +--rw receivers
            +--rw receiver* [address port]
               ...
               +--rw protocol

My proposal is have encoding and protocol together:

(A)
      +--rw subscription* [identifier]
         ...
         ...
         +--rw receivers
            +--rw receiver* [address port]
               ...
               +--rw protocol
               +--rw encoding

or:

(B)
      +--rw subscription* [identifier]
         ...
         +--rw encoding
         +--rw protocol
         ...
         +--rw receivers
            +--rw receiver* [address port]
               ...

I think that this is *less* complex and probably more optimal than the
current solution.

"Einar Nilsen-Nygaard (einarnn)" <[email-masked]> wrote:
> Martin,
> 
> As yet, we have no practical use cases where we would have a single
> configured subscription with multiple receivers who wish to receive
> the data in different formats. Thus supporting this seems like an
> unnecessary complexity for platforms, and one which potentially
> impacts optimisations that we already use in some platform
> implementations (e.g. sending the same encoded PDU to multiple
> receivers, relieving the platform of encoding the same data multiple
> ways).

But this optimization doesn't really work, as you note below (*).

> Of course, if a client really wants to have the same data sent to
> multiple receivers but in different formats, they can do this — just
> provision separate subscriptions with the same filter.

Exactly; this is more complex and less optimal since the same filter
might be evaluated twice, unless you add code to optimize for that
(which probably falls in your category of "unnecessary complexity").

(*) So if the operator requires this setup, he will have to configure
two different subscriptions today.  Thus, the platform will encode the
data twice, and your optimization above won't help.

> All-in-all, I don’t see any benefit in making the base model support
> this, only downsides, so do you have any specific use cases in mind
> where this would be a benefit? So far in the use cases we have looked
> at in SP, DC, enterprise and IoT we have not seen any requirement to
> support this, but we have seen the need for multiple receivers
> (e.g. to support HA/redundancy approaches).

The current model supports different *protocols* for the different
receivers.  Do you have a use case supporting that, or would (B) above
fulfil your requirements.

/martin

> As such, I would be
> reluctant to add this to the draft at this stage when the
> functionality can be achieved already if absolutely necessary.
> 
> Cheers,
> 
> Einar
> 
> 
> >>>>> *        (Potential confusion in allowing transport to vary, but
> >>>>> *        encoding
> >> not
> >>>> to vary?)
> >>>>> 
> >>>>> 
> >>>>> 
> > Einar's belief was that a publisher implementation would be unlikely
> > to service a single subscription into multiple encodings.  If such a
> > condition existed, it would be far easier to create two subscriptions.
> > This also would have fewer error conditions.
> > 
> > Encoding leaf should stay where it is.  Your previous ask was to put
> > encoding and transport and the same level. There is an option proposed
> > in the slides which does that.
> > 
> > Eric
> > 
> >> /martin
> > 
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 16 Nov 2017 08:30:20 +0000

Hi Martin,

Yes, I originally had both your options in the WG slides.    I removed (A) after discussion with Mahesh for the WG session slides to simplify the in-room discussions, as well as consideration of the points Einar makes below.  We can of course have more and deeper resolution discussions here.

Thanks,
Eric

> -----Original Message-----
> Sent: Thursday, November 16, 2017 2:54 AM
> To: Einar Nilsen-Nygaard (einarnn) <[email-masked]>
> Cc: Eric Voit (evoit) <[email-masked]>; [email-masked]
> Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different
> receivers of a single configured subscription?
> 
> Hi,
> 
> Exactly; this is more complex and less optimal since the same filter might be
> evaluated twice, unless you add code to optimize for that (which probably
> falls in your category of "unnecessary complexity").
> 
> (*) So if the operator requires this setup, he will have to configure two
> different subscriptions today.  Thus, the platform will encode the data
> twice, and your optimization above won't help.
> 
> > support this, but we have seen the need for multiple receivers (e.g.
> > to support HA/redundancy approaches).
> 
> receivers.  Do you have a use case supporting that, or would (B) above fulfil
> your requirements.
> 
> 
> /martin
> 
> 
> 
> > As such, I would be
> > >> subscription, one wants NETCONF/XML and the other
> RESTCONF/JSON.
> > >> Is that unlikely?
> > >
> > > encoding and transport and the same level. There is an option
> > > proposed in the slides which does that.
> > >
> > > Eric
> > >
> > >> /martin
> > >
> >

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 16 Nov 2017 11:28:51 +0000

(B) Would be fine for me.

Cheers,

Einar

> On 16 Nov 2017, at 07:53, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 17 Nov 2017 18:17:21 +0000

In the meeting room discussion during the NETCONF WG, sentiment was to use a common Transport across all receivers of a single configured subscription.   This was proposal (2) below.

I would like to see if there is any objection to this.   If not, we can close this issue in a few weeks.

Eric

> From: Netconf [mailto:[email-masked]] On Behalf Of Eric Voit
> (evoit)
> Sent: Thursday, November 16, 2017 3:30 AM
> To: Martin Bjorklund <[email-masked]>; Einar Nilsen-Nygaard (einarnn)
> <[email-masked]>
> Cc: [email-masked]
> Yes, I originally had both your options in the WG slides.    I removed (A)
> after discussion with Mahesh for the WG session slides to simplify the in-
> room discussions, as well as consideration of the points Einar makes below.
> We can of course have more and deeper resolution discussions here.
> 
> Thanks,
> Eric
> 
> > Subject: Re: [Netconf] Issue SN #4: Can Transport vary across
> > different receivers of a single configured subscription?
> >
> > Hi,
> >
> > > where this would be a benefit? So far in the use cases we have
> > > looked at in SP, DC, enterprise and IoT we have not seen any
> > > requirement to support this, but we have seen the need for multiple
> receivers (e.g.
> > > > Einar's belief was that a publisher implementation would be
> > > > unlikely to service a single subscription into multiple encodings.
> > > > If such a condition existed, it would be far easier to create two
> subscriptions.
> > > >>> transport or neither encoding and transport vary by receiver,
> > > >>> the more likely of your primary ask is supported.
> > > >>>
> > > >>>
> > > >> Not sure I understand what you mean.  To be clear, do you think
> > > >> the "encoding" leaf should stay where it is, or be moved down to
> > > >> the receiver, as a sibling to "protocol"?
> > > >
> > > > Encoding leaf should stay where it is.  Your previous ask was to
> > > > put encoding and transport and the same level. There is an option

---

From: Robert Wilton <[email-masked]>
Date: Fri, 17 Nov 2017 20:29:03 +0000

> I would like to see if there is any objection to this.   If not, we can close this issue in a few weeks.
No objection to proposal 2 (B) below, which keeps it simple for now.

If there is a future requirement to support different transports and/or 
encodings for a subscription, then it looks like there is also a viable 
upgrade path to also support (A) under a feature statement or using an 
augmenting module, perhaps with some appropriate when/must constraints.

I.e. choosing the more simple solution now, doesn't seem to rule out 
extending it to the more complex solution in future, if the need arises.

Thanks,
Rob

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 20 Nov 2017 19:15:20 +0000

Hi,

Yes, per the discussion in the room I think this makes sense, as it keeps things simpler (for the 90+% of cases that have no need for multiple transports etc).  

Just to clarify, this means both common transport and common encoding.  
--- Alex

> Sent: Friday, November 17, 2017 10:17 AM
> To: [email-masked]
> In the meeting room discussion during the NETCONF WG, sentiment was to
> use a common Transport across all receivers of a single configured
> subscription.   This was proposal (2) below.
> 
> > after discussion with Mahesh for the WG session slides to simplify the
> > in- room discussions, as well as consideration of the points Einar makes
> below.
> > > I think that this is *less* complex and probably more optimal than
> > > the current solution.
> > >
> > > > As yet, we have no practical use cases where we would have a
> > > > single configured subscription with multiple receivers who wish to
> > > > receive the data in different formats. Thus supporting this seems
> > > > like an unnecessary complexity for platforms, and one which
> > > > potentially impacts optimisations that we already use in some
> > > > platform implementations (e.g. sending the same encoded PDU to
> > > > multiple receivers, relieving the platform of encoding the same
> > > > data multiple ways).
> > >
> > > > multiple receivers but in different formats, they can do this —
> > > > just provision separate subscriptions with the same filter.
> > >
> > > (*) So if the operator requires this setup, he will have to
> > > configure two different subscriptions today.  Thus, the platform
> > > will encode the data twice, and your optimization above won't help.
> > >
> > > > All-in-all, I don’t see any benefit in making the base model
> > > > support this, only downsides, so do you have any specific use
> > > > cases in mind where this would be a benefit? So far in the use
> > > > cases we have looked at in SP, DC, enterprise and IoT we have not
> > > > seen any requirement to support this, but we have seen the need
> > > > for multiple
> > receivers (e.g.
> > > receivers.  Do you have a use case supporting that, or would (B)
> > > above fulfil your requirements.
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > > As such, I would be
> > > > >>>>> In the WG session tomorrow, I am hoping to get "hum
> feedback"
> > > on:
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >> Why is this unlikely?  Suppose I have two receivers for the
> > > > >> same subscription, one wants NETCONF/XML and the other
> > > RESTCONF/JSON.
> > > > >> Is that unlikely?
> > > > >
> > > > >> the "encoding" leaf should stay where it is, or be moved down
> > > > >> to the receiver, as a sibling to "protocol"?
> > > > >
> > > > > put encoding and transport and the same level. There is an
> > > > > option proposed in the slides which does that.
> > > > >
> > > > > Eric
> > > > >
> > > > >> /martin
> > > > >
> > > >