* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Rtgwg Status Pages

Routing Area Working Group (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2004-Feb-19 —  

IETF-103 rtgwg minutes

Session 2018-11-05 1610-1810: Chitlada 3 - Audio stream - rtgwg chatroom
Session 2018-11-08 0900-1100: Chitlada 3 - Audio stream - rtgwg chatroom


minutes-103-rtgwg-00 minutes

          RTGWG IETF103
          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
                   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
                   already a core protocol, we can reduce number of protocols. you
                   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
                   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
          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
          Jacob:   device knows how to get to the controller. Controller gets to
                   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
                   the new device is connected. BGP ensures connectivity to the
                   controller as long as there are links. If a device is becoming
                   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
                   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
                   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
                   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
                   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
                   which can do everything. We don’t let device auto config
          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
          Igor:    controller connects to devices in band and out of band.
          The initial
                   configuration is done using out of band, that means in band
                   need to be up. If you were to do in band only, you would
                   connect device one, then everything connected to the next
                   ring. It
                   doesn’t need a whole new protocol to do this. Is there customer
                   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
          Jacob:   what if you put a different switch into that slot?
          Igor:    the switch won’t come up because it doesn’t match the
                   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
                   it out and make it work.
          Igor:    again this is unlikely. This is not how it’s done. You will be
                   power management etc, you can’t randomize things. Controllers
                   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
          Sanjay:  it has a number of different cases. Once our goal is not to
                   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
          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
                   wireline convergence group. The BBF has not consolidated the
                   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
                   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 2021
          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
          Donald Eastlake
          15 min
          Dave:    from BFF liaison manager point of view, sending an liaison will
                   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
                   we’ve already done some tests in our fixed network. They can
                   requirements. I think IETF should focus on fixed network on
                   plane and control plane separation for BNG. We’d like to work
                   Nokia to develop the architecture on FMC.
          Wim from Nokia: I think it’s good to send the liaison. I believe if we
                   too fast into the fixed network we have a lost opportunity to
                   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
                   protocol is the best. We should not come up with two different
          Donald:  I disagree. The completion of these documents which ere already
                   use would have any significant effect on the timing of
          Wim:     it’s up to BBF to decide.
          Donald:  I don’t think doing what I’m suggesting will actually
                   affect the subsequent efforts.
          Andrew:  I second what Wim said on sending the liaison. I also don’t
                   pseudo rush here. Trying to say this is done is premature. The
                   of changes in software will be big.There is fundamental issues
                   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
                   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
                   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
                   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
                   We’re not against sending a liaison, but not to say we’re gonna
                   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
                   going to end up with a platform that would terminate access
                   as PPPoE, hence the concern I raised in Montreal which is we
                   have the
                   opportunity to have many protocols support the same using
                   functionality, and this was part of the motivation for the
                   second liaison.
          Wolfgang from DT: I just wanted to second the notion that fixed mobile
                   convergence is not as straightforward as many people like to
                   There are products that aren’t there in the mobile world like
          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
                   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
                   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
                   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
                   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
                   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
                   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
          Linda:   I will talk to you afterwards.
          Wim:     the two gaps which you identified so far it's mainly about
                   tunnel establishment and the not traversal, are those the two
                   main caps?
          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
          Linda:   for IKE we had that more than our discussion in i2ns working
                   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
                   semantics on how to do it. I think it's where we need to have
                   more discussions.
          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
                   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 possible.
          Jeff T:  we try to decide from architecture prospective.
          Linda:   this is really an example solution. we need to show the problem,
                   gap, and example solution.
          Chris:   if this is to become WG document, will you be open to
          Linda:   yes. Also the solution can be in other WG. Here is to identify
                   problem, gap, and stimulate other people to work on it.
          Keyur:   if you're looking for solution outside of BGP, there was a
                   expired that was a generic solution. when you can't fight,
                   join them.
          Dino:    there is a lisp crypto draft, negotiate keys without key
          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
                   the work and continue to work on it.
          Chris B: this is in the broad scope of RTGWG. is there anyone who think
                   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
                    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
          Bo:       yes. I'll ask Linda for help.
          Chris:    this draft was presented at OPS. at this point, you want
                    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
          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 data.
          Jeff T:   GRPC and YANG push are there, data consumptions are how you
                    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 stage.
          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
                    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
          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 implementations.
          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
                    make it work.
          Michale A: yes, so sysrepo.org has everything. there are docker images
                    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
          Dean:     there is a community maintaining it. There is not a ready
                    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
                    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
                    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 followed.
          Michael A: so we use this for managing both services and the home gateway
                    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
                    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
                    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
                    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
                    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
                    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
          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
          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
                    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.

Generated from PyHt script /wg/rtgwg/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -