* 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-104 rtgwg minutes

Session 2019-03-26 0900-1100: Congress Hall 1 - Audio stream - rtgwg chatroom
Session 2019-03-29 1050-1250: Grand Ballroom - Audio stream - rtgwg chatroom


minutes-104-rtgwg-00 minutes

          Tuesday, March 26, 2019
          9:00-11:00      Tuesday Morning Session; Congress Hall 1
          RTG    rtgwg       Routing Area Working Group
          Chairs: Jeff Tantsura, Chris Bowers
          WG Status Web Page: http://tools.ietf.org/wg/rtgwg/
          1) 09:00-09:10 - WG Status Update
          Jeff Tantsura, Chris Bowers
          10 minutes
          2) 09:10-09:30 - draft-ietf-rtgwg-atn-bgp &
          Fred Templin
          20 minutes
          Chris B:   you had some experimental data? Can you provide some details?
          Fred:      100 packets/s through BGP, then withdraw a route. We saw
                     drop, that’s how we found the problem.
          Jeff:      can you have an appendix to describe this problem?
          Fred:      good suggestion, we can do it.
          3) 09:30-09:50 - draft-wu-model-driven-management-virtualization
          Qin Wu
          20 minutes
          Greg:      are you aware of the work at MEF, service, orchestration etc?
          Qin:       yes. these are similar to service models at IETF.
          Greg:      there are models from IETF defined from SPs pointer of view,
          like L3VPN.
                     MEF defines from Subscribers point of view, like UNI. What
                     you’re describing
                     here is what MEF is already doing.
          Qin:       there are service models defined from different angle. For
                     L3vpn also considered customer’s point of view. We’re
                     compliant with those models.
                     There is no conflict, but we do need to collaborate.
          Greg:      there are models, carrier ethernet, defined to order
          services. MEF UNI model is being
                     published, and there are service OAM, testing etc. I’d
                     suggest be careful with duplicate
          Qin:       we’re aware of those. We’re take it offline and cooperate
          with other SDOs.
          Greg:      speaking of work cycle and orchestration, IETF is behind. I’d
          encourage you to look
                     at MEF etc. like service OAM, or testing model.
          Qin:       MEF models are more carrier specific. At IETF, you can leverage
          YANG push etc.
          Greg:      I’m just suggesting to look at what MEF is doing.
          Rob Wilton:    For Greg, at MEF, are they referencing IETF model for
          Greg:       work on L3 is being developed, they do have carrier ethernet,
          that’s L2. Again
                      it’s not L3. It’s better we take it offline. MEF has a
                      good lead on that.
          Qin:        we may leverage the work there. At IETF, it’s better we
          have some thing to reference
                      to help developer and service providers. It’s important
                      to map MEF service model to
                      IETF device model. We’re engaged with MEF already.
          Charles:    I’m active at MEF. there are overlaps, even conflicts
          between MEF and IETF.
                      There are service models at MEF, which are different from
                      IETF. It starts from MEF,
                      then switch to some propriety model, or some model being
                      defined in MEF. We’d
                      like to use some models defined in IETF.
          Yong Lee:   I’m an active participant at MEF. I don’t see any
          conflicts between MEF and
                      what Qin is doing here. MEF has different ideas, they don’t
                      always use YANG models.
                      Definitely within in IETF, we have security build in. I
                      disagree with what Greg said.
          Rob:        I have sympathy with what you said in terms IETF has lots
          of models from different
                      WGs. Having some informational model to make some suggestions
                      will certainly help.
                      This is useful. Mapping service model from other SDOs with
                      IETF is also useful.
          Qin:        That’s one of our motivations. we’d like to provide
          reference for customers. This draft is
                      trying to inspire some discussions to see whether new work
                      is needed.
          Rob:       I have Yang Package draft in NETMOD might be helpful. How
          to package
                     things together. That’s another way to solve the
                     problem. Another way
                     is through tags, which is being WG last called. There are
                     ways to solve this problem.
          Qin:       Yang Catalog is also related. We did some work in Hackthon. We
                     need additional input to make people aware of it.
          Jeff T:    I disagree with Greg. MEF models don’t provide enough
          Chongfeng: most models are not widely used in SPs. This draft may help for
                    carriers. I support this work.
          Ignas:      thanks for raising this. you brought up a lot of pain
          points. But
                      on the other hand, you’re proposing to add another layer
                      of models
                      to solve the problem, that will not happen. it’s not
                      realistic to
                      define a set of service model for all interconnected
                      products. it’s
                      not practical as different customers have different
                      About the quality of the models, that’s problematic area. We
                      do have
                      technology model, but they implement the same function not
                      necessarily in workable way . This is area need to be
                      addressed first.
                      Thank you for the work.
          Stephane L: there are no implementations. Plus we don’t have enough
          models to
                      make it work. IETF is slow. We don’t have enough people
                      working on it.
          Qin:        we can start from LNE model.
          Stephane:   there are OC models ready to be used, whether to use IETF
          is in question.
          Qin:        if IETF can catch up, it is more promising.
          4) 09:50-10:00 - draft-li-rtgwg-tunnel-policy-yang
          Donald Eastlake
          10 minutes
          Rob:       is this a device or service model?
          Donald:    service.
          Tarek Saad: there are some work done in TEAS. What are you trying to
          define here?
          Donald:    select tunnels.
          Vishnu:    TEAS this afternoon.
          xx:        in TEAS there is work on how to map service on tunnels,
          it seems overlap.
          Jeff Hass: please consider changing the name to be less generic.
          Dhruv:     this sounds more like device model. Other work at TEAS is
          service level.
          Lou Berger: if your focus in tunnels, you may want to come TEAS. If
          your focus
                     is VPN, then BESS. Either way you need to know the work
                     at TEAS.
          Jeff T:    please look at TEAS, and know what should be done.
          5) 10:00-10:10 - draft-ietf-rtgwg-arp-yang-model
          Rob Wilton
          10 minutes
          Jeff Hass: I have some thoughts based on SNMP. If you really have
          to separate
                     internal subsystems that can have distinct discontinuities,
                     makes sense. YANG is more towards a cohesive view, you’re now
                     putting in a hint to the system that some pieces of a tree
                     have completely different idea of counters. That’s tricky.
          Rob:       After the router is rebooted which is one standard
                     time. Clear statistics is what I’m worrying about. Maybe
                     we shouldn’t
                     allow it in YANG.
          Jeff:      I don’t think it’s wrong ideas, but it’s tricky. We
          should discuss
                     it in NETMOD.
          Jeff H:    This is something a platform needs to decide. You chose
          a default,
                     which might be wrong for some platforms.
          Rob:       they have a choice to deviate. If every one is different,
          you have to
                     leave it vague.
          Jeff H:    you may want to put a comment in the module for deviation.
          Jeff T:    would we start Yang doctor review after resolving these issues?
          Rob:       yes.
          6) 10:10-10:20 - draft-mirsky-rtgwg-oam-identify
          Greg Mirsky
          10 minutes
          Jeff T:   please ask people to participate on the list.
          Greg:     will do.
          7) 10:20-10:35 - draft-ietf-rtgwg-segment-routing-ti-lfa
          Stephane Litkowski 
          15 minutes
          Stewart:  I’m afraid we’re losing the unconditional
          correctness. Fundamentally
                    you should repair in the topology you work in.
          Stephane: I agree.
          Jeff T:   support single algorithm within a calculation.
          Chris B:  for option one about local policy, please spell out an
          example for
                    that may cause loop, and how to avoid it.
          Stephane: yes. each flex-algo will have a strict version, we’ll double
          the algorithms.
          Stewart:  you need to operate in a topology in terms of path and repair
          Peter P:  we don’t need this strict algorithm for every flex-algo.
          Jeff T:   are you suggesting a more generic way to do it?
          Peter P:  no. the LFA should be calculated within a single algorithm.
          8) 10:35-10:50 - draft-wood-rtgwg-sdwan-ose-yang
          Bo Wu/Steve Wood
          15 minutes
          Wim:   I think this is good work in general. Are you going to L2 or
          L3 example?
                 What do you prefer to use?
          Bo:    we don’t touch it. it depends on the domain to decide L2 or L3.
          Wim:   it’s good to leverage the ONET work.
          Steve: are you talking about between the gateways?
          Wim:   it’s not only about interconnections, also end to end connection.
          Steve: it’s about how to stitch those things.
          Wim:   we can take it offline. I hope we can make it a reference model for
                SD-Wan service.
          Chris B: let’s discuss it offline.
          Wrap Up
          Jeff, Chris
          Friday, March 29, 2019
          10:50-12:50     Friday Morning session II ; Grand Ballroom
          RTG    rtgwg       Routing Area Working Group
          Chairs: Jeff Tantsura, Chris Bowers
          WG Status Web Page: http://tools.ietf.org/wg/rtgwg/
          1) 10:50-11:10 - draft-homma-slice-provision-models
          Shunsuke Homma
          20 minutes
          Greg:     how this work is related with MEF? Because MEF has a slicing
                    matching what you’re trying to do.
          Shunsuke: Slicing is not just for 5G.
          Greg:     have you looked at what they’re doing?
          Shunsuke: I’m trying to provide a protocol for customer.
          Greg:     it’s better to check other SDOs before starting. It’s
          better to send
                    a liaison for review. This work has been done in MEF already.
          Jeff T:   procedure wise we’ll send a liaison if we decide to do the
          work. Now
                    it’s just a personal draft.
          Greg:     I’d suggest to review work done in MEF.
          Jeff T:   it will be good if you review other SDOs work.
          Shunsuke: I think we need to unify.
          Robin:    In TEAS, there are some slicing work that need to be aligned.
          Shunsuke: we’re trying to clarify the relationships.
          Robin:    I just made a suggestion.
          Jeff T:   there are other work going on.
          2) 11:10-11:30 - draft-ietf-rtgwg-net2cloud-gap-analysis &
          Linda Dunbar
          20 minutes
          Sue:      I’d like to put a spin. There is time for deployment. Some
                    are needed.
          Linda:    thank you.
          Chris:     what’s the focus of these two documents? Gap analysis is
          focusing on
                     connecting SDWAN to cloud, to make it standard? Is it accurate.
          Linda:     yes
          Chris:     the title is a bit misleading.
          Linda:     we call it network to data center, because it’s the main
          drive in
                     market. It’s different from the original SDWAN, in ONOG now,
                     the main
                     idea is to reach cloud from anywhere. I call it network to
                     cloud, to
                     emphasize it’s not just to connect branch offices.
          Chris:     some examples are not about connect to cloud. Just to look
          at the
                     title, it’s not clear.
          Linda:     we’ll add a session to clarify.
          Jeff:      it would be good if you put more solid example. How to
          connect from
                     to cloud, so readers can easily figure out what this document
                     is about.
          3) 11:30-11:40 - draft-hu-rtgwg-srv6-egress-protection
          Huaimo Chen
          10 minutes
          Greg:    I recall we had similar discussion on RSVP TE. It would be good
          to have
                   a strong use case. You’re changing SR now to create a
                   transition state.
          Huaimo:  we can add some reference regarding the 1st point. For the 2nd,
          it’s to
                   add more function.
          Greg:    we need to discuss whether we need it.
          Huaimo:  this is from a customer.
          Greg:    there are other solutions for this, why make it more
          complicated? The
                   simplicity for SR is broken here, you’re going back to RSVP TE.
          Huaimo:  the states here are much less compared to RSVP TE.
          Greg:    you also need to monitor your backup path. You’re creating
          new state
                   and complexity. We need to discuss whether this is needed?
          Huaimo:  I don’t think it’s complicate. Either we monitor or compute
          backup path,
                   we need to do it either way.
          Greg:    if you’re advocating compute from upstream, it can be done by
                   controller. Again we need to discuss whether it’s needed.
          Jeff:    Greg, please send your statement to the list for discussion.
          Peter:   On the contrary, I think this is interesting problem to
          solve. However
                   you solution only works if you have the same VRFs on the PEs
                   which may
                   not be true. 2nd the synchronization is needed between the
                   PEs. I agree
                   with the problem statement, but the solution is not complete,
                   more work
                   needs to be done.
          Huaimo:  we’ll enhance.
          Jie:     I think this is good idea to solve the problem. We’re not
                   per path state.
          xx:      PE1 already have two paths to CE. these are resolved already.
          Jie:     this is for local protection, not end to end.
          Greg:    how do you detect the failure?
          Huaimo:  PE1 will detect.
          Greg:    no. You can’t distinguish node failure from link failure. You
                   know what failed in a tunnel.
          Huaimo:  we have detailed discussion in the draft.
          Chris B:  good discussion. this is a problem needs to be solved.
          Stewart:  regular FRR can fix it. It will take two failures for FRR
          not working
                    for this problem.
          Himanshu: if you’re doing BGP PIC, it will switch PE4. This has a
          limited scope.
                    There are other solutions too.
          Jeff:     lots of work done in this area. Please review those and start a
                    discussion on the list.
          4) 11:40-11:50 - draft-li-6man-ipv6-sfc-ifit
          Zhenbin Li
          10 minutes
          Joel:     It’s on the wire. We have multiple encapsulations, making
          another one
                    doesn’t help. The point of SFC is to provide a common
                    transport, this
                    were brought up in SPRING, it supposed to work with all
                    so we don’t have N**2 issue. Creating SRv6 encapsulation
                    for this, we
                    need to think about it.
          Shuping:  we’ll consider your comments later.
          Robin:    is there any draft about SFC in IPv6?
          Joel H:   SFC is not about specific data plane. we’ve done one in
          MPLS. If we
                    can do similar thing, we can do SFC in SRv6 or IPv6.
          Jeff H:   you’re introducing recomputing at every hop at line
          rate. It’s
                    something to consider.
          Shuping:  for the meta to be inserted, it’s only to write. If we want
          to add
                    ioam, it has to be inserted somewhere.
          Greg:     if you add something in the packet, you need to recalculate the
                    checksum. Put them in the packet has limitations, like
          Shuping:  that belongs to IPPM.
          Greg:     are you doing protection? Then you have extra work. There
          are other
          Cheng Li: the problem mentioned by Greg is not unique, it applicable to
          all iOAM.
          Greg:     are you proposing solution or problem?
          Cheng Li: solution.
          Greg:     you’re introducing problem.
          Shuping:  security of the data , or risks introduced by these data
          are different.
                    We have solutions.
          Greg:     please think about the problem.
          Jeff T:   this really belongs to IPPM
          5) 11:50-12:05 - draft-ietf-rtgwg-yang-rib-extend &
          Yingzhen Qu
          15 minutes
          Ignas: this is because importing modules from other SDO. Let’s discuss
          it offline.
          6) 12:05:12:15 - draft-chen-npm-use-cases
          Yunan Gu
          10 minutes
          Jeff T:   the use case is needed. You’re gathering op state, how do you
                    establish your intension? Let’s discuss offline.
          Acee:     you have a proposal to collect all info in IGP while we’re
          trying to
                    reduce flooding.
          Chris B:  that’s from customer case.
          Acee:     like BMP for isis. It’s going to increase the overhead. This
          has a
                    different application range other than data center.
          Jeff H:   you may injecting data into the network through IGP, which
          might be bad.
          7) 12:15:12:30 - draft-nslag-mpls-deprecate-md5
          Andy Malis
          15 minutes
          Jeff H:    TCP AO is finally starting seeing deployment. It protects
          half of
                     your story.
          Andy:      it’s still better than MD5.
          Alvaro:    this one has some history. If TCP AO referred, use TCP IO.
          Andy:      perhaps we can do better.
          Eric Gray: it seems AO is a TCP thing. What additional support you need
          to do?
          Andy:      it’s implementation issue.
          Eric:      I’m just curious what extra work need to be done.
          Jeff H:    maybe you can consider IPsec, although it’s not my
          favorite. You can
                     use both of them there. The challenge is that security
                     people want
                     you to use it. In routing, it’s a chicken egg issue. You
                     spend some
                     effort, you can get IPsec work there.
          Andy:      oppose we use TCP AO, what do you suggest about crypto
          algorithm for
                     LDP? Especially for low end router.
          Jeff H:    I don’t have specific experience with these
          algorithms. Security
                     people tend to suggest something heavy. The requirement
                     for routing
                     might be different, you want something enough to cover
                     your need.
                     We don’t want something overkill. You want something
                     strong enough
                     to provide reasonable protection. For example, key roll over
                     may help.
          Stewart:   how often do we need to spin a key so security people will
          be happen?
          Jeff H:    hmd5 was suggested.
          Hamashu:   I’m glad you bring it up. What’s your goal?
          Andy:      does anyone care? Using Md5?
          Stewart:   are they using it for checksum? Or security?
          Andy:      we don’t know.
          Jeff T:    MD5 is deployed. It’s difficult to get operators to do
          something different.
          Wrap Up:
          Jeff, Chris

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