Subject: [netmod] ietf 91 netmod agenda (revised)

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Nov 2014 15:35:08 +0100

Hi,

I have uploaded a new agenda.

http://www.ietf.org/proceedings/91/agenda/agenda-91-netmod

Note that the agenda may not be 100% correct or complete but hopefully
we are converging to something stable. We try to take into account
that certain contributors are not available on Friday. Please send
requests for changes to the list or to both co-chairs since this will
make synchronization easier. While Tom will run both meetings, we (the
chairs) generally split responsibility between us - infrastructure
work primarily goes to me, data modeling work primarily goes to Tom.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 5 Nov 2014 16:06:07 +0100

> I have uploaded a new agenda.

* A YANG Data Model for Routing Management              17:45-17:55 (10 min)

  https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16

I don’t know yet how far-reaching the discussion in the rtgwg meeting is going to be but 10 minutes will hardly suffice – unless the conclusion from the routing folks will be that it is all rubbish and we should stop it.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Nov 2014 16:10:19 +0100

We have about 80 spare minutes in the agenda so I will allow sufficient runway for open discussion as-needed.

Tom 

> On Nov 5, 2014, at 4:06 PM, Ladislav Lhotka <[email-masked]> wrote:
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Nov 2014 16:40:07 +0100

> I don’t know yet how far-reaching the discussion in the rtgwg meeting is going to be but 10 minutes will hardly suffice – unless the conclusion from the routing folks will be that it is all rubbish…

We do not know either. Your proposal? We have to plan with something.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 5 Nov 2014 16:47:41 +0100

> We do not know either. Your proposal? We have to plan with something.

20 minutes at least, but I am OK with Tom’s answer.

Lada

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 5 Nov 2014 19:34:02 +0000

Just one comment, peer mount includes also datastore push, which as a topic can also stand on its own / independent of peer mount, due to its ramifications e.g. for applications that relate to service assurance (that may otherwise feel compelled to revert to periodic polling, or not see a reason to use YANG/Netconf).  Could we call that out as a separate item, perhaps on Friday (where we also have more room for AOB, and one less thing to cram into an already crowded agenda on Thursday)?  
Thanks
--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, November 05, 2014 6:35 AM
To: [email-masked]
Subject: [netmod] ietf 91 netmod agenda (revised)

Hi,

Note that the agenda may not be 100% correct or complete but hopefully we are converging to something stable. We try to take into account that certain contributors are not available on Friday. Please send requests for changes to the list or to both co-chairs since this will make synchronization easier. While Tom will run both meetings, we (the
chairs) generally split responsibility between us - infrastructure work primarily goes to me, data modeling work primarily goes to Tom.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 5 Nov 2014 20:12:53 +0000

I'm generally supportive of this aspect of the peer-mount drafts, as I'm
aware of a swelling desire to improve NETCONF Notifications.   That said,
I suggest moving this discussion to the NETCONF WG.

Thanks,
Kent

On 11/5/14, 2:34 PM, "Alexander Clemm (alex)" <[email-masked]> wrote:

>Just one comment, peer mount includes also datastore push, which as a
>topic can also stand on its own / independent of peer mount, due to its
>ramifications e.g. for applications that relate to service assurance
>(that may otherwise feel compelled to revert to periodic polling, or not
>see a reason to use YANG/Netconf).  Could we call that out as a separate
>item, perhaps on Friday (where we also have more room for AOB, and one
>less thing to cram into an already crowded agenda on Thursday)?
>Thanks
>--- Alex
>
>Note that the agenda may not be 100% correct or complete but hopefully we
>are converging to something stable. We try to take into account that
>certain contributors are not available on Friday. Please send requests
>for changes to the list or to both co-chairs since this will make
>synchronization easier. While Tom will run both meetings, we (the
>chairs) generally split responsibility between us - infrastructure work
>primarily goes to me, data modeling work primarily goes to Tom.
>
>/js
>
>--

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 5 Nov 2014 21:56:15 +0000

> From: Kent Watsen, November 05, 2014 3:13 PM
> 
> 

