Subject: [netconf] configuring multi-channels

From: Tianran Zhou <[email-masked]>
Date: Tue, 17 Sep 2019 01:41:16 +0000

Hi Martin,

The channel is concept is from 
https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-originators/
There are multiple publication channels per device/subscription.

It should be better if the client is not aware of the channels. These can be achieved by using the UDP based publication channel as in:
https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/
The publishers can use the same IP as the subscription channel, and use dynamic ports. So no per channel configurations need.

For https-notif, we can consider to pre-configure all the possible/potential publication channels. But the usage of which channels is decided by the device dynamically during the run time.

Regards,
Tianran

> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Tuesday, September 17, 2019 3:27 AM
> To: [email-masked]
> Cc: Tianran Zhou <[email-masked]>; [email-masked]
> Subject: Re: [netconf] Adoption Call for
> draft-mahesh-netconf-https-notif-00
> 
> Kent Watsen <[email-masked]> wrote:
> >
> > Hi Tianran,
> >
> >
> > > Considering the multiple stream originator case, I would suggest this
> https-notif to add a channel level configuration.
> > > i.e.
> > >
> > > +--receivers
> > >    +--receiver
> > >       +--channels
> > >          +--channel
> > >             +--here put the http client server configurations
> > >
> > > This is compatible with the single originator case with only one channel
> configuration.
> >
> > We can look at this.  Maybe use a choice statement between the two options...
> 
> I don't think this is a good idea.  But then I don't really understand the
> 'channel' concept.  I don't understand why the client needs to be aware of
> these channels, but this should probably be discussed in a separate thread.
> 
> 
> /martin
> 
> 
> >
> > Kent // co-author
> >
> >
> > >
> > > If you do not like this, I think existing https-notif model also works.
> > > i.e. each receiver configuration stands for one channel.
> > > But this is not clear IMO.
> > >
> > > Best,
> > > Tianran

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Sep 2019 08:35:33 +0200 (CEST)

> There are multiple publication channels per device/subscription.

In that document, the word "channel" is present three times + one
(broken) XML example.  The concept of a channel needs to be explained
in detail so that we can have a meaningful discussion.

/martin

> It should be better if the client is not aware of the
> channels. These can be achieved by using the UDP based publication
> channel as in:
> The publishers can use the same IP as the subscription channel, and
> use dynamic ports. So no per channel configurations need.
> 
> For https-notif, we can consider to pre-configure all the
> possible/potential publication channels.
> But the usage of which
> channels is decided by the device dynamically during the run time.

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 17 Sep 2019 06:50:54 +0000

In this document, we defined two types of publication channels:
   Master Publication Channel: the session between the Master Publisher
   and the Receiver.
   Agent Publication Channel: the session between the Agent Publisher
   and the Receiver

Do you think it's enough or anything you think should be clarified?

Thanks,
Tianran

> Sent: Tuesday, September 17, 2019 2:36 PM
> To: Tianran Zhou <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: configuring multi-channels
> 
> > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-origi
> > nators/ There are multiple publication channels per
> > device/subscription.
> 
> (broken) XML example.  The concept of a channel needs to be explained in
> detail so that we can have a meaningful discussion.
> 
> 
> 
> /martin
> 
> 
> > It should be better if the client is not aware of the channels. These
> > can be achieved by using the UDP based publication channel as in:
> > > I don't think this is a good idea.  But then I don't really
> > > understand the 'channel' concept.  I don't understand why the client
> > > needs to be aware of these channels, but this should probably be discussed
> in a separate thread.
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > Kent // co-author
> > > >
> > > >
> > > > >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Sep 2019 09:13:58 +0200 (CEST)

> Do you think it's enough or anything you think should be clarified?

These are just names.  But why does these names imply that the client
has to configure anything?

/martin

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 17 Sep 2019 07:56:23 +0000

> Sent: Tuesday, September 17, 2019 3:14 PM
> These are just names.  But why does these names imply that the client has
> to configure anything?

