> TEAS Agenda For IETF 105
> Version: Jul 19, 2019
> Session 1: Tuesday, July 23rd 2019
> Session 1 13:30 - 15:00 Tuesday Afternoon Session I
> Session 2 15:20 - 16:50 Tuesday Afternoon Session II
> Location: Laurier
> Slides: https://datatracker.ietf.org/meeting/105/session/teas
> Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-105-teas
> Meetecho: http://www.meetecho.com/ietf105/teas/
> Audio stream: http://mp3.conf.meetecho.com/ietf/ietf1053.m3u
> Jabber: xmpp:teas@jabber.ietf.org?join
> Available post session:
> Recording: https://www.ietf.org/audio/ietf105/
> YouTube:
> Presentation Start Time Duration Information
> 0 13:30 10 Title: Administrivia & WG Status
13:36
> 1 13:40 10 Title: WG Draft updates
> Draft: Many
> Presenter: Chairs
13:42
> 2 13:50 10 Title: A YANG Data Model for Traffic Engineering Tunnels and Interfaces
> A YANG Data Model for MPLS Traffic Engineering Tunnels
> A YANG Data Model for Resource Reservation Protocol (RSVP)
> A YANG Data Model for RSVP-TE Protocol
> Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-te-21
> https://tools.ietf.org/html/draft-ietf-teas-yang-te-mpls-01
> https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-11
> https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te-07
> Presenter: Tarek Saad / Xufeng Liu
(Regarding draft-ietf-teas-yang-te-21)
Lou Berger: Is there support for the IPSEC RSVP types? RFC 2209?
Tarek Saad: I'm not sure, we'll check
Lou Berger: You should. We need to support it. The session will probably be OK but sender template may be a problem.
Dhruv Dhody: Question about name collision, especially the first case where the controller learns the tunnel name from devices (open issue #2 in slides): do you have any details on where the R1/R2 string will come from (the prefix for controller source)
Tarek Saad: one proposal was to use source address, but that's unpredictable (could be a DNS name or a configured name at the ingress, etc)
Dhruv Dhody: so why didn't we put name + source as the key?
Tarek Saad: we have one list that has all tunnels from all devices. We could split it but we want the model to work on both controllers or devices
Pavan Beeram: It depends on where you get the information, and it is also possible to have multiple sources for the same name. This is a controller only consideration, and it is set based on the identifier used by the controller to identify the source of the LSP
13:52
> 3 14:00 10 Title: TE topology yang models
> Draft: https://tools.ietf.org/html/draft-ietf-teas-yang-l3-te-topo-05
> https://tools.ietf.org/html/draft-ietf-teas-yang-sr-te-topo-05
> Presenter: Xufeng Liu
(Regarding draft-ietf-teas-yang-l3-te-topo-05)
Greg Mirsky: clock synchronisation is important for accurate delay measurement; packet loss and delay variation aren't susceptible to clock synchronisation
Xufeng Liu: the authors have discussed this. The current approach is to keep the 2-way metrics as they can be useful in some situations.
Greg Mirsky: An interesting question is how to determine clock synchronization, and determine whether the quality of it is up to the standard required for delay measurement. Some applications, e.g. ultra-low-latency in 5G, may require very high quality clock synchronization. Using 2-way measurement to calculate 1-way metrics is useful, but it's important to specify that this has been done.
Rakesh Gandhi: do you have both 1- and 2-way populated, or just one or the other?
Xufeng Liu: we allow both, but you can have only one of them. If one doesn't exist you just don't use it.
Rakesh Gandhi: it would work when you have for example only 2-way, and you can get the 1-way data dividing by 2.
Xufeng Liu: yes.
Greg Mirsky: there are measurement methods that provide both 1- and 2-way measurements.
Xufeng Liu: do you see any changes needed to the model?
Greg Mirsky: clock synchronization is a separate question and I'm not aware of methods to quantify it or measure it. For performance measurement we can discuss how this model relates to the STAMP yang model (IPPM WG draft).
Xufeng Liu: this is a TE model so we're only concerned with TE metrics, importing the groupings from te-types. If we need to add things it could be troublesome we're already past WGLC, so it would be better if we could live with this.
Greg Mirsky: I'll take a look and see. It would be good if the clock measurement model is easy to map into the model that characterizes link performance.
14:03
> 4 14:10 10 Title: A Yang Data Model for VN Operation
> Draft: https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-06
> Presenter: Dhruv Dhody
Qin Wu: changing to AP would make sense. RFC8453 has already cover both the customer view and operator view, and CE or PE as the end point of VN.
Dhruv Dhody: Just changing to AP will solve the problem, but the bigger question is can we have a VN member with just PE-PE without an attached CE. AP is an identifier between CE and PE. We'd want to drill down that requirement a bit an see how we can solve it. Does the slide reflect that?
Qin Wu: First issue on (slide 4) on VN members is good so far.
Dhruv Dhody: did I explain the second issue properly (since it comes from you)?
Qin Wu: On that one, since you follow the ACTN framework and support customer and operator views, you need to distinguish between them. How do you do that? You could also introduce a node-id to support PE-PTE connectivity.
Dhruv Dhody: bigger question for the WG is what we think about this requirement
Qin Wu: Loopback is already defined in the model, right?
Dhruv Dhody: yes, you can us it without any change; it's just an identifier, like binding a loopback interface to a VRF
Qin Wu: I'm not sure which is the best choice. You could introduce another identifier to indicate whether this is customer or operator view.
Dhruv Dhody: need to make it clear what we're referring to, i.e. AP could refer to a CE or a PE.
Lou Berger: why is this comment scoped to ACTN rather than being general? Nothing in this discussion is specific to a controller-based model.
Qin Wu: I mentioned on the list that I'd prefer this to be generic, but this draft has an ACTN context, using ACTN figures and terms. The VN itself should be generic.
Lou Berger: So ACTN is used as an example.
Igor Bryskin: my understanding is that you see a VN as a node that has links, and it's the responsibility of service mapping to assign CEs to a VN. But it should be decoupled; you can talk about a VN as an abstract topology or a set of tunnnels.
Dhruv Dhody: so you're saying that this is already there, and we can do this right now?
Igor Bryskin: Yes. VN as a service doesn't include clients of the service; the model maps clients to the service. This could be done at the same time, or later, and the mapping could change at any time. I think it's perfectly legal to think about VN without CEs.
Daniele Ceccarelli: I think the requirement makes sense but I agree with Igor on the requirement. An AP doesn't imply a CE. The AP can have a 1:1 mapping with the PE node and you can have a hook with nothing hanging off it.
Italo Busi: what's the difference between a PE-PE VN member and a te-tunnel? Why aren't we using the tunnel model to represent the PE-PE VN member?
Dhruv Dhody: Do we want to talk about this *again*?
Italo Busi: no, I'm just trying to understand why we don't use the tunnel model.
14:15
> 5 14:20 10 Title: YANG models for VN & TE Performance Monitoring Telemetry and Scaling Intent Autonomics
> Draft: https://tools.ietf.org/html/draft-ietf-teas-actn-pm-telemetry-autonomics-00
> Presenter: Dhruv Dhody
Igor Bryskin: when the client tries to configure scaling for the tunnel it defines conditions and thresholds. So you have to take a list from the model to define them correctly. But what the client wants a combination of two conditions? it would be awkward to modify the model. You're trying to envision the client's logic when they do this. I think a better way is the approach taken in NETMOD to try to introduce information in yang in the form of logic rather than configuration. So you can define thresholds and conditions, and then the combinations of these that trigger particular events.
Greg Mirsky: in IPPM WG discussion we got feedback from people using PM in the field, and we learned that min and max are not very useful metrics. Mean is a little bit useful. What's a lot more useful is a percentile, and usually they use 95%, 99%, and 99.9%, which are used as threshold. Then you can determine the percentile and compare it to the threshold.
Lou Berger: do you have a reference for that?
Greg Mirsky: STAMP yang model. It's a WG document.
Haomian Zheng: Regarding te-kpi-telemetry, it is current generic model without technology-specific performance monitoring. Do we have plan to add tech-specific parameters into this work?
Dhruv Dhody: Not for TEAS, but may do some work in CCAMP if there is demand for technology-specific. We can use this as a base and do augmentation on it.
14:24
> 6 14:30 10 Title: GMPLS Signaling Extensions for Shared Mesh Protection
> Draft: https://tools.ietf.org/html/draft-ietf-teas-gmpls-signaling-smp-01
> Presenter: Italo Busi
Tarek Saad: why wouldn't you use soft pre-emption? That wouldn't tear down the LSP.
Italo Busi: Good suggestion - we can discuss more offline
Pavan Beeram: in the previous version you were using protection?
Italo Busi: yes, we added a new field.
Pavan Beeram: initial feedback was to use a new c-type
Lou Berger: for the issues you raise, it seems you're not consistent with RFCs 4872 and 4873. Did you look to ensure you're aligned with those RFCs, in particular with respect to notification about errors and faults, and protection switchover?
italo Busi: in 4872 SMR, the protecting LSP is torn down when there's pre-emption.
Lou Berger: Look at 1:1 and 1+1 protection; it uses notifies so you don't have to change state at intermediate nodes and that gives you faster switchover. I'd suggest you re-use the mechanisms there as much as possible.
Italo Busi: OK. For pre-emption priority it's a bit different. SMR relies on GMPLS. What we want here is to keep an LSP in the control plane and not activate it in the data plane.
Lou Berger: re APS: our AD has said we need to be careful not to standardize ahead of the SDO that owns the technology in question where we don't own it. So I'm a bit concerned about options 2 and 3 (slide 6); we don't want to get ahead of the ITU-T on things they own.
Italo Busi: so keep it out of scope?
Lou Berger: I think that's safest.
Deborah Brungard: what's the solution at ITU-T?
Italo Busi: ITU-T G.808.3 is a generic recommendation without any APS protocol, which is supposed to be left for technology-specific solutions. Currently the only technology defined today for SMP is OTN-SMP, adn we don't have any APS protocol defined for that. There has not been any solution yet.
Deborah Brungard: should we have a liaison to ITU-T to say we're working on this and ask them what their expectations are? Or maybe we should do a vendor-specfic one.
Lou Berger: would you be willing to draft a liaison?
Italo Busi: yes, OK
14:37
> 7 14:40 10 Title: Interworking of GMPLS Control and Centralized Controller System
> Draft: https://tools.ietf.org/html/draft-ietf-teas-gmpls-controller-inter-work-01
> Presenter: Haomian Zheng
Pavan Beeram: this work covers intiating tunnels/LSPs from the head, like PCE. Does it cover transit too, i.e. end to end provisioning?
Haomian Zheng: yes. It can be done end-to-end or segmented
Pavan Beeram: does this cover the situation where the controller has to program every hop?
Haomian Zheng: Yes. You can do it from the controller and stitch every hop together.
14:45
> 8 14:50 10 Title: RFC3272bis -- Design Team report
> Draft:
> Presenter: Adrian Farrel
(options referenced in discussion are on the last slide)
Lou Berger: do you personally have a preferred option to continue? Does the design team?
Adrian Farrel: I think other members of the design team should answer for themselves. Personally, I think we should try option 2 (new techniques with current team) as I think this is useful work, but I'm not getting the sense there's a huge desire to do the work, in which case option 4 (abandon the effort) may be best.
Igor Bryskin: We're asking too much from the DT. The work is huge. We have to do it really seriously or take option 4
Lou Berger: so you'd agree with option 2 or 4?
Igor Bryskin: yes.
Tarek Saad: I thought there was enough change to review and publish a -00 draft, at least. I think we can deliver a -00 version, so I'm leaning towards options 2 or 1 (carry on as we are).
Julien Meuric : option 2 or 3 (relaunch with a new DT) look good. Choice between 1 (carry on as we are) and 2 is up to the DT leader; I'd prefer to try these before anything else and give the design team a second chance.
Lou Berger: we (the Chairs) would like to see the work progress. We don't care about tooling; that's the design team's call. For me, option 1 and 2 are similar.
Adrian Farrel: that's an internal difference for the team. So I think we'll go with 1 or 2.
Lou Berger: so let's proceed with 1 or 2, at the discretion of the design team
14:54
> Adjourn 15:00
>
> 15:20 - 16:50 Tuesday Afternoon Session I
> 0 15:20 10 Title: Administrivia
> Draft:
> Presenter: Chairs
15:21
> 9 15:30 10 Title: ACTN Applicability of ACTN to Support Packet and Optical Integration
> Draft: https://tools.ietf.org/html/draft-lee-teas-actn-poi-applicability-00
> Presenter: Daniele Ceccarelli
Michael Scharf: I think we should split VPN from POI. The problems can be solved independently. On more POI use-cases - there are quite a lot of them and what you have here is probably not the most important one. There are higher priority use-cases.
Daniele Ceccarelli: OK. The goal here is to create a generic use-case and try to address it. Are you saying we should define separate use-cases and then show how we address each?
Michael Scharf: I think there is value in documenting all the use-cases; there are several that are well-known. But you should start with the more realistic ones that are closer to market needs than what's in this document.
Italo Busi: I agree that we should split the doc. Packet-optical deals with multi-layer infrastructure while VPN deals with supporting VPN services over ACTN and can apply to only IP
Haomian Zheng: I'm not sure whether we can split the doc in a perfect way, as VPN is very specific and POI has a lot more use-cases. So we could consider VPN to be just another use-case, and make sure it won't conflict with other POI cases.
Dhruv Dhody: On the difference bewteen service-network model and service-device model: L3NM was discussed in RTGWG and maybe in the Ops area. Are we doing 2 [Service-device model] because we don't have a L2NM, or because you think it's the right thing to do? Is this something that the controller can use to talk to the device?
Daniele Ceccarelli: I think in the future all controllers will have the ability to create VPNs, so everything will be service-network model (no. 1). In the meantime, the service-device model is definitely needed.
Igor Bryskin: I don't understand this idea of the L3 network model because the model is an API between two controllers, and a controller has to talk to many people so so you have to have different models. There may be orchestrators on one side, but I don't understand what might be on the other side of a L3VPN model. So MDSC can talk to devices, e.g. whenever there's a need to attach service to tunnels produced by other models
Dhruv Dhody: I disagree; when implementing, we found that not having an L3NM model created too much confusion. The domain controller's job is to talk to the device for the TE model, but for VPN you bypass it and go straight to the device, which didn't seem like the right approach. In any case, TEAS probably isn't the right place for L3NM discussion.
Daniel King: the idea of modelling services and then developing models like the IETF does tends to lose integration and operational issues. We're good at fragmenting the models, but we tend to lose sight of the end-to-end service. What we hear from industry is that yang, and the IETF yang models, don't get used because the IETF doesn't understand the end-to-end service and it's hard to use the separate models to provision it. So, we do need these documents. Second thing: as a co-author of the other POI document I do think there's some synergy here; we need to look at particular use cases and do some gap analysis on which models you need to combine to provision a service.
Italo Busi: I agree with Dhruv. Interface 2 (service-device model) has an issue with the consistency of naming. We need something in the domain controller that takes the configuration of the VPN service and turns it into device configuration. It could be a lightweight solution if this is too complex for the domain controller.
Daniele Ceccarelli: just the first interface type (service-network model) would be great. The problem is that there's a lot of service-device implementation deployed at present.
Lou Berger: so we look forward to seeing what happens with the draft.
15:40
> 10 15:40 10 Title: ACTN applicability to 5G transport
> Draft: https://tools.ietf.org/html/draft-lee-teas-actn-5g-transport-00
> Presenter: John Kaippallimalil
Tom Herbert: On the mechanism, IPv6 extension headers could be a possibility. I wrote a draft for firewall (FAST) that's almost identical to this, ie we have a header that carries QoS and other information inside an opaque value. I presented my draft in IntArea as I wasn't sure where it should be, but maybe it should be here. It woudl serve a lot of the same aspects and also has some other features.
John Kaippallimalil: I'll look at it. We need more feedback on the mechanisms.
Tom Herbert: it's nice that there's options, but that's also a problem. The value of hop-by-hop IPv6 extension headers is that you do it once and it should work.
John Kaippallimalil: we want to do this for IPv4 and v6
Tom Herbert: Ipv4 is a separate question - I have some ideas on that. But it would be nice to have just one solution.
15:51
> 11 15:50 15 Title: 5G Transport Slice Connectivity Interface
> Draft: https://tools.ietf.org/html/draft-rokui-5g-transport-slice-00
> Presenter: Reza Rokui
Igor Bryskin: [On slide 2] Are these segments like having multiple connections (i.e. point-to-point), or having multiple topologies?
Reza Rokui: the latter one
Igor Bryskin: it might be better to draw it as a topology
Reza Rokui: OK. But this is a very high-level description
John Kaippallimalil: do you view this as one domain (transport and 3GPP)? And are these slices dynamic?
Reza Rokui: slices are very dynamic. There will be no configuration associated with them. And multiple domains will be possible. We should talk offline to see how our drafts fit together
Haomian Zheng: Are there any gaps in the existing models in thsi WG?
Reza Rokui: none of the models today meet the requirements here so augmentations will be needed. We don't yet know which ones though
Haomian Zheng: this ties into controller hierarchies; if we generalize this we end up with something similar. We have the TE and VN models, and layer-specific service models in other WGs, and my understanding is that a combination of those models is enough to satisfy this sort of requirement
Reza Rokui: we're supporting different connections, which are implemented by tunnels. There's a difference with the context we have here. But this is complementary with the hierarchy we have today and is a different use-case in the context of 5G.
Eric Gray: We're talking about an abstract interface which really describes a service interface, i.e. it specifies requirements for capacity, othe rparameters, etc, and this is done in a way that's orthogonal to the devices being used in the network. BBF can provide a mapping from that abstract interface to devices in SP networks. IETF has a number of models that support this ... so what don't we have? It looks like we're doing all these things at the same time whereas we probably need top-down development. I don't think we know exactly where we're going to end up with all this.
Reza Rokui: We have to study these things. The interface should be abstract, vendor- and technology-agnostic. What we're doing here is to map that interface to a specific implementation. We have to figure out how the IETF and BBF can work together.
Eric Gray: The issue is that you were talking about protocol work or yang work at the next IETF and I don't see how that's realistic given that we need to figure out what's there and what's missing from a top-down approach, e.g. 3GPP figuring out exactly what they're looking for. Other organizations will want to have a say and be coordinated with us. Doing protocol work by the next IETF may be over-optimistic.
16:10
> 12 16:05 15 Title: Packet Network Slicing using Segment Routing
> Draft: https://tools.ietf.org/html/draft-peng-lsr-network-slicing-00
> Presenter: Ran Chen
Tarek Saad: how to assign bandwidth to an SR flex-SID for the slice? How do you do bandwidth accounting for a SID?
Lou Berger: we've been grappling with what do to do with these drafts; there's clear interest on work in this area.
Poll: should we be working on support of 5G/slicing? Quite a lot
Lou Berger: maybe the right way to proceed is to set up a design team with the people who are interested in this and come up with a direction for the work in this WG. We'd expect that to be somewhat contentious but it would be good to have a proposal. We'll have to work to put the DT together so we aren't going to kick it off now. We'll need a balance of people - some who know what's happening outside the IETF, and those who know what's happening here and elsewhere in the IETF. So, we'd like some feedback from the WG.
Poll: who thinks this approach makes sense? A good number
Who thinks it doesn't? None
Lou Berger: please send a message to the chairs if you're interested. We'll send out a formal call once we have a charter for the DT, but there's no need to wait for that before you drop us a line.
Igor Bryskin: what would be the downside of not having a DT given that there's a lot of interest in the WG?
Lou Berger: sometimes we just tell authors to sort things out themselves. This time we're trying to be a bit more structured about it.
Igor Bryskin: if we have multiple solutions then we have to merge them, which is far more difficult.
Lou Berger: we don't think there's much agreement on the approach here, which is why we can't just tell the authors to merge their documents
Deborah Brungard: hopefully this DT will be more active than Adrian's :) We know that other SDOs are working on this (BBF, ITU). And we also have to define the terms we're going to use to talk about it - the ITU had trouble with mapping 3GPP terms to transport ones.
Jie Dong: I support a DT. What would be the DT's deliverable?
Lou Berger: that will be part of the charter so I don't want to commit now. We want to have a solid proposal for the WG. We won't expect a protocol solution - a framework at most.
Jie Dong: so a framework draft in this WG?
Lou Berger: yes, that could be a solution. We'd hope the DT would leverage all docs published so far - RFCs, WG drafts, and individual drafts.
16:24
> 13 16:20 15 Title: IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels
> Draft: https://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00
> Presenter: Tarek Saad
Uma Chunduri: What happens with setup if it's a loose path?
Tarek Saad: we're considering that. We have to be careful about loops under some conditions. But for now we're sticking to strict paths. You can have a loose hop in the ERO that gets expanded during signaling, but we don't want to rely on IGP routing.
Uma Chunduri: so how do you do loose path?
Tarek Saad: we can pin the path along the IGP path
Uma Chunduri: if it's a loose segment then you can encapsulate further.
Lou Berger: you can still run CSPF on the destination if the expanding node has the topology information.
Pavan Beeram: this is no different to loose-hop expansion today.
Uma Chunduri: but at the head, the loose path should have a
Lou Berger: keep in mind that in RSVP-TE the route calculation is based on endpoints, not the data plane identifier. We happen to be using an IP address as a data-plane identifier, but that's not used at all in the control plane. The only case where we use the label is optical.
Uma Chunduri: but what happens if the EAB gets to a node where the next-hop for it isn't installed?
Tarek Saad: part of the signalling is to install a RIB entry for the EAB.
Lou Berger: we hit this in DETNET where we have IP packets that escape the provisioning path. You have this issue whenever you're doing IP.
Uma Chunduri: you can handle this with encapsulation.
Igor Bryskin: how do we use these tunnels? Do we put a service label on them?
Tarek Saad: putting services over IP tunnels is possible today
Igor Bryskin: normally you would carry a label
Tarek Saad: you can carry information in IP options extensions
Igor Bryskin: are you talking about IPv4 or v6?
Tarek Saad: it's possible with both.
Igor Bryskin: are you going to use the IPv4 header for service information? Where does the label go?
Tarek Saad: we're establishing the tunnel in the transport layer. There could be multiple services over the tunnel
Igor Bryskin: there's obvious similarities with PBT-TE, and there are reasons that didn't succeed. Can you nest tunnels within tunnels?
Tarek Saad: Like IP-in-IP encapsulation? They do that in SRv6 too.
Igor Bryskin: bu every encapsulation requires a new header
Tarek Saad: yes, but they're doing that even in SRv6 and SRv6+.
Lou Berger: you could do this even without the encapsulation, and there could be value there, especially in the context of the DETNET work which uses more headers than just the destination. The expectation is that DETNET won't do control plane extensions but will just send requirements to other WGs. It would be good to be ahead of the game.
Tarek Saad: We can look at the DETNET requirements. Not needing multiple encapsulations would be a good thing
Dhruv Dhody: how do you assign separate address blocks? Where does that space come from?
Tarek Saad: the address block doens't need to be routable and can come from the well-known private address space. And it can grow dynamically as required.
Dhruv Dhody: Compare this to IP openflow with a controller and doing badnwidth management there... why use this instead?
Tarek Saad: we can now do distributed bandwidth-management, pre-emption, etc as for TE.
Julien Meuric: It looks like you rely on RFC 4090 for FRR. Have you considered looking at RFC 4873 (segment recovery with GMPLS)? This is just switching capability in GMPLS
Tarek Saad: There's no specific bias. 4090 is more common in the packet world.
Julien Meuric: so is this just convenient?
Tarek Saad: we're open to looking at 4873 and 4872
Adrian Farrel: you seem to be doing global context, destination-assigned, non-swappable label.
Tarek Saad: not global. It's between the ingress and egress along the path.
Adrian Farrel: But that is global, because paths might cross, and so the EA will have to be globally unique or the packets will be cross-routed when the paths cross. So the only difference between MPLS and this is is the size of the label. If that's true, and you believe that 20 bits isn't enough, you should limit it to IPv6
Tarek Saad: is there an issue in IPv4?
Adrian Farrel: People may be unwilling to consider IPv4 extensions. If you think that 20 bits is not enough for a label you should limit this to IPv6
Lou Berger: they could claim to be supporting the DETNET control plane, which includes v4 and v6
Poll: how many people think this is a topic we should work on (IP TE)? A few
How many think we shouldn't work on this? None
16:46
> 14 16:35 15 Title: Instant Congestion Assessment Network (iCAN) for Data Plane Traffic Engineering
> Draft: https://tools.ietf.org/html/draft-liu-ican-00
> Presenter: Bing Liu
Lou Berger: this has been presented in multiple WGs. Where does it belong? We should discuss with our AD.
Michael Scharf (as member of TSV area directorate): you have to look carefully at congestion control loops, and do this early in the design. There can be other control loops in the system which can interact.
Lou Berger: that's all. See you in Singapore.
> Adjourn 16:50