Re: [netconf] configuring multi-channels

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:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, September 17, 2019 11:20 PM
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [netconf] configuring multi-channels

Hi,

On Tue, Sep 17, 2019 at 7:48 AM Martin Bjorklund <mbj@tail-f.com<mailto:mbj@tail-f.com>> wrote:
Kent Watsen <kent+ietf@watsen.net<mailto:kent%2Bietf@watsen.net>> wrote:
>
> 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)

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!

+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
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf