Re: [Rtg-yang-coord] [netmod] ietf 91 netmod agenda (revised)

["Eric Voit (evoit)" <[e-mail]>]

Hi Alia,

It would be great to make a subset of Pub/Sub related drafts reusable for I2RS.  No matter what WG eventually owns the charter.

To make some progress here. I looked at I2RS draft-ietf-i2rs-architecture-05 and pulled out the following:

·        section 6.3 says that when local config preempts I2RS, external notification might be necessary

·        section 6.4.2 points to “subscribing to an information stream of route changes receiving notifications about peers coming up or going down”

·        section 7.6 is gives high level pub/sub (notification) guidance

Trying to learn more, I looked at two other drafts, and pulled out some requirements which perhaps cover more I2RS needs:

draft-ietf-i2rs-usecase-reqs-summary

·        PI-REQ01: monitor the available routes installed in the RIB of each forwarding device, including near real time notification of route installation and removal.

·        PI-REQ05: The ability to interact with traffic flow and other network traffic level measurement protocols and systems

·        PI-REQ10: The ability to interact with policies and configurations on the forwarding devices using time based processing, either through timed auto-rollback or some other mechanism.  This interaction should be through existing configuration mechanisms, such as NETCONF, and should be recorded in the configuration of the local device so operators are aware of the full policy implemented in the network from the running configuration.

(expired) draft-camwinget-i2rs-pubsub-sec shows the need for:

·        Time delivery sensitivity

·        Support for multiple protocols or implementation layers

·        Secure, authorized communications

·        Support for a range of data delivery content

There is a wide range of guidance in the bullets above.  So I stepped back and looked at some history.  There are a number of switching and routing protocols which have done pub sub in the past.  It turns out that several of these have a deep relationship with multicast.  For example:

·        Audio-Video Bridging streams needing guaranteed latency (802.1Q-2011 Clause 35)

·        Multicast Routing Adjacencies in MPLS VPNs  (RFC6513)

·        OSPF uses multicast addresses for Route Flooding (RFC2328)

·        Every multicast topology establishment protocol (IGMP, PIM, etc.)

Since NETCONF is connection oriented, perhaps we will need alternative transports for these type of notifications/messages.

As we try to progress draft-netmod-clemm-datastore-push, we will try to ensure YANG objects representing subscriptions stay independent of underlying transport.  I believe this is worthwhile.  Do you agree?   If yes, that provides a context for future decomposition of some of the work.   Beyond that I was wondering if you have thoughts/guidance/pointers on what other transports beyond NETCONF might be needed in the near term for I2RS?

Thanks,
Eric


From: Alia Atlas, November 05, 2014 7:24 PM


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)" <[e-mail]<mailto:[e-mail]>> wrote:
> 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
>
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[e-mail]<mailto:[e-mail]>]
> Sent: Wednesday, November 05, 2014 2:41 PM
> To: Eric Voit (evoit)
> Cc: Kent Watsen; Alexander Clemm (alex); [e-mail]<mailto:[e-mail]>
> Subject: Re: [netmod] ietf 91 netmod agenda (revised)
>
> On Wed, Nov 05, 2014 at 09:56:15PM +0000, Eric Voit (evoit) wrote:
> > > From: Kent Watsen, November 05, 2014 3:13 PM
> > >
> > >
> > > 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.
> >
> > 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
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod