Minutes IETF101: rtgwg
Routing Area Working Group
||Minutes IETF101: rtgwg
IETF 101 London
TUESDAY, March 20, 2018
0930-1200 Morning Session I
150 minutes (130 used)
Chairs: Jeff Tantsura, Chris Bowers
WG Document Status Update
Jeff Tantsura, Chris Bowers
Routing Policy Model
Acee: clarification on the model. Neighbor set is used match route attributes,
not source. It’s explicitly described in the draft. the model allows a calling
function which you can pass only TRUE or FALSE, not accept or reject route.
Stephane: what’s strategy of routing protocols? Augment or import? Ospf as an
example. Yingzhen: use OSPF as an example, we can do separate augmentation, or
put into this draft. Stephane: do you think someone can use ospf without
policy? Yingzhen: we will try to progress this model ASAP. We understand
without this model, no route redistribution. Acee: some vendors do
redistribution inside protocols, some outside protocols. Standardizing it is
hard. We don’t want to delay IGP models although they’re not useable. Yingzhen:
if consensus can’t be reached. We will only provide examples for vendor to do
augmentation. Stephane: at IETF we should try to standardize it. Yingzhen: yes,
we’ll try. Jeff Hass: policy is hard. We should allow base protocol to
progress. We should come up with minimum set to progress, and allow it to be
extended. For features outside the minimum set, they can augment. Yingzhen:
we’ll try to standardize all common features. Acee: probably some vendors
already implemented. I’d like to see BGP model do the same thing. We can do
them quickly. Yingzhen: OC BGP model was used in the examples, and we’d like to
switch to IETF BGP model. So there are some dependencies on BGP. Keyur: let’s
work offline and resolve the issues. Jeff: please review the drafts and see if
there is anything missing. We’d like to progress it fast.
ARP YANG Model
Jeff: how many people have read the draft?
YANG Model for QoS (and QoS operational parameters)
Aseem: seek WG adoption.
Jeff: how many read the model?
Maybe only a couple.
XX from DT: Why this WG? will you also present in transport?
Aseem: we have discussed in the past.
Jeff: the work is going to progress in RTGWG.
XX: it seems scheduling is up to vendor augmentations. So lots of vendor
specifics. Aseem: we have defined the parameters. How to put them in policy is
not decided, but allow vendors to stitch models together. XX: it will be good
to have a standard one. I’ll send you an email and make suggestions. Aseem:
Alia: when this draft was first brought up, we talked to transport area. This
should normally be in transport. Only considering rtgwg has more Yang model
experience, that’s why it’s doing here.
Dean B: I like how you break up the functions that needed in QoS. You didn’t go
into vendor implementations. I haven’t read the draft, did you put some
examples in hierarchical QoS? Aseem: yes. We have included how hierarchical
model be bounded to policy. Chris: there are several versions of this draft.
Probably a good time for adoption call. Aseem: totally agree. it takes time to
do this work.
Update from Routing Area YANG Architecture Design Team
Lou: forgot to thanks Alia, she started this team.
Alia: Thank you to the whole the DT, especially you for leading the team.
Control and User Plane separation for BNG
Acee: I see the data, is it true?
Long: yes, later I will show more test data.
Acee: will you also show how to do load balance?
Dean B: when you say virtual or physical UP, do you differentiate x86 based or
Rong: two types user plane. Virtual and physical for different services.
Physical to handle large traffic. Dean: this is not what I asked. I asked what
they’re running on and where? Dean: for your data forwarding, which do you use
to forward data, x86 or specific ASICs? When you get 10k access, if you’re
using x86 how many servers and CPUs are used? Rong: for light traffic, it’s
forwarded to virtual user data plane. Dean: never mind. Chris B: there are two
types of user planes. so I’d assume virtual plane is on VMs based on x86.
Physical could be either. Rong: yes. Dean: over how many servers do you need to
achieve that 10k? Zitao Wang: virtual data plane is based on x86. Physical can
be either. Control plane is based on x86, running on cloud to achieve the scale.
Wim henderickx: the work is already being done in BBF and 3GPP. why replicate
the work here? Not leveraging? You’re proposing vxlan between UP and virtual
UP, there are proposals in 3GPP and BBF already. Ning Zhong: the interface and
model is not in the scope BBF. The model there focus on access. Wim: there are
collaboration between 3GPP and BBF to work on the model. Ning Zhong: it’s for
slicing. Chris Hopes: when you present statistics, it’s important to say what
hardware? So we have some idea about the scale. Georgios from Huawei: the 3GPP
and BBF is more about interfaces, not BNG. Wim: there are also vxlan proposed,
also how to populate FIB. Georgios: 3GPP is working on requirement. Wim: among
SDOs, we need to consider the overlap, we need to figure out gap. ChrisB: we
need to figure out the long-term scope. We’ll set up a meeting with authors,
open discussions on this work. Long: we also want to have protocol discussions.
Jeff: the amount of work is growing. We need to figure out the amount of work.
Zitao Wang: what defined in BBF are requirements and architectures. 3GPP also
defined it separate, and different. Acee: I’d like to see some discussion
offline in the alias. Chris B: we will set it up and report back what we find
Control and User Plane separation for BNG (YANG model)
gRPC Services on Network Devices - Implementation Update
Update on progress towards:
gNMI - config manipulation and streaming telemetry implementation.
gNOI - operational commands.
gRIBI - RIB injection service for gRPC.
Jeff: any intention to update gRPC draft?
Igor from Huawei: would it be useful to get other than current data state
coming from network devices, like historical data, average rate etc.? Rob: it’s
about implementation costs. It’s a tradeoff. So you can use software to cache
it instead of storing in device. Benoit: you mentioned you don’t use Yang. What
about semantics? Rob: for schema of device, we use YANG in OC. if it’s an
interface not schema based, we don’t use yang. It doesn’t have much validation.
There are places the validation is not there or somewhere else. Benoit: what if
you have a -minus counter? Rob: in that case you can’t get it pass in Yang. for
others schema unaware, We don’t validate it. The cost of maintaining is
expensive. We depend on the consumer to do validation. Aijun Wang ChinaTelecom:
can you list the 6 vendors? Is there communication between management and
device using IETF YANG. Rob: it’s not my place to mention the implementors.
does this depend on IETF yang? No, it’s openconfig yang. gNMI is agnostic to
yang. Zitao Wang: so gNMI is the transport of YANG? Similar to Netconf? Rob:
it’s similar. the protocol is defined in the network device and management.
Considerations on Network Virtualization and Slicing
Jari: BOF on Thursday morning on slicing.
Rob: this is a good piece of work. What’s not there is the advantage of
virtualization, overlay. It’s important to see how quick IETF can do this to
remain relevant. Jari: it’s never black and white. You don’t always need
protocol, maybe only software. Some standardization needed going forward, need
to specify data model, APIs etc. Rob: I can go to open source in a week of two,
instead of IETF. Xxxx: Yang may have it’s limitations. You may want to do more
than yang. Jari: yes, that’s for sure. You may have different needs. Dean B: we
have to be careful about how to use the words, centralized may mean
distributed/localized. I have issues with those names. Jari: I agree mobile
networks are well distributed. I’m more referring to local domain, how to
config the network. Dean: when you limit from one domain, you may have to think
how to distribute the function. Georgios from Huawei: thanks for your
contribution. When combining with IOT. Where do you place the AI technology?
Some should be close to user, some should be somewhere else. One possible way
is to define policy in IETF. Jari: agreed. That’s needed to be done. Dean:
regarding service models. I’m against doing service model without service
providers. Jari: agreed. Jeff T: we’re talking to operators to participate the
work, it’s on-going effort.
Numbering Exchange Protocol
Acee: speaking as LSR chair. Why are we looking at this? Right now we can do
per topology basis, more complicated than this. Why are we looking at this?
Reudiger from DT: I’m the answers to this. What are your goals to design this
metric? What are you expecting to get out of this? Inventing a new metrics. I
don’t see what’s good. Omar: NEP uses a new metric to choose the best route.
xx: why not use financial cost? Shows delay high cost? Omar: I’ll look at that.
Acee: what benefits are you going to get? If someone wants to do this with
existing IGP, you may use a new metric. Omar: let’s discuss it on the alias.
Let’s show how different routes are chosen. Acee: why is this route better?
Chris B: let’s take this to the list.
THURSDAY, March 22, 2018
1330-1530 Afternoon Session I
120 minutes (95 used)
Enterprise Multihoming using Provider-Assigned Addresses
1:30 - 5 min
Jeff: IMO it’s ready for last call. If you have objection, please let us know.
Toward a Network Telemetry Framework
1:35 - 10 min
Greg: your characterization of existing OAM is objective. I agree SNMP is not
the right vehicle. YANG is being development. Haoyu: I don’t see they are not
related nor useful. This is just to summarize, to see the gap. Greg: so don’t
be so objective. Greg: This is in accurate. Are you implying accurate
measurement are not in-band? Mahesh: I’d encourage this work, netconf are
working on this, more people are working on it. Jeff: RTG is not the only area
proposing this. Rick Taylor from Airbus: agree with Mahess, need to expand it.
It’s always a challenge. Big +1. Greg: why are we starting using Telemetry
instead of OAM? In the doc, I’d encourage not to use any marketing terms,
making conclusions one technology is better than other. You will find
requirement analysis is more needed. Haoyu: my understanding telemetry is wider
range term. We need to normalize the language. Linda D: this is good work. We
need to think from big picture. A network may have many elements involved. So
having big picture in mind is useful. Jamal Had Salim: please consult us before
you go to next step. There are lots of work we’re doing in this area.
Enterprise to Cloud DC connectivity
1:45 - 10 min
1:55 - 10 min
Lou: I agree with your statement. Where should it be done?
Stewart: let’s me get to next slide, and we will talk about it.
Greg: adding resource reservation, does it change SR?
Stewart: yes. If we need resource at every node. You may not need to do this
all the time. It depends where you are. You might be ok with shared resources.
Lou: I think it will be great to find it a home. It’s great work. It’s a larger
than detent. I don’t agree it doesn’t belong to TEAS, which is the center of TE
architecture. It’s important to find protocol home, we need to fix it. The
resource reservation fits it well. Stewart: need to decide the right WG. Jeff:
resource reservation makes it maks sense to TEAS. Lou: you got the description
right. That’s all TEAS. Greg: I’ll change the statement about SR. At this
moment, it might be too early to say it. XX from DT: it’s related to spring.
Toerless: what’s the relationship to slicing? Stewart: it’s similar. Whether or
not slicing happens, it’s useful technology. Matin as AD: in case multiple docs
are needed, are you open to multiple WGs? Stewart: we may have a doc in ISIS.
We need a home for the architecture doc. I’m looking for expertise for the
Testing of TI-LFA implementations
2:05 - 10 min
Jeff: how is SRLG is done/configured?
Carsten: I don’t know.
Jeff: how it should be done may be included in the draft, it’s still being
discussed. Acee: it looks like for SRLG, the topology shows it could use local.
So you may not really need it. Carsten: sine only one support of it, it used
simple topo. Jeff: thanks for coming here and present it.
Ingress Filtering for Asymmetric Routing
2:15 - 15 min
BGP-based Mobile Routing for the Aeronautical Telecommunications Network
2:30 - 15 min
Chris B: just to share with the WG, do you want to standardize the
architecture? Or protocol work? Fred: it might be informational in BGP. Acee:
specking as co-author, this doc doesn’t have details, it meant to be
informational. Chris B: we will discuss this offline to figure out a WG for
Link State Over Ethernet
2:45 - 10 min
Jeff: these prefixes are for the interfaces, right?
Randy: yes. Not exchanging routing tables.
Rick Taylor from Airbus: do you want to metric with the address? It might be
useful. Randy: point taken. Chris B: is there assumption about p2p? Randy:
broadcast is considered p2mp. Mays from University of ESSEX: How is it
different OSPF link discover? Randy: no multicast. Acee: this is a discovery
protocol, no routing protocol. Someone suggested taking hello out of ISIS and
OSPF, and in MANET. There are many ways to solve this problem. Rick: I like
this work. Reiterate, adding metric might be useful. The more for bottom layer,
it will be more useful. Randy: point taken. Keyur: just say more on these
points. it’s like BFD to provide generic service to protocols. Jeff: you
mention label distribution in one of your slide, why? Randy: I want to know
what label you have. Chris: we don’t understand the use case for this. You many
have multiple labels. Randy: you may have multiple. Chris: looks like you’re
doing routing. Randy: label in SAFI. Keyur: it’s not meant to be overlay. It’s
hop-by-hop. It’s not meant to be sent to other neighbors. Jeff T: let’s talk
Service Routing over Path-based Forwarding
2:55 - 10 min
Greg from ZTE: what’s the rolls of PCE if you’re using bier-te?
Dirk: Path calculation.
Greg: why not use SR then BIER? no need of bier-te?
Dirk: it’s based on the policy.
Jeff: what about the control plane?
Dirk: next slide. SR means service routing here.
Acee: this is adding late. What’s the difference between this and routing to an
anycast address? Jeff: it could belong PCE or BIER. Very interesting work,