Minutes IETF103: rtgwg

Meeting Minutes Routing Area Working Group (rtgwg) WG
Title Minutes IETF103: rtgwg
State Active
Other versions plain text
Last updated 2018-11-29

Meeting Minutes


RTGWG IETF 103 Agenda

16:10-18:10     Monday Afternoon session II
Chitlada 3

RTGWG draft update:
Chris and Jeff
Jeff: welcome to Bangkok. Note Well. IPR disclosure.

RIB YANG Data Model
Yingzhen Qu
5 mins

Jeff: How many people have read draft?
      A few people respond...
Jeff: Please read.

A YANG Data Model for Routing Policy Management
Yingzhen Qu
5 mins

Acee:     Keyur requested to encapsulate lists in containers so they
          can be retrieved with a single NETCONF or RESTCONF operation.
Yingzhen: Will provide in the next revison.
Sue Hares: Please ask when they plan WG last call?
Acee:     Well before BGP YANG.
Jeff T:   As soon as possible, please review.
Sue:      BGP YANG model is waiting on this draft for WG last call.

Architecture for Use of BGP as Central Controller
Huaimo Chen
10 min

Chris B: based on the title, I thought it was related with BGP SR TE.
Huaimo:  slide 3 shows the block how to set up SR TE path. We can have a
         request, because BGP already has SR information and SID info,
         and controller can compute the path, then allocate SIDs along the path.
Chris B: there are methods being standardized to pass the information from a
         BGP controller to an ingress node, is this using those methods? It
         might be better to make some clarifications in the document.
Huaimo:  if there are existing solutions, we’ll use them.
Jeff:    you don’t have references. Please add more details what you’re trying
         to do.
Huaimo:  Yes.
Greg:    are you suggesting BGP to implement constrained SPF?
Huaimo:  yes. Why not?
Greg:    I just want you to say it.
Huaimo:  BGP already has those info. It’s easy to have CSPF to calculate
         traffic engineering path.
Tony Li: BGP is not a dump truck. I don’t want to go to that. Let me ask you a
         different question. What’s the difference between this and PCEP?
Huaimo:  PCEP is another protocol. It may increase your network cost. BGP is
         already a core protocol, we can reduce number of protocols. you don’t
         need to install controllers. Just like SR, customers are happy. We
         can reduce protocol number.
Tony:    customers may not be happy if youÕre folding more stuff into one
         protocol. All your complexities become one big monster.
Jeff:    please add more details into the draft.

Automatic discovery and configuration of network fabric in Massive Scale Data
Centers draft-heitz-idr-msdc-fabric-autoconf-00 Jakob Heitz 20 min

Chris B: is the network endpoint table on the controller or device?
Jacob:   on controller. The controller learns all the links, it’s a link
         state table.
Chris:   so it use the info to calculate SRv6 path. does switch has similar
Jacob:   device knows how to get to the controller. Controller gets to the
         device using SR.
Chris:   so it uses the ADJ sid.
Jacob:   yes.

Sam A:   what exactly are you standardizing here?
Jacob:   I need a couple of things in DHCP to make the DHCP piece work.
Sam:     I didn’t see those in the doc.
Jacob:   will do.
Sam:     what if the controller doesn’t know a device got added?
Jacob:   each device will be DHCP relay agent. If a device see router
         advertisement, if a router requires an address and sees the RA
         with M bit set, it will start the DPCH solicit.
Sam:     if the controller doesn’t know how to reach the router?
Jacob:   the controller knows how to reach a DHCP relay agent.
Sam:     the assumption is that the controller always can reach an agent.
Jacob:   the controller will always know how to reach a relay agent to which
         the new device is connected. BGP ensures connectivity to the
         controller as long as there are links. If a device is becoming total
         isolated, it’s not working.
Sam:     Let’s talk offline.
Tony Li: I like it. Will it be simpler to enable routing incrementally as you
Jacob:   slide 5. The yellow guy doesn’t know how to reach DUT because each
         device knows only its immediately connected. I’m doing this for
         scalability. You could run ISIS, but it doesn’t scale.
