Minutes IETF105: rtgwg

Meeting Minutes Routing Area Working Group (rtgwg) WG
Title Minutes IETF105: rtgwg
State Active
Other versions plain text
Last updated 2019-07-31

Meeting Minutes

   RTGWG Agenda IETF 105
Chairs: Chris Bowers
        Jeff Tantsura
Secretary: Yingzhen Qu

WG Status Web Page:Êhttp://tools.ietf.org/wg/rtgwg/
Jabber room: rtgwg@jabber.ietf.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Ê
Linda Dunbar

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?
Linda:       yes.
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 
             this doc?
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 
             discussions there.
Ali:         if the gaps are real gaps, then theyÕre good to be documented.

Preferred Path Loop-Free Alternate (pLFA)
Stewart Bryant
Jeff T: weÕll be watching the PPR progress in LSR.

Protocol Assisted Protocol (PAP)Ê
Lei Li

Greg M:    before troubleshooting, how this abnormal behavior is detected? 
           Quality degradation? 
Lei:       PAP is just a channel between the equipment. How defaults are 
           detected, itÕs still the traditional one. PAP is just the channel 
           to communicate.
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)Ê
Donald Eastlake

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
Bing Liu

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 
            replacing BFD?
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 
            micro burst?
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
Reza Rokui

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 
          different slice?
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
Aseem Choudhary

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 
          different ways.
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 
          same thing.
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 
          about it.
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

Dean Bogdanovic

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 
          in YANG?
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 
         the relationship?
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
Jari Arkko

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.