Several kinds of transport protocol can be used to carry data between the publisher and the receiver. UDP based, TCP based.
Transport like https-notif need client-server configuration.
That is to say the configuration is about the transport like in draft-mahesh-netconf-https-notif-00.

Tianran

> > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-o
> > > > rigi nators/ There are multiple publication channels per
> > > > device/subscription.
> > >
> > > (broken) XML example.  The concept of a channel needs to be
> > > explained in detail so that we can have a meaningful discussion.
> > >
> > >
> > >
> > > /martin
> > >
> > >
> > > > It should be better if the client is not aware of the channels.
> > > > These can be achieved by using the UDP based publication channel as
> in:
> > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channe
> > > > l/ The publishers can use the same IP as the subscription channel,
> > > > and use dynamic ports. So no per channel configurations need.
> > > >
> > > > > > We can look at this.  Maybe use a choice statement between the
> > > > > > two
> > > options...
> > > > >
> > > > > understand the 'channel' concept.  I don't understand why the
> > > > > client needs to be aware of these channels, but this should
> > > > > probably be discussed
> > > in a separate thread.
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > > > >
> > > > > >
> > > > > > Kent // co-author
> > > > > >
> > > > > >
> > > > > > >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Sep 2019 10:27:58 +0200 (CEST)

Tianran Zhou <[email-masked]> wrote:
> Several kinds of transport protocol can be used to carry data between
> the publisher and the receiver. UDP based, TCP based.

With the POST-based HTTP protocol in draft-mahesh-netconf-https-notif,
why can't the agent publisher simply POST to the receiver?  It is
probably useful if the *server* can indicate to the client that this
will/may happen, but I don't understand why the client needs to
configure anything special.

/martin

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 17 Sep 2019 08:48:21 +0000

> Sent: Tuesday, September 17, 2019 4:28 PM
> > > These are just names.  But why does these names imply that the
> > > client has to configure anything?
> >
> With the POST-based HTTP protocol in draft-mahesh-netconf-https-notif, why
> can't the agent publisher simply POST to the receiver?  It is probably useful
> if the *server* can indicate to the client that this will/may happen, but
> I don't understand why the client needs to configure anything special.

I agree with you. My understanding to draft-mahesh-netconf-https-notif is that the configuration is on the *server* side.
The configuration need to indicate both client and server information. For example:
   module: ietf-https-notif
     +--rw receivers
        +--rw receiver* [name]
           +--rw name           string
           +--rw tcp-params
           |  +--rw remote-address    inet:host
           |  +--rw remote-port?      inet:port-number
           |  +--rw local-address?    inet:ip-address
           |  +--rw local-port?       inet:port-number
           |  +--rw keepalives!

Include both remote and local IP.

I am sorry, could you point out if there is any that mislead you. :-) 

Best,
Tianran

> > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stre
> > > > > > am-o rigi nators/ There are multiple publication channels per
> > > > > > device/subscription.
> > > > >
> > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-ch
> > > > > > anne l/ The publishers can use the same IP as the subscription
> > > > > > channel, and use dynamic ports. So no per channel
> > > > > > configurations need.
> > > > > >
> > > > > > > > We can look at this.  Maybe use a choice statement between
> > > > > > > > the two
> > > > > options...
> > > > > > >
> > > > > > > understand the 'channel' concept.  I don't understand why
> > > > > > > the client needs to be aware of these channels, but this
> > > > > > > should probably be discussed
> > > > > in a separate thread.
> > > > > > >
> > > > > > >
> > > > > > > /martin
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Kent // co-author
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > If you do not like this, I think existing https-notif
> > > > > > > > > model also
> > > works.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Sep 2019 11:05:00 +0200 (CEST)

Tianran Zhou <[email-masked]> wrote:
> > why
> I agree with you. My understanding to draft-mahesh-netconf-https-notif
> is that the configuration is on the *server* side.

The local-address and -port are conditional on an if-feature, but I
agree that this is problematic in the case that an publisher agent on
a line card wants to push directly to the receiver.

/martin

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 17 Sep 2019 09:17:22 +0000