Tony:    isn’t MSDC gonna run some kind of routing?
Jacob:   that’s the draft I presented at IDR interim. BGP aggregated routing
         in IDR with RFC 7xxx.
Tony:    why not deploy that incrementally with messing with SR?
Jacob:   are you saying putting the aggregated address in the beginning?
         Before controller gets certain information, it doesn’t know which
         router it’s talking to.
Tony:    wouldn’t it be better if the controller has some knowledge ahead of
Jacob:   that would be nice. But it doesn’t have to.
Igor:    can you tell us which MSDC doesn’t have a topology defined ahead of
         time? we run datacenter. We have a controller that does something
         similar to this out of band. we predefine the topology, wire plan, etc.
         we don’t need auto discovery, why do we need this? We have controller
         which can do everything. We don’t let device auto config themselves.
Acee:    you said topology plan, do you use aggregated route?
Igor:    yes. We predefine those things, we have a plan. Controller will
         verify whether topology plan matches reality. Stick to the plan.
Jacob:   how does controller communicate with device? Through management port?
Igor:    controller connects to devices in band and out of band.  The initial
         configuration is done using out of band, that means in band doesn’t
         need to be up. If you were to do in band only, you would basically
         connect device one, then everything connected to the next ring. It
         doesn’t need a whole new protocol to do this. Is there customer asking
         for it? It seems a wrong way to configure the network.
Jacob:   I’d like to talk to you offline. basically you don’t need to
         configure any position dependent info, you can take a device out then
         put it back.
Igor:    in MSDC, you have wire plan and topology plan, MAC matches sys ID.
Jacob:   what if you put a different switch into that slot?
Igor:    the switch won’t come up because it doesn’t match the configuration.
         Again we design how things are, and it’s better be that way.
Jacob:   as long as it’s the same kind of switch, your controller can figure
         it out and make it work.
Igor:    again this is unlikely. This is not how it’s done. You will be doing
         power management etc, you can’t randomize things. Controllers are
         supposed to program according to the plan.
Jacob:   I can replace one switch with the same kind, not randomized.
Igor:    switch needs to installed to the place according to the plan.
Jeff:    this is a discussion that can go forever.
Acee:    I can see what you’re saying. It makes things easy. Are you saying we
         got wrong requirement?
Igor:    yes. It’s not random. You can do in band only.
Jacob:   I hear what you say. I can make changes. Let’s talk offline.

Jeff:    if this work continues, it belongs to RTGWG, not IDR.
Jacob:   it does belong to IDR. I have the name in IDR.
Jeff:    no. The file name doesn’t matter.
Jacob:   where do you think it belong?
Jeff:    here.

Architecture for Control and User Plane Separation on BNG
Sanjay Wadhwa
15 mins

Chris B: I’m not sure we’re tasked to pick a protocol. We were asked by BBF to
         focus on these drafts and their first liaison.
Sanjay:  the subsequent liaison says that we will have some BNG changes
Chris:   in the subsequent liaison it’s clear that they have yet to perform a
         feasibility study. until we’re told otherwise, they’re not asking us
         to pick a protocol.
Sanjay:  that’s why we’re calling it a candidate.
NingZong: PFCP is owned by 3GPP. are you asking IETF to do 3GPP extension?
Sanjay:  it has a number of different cases. Once our goal is not to reinvent.
         We want the BNG to be able to handle multi access.
Ning:    what you want IETF to do here? Protocol extension?
Sanjay:  correct. 3GPP is not going to looked at fixed BNG. We want to use a
         single protocol. We can extend those ideas here in IETF.
Ning:    so you want to extend 3GPP protocol and see if it can be applied here?
Sanjay:  Mobile IP is defined here and used in 3GPP.
Jason BBF liaison manager: pretty much what Sanjay is saying is true. There’s
         work on fixed only architecture detailed in TR 384, that’s liaised in
         March. What’s subsequently liaised is the work from the wireless
         wireline convergence group. The BBF has not consolidated the proposal.
         we’re trying to come up with a unified set of protocol that can deal
         with the whole thing.  BBF needs to sort out first.
Jeff:    time frame?
Jason:   the next meeting is December.
Georgios: the end liaison has been sent from BBF to IETF. The main goal of the
         liaison is to starting requirement to identify whether to separate
         user and control plane. What is clear is we like to focus on fix mobile
         convergence, meaning companies interested in this will have wait until
Sanjay:  3GPP, they’re not looking at fixed BNG.
Andrew:  we want to have a convergence of fixed and mobile. We don’t want to
         have three protocols. In stead of 2021, we’re looking at 2030.
Chris:   running out of time. let’s move on to the next presentation.

Architecture for Control Plane and User Plane Separated BNG: Update on cuspdt
drafts draft-cuspdt-rtgwg-cusp-requirements
draft-cuspdt-rtgwg-cu-separation-yang-model Donald Eastlake 15 min

Dave:    from BFF liaison manager point of view, sending an liaison will be
         good. If nothing else it will get some clarity back from BBF.
ZhongQiang Li from China mobile: what we need is the BNG for fixed network.
         we’ve already done some tests in our fixed network. They can satisfy
         requirements. I think IETF should focus on fixed network on user
         plane and control plane separation for BNG. We’d like to work with
         Nokia to develop the architecture on FMC.
Wim from Nokia: I think it’s good to send the liaison. I believe if we rush
         too fast into the fixed network we have a lost opportunity to solve
         the FMC use case.  I recommend we speed up the work together in BBF
         on FMC. So next IETF we can get requirements in and then see which
         protocol is the best. We should not come up with two different
Donald:  I disagree. The completion of these documents which ere already in
         use would have any significant effect on the timing of subsequent
Wim:     it’s up to BBF to decide.
Donald:  I don’t think doing what I’m suggesting will actually significantly
         affect the subsequent efforts.
Andrew:  I second what Wim said on sending the liaison. I also don’t like
         pseudo rush here. Trying to say this is done is premature. The amount
         of changes in software will be big.There is fundamental issues in
         protocol. We need to take time to work on it.
Donald:  I didn’t claim these drafts are in final form. There is work need to
         be done for editorial changes and completeness.
Andrew:  it’s not editorial change, from open flow to new protocol, I can show
         you this is even worse than open flow.
Georgios: there are carriers wanting to have a solution now. requirements for
         fixed network is very different. Not possible to have the same
         solution. What I have to say the timeline, if we want to have a
         common solution, for fixed network it will be complicated, time line
         will be after release 17, 2021. Carrier wants to have a solution now
         instead of waiting for 3GPP.
Sanjay:  we presented here is multi access BNG. When you looked convergence as
         a whole, it’s different. What’s presented here only works on Ethernet
         access BNG, not addressing the multi access part.
Ningzong: the fist liaison: I think it’s valid. The 2nd is to get more
         information, not a replacement.  I see the 1st one real requirement.
         We’re not against sending a liaison, but not to say we’re gonna have
         a unified protocol. We’re not against FMC case either.
Chris:   cutting the line.
Dave Allan: carriers wanted to support existing stuff, which meant we were
         going to end up with a platform that would terminate access protocols
         as PPPoE, hence the concern I raised in Montreal which is we have the
         opportunity to have many protocols support the same using facing
         functionality, and this was part of the motivation for the second
Wolfgang from DT: I just wanted to second the notion that fixed mobile
         convergence is not as straightforward as many people like to believe.
         There are products that aren’t there in the mobile world like access.
Geogis:  what’s the conclusion?
Jeff T:  the conclusion is there is no convergence yet. We see space for both
         groups to continue working. Hopefully there will be clarities by next

9:00-11:00      Thursday Morning session I
Chitlada 3

