Minutes IETF104: rtgwg
minutes-104-rtgwg-00

Meeting Minutes Routing Area Working Group (rtgwg) WG
Title Minutes IETF104: rtgwg
State Active
Other versions plain text
Last updated 2019-04-04

Meeting Minutes
minutes-104-rtgwg

   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 &
draft-templin-rtgwg-scalable-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 packets
           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 example,
           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 work.
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 device? 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 different
           ways to solve this problem.
Qin:       Yang Catalog is also related. We did some work in Hackthon. We do
           need additional input to make people aware of it.
Jeff T:    I disagree with Greg. MEF models don’t provide enough details.
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 requirements.
            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, that
           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 could
           have completely different idea of counters. That’s tricky.
Rob:       After the router is rebooted which is one standard discontinuity
           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 path. 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 project,
          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 &
draft-ietf-rtgwg-net2cloud-problem-statement
Linda Dunbar
20 minutes

Sue:      I’d like to put a spin. There is time for deployment. Some feedbacks
          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 introducing
         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 don’t
         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 encapsulation,
          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 integrity.
Shuping:  that belongs to IPPM.
Greg:     are you doing protection? Then you have extra work. There are other
          proposals.
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 &
draft-ietf-rtgwg-policy-model
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