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 10:00 5m Administrivia Jeff/Chris 10:05 10m WG Status Update Jeff/Chris 10:15 10m Dynamic Networks to Hybrid Cloud DCsÊ https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-gap-analysis/ https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ 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 distribution. 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. 10:25 15m Preferred Path Loop-Free Alternate (pLFA) https://tools.ietf.org/html/draft-bryant-rtgwg-plfa-00 Stewart Bryant Jeff T: weÕll be watching the PPR progress in LSR. 10:40 10m Protocol Assisted Protocol (PAP)Ê https://datatracker.ietf.org/doc/draft-li-rtgwg-protocol-assisted-protocol/ 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 incompatible. 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. 10:50 10m Control-Plane and User-Plane Separation BNG Simple Control Channel Protocol (S-CUSP)Ê https://datatracker.ietf.org/doc/draft-cuspdt-rtgwg-cu-separation-bng-protocol/ 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 presentation. 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. 11:00 20m Instant Congestion AssessmeNt (iCAN) for Data Plane Traffic Engineering https://tools.ietf.org/html/draft-liu-ican-00 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. 11:20 10m 5G Transport Slice Connectivity Interface https://datatracker.ietf.org/doc/draft-rokui-5g-transport-slice/ 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 interface? 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 10:00 10m YANG Model for QoS https://datatracker.ietf.org/doc/draft-asechoud-rtgwg-qos-model/ 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. 10:10 30m 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 language. 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 guarantee. 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. Ê10:40 Ê10m Layer 3 VPN Network ModelÊ https://datatracker.ietf.org/doc/draft-aguado-opsawg-l3sm-l3nm/ 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 pruned? 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. Ê10:50 Ê15m Changes in the Internet Threat Model https://datatracker.ietf.org/doc/draft-arkko-arch-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.