SD-WAN cloud interconnect problem statement and gap analysis
Linda Dunbar
20 min

Dino:    your comment about ONUG, so yes they want to come to the IETF for
         solutions. and a lot of people have done a lot of hard work to make
         that happen, however if the IETF comes up with too complex of salu
         they're gonna go elsewhere, or the vendors are just going to do it
         themselves. so you have to be able to articulate extremely clearly to
         these users what the solution is gonna be.
Linda:   yes.
Lou B:   on the gap analysis at the last meeting, we talked about RFC 5566
         having provided some possible capabilities and solutions. did you take
         a look at that?
Linda:   I took that out. I was told that was obsoleted and we shouldn't use it
         as a reference, so we took it out. we do want the controller to be
         aware of all the possible transport networks. some are underlay and
         some are overlay, they're different from tunnel. tunnel is end to end,
         and this is talking about particular segment.
Lou:     The encaps SAFI certainly could support segments. it's it doesn't
         know about the application, it just does about tunnels. so how I use
         it as your call. I was involved with deprecating that. in fact I
         advocated it since we were the only who implemented it, and thought it
         was too complex. but that was because there was no use case, and if
         you think your use case can be solved by something we've worked on
         before, it's better to use an existing solution than to go through the
         process of defining something new. so I encourage you to look at that
         and if it meets your use case, use it. if it doesn't, you know maybe
         look at what we ended up replacing it with, which was just the way
         everyone effectively used it because it's a lot easier which is the
         encap attribute figure out how to extend that or use that.
Linda:   I'm glad you gave this comments.I've been puzzled by this, and
         people told me not to fight.
Lou:     we updated it based on implementation experience. the experience is
         that we could use it in two different ways, and one of them we found
         to be overly complex for our use cases, and given that there were two
         ways and one was overly complex, we went with the one that was
         simpler. now this is a different use case okay.
Linda:   so for 5512, i want to separate between tunnels and the transport.
         so in SD-WAN we're talking about transport. the tunnel can be between
         CPE 1 and CPE 3, but the traversing can go through different networks.
         so that part even 5512 is not coming that, so that can be extended. we
         can talk about that offline. It'll be great if you can join the work.
Lou:     yes, that will be great. 5512 you can actually support stacking of
         tunnels. it allows you to do that, and it sounds that's what you're
         doing here. maybe I'm misunderstanding. so we can talk offline.
Linda:   I will talk to you afterwards.
Wim:     the two gaps which you identified so far it's mainly about IPSec
         tunnel establishment and the not traversal, are those the two main
Linda:   there could be more. I'm looking for more feedbacks. There are
         comments that this particular part wasn't described very well, we will
         get more feedback on that.
Wim:     there are way more gaps than you identified. we don't necessary
         reinvent. the IPsec process, still use IKE to do the process. I
         believe there could be some extensions which are useful but I'm not
         sure a new SAFI is the right way to go. there are other areas, like
         load balancing, that's another area not so easy to address.
Linda:   for IKE we had that more than our discussion in i2ns working group
         yesterday. so for the IKE itself the content we don't change, but how
         do we set it up. so in i2ns there are three cases. the first case is
         controlled or facilitated configuration, because for Ike has lots of
         configuration.  second case which has lots controversial is actually
         controller for the CPE which is low cost, low power.  they don't want
         to deal with or communicating with so many peers, so they depend on
         the controller to help them to do a key propagation. That created lots
         of issues. Third case, and Dave is in the room as well, so he proposed
         a third case is controller facilitate IKE. so controller facility IKE
         means for me I don't have to talk to everybody I just send it to my
         controller, my controller determine who do I send to, and then we need
         established the key.
Wim:     I think we agree that there is a problem to be solved. I think it's
         semantics on how to do it. I think it's where we need to have more