> Sent: Tuesday, September 17, 2019 5:05 PM
> > > > Several kinds of transport protocol can be used to carry data
> > > > between the publisher and the receiver. UDP based, TCP based.
> > > With the POST-based HTTP protocol in
> > > draft-mahesh-netconf-https-notif, why can't the agent publisher
> > > simply POST to the receiver?  It is probably useful if the *server*
> > > can indicate to the client that this will/may happen, but I don't
> > > understand why the client needs to configure anything special.
> >
> The local-address and -port are conditional on an if-feature, but I agree
> that this is problematic in the case that an publisher agent on a line card
> wants to push directly to the receiver.

Right. Thanks for your clarification.
So for TCP based transports, we have to preconfigure all the potential local-remote pairs, aka the channel information in my words:-), on the server.
For each subscription, the device can decide which set of publishers to serve.

Thanks,
Tianran

> > > > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-
> > > > > > > > stre am-o rigi nators/ There are multiple publication
> > > > > > > > channels per device/subscription.
> > > > > > >
> > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pu
> > > > > > > > b-ch anne l/ The publishers can use the same IP as the
> > > > > > > > subscription channel, and use dynamic ports. So no per
> > > > > > > > channel configurations need.
> > > > > > > >
> > > > > > > > > > We can look at this.  Maybe use a choice statement
> > > > > > > > > > between the two
> > > > > > > options...
> > > > > > > > >
> > > > > > > > > I don't think this is a good idea.  But then I don't
> > > > > > > > > really understand the 'channel' concept.  I don't
> > > > > > > > > understand why the client needs to be aware of these
> > > > > > > > > channels, but this should probably be discussed
> > > > > > > in a separate thread.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > /martin
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Kent // co-author
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > If you do not like this, I think existing
> > > > > > > > > > > https-notif model also
> > > > > works.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Sep 2019 11:58:08 +0200 (CEST)

Tianran Zhou <[email-masked]> wrote:
> So for TCP based transports, we have to preconfigure all the
> potential local-remote pairs, aka the channel information in my
> words:-), on the server.

No I don't think that's the (correct) solution.  Why is it important to
configure this at all?

/martin

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 17 Sep 2019 10:06:03 +0000

> Sent: Tuesday, September 17, 2019 5:58 PM
> > > > > > > >    Master Publication Channel: the session between the
> > > > > > > > Master
> > > Publisher
> > > > > > > >    and the Receiver.
> > > > > > > >    Agent Publication Channel: the session between the
> > > > > > > > Agent
> > > Publisher
> > > > > > > >    and the Receiver
> > > > > > > >
> > > > > > > These are just names.  But why does these names imply that
> > > > > > > the client has to configure anything?
> > > > > >
> > > > > simply POST to the receiver?  It is probably useful if the
> > > > > *server* can indicate to the client that this will/may happen,
> > > > > but I don't understand why the client needs to configure anything
> special.
> > > >
> > > > I agree with you. My understanding to
> > > > draft-mahesh-netconf-https-notif is that the configuration is on the
> *server* side.
> > > agree that this is problematic in the case that an publisher agent
> > > on a line card wants to push directly to the receiver.
> >
> > So for TCP based transports, we have to preconfigure all the potential
> > local-remote pairs, aka the channel information in my words:-), on the
> > server.
> 

Then, could you give any hint on the correct solution in your mind?
What configuration should be avoided in an idea solution?

Thanks,
Tianran

> > > > > > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-mu
> > > > > > > > > > lti- stre am-o rigi nators/ There are multiple
> > > > > > > > > > publication channels per device/subscription.
> > > > > > > > >
> > > > > > > > > In that document, the word "channel" is present three
> > > > > > > > > times
> > > > > > > > > + one
> > > > > > > > > (broken) XML example.  The concept of a channel needs to
> > > > > > > > > be explained in detail so that we can have a meaningful
> discussion.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > /martin
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-ud
> > > > > > > > > > p-pu b-ch anne l/ The publishers can use the same IP
> > > > > > > > > > as the subscription channel, and use dynamic ports. So
> > > > > > > > > > no per channel configurations need.
> > > > > > > > > >
> > > > > > > > > > For https-notif, we can consider to pre-configure all
> > > > > > > > > > the possible/potential publication channels.
> > > > > > > > > > But the usage of which channels is decided by the
> > > > > > > > > > device dynamically during the run
> > > time.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Tianran
> > > > > > > > > >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Sep 2019 12:12:26 +0200 (CEST)

> What configuration should be avoided in an idea solution?

I don't exactly know; my original comment was that I don't think we
should add 'channel' to this model at this time.

But for this protocol, perhaps the local-address and local-port is not
needed; it should be ok for the receiver to get POSTs from any local
ip / port.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 17 Sep 2019 14:42:13 +0000

Martin,

As for why there is a need to configure anything on a per-channel basis, here are some possible reasons:

  - different TCP-level parameters (source IP, possibly a VRF)
  - different TLS-level parameters (TA cert, client cert)
  - different HTTP-level parameters (basic auth)

Does any of this matter?  Is the only issue if the receiver can know which line card sent the message?  Or is it needed to enable the networking connection to be established, which can somehow be different amongst the line cards?

If we purposely shun variations, then the need to configure anything per-channel goes away, which would make things much easier all around.  But then we'd have to ask, what remains in the multi-stream-originators draft?

Kent // contributor

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Sep 2019 16:48:03 +0200 (CEST)

>   - different TCP-level parameters (source IP, possibly a VRF)

Perhaps.  But setting this per linecard would require the client to know
all the line cards and which IP each line card can use.

>   - different TLS-level parameters (TA cert, client cert)

Do you see a use for this?

>   - different HTTP-level parameters (basic auth)

Do you see a use for this?

> Does any of this matter?  Is the only issue if the receiver can know
> which line card sent the message?  Or is it needed to enable the
> networking connection to be established, which can somehow be
> different amongst the line cards?
> 
> If we purposely shun variations, then the need to configure anything
> per-channel goes away, which would make things much easier all around.
> But then we'd have to ask, what remains in the
> multi-stream-originators draft?

I don't know, but if we can solve the problem w/o an additional
specification, that seems like a good thing!

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Sep 2019 08:20:06 -0700

Hi,

> specification, that seems like a good thing!

+1 to all of Martin's concerns.

The notification already has a subscription-id, maybe a
message-generator-id.
Is the proposal to add an arbitrary channel-id to the notification header?

It seems simpler and possibly useful to the client to retrieve the
read-only message-generator-id
that is being used for connection (from this new module).
This should not be configurable by the client and a new arbitrary number
should not be invented for it.

> /martin

Andy

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

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 18 Sep 2019 01:47:46 +0000

Hi Andy and Martin,

The proposal in draft-zhou-netconf-multi-stream-originators is to add the read only message-generator-id.
So that the receiver can verify the full set of YANG objects promised are being provided across the sum of stream originators.

   module: ietf-multiple-stream-originators
     augment /sn:subscriptions/sn:subscription:
       +--ro message-generator-id*   string
     augment /sn:subscription-started:
       +--ro message-generator-id*   string
     augment /sn:subscription-modified:
       +--ro message-generator-id*   string
     augment /sn:establish-subscription/sn:output:
       +--ro message-generator-id*   string
     augment /sn:modify-subscription/sn:output:
       +--ro message-generator-id*   string

So we are not going to configure a channel-id or message-generator-id.

I am just thinking how to configure the transport when there are multi originators. If draft-zhou-netconf-multi-stream-originators need to provide some guidelines or it’s deferred to the transport documents like https-notif.

Best,
Tianran

From: netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, September 17, 2019 11:20 PM
To: Martin Bjorklund <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [netconf] configuring multi-channels

Hi,

On Tue, Sep 17, 2019 at 7:48 AM Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:

The notification already has a subscription-id, maybe a message-generator-id.
Is the proposal to add an arbitrary channel-id to the notification header?

It seems simpler and possibly useful to the client to retrieve the read-only message-generator-id
that is being used for connection (from this new module).
This should not be configurable by the client and a new arbitrary number should not be invented for it.

/martin

Andy

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