We have been wondering about the right home for the push draft.  Netmod might not be it because a generalized Pub/Sub mechanism might be needed beyond YANG encoding.  However we are hoping that the Pub/Sub mechanism could work with many transports (including multicast transports).  Is NETCONF WG able to support a Pub/Sub mechanism maximally decoupled from NETCONF transport?

Eric
 
> >(that may otherwise feel compelled to revert to periodic polling, or
> >not see a reason to use YANG/Netconf).  Could we call that out as a
> >separate item, perhaps on Friday (where we also have more room for AOB,
> >and one less thing to cram into an already crowded agenda on Thursday)?
> >Thanks
> >--- Alex
> >
> >we are converging to something stable. We try to take into account that

---

From: Andy Bierman <[email-masked]>
Date: Wed, 5 Nov 2014 14:05:27 -0800

> We have been wondering about the right home for the push draft.  Netmod might not be it because a generalized Pub/Sub mechanism might be needed beyond YANG encoding.  However we are hoping that the…

The NETMOD WG may have a wide open charter, but I am pretty sure
it does not include any protocol work at all.  I don't know if NETCONF
is the right WG, but this is not in scope for NETMOD.

> Eric

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Nov 2014 23:40:33 +0100

> We have been wondering about the right home for the push draft.  Netmod might not be it because a generalized Pub/Sub mechanism might be needed beyond YANG encoding.  However we are hoping that the…

Looking at the charter of this WG, it seems pretty clear that NETMOD
is not chartered to do protocol work. And NETMOD can't answer the
question whether NETCONF can help you or any other working group.

That said, I am unsure what you want to do. Are we talking about
<draft-netmod-clemm-datastore-push-00.txt>? That document defines YANG
notifications and data objects, so this is a data model. But then you
write "a generalized Pub/Sub mechanism might be needed beyond YANG
encoding" that is "maximally decoupled from NETCONF transport". Is
there another I-D for this? I really like to understand things better.

/js

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 5 Nov 2014 22:55:29 +0000

Hi Juergen,

Yes, at its essence, this is a data model.  This is why we think Netmod is the relevant group, and why we would like to discuss it here.  

In addition to configuring the subscriptions, there is the issue of how you perform the actual push.  This is done by defining a notification, which will be transported using a <notification> element per RFC 5277.  

In the future, it is conceivable that alternative transport mappings (e.g. pub/sub, someone even brought up ipfix export) may be defined.  It is our intention to have an architecture that will allow for that, i.e. to have the same subscription model apply also in such a case.  But really, this is orthogonal.  

Getting back to the original message, it would be good to break this into a separate item, hence I would request to a time slot on Friday.  This is also practical from a "load-balancing" perspective, as the agenda on Thursday is a lot heavier than Friday's.  In the peer-mount slot, there are potentially already three other separate drafts to talk to (requirements - use case - mechanism), and the push draft has applicability beyond that.  

Thanks
--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Wednesday, November 05, 2014 2:41 PM
To: Eric Voit (evoit)
Cc: Kent Watsen; Alexander Clemm (alex); [email-masked]
Subject: Re: [netmod] ietf 91 netmod agenda (revised)

> We have been wondering about the right home for the push draft.  Netmod might not be it because a generalized Pub/Sub mechanism might be needed beyond YANG encoding.  However we are hoping that the…

Looking at the charter of this WG, it seems pretty clear that NETMOD is not chartered to do protocol work. And NETMOD can't answer the question whether NETCONF can help you or any other working group.

That said, I am unsure what you want to do. Are we talking about <draft-netmod-clemm-datastore-push-00.txt>? That document defines YANG notifications and data objects, so this is a data model. But then you write "a generalized Pub/Sub mechanism might be needed beyond YANG encoding" that is "maximally decoupled from NETCONF transport". Is there another I-D for this? I really like to understand things better.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 5 Nov 2014 23:53:56 +0000

> From: Alexander Clemm, November 05, 2014 5:55 PM
> 
> Hi Juergen,
> 
> Yes, at its essence, this is a data model.  This is why we think Netmod is the
> relevant group, and why we would like to discuss it here.
> 
> In addition to configuring the subscriptions, there is the issue of how you
> perform the actual push.  This is done by defining a notification, which will be
> transported using a <notification> element per RFC 5277.
> 
> In the future, it is conceivable that alternative transport mappings (e.g. pub/sub,
> someone even brought up ipfix export) may be defined.  It is our intention to
> have an architecture that will allow for that, i.e. to have the same subscription
> model apply also in such a case.  But really, this is orthogonal.