Linda:   Thank you so much.
Keyur:   I just wanted to remind you basically you and I had conversation. it
         is RFC 5566 that we are updating and ensuring that it goes over
         tunneling encaps. as an author of a tunneling encaps I'm updating both
         RFCs. so I just wanted to let you know that work is going on, happy to
         work with you and cover this.
Linda:   that will be great, thank you. so there is more reason to make it a
         WG draft.
Jeff T:  I think when you have BGP, when you have a hammer, everything looks
         like a nail. we really need to find right boundaries between
         management plain interruptions versus control interruptions. you
         shouldn't be doing everything bgp just because BGP is there.
Linda:   for us, we want something simple. more problems when scale up.
         everybody is using BGP. just like IPv4, people say don't use IPv4, we
         have IPv6. But because it's there, we just add something and make it
         work. They want to deploy it as fast as possible, as simple as
Jeff T:  we try to decide from architecture prospective.
Linda:   this is really an example solution. we need to show the problem, the
         gap, and example solution.
Chris:   if this is to become WG document, will you be open to suggestions?
Linda:   yes. Also the solution can be in other WG. Here is to identify the
         problem, gap, and stimulate other people to work on it.
Keyur:   if you're looking for solution outside of BGP, there was a draft
         expired that was a generic solution. when you can't fight, join them.
Dino:    there is a lisp crypto draft, negotiate keys without key management
Linda:   LISP was proposed as an alternative solution.
Dino:    glad you mentioned it.
Chris:   any other comments?
Jeff:    how many read the drafts? pretty good. I think Routing WG will take
         the work and continue to work on it.
Chris B: this is in the broad scope of RTGWG. is there anyone who think we
         shouldn't be working on this? (none) ok. thanks.
Jeff:    please keep it sync with data model progress.

SD-WAN service model
Bo Wu
10 min

Linda:    ONUG SD-Wan part abandoned the efforts. ONUG tried to catch the
          enterprises need, and they had interwork group. it takes long time to
          do interpretability. They found out enterprise today is more about
          portability. they've moved to security. they have defined APIs, and
          they may bring it to IETF. We should work with them.
Jeff:     it would be good to get Yang help? would you be able to reach Steve?
Bo:       yes. I'll ask Linda for help.
Chris:    this draft was presented at OPS. at this point, you want feedback
          from this group, we started efforts in SD-WAN, we will have
          continuing efforts. Just to provide some contexts, the work won't be
          adopted here, but it's related with our initiative.
Jeff:     please make sure different levels of Yang models are interoperable.

Explicit Topology Marking using RFC 8377
Donald Eastlake
5 min

Network monitoring protocol and neighbor state monitoring
Yunan Gu and Robin (Zhenbin) Li
15 min

Chris B:  the side meeting consensus means we don't need new protocols to do
          it. The project name, network monitoring protocols, sounds like we
          need new protocols. I was thinking network operators represented
          aren't at IETF. it might be useful to define use cases, a subset of
          data what's needed to troubleshoot. A mide-size operators won't look
          at thousands of YANG, so they can also benefit from the subset of
Jeff T:   GRPC and YANG push are there, data consumptions are how you model
          it and Yang helps. how do you relate events, so this is interesting
          space to work on. there's a lot of stuff out there that you didn't
          mention, I don't want us to reinvent the wheel. we need to focus on
          what needs to be solved rather than reiterating what has already been
          solved. so you mentioned some tools but didn’t mention some others I
          think we need to look wider what's available in the industry, what
          open-config is doing, what has been done in IGP and BGP working
          groups, where we define data model that also provide operational
