Minutes IETF105: rtgwg
Routing Area Working Group
||Minutes IETF105: rtgwg
RTGWG Agenda IETF 105
Chairs: Chris Bowers
Secretary: Yingzhen Qu
WG Status Web Page:Êhttp://tools.ietf.org/wg/rtgwg/
Jabber room: firstname.lastname@example.org
RTGWG Session 1
Monday, 22 July 2019, Morning Session I 10:00-12:00
Room Name: Place Du Canada
WG Status Update
Dynamic Networks to Hybrid Cloud DCsÊ
Chris B: I provided some comments on the problem statement. Both Jeff
and I feel this still needs lots of work. Is it possible to
combine the two docs?
Chris B: this will save lots of work during LC.
Ali: my concerns are some of your points are ambiguous, and need
to be clarified. I donÕt think we need another draft.
Linda: that was just the discussion on the emails. The gap is really
about the wan port.
Ali: I'm not sure it's really a gap. It provides lots of flexibilities.
Chris B: did you make the comments on the list? With this respect to
Ali: I don't remember which WG I responded to.
Linda: It will be great if you can send something about tunnel encap,
we had lots of discussions, however it didn't address wan port
property. It's not about encapsulations, and client route
Sue Hares: it's possible what you're just saying, but the security draft
doesn't have the right content. We need to put it some place
and decide where itÕs gonna go.
Martin: is it necessary to publish the docs?
Linda: for problem statement, itÕs beneficial for the community to
see the doc. I personally believe so. For gap analysis, after
gaps identified, itÕs great if we have drafts to address them.
Alia: I believe the problem statement is valuable. IÕm not sure about
publishing gap analysis.
Keyur: I agree with Ali. Make sure to cross reference, real work
happening in IDR.
Sue: we will discuss the topic in IDR. Maybe you want to move some
Ali: if the gaps are real gaps, then theyÕre good to be documented.
Preferred Path Loop-Free Alternate (pLFA)
Jeff T: weÕll be watching the PPR progress in LSR.
Protocol Assisted Protocol (PAP)Ê
Greg M: before troubleshooting, how this abnormal behavior is detected?
Lei: PAP is just a channel between the equipment. How defaults are
detected, itÕs still the traditional one. PAP is just the channel
Jeff Hass: IÕd suggest rather than inventing a new protocol, you may want
to work on existing protocol, something like YANG, or gNMI. IÕll
take the question to the mailing list.
Loa A: IÕm not sure itÕs a merit to add more network-wide data. Not
relying on a centralized server? Is this mean your server is
not working? Or take out the server? Two different situations.
Robin: this mechanism is complementary to centralized solution.
Loa: I will read more. Does BGP know youÕre the source of question?
Like route oscillation.
Lei: BGP knows it.
Xx: how about detecting black hole? When you canÕt forward traffic.
Chris: please take other questions to the list.
Dean: youÕre mixing service level data with device level. Those are
Jeff T: you may want to put in one complete example, like BGP. ItÕs not
clear in the draft.
Lei: Yes, weÕll add some details.
Control-Plane and User-Plane Separation BNG Simple Control Channel Protocol (S-CUSP)Ê
Martin: this presentation doesnÕt change the statement I made after
consultation with IESG. Until we hear back from BBF, which
is making requirements, no IETF work. This decision from
IESG still holds.
David Cinecrop: as BBF representative, IÕll give an update after the
Xx: I guess youÕre waiting for BBF work.
Donald: there is not intend for IETF to adopt any draft for now.
anybody can post a draft.
David: work in BBF is progressing well. You should be able to find it.
There is an equivalent of WG doc, and itÕs comprehensive doc.
ItÕs not about protocol design, it sets a stage for protocol
selection. ItÕs taking the output of the BOF. BBF is appreciating
IETF for the discussion.
Instant Congestion AssessmeNt (iCAN) for Data Plane Traffic Engineering
Yimin Shen: In your example, there is only one ingress router. If you add
more, there will be race condition and congestion. Then there
is no guarantee.
Bing: the systems works in pairs, and you can deploy multiple pairs.
You can extend it.
Greg M: youÕre comparing with BFD?
Bing: itÕs not against BFD.
Greg M: YouÕve having additional OAM in addition to BFD? Are you
Bing: Neither. You can add extra benefit from BFD.
Greg M: if youÕre using BFD? Maybe you want to join the discussion
of BFD extensions. Another reference is to look SFC work on
using marking method. We have an RFC on residence time in MPLS.
Bing: would you please send an email to the list?
Xx: you mentioned micro bursts. How you handle the timing of
Bing: ThatÕs one of the motivations. ItÕs almost impossible for
controller to handle micro bursts. the egress provide feedback
every 3.3ms, and ingress routers do adjustment every 10ms.
WeÕd like to find partners who are interested in this method.
Xx from cisco: Unicast or multicast?
Bing: no multicast yet.
Xx from cisco: multicast is issue from both sides.
Bing: multicast will be considered later.
David from Marvel: have you considered the packet order issue?
Bing: in backup slides.
Jeff T: the draft is very general? WhatÕs your plan?
Bing: the current draft only has the skeleton. WeÕd like to collect
feedbacks, especially from service providers. If people agree
with this work, IPPM is related. Also signaling between routers.
Jeff T: it will be good to add some details.
5G Transport Slice Connectivity Interface
Xx: do you see there is a single interface to control all transport
network function or a set of interfaces?
Reza: the latter one. it could be a set of functions that as you will
see as I go through it. This interface addresses three the
functions: automation, aka creation, monitoring, and assurance,
analytics and optimization whether or not we need one interface
to address these three or we need three or more basically this
under discussion. In my opinion I think it's a multiple interfaces.
Dean B: why do you need two transport slices?
Reza: itÕs different slice for different purpose. Your endpoints are
different. The first one is from RAN to core, and the 2nd is
between CU and DU.
David from Ericson: are we looking for one singular transport slice
connectivity interface that can accurately represent all
different types of transport technologies?
Reza: yes. ItÕs technology agnostic. For example from eNode B the
core, the connectivity is the same with the same SLA although
the underlying implementation is different. ItÕs the abstract
layer we create, very high level.
Chris B: you also mentioned BBF. I understand 3GPP has defined some
interfaces, have they said theyÕre not defining the transport
David: speaking as BBF liaison. 3GPP sc5 has sent out a widespread
liaison asking for the interfaces that can be used to
facilitate network slicing in the transport level. I believed
it was sent to IETF, but IÕm not exactly sure. It was sent to
at least 3-4 SDOs, and BBF is one of them. Each liaison has
answered what they can do. The target interface here is an
abstraction of all of these different management interfaces.
Reza: based on the discussion we had with operators, there is a need
to have the same type of logic interface.
David: the work started in BBF is on transport network management
slice interfaces. There is no assumption that there will be one
interface to rule them all.
Jeff T: has anyone in IETF received this letter?
David: I can check.
Uma: what happens if the RAN interface is bad? Do you take it to a
Reza: if end to end is not working, maybe they have to change the
transport. Neither router or transport has the end to end context.
Uma: good answer. We have similar idea presented at DMM. We have
a draft. ThereÕre some correlations.
Dean B: you said those interfaces should be technology agnostic with
high level SLA, do you believe this is the right area to do that?
Reza: I donÕt know. I hope to get an answer from the WG.
Georgios: the activities are related although were given different names.
WeÕll need to synchronize the work, whatÕs need to be done at
BBF and IETF?
David C: can you elaborate how you see the work between IETF and BBF?
Reza: maybe at the end of day, we only need to do one. We can do a
requirement at IETF. Information model is done in BBF. Maybe
Georgios has some comments.
Jeff T: there are different IETF activities, you need to look at those.
Reza: IÕm going to present this at TEAS also.
RTGWG Session 2
Tuesday, 23 July 2019, Morning Session I 10:00-12:00
Room Name: Laurier
YANG Model for QoS
Dean B: this doc has been 7 years?
Aseem: no, started from 2015.
Dean: the previous version we started in 2014. We were still trying
to adopt it?
Chris B: thereÕs reason for that. The QoS model is quite difficult to
standardize. whatÕs your point?
Dean: The point is youÕre trying to match all functionalities instead
of basics, and details can be specified later.
Aseem: we agreed to have a super set of operations and approved by
all vendors. It allows vendors to implement in a couple of
Dean: youÕre over specifying things in a single draft. It should be
a draft with basics, then additional features added on top of
that, like buffer and queues.
Assem: we have to have agreement among basic QoS.
Robert: this doc has not been adopted, we need to get something shipped.
Maybe not perfect. We should try to push.
Aseem: there was an adoption call. We got some comments. Other than
that, the model has been stable.
Stephan L:the model is quite complex. Happy to see there are vendors trying
to prototype the model and the outcome.
Aseem: we have some similarities among vendors.
Stephan: there are some similarities, but not exactly the same. WeÕre
facing difficulties when moving from one vendor to another as
the syntax are complete different, you canÕt do exactly the
Aseem: we have debated and do have similar set of schedulers and queuing.
Acee: the chip makers have no intension to make this unified for QoS.
I tried to unify CLI for different line cards, itÕs impossible to
find one size fits all.
Aseem: we have debated, and we have come up with one that works for
everyone. All vendors should be able to use it. IÕm confident
Chris B: weÕre planning to adopt it. There were feedbacks saying that
it might not be as useful. Any one objecting it?
Dean: I support adoption. My comment is just this is too complex.
If we put other related model to work with it, it will be hard.
Chris B: so you support the adoption?
Dean: IÕll suggest cut significant amount.
Jeff T: weÕll continue the adoption.
Network Automation Evolution
Benoit: what are the top three things to do?
Dean: better abstraction forget detail, telemetry, reengage gNMI
telemetry. Vendors to be open to what weÕre proposing.
Robert: it will be useful to document how to use YANG. What do you
see the API between service and network operator? Something
Dean: whatever you choose.
Robert: who writes it? Who choose it?
Dean: there are frameworks that can be used. Maybe YANG, or other
languages. We have to evolve, like YANG NEXT? It seems to
be disappeared. ItÕs a common interface that can used, not
language specific, can have variant features.
Robert: something like Yang into open API then generate the right
Leo: whatÕs the north bound interface? How do you verify your
intended provision is committed?
Dean: south bound is the API to the device. devices are the physical
layers. Device management platform is where to abstract the
devices in a set of functions and resources. Message bus is
where you can subscribe and collect data, so you have multiple
south bound and north bound interfaces. What the actual
interface, might be YANG or something else. We need to agree
the architecture then move forward. For the 2nd question, I
need to unit test to make sure I have the right outcome, and
operation model translates correctly to device model.
Leo: for synchronized communication, you can see the results seconds
later. But for asynchronized, you send something, there is no
Dean: youÕre interested in synchronize?
Leo: the feedback should come back quick. If it is asynchronized,
the results may come back in hours.
Dean: today the reality is minutes.
Leo: my point is fast is good for telemetry, but not everything.
XuFeng: what youÕre describing is like notifications, other kind of
notification not telemetry, and NETCONF has it.
Xx from Huawei: why do you think itÕs distributed system?
Dean: if I want to create a single management system. How to scale
it? The latency you see will be big, then whether it make sense.
So hierarchical might be better.
Xx: there might be multiple platforms. how do they interact?
Dean: people may have different ways to do it.
Xx: the term service is mixed. Management platform is not aware
of the service?
Dean: the device management platform and the service platforms
are different. for network operators, services are the revenue
generator, and physical layer is cost. They want to produce
services faster, and make sure devices are managed correctly.
Stephan: abstraction is something required to speed up creating services
etc. If we focus on network operations, donÕt you think people
will lose skills if theyÕre only managing abstraction?
Dean: like computer language. Like high level language, python, are
we losing skills? People who really wants to understand it can
still do it. ItÕs a hard journey. There is something set for both.
Stephan: 20 years later, will I be able to know how the box work?
Robert: sync vs async way. IÕm a big fan of async way. The configuration
applies some time later. You donÕt want to be blocking while
waiting for feedback.
Dean: yes. There are certain things have to be done synchronically.
Robert: yes, and those things can be done through controller.
Jeff T: you have to async. You donÕt want to be locking forever.
Layer 3 VPN Network ModelÊ
Oscar Gonzalez de Dios
Igor B: we have device models, service models, like l3sm. WeÕre also
allowing steering models. ItÕs not clear what weÕre missing.
Oscar: the models you mentioned are complimentary. the current service
model is created based on the services they want to use. For a
tcp connection, the customer doesnÕt care where itÕs connected.
IÕll put some info on the mailing list.
Igor: theyÕre not expected to get into the network resources?
Oscar: this is from service orchestration layer. The operators are
not expected to use it.
Igor: so operators use L3SM, then other models are used to discover
services. We need to talk on the list.
Oscar: happy to clarify on the list.
Chris B: it will be in the ops area list.
Prakash from cisco: is there any dependencies on the device model? WhatÕs
Oscar: so far itÕs independent and it should be.
Prakash: different segment of network will use the same technology?
Oscar: yes. ItÕs assumed that the controller is able to provide the
service based on device configurations.
Robert: regarding the prune bit and hierarchical controller, whatÕs
Oscar: we havenÕt really started the prune yet. ItÕs the next step.
Robert: the prune may change information and make it optional.
Oscar: we may make it optional.
Drew: in some implementation, we see l3sm to device model directly
not needing this.
Changes in the Internet Threat Model
Frank B: this is useful. We may want to trust device. We believe everyone
behaves, maybe tomorrow we donÕt want to trust anyone. YouÕre
trying to reverse it. Ê
Jari: yes I agree. There is necessarily a solution, at least we want
to be aware.
Jeff T: you canÕt be paranoid enough.
Adrian: you canÕt say you donÕt trust it until it approves. It will
behave until untrustable.
Jeff: thank you everyone, see you in Singapore.