Minutes IETF106: rtgwg
Routing Area Working Group
||Minutes IETF106: rtgwg
RTGWG Agenda IETF 106
Chairs: Chris Bowers
Secretary: Yingzhen Qu
WG Status Web Page: http://tools.ietf.org/wg/rtgwg/
Jabber room: email@example.com
RTGWG Session 1
Wednesday, 20 Nov 2019, Afternoon Session I 13:30-15:00
Room Name: Padang
WG Status Update
draft-ietf-rtgwg-bgp-pic has changed shepherd, and Yingzhen will take over.
Regarding expired draft:
Draft-ietf-rtgwg-segment-routing-ti-lfa: Stephane: we’re in the process of
updating it, but it will take more time.
Yingzhen: both RIB extension model and routing policy model have been stable,
will request last call after this IETF.
Dynamic Networks to Hybrid Cloud DCs
Stewart: I don’t understand what you’re proposing. You’re talking about
proprietary cloud designs which are within the scope of the provider
to define and modify APIs, we don’t have standard solutions. You can
design a sim layer that they have to map to, but we can’t map
Linda: I’m not proposing a solution. I’m just saying it’s a problem, which
might be out of the scope of IETF. It’s just a problem.
Wim: you start from problem statement, then you’re mixing SDWAN with
net2cloud. You’re putting too much content. You should focus on cloud
interconnection or SDWAN. From reading the document personally I don’t
do where you want to go.
Linda: good suggestion. we’ll focus on net2cloud, taking out SDWAN.
Wim: focus on two requirements: internet facing services, and private VPN
use cases. Focus on these two areas and make it clear what needs to
Jeff T: maybe you can consider separating SDWAN work if you consider it’s
valuable. You’ve put lots of efforts writing it.
Linda: I’ll write a short draft focusing on problems with net2cloud, not
SDWAN. If I found some of valuable parts, I will create a separate
Application-aware IPv6 Networking (APN6)
Problem statement & usecases and Framework
Wim: why contain to IPv6 only?
Shuping: it doesn’t have to be. We will have to do with extensions for
MPLS/IPv4. Wim: SR has both MPLS and IPv6. is it possible to do with MPLS?
Shuping: yes, we acknowledge that and we’ve done some analysis. We’d like to
carry not only ID but also meta data.
Wim: you can do meta data in SFC.
Robin: regarding data plane, it’s open. IPv6 seems to be simplest because of
SRv6, but MPLS and VxLAN based are possible. For SFC, we don’t think
it’s enough. Meta data is not standardized well.
Wim： you should make it open although I believe IPv6 is the future.
Erik Kline: I’d suggest removing the revenue related part from the document.
This has network neutrality issue. In the framework, you have
application sending metadata that has some serious privacy issues. You
could end up forcing devices in a large network to DPI their traffic,
and I don’t see the issues being discussed in these documents. It’s a
Shuping: we acknowledge the security and privacy issue, and that’s documented
in the draft. Some mechanisms such as access control and
authentications are needed.
Erik Kline: the potential for abuse is not discussed.
Jeff T: looking at 6man SRH discussion, they’re focusing on a single domain.
You’re proposing Internet wide?
Shuping: we could start from a single domain. We discussed with operators and
they own their networks as well as the applications.
Jeff T: my point is privacy should be a center work. if you can’t provide
privacy, technology is not usable.
Shuping: my understanding of privacy is information exposed by applications,
and the information can be encrypted, also the applications should be
Jeff T: I’d like you make this the center of your work and make it clear how
you’re going to do it.
Aijun Wang: I think this is useful, and we want to make sure to make the
applications SLA insurance. there are so many applications, if you use
application ID and the router may not be able to hold so much
information. How do you consider this problem?
Shuping: it depends on the device capability. First, not all applications are
process this way, only for demanding applications with special needs.
Aijung Wang: for traditional network, we classify applications into several
categories, and it can be easily deployed. it’s not possible to deploy
these many different applications.
Shuping: that’s about how to design the application ID. Currently we have
segment, and could somehow to categorize traffic into groups.
Doc Montcomery: why can’t you achieve with existing solutions like QoS, is it
in the draft?
Robin: yes. There is problem statement in the draft.
Doc: is your ID global unique?
Shuping: that depends. It needs to be unique in one domain. And we will need to
consider multi domain case.
Linda: I found it’s very useful. Even people are concerned with security
reasons, we can do something to hide user information. Bring the
application information into the network is very helpful, and this
has been discussed in other SDOs. Customers want application based
forwarding not based on IP address but application ID.
SRv6 Path Egress Protection
Kereeti: do you think it will work with SRv6+?
Huaimo: if SRv6+ progress, we will consider adding support for it.
ChenWeiQiang from China mobile: This is useful. For 4G, China Mobile deployed
dual home for protection. I think this can be used in future. Can it
be configured more than more back up?
Huaimo: we need to consider it.
Aijun: can the mapping be done automatically? Currently it’s configured.
Huaimo: it can be manually configured. right now it’s controller environment
and can be done through controller.
Aijun: if this can be deployed automatically it can ease the management of
Huaimo: this draft is about basic solution. Based on this, we can extend the
Shraddha Hedge: you could use any cast locator, why is it not used here?
Huaimo: the locator here provides the association of egress node.
Shraddha: just same locator on both PE3 and PE4, and it will be the same SID.
Anycast locator. You think it works?
Jeff T: for my understanding, you’re providing back up. Unless your primary
is down, traffic is send to the primary. For anycast, traffic is sent
to any node.
Huaimo: I don’t know the exact semantics.
Jeff T: you’re proposing backup while Shraddha is proposing any cast, and
there is difference.
Louis Chan: if you want to protect VPN, do you need to look deep into the
packet? How many labels do you need to read into the stack?
Huaimo: for vpn, we need more information and the details are in the draft.
Stewart: we’re not ready. You need to consider whether any cast is better
solution, and whether you’re compliant with architecture design.
Jeff T: please use the list to discuss the issues.
Architecture for Use of BGP as Central Controller
John Scudder: why do we need to work on this? People already have been doing
for some years and seems like we could do just fine without any RFC.
I would discourage the working group to take it. We don’t need an RFC.
If you have any convincing reason, please go ahead.
Huaimo: we’ve been using this for some time. And some document as
informational might be helpful.
Stephane: I don’t like you use BGP as a controller, it’s a protocol and south
interface, but not a controller. BGP is just an interface so
controller could use to program a path, and we already have
extensions to do so.
Huaimo: you think we should generalize it?
Stephane: no, we already have controller architecture in IETF.
I2RS: Mistake or Solution
Jeff Hass: former chair of I2RS. this is the undead coming back to haunt you.
The presentation has lots of excellent points. I2RS failed what we
want ed to accomplish and end up with models. But we helped NETCONF
and NETMOD, and lots of work were pushed by I2RS. RIB model got
upgrade. There are lots of inputs that this failed experiment had in
terms of pushing on the rest IETF ecosystem to develop good stuff. If
we don’t solve problem in IETF and vendors will fork off and do their
own things, and the most successful is Google. Walking dead SNMP is
returning in many aspects. People are solving exactly the same
problem as we did in I2RS.
Dean: I agree with your comments. This slides shows the value coming out
of I2RS (Initial Services Included in I2RS). I still see controller
agent, and I’d say let’s remove that and put in appropriate layers
and decide whoever framework we want to support.
Jeff Hass: I tend agree and I think those things are necessary. My prediction
as long as we force this work to touch NETCONF it shall fail. People
in that group do not have an agenda that align with us.
Rob Wilton: we got in NETMOD with Andy and NMDA architecture was we almost got
to the point of defining what you’d need for I2RS and we didn’t do
this the small bit at the very end, so the architecture talks about
how you would do a dynamic datastore but doesn’t define one. I still
think there’s a small step fro that point of view to enable that
functionality because the data models have already been written.
Whether that’s the right thing to do is a very different question.
Dean: I’ll resist my comment on NMDA architecture.
Jeff T: what’s your position?
Dean: we have some models and people are not implementing because some
models are too big, too complicated. Instead of putting everything
under the sun, what framework we need to or API, we should be
flexible. Why can’t we have a FIB model and RIB model and understand
how the RIB to FIB translation has been done and just compare them
and know what is my actual state. I have to know may RIB models and
FIB models from vendors to do things like that to give me a much
better overview, and what’s actually really on the wire versus some
other groups are doing. I’m also worried that we’re pushing too much
a 20 year old technology that was first proposed in November 2002.
It’s not the friendliest programing tool. Moving forward I’d like
to see us being more flexible to those new tools and new frameworks.
Decouple NETCONF from YANG, don’t keep them connected.
Jeff T: anything actionable for the WG?
Dean: I’ll write a draft, set of requirements and action items before next
Jeff T: that would be great. Thank you for your presentation.
RTGWG Session 2
Friday, 22 Nov 2019, Morning Session I 10:00-12:00
Room Name: Padang
Andrew Gray: how’s micro BFD play into this?
Greg I don’t know about micro BFD. I know about S-BFD.
Jeff T: it’s BFD over LAG.
Greg: BFD LAG spans cross a singe hop session. This extension allows you
to go over one session. I haven’t thought about it, but I’ll.
Andrew Gray: From our perspective, there would be a fair amount of interest in
having that either in the negotiation, or the capability
Greg: basically the RFC as I remember it create only single hop BFD
session over constituents session and it has no difference from a
single BFD session.
Andrew Gray: pretty much yes. But it’s a capability that needs to be enabled on
both sides. Since we’re already negotiating all the other
parameters we might be enabled as well.
Greg: each individual session comes up individually.
Jeff T: you need to configure it.
Greg: we will work on it.
Jeff: micro BFD is useful. You need to consider it.
Tony Li: we’ve been trying to get BFD into hardware and this makes it
harder. any other way to do it? Not BFD?
Greg: I’d like to inherit some good features from BFD, like robustness.
Louis Chan: you’re piggy backing all TLVs in BFD sessions.
Greg: not all of them. I don’t see the real need for all of them.
Louis Chan: if you separate different TLVs into different packets, it’s easy
Greg: I want to stress there is no requirements to do it in a periodic
Gateway Function for Network Slicing
Jeff T: speaking as a design team member, step # 1 Ii’s better if we can
align the terms.
Shunsuke: This document is published in IETF so the terminologies should be
idea friendly, I’ll do the modifications.
David Allan: I’m trying to understand the relationship between the gateway and
5G network? How’s that related to various interfaces?
Shunsuke: slice gateway is not a device but a definition providing a mapping
function to 5G systems. David: is it in the draft? Shunsuke: yes Jie Dong:
I think it’s useful to document the use cases.
IETF/BBF liaison discussion
Chris B: there is a liaison from IETF to BBF. Based on the IESG feedback, in
the future we won’t be allocating time for BNG topic unless there is
a request from BBF.
Evangelos: This is an IETF solution that can actually support it.
Chris B: Since you brought it up, let’s have a discussion about the liaison.
Dave: Speaking as BBF liaison. We’re gonna suspend BNG topics here in IETF.
For BBF activities, there has been a protocol selection done from
control plane to user plane, which is PFCP. Topics like this are
always welcome in that venue.
Evangelos: the importance of this talk is having a data model along with the
protocol is useful.
David S: there is also work going on at BBF regarding data model and
management plane. I can talk to you offline about some details.
Dean B: I’d like to see a distributed architecture for BNG that should be
implementation independent unless you really have an implementation
that you can present the results.
Diego Lopez: our intention was to explore unified access for BNG. Whether it’s
cable, in genera it’s for the access side and it’s important.
Greg: Concur with the previous statement. get the requirements whether it’s
access network specifically.
Jamel Had Salim: how’s the decision was made regarding the liaison?
Chris B: the liaison is public.
Jamel: what’s the process of BBF to do this liaison?
Chris B: let’s take it offline.
David S: BBF changed their bylaws such that everyone can pay a small fee and
access the work in progress.
Fengwei Qin: the solution from BBF is not covering our network situation. We
can talk after the meeting.
Evangelos: let’s talk after the meeting.
David S: if there are requirements that’s missing in the BBF, you an still
submit it there.
Louis Chan: to standardize a protocol in between is a very big challenge. There
are many different vendor implementations, only a small standard
portion at IETF. There are different line cards, and how you send
one message to control plane for those line cards?
Evangelos: is the first question how do you standardize the connection to the
Louis: it’s very vendor specific, and only a small portion is standardized,
so it’s difficult to standardize the whole thing.
Evangelos: it’s already an IETF standard.
Louis: you need to translate all the radius from control plane to forwarding
Diego: there is no data path to control path using radius. Radius is a
Louis: there is still enforcement in someway.
Dean B: having a fixed set of basic primitives then have vendor augment it
is very useful. Louis mentioned radius is a good example, I like the
idea, the question is whether there is any implementation? If you
could explain why this is better? There are other frameworks. I can
use plenty ways to model it, why this? You need to do the comparison
why you should use.
Evangelos: ForCES is not only about serialization, it’s an architect that has
already specific capabilities like HA etc. for other framework, you
will have to develop these.
Dean B: except being IETF protocol, I can use existing frameworks.
Diego: they’re not IETF standard, and this has been deployed.
SRv6 Deployment Consideration
Dino: can you put some values about the switchover? How long does it take
to make the switchover? In seconds or ms?
Chongfeng: it’s in days to get the service up instead of months.
Dino: did you do any measurement on the switchover time?
Chongfeng: not yet.
Tony Li: it’s more about VPN. Any real TE?
Chongfeng: no TE yet.
Tony LI; There are simpler solutions than SRv6. How much bandwidth have you
wasted to get this VPN?
Chongfeng: the bandwidth is from Gbits to 10Gbits.
Tony Li: you could have done it with simpler solution. Did you consider how
much bandwidth wasted?
Robin: the benefit is to cross multiple domain. the backbone is pure IP and
it’s difficult for VPN.
Tony: you could run GRE tunnels.
Robin: let’s take it offline.
Dino: how many sids are used in each path?
Robin: right now only on edge nodes, no SRH yet. In the future no more than
10. David Dai: for the incremental deployment slides, the first step is to
ipv4 to ipv6, and step two is to upgrade edge devices. What if we only
upgrade ipv6 in the core network, and edge networks are still ipv4,
how does it work in this scenario?
Chongfeng: in our case, IPv6 has been deployed everywhere, so we’re considering
this is a better solution than SR-MPLS. For other operators, maybe
SR-MPLS is a better choice.
David Dai: maybe in some cases, we should update the edge devices first.
Wim: you’re comparing with MPLS, there are other implementations in IP,
then your comparisons are not always true. It’s not 100% accurate with
the capabilities we have at IETF.
Chongfeng: this is not an absolute comparison. In some cases, SR-MPLS has
Wim: if you want to document how to migrate to SRv6, that’s ok. But if you
want to do a comparison, better also consider other aspects.
Saturo from SoftBank: thanks for sharing. I’m happy to see SRv6 deployed not
from green field. In the future, it will be helpful if you include TE,
or flex-algo that will reduce the SIDs field. Inter-domain flex-algo
Chongfeng: it’s depending on the process of compressed sids.
Saturo: it’s a bit scary you mentioned compressed SID. For me, 128bits is
fine. Jeff T: it’s interesting to see the migration from RSVP-TE, and see how
resolve bandwidth reservation.
SR-TE Path Midpoint Protection
Louis chan: due to micro loop, there is still possible to drop traffic. We can
Huaimo: the problem you mentioned is invisible. When N fails, P start FRR
before IGP convergence.
Louis: during IGP reconvergence, there is insychronized state, there will
be packet drops.
Huaimo: there will be micron-loops but minimum.
Martin: use any cast can solve the problem, maybe even faster?
Huaimo: there are issues with any cast.
Martin: what are the issues?
Huaimo: we can talk offline with more details.
Stephane: you can’t always any cast in some network design.
Martin: any cast works will be useful in some cases.
Huaimo: any cast might be a solution for egress, and harder for midpoint.
Stephane: can’t you solve by delaying ? not about your solution. Just try to
keep your forwarding in your hardware for a couple of seconds.
Chris B: Stephane is asking why not just delay installing the blackhole? Keep
the old entry.
Huaimo: good question, so it’s to delay IP forwarding.
Stephane: MPLS forwarding. If we just delay to change it, it works. Only keep
the forwarding plane.
Huaimo: we need to have some ways to keep the forwarding entry.
Stephane: I’m not sure you need to keep the control plane.
Huaimo: we need to let them know to keep the forwarding entry for some time.
Stewart: presume if you use anycast in the end, all the fast reroute will
resolve the issue. P discovers it can’t go to N, then it will go to
N’, which is N1, then C. So any cast would work for a very common
Huaimo: if you have details using any cast, please propose the details in
Dino: I’d support the idea because if if the SID is an any cast address
with reroute, then the headend doesn’t have to change the SRH, and
this is very useful.
Huaimo: there might be routing loops with any cast and there are other
issues. Stewart: in real networks with multiple hops, this solution may break
If you use any cast at exits, then ordinary FRR could deal with any
Huaimo: in theory, and we have pictures showing issues.
Dino: Please state the issues.
Huaimo: for egress, I’ve sent those issues to the list. If you’re proposing
a solution, please give details.
Stewart: please state the issues related with any cast. Please specify detail
Huaimo: I’ve sent the issues to RTGWG and SPRING.
Cendiz: wherever you go you will need an anycast and it doesn’t scale.
Jeff T: the working group is demanding comparison with any cast. The best
way to address it in the draft, not the list. At least a section with
comparison and the benefits you’re proposing.
Peter: just for the any cast. Anycast will protect the egress node, but not
the node in the middle. If you do any cast, you will need any cast
for every node.
Dino: you have link-local to realize your IGP.
Shraddha: I have a proposal in SPRING talking about using any cast as well as
the delaying process that Stephane talked about. I’d like everyone
to take a look.
Louis: I think we need both solutions.
Jeff T: we need to decide with SPRING where the work belongs to. We should
be able to converge solutions.
YANG Data Model for
https://tools.ietf.org/html/draft-ietf-rtgwg-arp-yang-model-03 Bo Wu
Jeff Hass: I read several versions of this draft and I’d like to suggest to the
chairs that this is ready to go three versions ago and WG LC will
push the completion faster.
Hamasu from Ciena: is static ARP covered?
Bo: it’s covered.
Jeff T: I will start the YANG doctor review and the process. Thank you for
the good work.