Rob S:    I have some experience in this area. we've been working on this for
          a bunch of time I think the observation that we don't need another
          protocol is key. we've kind of defined some transports as Jeff said,
          we've been working on GRPC with a way to be able to have model data
          that doesn't need to be modeled in yang. I think that this moving
          towards a single solution is the right thing. there's two bits of
          work that I think the worth commenting on, one is what set of data do
          we need. I think it's an interesting problem to go and say okay what
          are the things that we can export, how to get it out of the device,
          what's the encoding is needed. we've done a bunch of work. there are
          shipping implementations of LSDB streaming. for example, over GRPC.
          we've kind of started to solve some of these problem spaces, where
          they're not traditional monitoring data sets. I think you'll find the
          largest implementations.  they're widely adopted, have some roadmap
          to getting a decent amount of the operational state we currently
          collect already. there's to me a problem space, around what
          additional data haven't we identified. I think some of that was what
          the point you were raising. basically, what instrumentation do we
          need in an implementation to be able to debug it. I would encourage a
          conversation with operators rather than a specification operator,
          because I would say that the expertise for operating. the other area
          that I think is interesting is this medium operator problem. I have a
          software engineering team and we're writing implementations. we have
          a bunch of resource to put on this. other operators maybe don't have
          the same expertise. the challenge there is that I don't think
          blueprints are the right thing. it's got to be running code. we need
          to get this kind of modern telemetry data at the stage of like mrtg,
          I can download a bunch of tutorials online that tell me how to get
          the things set up and have it go from data collection to graphing.
          right now, we've done a lot of work in the device facing bit. we've
          open source test frameworks around the data from the device. I think
          there's then the next layer up and so Yahoo oath recently open source
          panop sees which is their kind of next layer up. I think we should
          concentrate as an industry of getting this stack kind of stood up,
          and show how easy to adopt this stuff for those operators. that will
          make things go quicker. it's not necessarily standards documents or
          deployment documents.
Jeff T:   I don't always agree with Rob, but this one, yes. So it doesn't make
          sense to reiterate the things that have been solved. Let's focus on
          things that are not solved.
Rob:      did you agree with me or not?
Jeff T:   yes, I did.
Robin:    thanks for comments. We'll continue the work. Thanks for your help.
Jeff T:   please work with operators, not to reinvent new protocol.
Robin:    streaming telemetry can be a protocol, not new protocol.

How libyang, libnetconf, sysrepo, pyang are used in FRRouting
Dean Bogdanovic
20 min
Rob S:    we've done some other work in this area. just to add to the
          collective open source, we have a library that does from yang to
          Python and class bindings. we'll do a similar set of functionalities
          here. we also have written a library that's also open source. and in
          open-config it's called YGOT. that library also does yang to
          protobuf, which then gives you a bunch of other language bindings. it
          doesn't have the same validation, but at least lets you start dealing
          with the schema.  we've been using these with various other
Jeff T:   a buff to YANG ?
Rob S:    YANG to proto, not the other around. we don't take a proto and
          generate yang from it but we'll take a YANG model and generate a set
          of protobuf messages from it.
Jeff:     would you please send the info to the list?
Rob:      yes.

Michael A: we're looking into NMDA. we consider that like a suite.
Jeff T:   they're publicly available tutorial how to bring them together and
          make it work.
Michale A: yes, so sysrepo.org has everything. there are docker images and
          everything you can play with. We have Ubuntu packages. if it's not
          good, I'd  like feedback. Thank you.

David Dai: who will maintain the open source? how can user share experience?
Dean:     there is a community maintaining it. There is not a ready product.
          there is a difference between system product and open source. If you
          want to use it in open source in your product, you will contribute
          back to the community. This is where open source is valuable to
          kick-start certain things to be used by other people, and then
          through their commercial success they would give back to the open
          source community.
David:    everybody can do it?
Dean:     yes, and the question is if there is a critical mass of people and
          companies that have joint interest in supporting something like this.
          and based on the few last years, there is increasing interest and
          support for that. so this is just to raise the awareness in how it's
          been done and how his system been built. is it the system for
          production deployment? No, it's an example. but can they use those
          libraries to build a production ready system? Yes.
Lou:      one thing that Dean didn't say is that for most of what was talked
          about here is there up on github. anyone can go fork the repo, all
          the projects take pull requests. I'm a maintainer on FRR. we take
          pull requests from anyone all the time. when FRR was doing this
          particular work, I found a bunch of problems with live yang, and the
          person doing the work sent pull requests, and those folks accepted
          it. so it's sort of the normal today's open source process is being