Yes, both Juergen and Andy pointed out that such protocol work is not in Netmod charter.  And I completely agree this is something Netmod should *not* do.  

The point I communicated (poorly) is that additional drafts may need a home if the IETF desires Pub/Sub mechanisms beyond NETCONF.  Can any of this transport specific protocol work be generalized?  I don't know.  I do know of multiple implementations though.  Just for grins, below are some academic data-points showing people care...

New Generation SDN-Aware Pub/Sub Environment
http://www.thinkmind.org/download.php?articleid=icn_2014_9_20_30097
(investigates Pub/sub with Multicast, OpenFlow, ALTO)

Efficient Publish-Subscribe Architecture for the Smart Grid using OpenFlow and MPLS
http://www.cse.iitb.ac.in/~cs620/final_project_ppts/rohan_7.pdf 

Publish Subscribe Internet Routing Paradigm (PSIRP)
http://www.psirp.org/overview/solution.html 

Eric

> Getting back to the original message, it would be good to break this into a
> separate item, hence I would request to a time slot on Friday.  This is also
> practical from a "load-balancing" perspective, as the agenda on Thursday is a lot
> heavier than Friday's.  In the peer-mount slot, there are potentially already three
> other separate drafts to talk to (requirements - use case - mechanism), and the
> push draft has applicability beyond that.
> 
> Thanks
> --- Alex
> 
> > We have been wondering about the right home for the push draft.  Netmod
> might not be it because a generalized Pub/Sub mechanism might be needed
> beyond YANG encoding.  However we are hoping that the Pub/Sub mechanism
> could work with many transports (including multicast transports).  Is NETCONF
> WG able to support a Pub/Sub mechanism maximally decoupled from NETCONF
> transport?
> >
> 
> Looking at the charter of this WG, it seems pretty clear that NETMOD is not
> chartered to do protocol work. And NETMOD can't answer the question whether
> NETCONF can help you or any other working group.
> 
> That said, I am unsure what you want to do. Are we talking about <draft-
> netmod-clemm-datastore-push-00.txt>? That document defines YANG
> notifications and data objects, so this is a data model. But then you write "a
> generalized Pub/Sub mechanism might be needed beyond YANG encoding" that
> is "maximally decoupled from NETCONF transport". Is there another I-D for this?
> I really like to understand things better.
> 
> /js
> 
> --

---

From: Alia Atlas <[email-masked]>
Date: Wed, 5 Nov 2014 19:23:42 -0500

Eric,

This type of pub/sub functionality is something that is in the I2RS
architecture.

Regards,
Alia (no hats)
On Nov 5, 2014 6:54 PM, "Eric Voit (evoit)" <[email-masked]> wrote:

> Yes, both Juergen and Andy pointed out that such protocol work is not in
> Netmod charter.  And I completely agree this is something Netmod should
> *not* do.
>
> The point I communicated (poorly) is that additional drafts may need a
> home if the IETF desires Pub/Sub mechanisms beyond NETCONF.  Can any of
> this transport specific protocol work be generalized?  I don't know.  I do
> know of multiple implementations though.  Just for grins, below are some
> academic data-points showing people care...
>
> write "a

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 6 Nov 2014 08:57:28 -0500

20 min is cool.

> On Nov 5, 2014:10:47 AM, at 10:47 AM, Ladislav Lhotka <[email-masked]> wrote:
> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 6 Nov 2014 09:07:48 -0500

That is correct. We are not chartered to do protocol work. The notif stuff belongs elsewhere I think. 

	--Tom

> On Nov 5, 2014:5:05 PM, at 5:05 PM, Andy Bierman <[email-masked]> wrote:
>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Nov 2014 18:55:14 +0000

>is the right WG, but this is not in scope for NETMOD.

I only recommended NETCONF WG as the push-proposal appears to be an
extension to RFC 5277 (NETCONF Notifications) and maybe RFC 6470 (System
Notifications), both of which were done in the NETCONF WG.

Thanks,
Kent