Re: [netconf] configuring multi-channels

[Martin Bjorklund <[e-mail]>]

Tianran Zhou <[e-mail]> wrote:
> 
> 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:[e-mail]]
> > Sent: Tuesday, September 17, 2019 5:58 PM
> > To: Tianran Zhou <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: configuring multi-channels
> > 
> > Tianran Zhou <[e-mail]> wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Martin Bjorklund [mailto:[e-mail]]
> > > > Sent: Tuesday, September 17, 2019 5:05 PM
> > > > To: Tianran Zhou <[e-mail]>
> > > > Cc: [e-mail]; [e-mail]
> > > > Subject: Re: configuring multi-channels
> > > >
> > > > Tianran Zhou <[e-mail]> wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Martin Bjorklund [mailto:[e-mail]]
> > > > > > Sent: Tuesday, September 17, 2019 4:28 PM
> > > > > > To: Tianran Zhou <[e-mail]>
> > > > > > Cc: [e-mail]; [e-mail]
> > > > > > Subject: Re: configuring multi-channels
> > > > > >
> > > > > > Tianran Zhou <[e-mail]> wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: Martin Bjorklund [mailto:[e-mail]]
> > > > > > > > Sent: Tuesday, September 17, 2019 3:14 PM
> > > > > > > > To: Tianran Zhou <[e-mail]>
> > > > > > > > Cc: [e-mail]; [e-mail]
> > > > > > > > Subject: Re: configuring multi-channels
> > > > > > > >
> > > > > > > > Tianran Zhou <[e-mail]> wrote:
> > > > > > > > > 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?
> > > > > > > >
> > > > > > > > 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.
> > > > > >
> > > > > > 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.
> > > >
> > > > 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.
> > 
> > No I don't think that's the (correct) solution.  Why is it important to
> > configure this at all?
> 
> Then, could you give any hint on the correct solution in your mind?
> 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


> 
> Thanks,
> Tianran
> 
> > 
> > /martin
> > 
> > 
> > > For each subscription, the device can decide which set of publishers to
> > serve.
> > >
> > > Thanks,
> > > Tianran
> > >
> > > > /martin
> > > >
> > > >
> > > > >
> > > > > I am sorry, could you point out if there is any that mislead you.
> > > > > :-)
> > > > >
> > > > > Best,
> > > > > Tianran
> > > > >
> > > > >
> > > > > > /martin
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Tianran
> > > > > > >
> > > > > > > > /martin
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Tianran
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Martin Bjorklund [mailto:[e-mail]]
> > > > > > > > > > Sent: Tuesday, September 17, 2019 2:36 PM
> > > > > > > > > > To: Tianran Zhou <[e-mail]>
> > > > > > > > > > Cc: [e-mail]; [e-mail]
> > > > > > > > > > Subject: Re: configuring multi-channels
> > > > > > > > > >
> > > > > > > > > > Tianran Zhou <[e-mail]> wrote:
> > > > > > > > > > > Hi Martin,
> > > > > > > > > > >
> > > > > > > > > > > The channel is concept is from
> > > > > > > > > > > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > 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-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
> > > > > > > > > > >
> > > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > > From: Martin Bjorklund [mailto:[e-mail]]
> > > > > > > > > > > > Sent: Tuesday, September 17, 2019 3:27 AM
> > > > > > > > > > > > To: [e-mail]
> > > > > > > > > > > > Cc: Tianran Zhou <[e-mail]>;
> > > > > > > > > > > > [e-mail]
> > > > > > > > > > > > Subject: Re: [netconf] Adoption Call for
> > > > > > > > > > > > draft-mahesh-netconf-https-notif-00
> > > > > > > > > > > >
> > > > > > > > > > > > Kent Watsen <[e-mail]> 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
> > > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
>