Michael A: so we use this for managing both services and the home gateway for
          instance, I'm responsible for. there are other vendors that are using
          this in shipping products, as far as I've been told. because they
          needed to make their device manageable, so they took this and
          implement that. they were doing their own support for it, and it's
          not as much difference from Cisco or anyone else you know. Taking a
          bunch of tools and putting it in their products and then they sell
          support towards the end customer.  There are part of people involving
          development this that are consultants that I can direct you to them
          and if you want to get new features implemented, they can help you
          with that. we're developing a healthy community around all these
          different projects that are tied together in creating something that
          is useful as a whole.
Chris:    So some clarifications. The first part of your presentation talked
          about using open-source to do Network management as a network
          operator, this is more how you used open source in FRR the internals
          of a router, there's a distinction.
Dean:     in the beginning I said I will give you overview of the open-source
          tools that you can use in building a system, and then used FRR as an
          example how to use them. because I could have just left it, here's
          the overview of them, but this gives you an additional way how they
          were used in an open-source implementation.  you can go in there and
          take a look by yourself how it was exactly implemented.
Chris:    most of them will be using them to monitor networks.
Michael:  we were for instance in the process of packaging up the plug-ins
          that you use with sysrepo, but to implement the IETF interfaces an
          IETF IP and IETF systems model. so we use those standardized models,
          it talks to the kernel, it talks to the open wrt configuration
          subsystem.  Then you can configure this open wrt box. you can also
          take sysrepo in the same plugin and for the stuff that it talks to
          the kernel net link interface, you can run this on a server as well
          and you can change the IP address of the server interface or
          whatever. you didn't mention much about the plugins that you also
          need here, but this is what implements the model. you load the model,
          you load the plug-in, and now you can use the model that then runs
          the code in the plug-in that actually does something.
Dean:     there're guidelines how to develop plugins. I forgot to mention that
          each one of these daemons has its own plugin that is being used to
          connect to a different centralized management daemon. If you want to
          use a another one, you can develop that plugin by yourself and just
          use it there.
Jeff T:   if you're interested in FRR, there is tutorial.
Robin:    this is very useful. Open daylight also has some tools. you
          introduced this tool because it can satisfy because of this
          requirement of implementing plug-ins, correct?
Dean:     open daylight is a controller, it's at different layer. if you're
          writing new applications, and you want your applications to be
          managed by open daylight these are the tools to help you. essentially
          they're complementary.
Michael A: this makes the device manageable, not to manage the device. This
          was written in C, but the plug ins can be in different languages.
Rob:      we have implementations on tooling. Last year at ONUG, we had
          presentations, and there were examples. we have a few different
          projects working on this.
Jeff T:   can you make it available to the list?
Rob:      I just sent an email, will add to it.
Jeff:     will you be able to make a presentation with more details at next
Michael:  sure.
Lou:      one comment following up on what the Dean was talking about. this is
          can be used by others in their products, that's interesting for the
          IETF. I think it's really interesting that this can serve as a
          reference of an early implementation for emerging work that we're
          doing here, and it can really inform our work. for example, we were
          talking offline about how to support different versions based on
          what's going on in NETMOD with versioning. Having the hands-on
          experience can really help us make sure that what we're doing here
          works and help identifying any shortcomings in our specifications.
Dean:     I wanted to raise support for the same comment from Lou. I heard
          that from some other areas that they are having in their draft
          development process that they are having what they called release
          drafts, where they are looking together with the open source
          community to making sure that the draft has been forwarded is
          implementable. what is good, what is bad, and use it as a corrective
          action. this process that was done by the community was very helpful
          to validate some of the concepts and get some feedback in this whole
          draft development process.

Jeff T: Thanks everybody, and we'll see you in Prague.