Minutes IETF103: rtgwg
Routing Area Working Group
||Minutes IETF103: rtgwg
RTGWG IETF 103 Agenda
16:10-18:10 Monday Afternoon session II
RTGWG draft update:
Chris and Jeff
Jeff: welcome to Bangkok. Note Well. IPR disclosure.
RIB YANG Data Model
Jeff: How many people have read draft?
A few people respond...
Jeff: Please read.
A YANG Data Model for Routing Policy Management
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
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, well use them.
Jeff: you dont have references. Please add more details what youre trying
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. Its easy to have CSPF to calculate
traffic engineering path.
Tony Li: BGP is not a dump truck. I dont want to go to that. Let me ask you a
different question. Whats the difference between this and PCEP?
Huaimo: PCEP is another protocol. It may increase your network cost. BGP is
already a core protocol, we can reduce number of protocols. you dont
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 one
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 draft-heitz-idr-msdc-fabric-autoconf-00 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, its a link
Chris: so it use the info to calculate SRv6 path. does switch has similar
Jacob: device knows how to get to the controller. Controller gets to the
device using SR.
Chris: so it uses the ADJ sid.
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 didnt see those in the doc.
Jacob: will do.
Sam: what if the controller doesnt 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 doesnt 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 which
the new device is connected. BGP ensures connectivity to the
controller as long as there are links. If a device is becoming total
isolated, its not working.
Sam: Lets talk offline.
Tony Li: I like it. Will it be simpler to enable routing incrementally as you
Jacob: slide 5. The yellow guy doesnt know how to reach DUT because each
device knows only its immediately connected. Im doing this for
scalability. You could run ISIS, but it doesnt scale.
Tony: isnt MSDC gonna run some kind of routing?
Jacob: thats the draft I presented at IDR interim. BGP aggregated routing
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 doesnt know which
router its talking to.
Tony: wouldnt it be better if the controller has some knowledge ahead of
Jacob: that would be nice. But it doesnt have to.
Igor: can you tell us which MSDC doesnt have a topology defined ahead of
time? we run datacenter. We have a controller that does something
similar to this out of band. we predefine the topology, wire plan, etc.
we dont need auto discovery, why do we need this? We have controller
which can do everything. We dont let device auto config themselves.
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 port?
Igor: controller connects to devices in band and out of band. The initial
configuration is done using out of band, that means in band doesnt
need to be up. If you were to do in band only, you would basically
connect device one, then everything connected to the next ring. It
doesnt need a whole new protocol to do this. Is there customer asking
for it? It seems a wrong way to configure the network.
Jacob: Id like to talk to you offline. basically you dont 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 ID.
Jacob: what if you put a different switch into that slot?
Igor: the switch wont come up because it doesnt match the configuration.
Again we design how things are, and its better be that way.
Jacob: as long as its the same kind of switch, your controller can figure
it out and make it work.
Igor: again this is unlikely. This is not how its done. You will be doing
power management etc, you cant randomize things. Controllers are
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 youre saying. It makes things easy. Are you saying we
got wrong requirement?
Igor: yes. Its not random. You can do in band only.
Jacob: I hear what you say. I can make changes. Lets 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 doesnt matter.
Jacob: where do you think it belong?
Architecture for Control and User Plane Separation on BNG
Chris B: Im not sure were 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 its clear that they have yet to perform a
feasibility study. until were told otherwise, theyre not asking us
to pick a protocol.
Sanjay: thats why were calling it a candidate.
NingZong: PFCP is owned by 3GPP. are you asking IETF to do 3GPP extension?
Sanjay: it has a number of different cases. Once our goal is not to reinvent.
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 here?
Sanjay: Mobile IP is defined here and used in 3GPP.
Jason BBF liaison manager: pretty much what Sanjay is saying is true. Theres
work on fixed only architecture detailed in TR 384, thats liaised in
March. Whats subsequently liaised is the work from the wireless
wireline convergence group. The BBF has not consolidated the proposal.
were 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 separate
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
Sanjay: 3GPP, theyre not looking at fixed BNG.
Andrew: we want to have a convergence of fixed and mobile. We dont want to
have three protocols. In stead of 2021, were looking at 2030.
Chris: running out of time. lets move on to the next presentation.
Architecture for Control Plane and User Plane Separated BNG: Update on cuspdt
draft-cuspdt-rtgwg-cu-separation-yang-model Donald Eastlake 15 min
Dave: from BFF liaison manager point of view, sending an liaison will be
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 network.
weve already done some tests in our fixed network. They can satisfy
requirements. I think IETF should focus on fixed network on user
plane and control plane separation for BNG. Wed like to work with
Nokia to develop the architecture on FMC.
Wim from Nokia: I think its good to send the liaison. I believe if we rush
too fast into the fixed network we have a lost opportunity to solve
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 which
protocol is the best. We should not come up with two different
Donald: I disagree. The completion of these documents which ere already in
use would have any significant effect on the timing of subsequent
Wim: its up to BBF to decide.
Donald: I dont think doing what Im suggesting will actually significantly
affect the subsequent efforts.
Andrew: I second what Wim said on sending the liaison. I also dont like
pseudo rush here. Trying to say this is done is premature. The amount
of changes in software will be big.There is fundamental issues in
protocol. We need to take time to work on it.
Donald: I didnt claim these drafts are in final form. There is work need to
be done for editorial changes and completeness.
Andrew: its 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 for
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 now
instead of waiting for 3GPP.
Sanjay: we presented here is multi access BNG. When you looked convergence as
a whole, its different. Whats presented here only works on Ethernet
access BNG, not addressing the multi access part.
Ningzong: the fist liaison: I think its valid. The 2nd is to get more
information, not a replacement. I see the 1st one real requirement.
Were not against sending a liaison, but not to say were gonna have
a unified protocol. Were not against FMC case either.
Chris: cutting the line.
Dave Allan: carriers wanted to support existing stuff, which meant we were
going to end up with a platform that would terminate access protocols
as PPPoE, hence the concern I raised in Montreal which is we have the
opportunity to have many protocols support the same using facing
functionality, and this was part of the motivation for the second
Wolfgang from DT: I just wanted to second the notion that fixed mobile
convergence is not as straightforward as many people like to believe.
There are products that arent there in the mobile world like access.
Geogis: whats 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
SD-WAN cloud interconnect problem statement and gap analysis
Dino: your comment about ONUG, so yes they want to come to the IETF for
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.
Lou B: on the gap analysis at the last meeting, we talked about RFC 5566
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 doesn't
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 is
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 transport.
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 of
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 offline.
Linda: I will talk to you afterwards.
Wim: the two gaps which you identified so far it's mainly about IPSec
tunnel establishment and the not traversal, are those the two main
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 address.
Linda: for IKE we had that more than our discussion in i2ns working group
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 it's
semantics on how to do it. I think it's where we need to have more
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
Jeff T: I think when you have BGP, when you have a hammer, everything looks
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
Jeff T: we try to decide from architecture prospective.
Linda: this is really an example solution. we need to show the problem, the
gap, and example solution.
Chris: if this is to become WG document, will you be open to suggestions?
Linda: yes. Also the solution can be in other WG. Here is to identify the
problem, gap, and stimulate other people to work on it.
Keyur: if you're looking for solution outside of BGP, there was a draft
expired that was a generic solution. when you can't fight, join them.
Dino: there is a lisp crypto draft, negotiate keys without key management
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 take
the work and continue to work on it.
Chris B: this is in the broad scope of RTGWG. is there anyone who think we
shouldn't be working on this? (none) ok. thanks.
Jeff: please keep it sync with data model progress.
SD-WAN service model
Linda: ONUG SD-Wan part abandoned the efforts. ONUG tried to catch the
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 Steve?
Bo: yes. I'll ask Linda for help.
Chris: this draft was presented at OPS. at this point, you want feedback
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 interoperable.
Explicit Topology Marking using RFC 8377
Network monitoring protocol and neighbor state monitoring
Yunan Gu and Robin (Zhenbin) Li
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
Jeff T: GRPC and YANG push are there, data consumptions are how you model
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 didnt 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
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
Jeff T: I don't always agree with Rob, but this one, yes. So it doesn't make
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 help.
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
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
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?
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 and
make it work.
Michale A: yes, so sysrepo.org has everything. there are docker images and
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 experience?
Dean: there is a community maintaining it. There is not a ready product.
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
David: everybody can do it?
Dean: yes, and the question is if there is a critical mass of people and
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 talked
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
Michael A: so we use this for managing both services and the home gateway for
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 talked
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 open-source
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 plug-ins
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 that
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 you're
writing new applications, and you want your applications to be
managed by open daylight these are the tools to help you. essentially
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 languages.
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 next
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 heard
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.