Minutes IETF104: rtgwg
Routing Area Working Group
||Minutes IETF104: 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
2) 09:10-09:30 - draft-ietf-rtgwg-atn-bgp &
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
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
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
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.
it’s not L3. It’s better we take it offline. MEF has a good lead on
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
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
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
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
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
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
Rob: is this a device or service model?
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
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?
6) 10:10-10:20 - draft-mirsky-rtgwg-oam-identify
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
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
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
Chris B: let’s discuss it offline.
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
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 &
Sue: I’d like to put a spin. There is time for deployment. Some feedbacks
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.
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
3) 11:30-11:40 - draft-hu-rtgwg-srv6-egress-protection
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
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
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
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 &
Ignas: this is because importing modules from other SDO. Let’s discuss it
6) 12:05:12:15 - draft-chen-npm-use-cases
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
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
7) 12:15:12:30 - draft-nslag-mpls-deprecate-md5
Jeff H: TCP AO is finally starting seeing deployment. It protects half of
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
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