INSTRUCTIONS:
Please find the related presentation slot below and add/correct notes there.
Please DO NOT add notes at the end or beginning.
 
NOTE TAKERS ADD YOUR NAMES HERE (not required):
Ethan Grossman
János Farkas
    
> DetNet Agenda IETF104 (Prague)
> Version: Mar 12, 2019
> Wednesday, March 27, 2019 (CET) (+01)
> 9:00-11:00  Wednesday Morning session I
> Congress Hall 1
> Slides: https://datatracker.ietf.org/meeting/104/session/detnet
> Etherpad:       http://etherpad.tools.ietf.org/p/notes-ietf-104-detnet?useMonospaceFont=true
> Meetecho:       http://www.meetecho.com/ietf104/detnet/
> Audio stream:   http://mp3.conf.meetecho.com/ietf/ietf1043.m3u
> Jabber: xmpp:detnet@jabber.ietf.org?join
> Available post session:
> Recording:      https://www.ietf.org/audio/ietf104/
> YouTube:        https://www.youtube.com/user/ietf/playlists


> Num Start Duration Information
> 1  9:00    10      Title:  Intro, WG Status, Draft Status
> Presenter:      Chairs
> Draft:
    Architecture draft had IESG review comments from security area - these were addressed to their satisfaction by authors and Security draft authors. Should make it to RFC editor queue soon.  
Security draft still being held up from publication to make sure it is aligned with solution drafts. Hope for publication requests for solution drafts by Montreal (i.e. next IETF 105) so once those are stable we can finish the Security draft and consider publication. Also at Montreal we plan start discussion of what to do next, e.g. control plane or other topics. If you have other topics, Montreal would be a good place to consider them. Note that not everything is in scope for DetNet, but we can discuss where to route them e.g. to other working groups.  

> 2  9:10    10      Title:  DetNet Architecture
> Presenter:      János Farkas
> Draft:  https://tools.ietf.org/html/draft-ietf-detnet-architecture-12
Lou Berger: Re: "No expectation that DetNet app-flows will respond to congestion control": 
An implication, ripple effect:  At Service interface level, must understand whether app traffic supports congestion control or not - this affects flow model, Yang model; we hadn't before had awareness of anything related to application. To address this have toadd extra text on requirements for what we have to do for traffic that is not congestion controlled.
Stewart Bryant: Concern about congestion controlled traffic. Amount of traffic in the open that wasn't congestion aware was trivial. IN cases where non-elastic is in a controlled environment. We don't want to require full analysis of application traffic before it can be deployed on network. 
Janos Farkas: Correct, we are for a single administrative domain, a controlled environment, plus we have added text regarding rate limiting and use of shapers; that's all you need; you don't need to know every flow. These are the rate limiting tools you need to have protection against misbehavior, at entrance to DetNet domain.  
Stewart Bryant: Why a single domain vs a set of domains that understand what each component is doing?
JF: Our charter says that. 
SB: Maybe revisit that? Unreasonable to not be able to split domain into multiple components if that suits you.  
JF: Maybe add that in our charter update? First finish current charter, then enhance? 
SB: People will ignore it if they don't like it. 


SB: (Regarding "scope of DetNet is a single administrative domain"): We would be better served to say "within a controlled domain, not the open Internet". Because we did that with pseudowires, but then we had to do multi-segment pseudowires which are not a single administrative domain. Could imagine needing similar thing with DetNet also. Better to say "one or more controlled domains", not a single one which has its own set of restrictions.   

JF: But if two domains, do you mean they might have separate owners? 
SB: Yes so that labels could be managed by the domains separately. Better to point to the real problem, which is that this is about control and oversight of the deployment, not about restriction to a single administration. 

LB: Good to check exact text of docs - the only place where explicitly says single administrative domain is when talking about security. Architecture text says "not for large groups of domains such as the Internet". We can agree on that much, as stated in our charter, so probably no contention there. So regarding single admin or not, please read draft text in context. 

Deborah Brungard: This is a "hot button" item, "Domain, what is the domain?" Could say a DetNet domain crosses multiple adminstrative domains. The most important is that it is a controlled domain. Sub-networks may not be not DetNet aware but can still get across them. So if it says "Administrative domains" in the Security section please review, give it a bit more thought before deciding. 

LB: Doc is now owned by IESG. 
Deborah Brungard: These are not technical changes, just clarification, charter is clear, mostly want to say "not the open Internet"

JF: Text in doc was copied from Charter. Says "closed group of administrative control". 

LB: But Security Considerations section says "intent of a single administrative domain". 
Deborah Brungard: How about instead saying "single administrative control".  

LB: So replace "single administrative domain" with "single administrative control"? 
Deborah Brungard: Or "closed group of administrative control", get away from use of "domain".
LB: But I'm worried about any changes here, we have to be careful since draft already with IESG, need to be coordinated with IESG. 

Deborah Brungard: If they push back on removing "domain" I can explain to them that it is very confusing. 

SB: Text "Within closed group of administrative control" is good, sets out what we need to do. Need to make sure that is reflected everywhere. 
JF: Need to review new Security text for this, since was recently revised, maybe we weren't too careful about this there, but we were careful in charter about this. 

David Black: On behalf of Transport area, thanks for massive improvments over draft 8. 
Going back to Stewart's comment, I agree that it should not be necesary to analyze applications for congestion control or lack thereof. There are many DetNet applications that are not congestion controlled, e.g. broadcast video editing. Paradigm to apply is assume it is not congestion controlled unless you know it is congestion controlled, and take appropriate measures at the boundaries. Applies double if doing PREOF - if a replicated flow escapes, the elimination node may not notice that it is only recieving the other flow, so you can have an unresponsive flow going out and causing damage. 

JF: We did add text for this (sec 3.3.2) 
LB: This will impact Yang models, so we need a way to indicate this, which is not there now; make it optional with a default value of false. 
DB: Right; treat it as a potential source of problems, deal with them, but if you have no problem, so much the better. 
 

> 3  9:20    30      Title:  DetNet Data Plane drafts (IP and MPLS)
> Presenter:      Balázs Varga
> Draft:  https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-ip-02
> Draft:  https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-mpls-02

Balázs Varga: Question to WG: Are we are creating building blocks or a solution? Means how many documents to define the data plane? If building blocks, then we would split the data plane drafts into more drafts (see proposal in slide). Usually IETF specifies building blocks, but some other SDO's are specifying solutions. We would like to do last call before Montreal. 

Norm Finn: Breaking up docs sounds promising. Do you have comments on how to address zero congestion loss, finite latency? I know how we do this in TSN parts, but how to tie this into doc structure for non-TSN parts? 

JF: Maybe it isn't part of data plane docs? Put in Bounded Latency draft? 
Norm Finn: Hopefully it can do that for all of them. 

LB: Items 3,4,5,6 would need to talk about req'ts on underlying layers for Q'ing mechanisms. This group generally doesn't define Q'ing mechanism, but we do discuss how to use Q'ing mechanism, or where an implementatino is required to use one, e.g. IntServ and DiffServ; mechanism to achieve service is not described, only behavior on the wire is required. 

NF: Understood. 

David Black: Where would the guide be to tell how to put these together? Which docs apply to what they are trying to build and how to put it together? 
LB: Is there ever something like that? 
DB: This WG is building an overall technology. I know some examples at smaller scope, like in Transport, after the fact we had to write guide to TCP specs. Maybe good to do this before people try to implement. Where does that go? 
LB: It would be in a separate draft. 
JF: Trying to do what 
Michael Scharf: (as reviewer of Arch doc). Noticed that there is a mix of diff't arch solutions in the doc, made review difficult. Good to separate into separate docs. But please pay attention to this. Split is a good idea based on Arch doc. 

BV: Have several scenarios in Arch doc. 

MS: But in reading it I dad to distinguish between things that apply in MPLS only, which should have been easier if it was split out. 
SB: Some will come from the proposed framework component of first docs. Maybe wait until split is done before trying to do summary. 

Deborah Brungard: (As AD) Good to think about this now, was late in some other cases. Looks daunting with 2 docs becoming 7. But looks clearer, and it is good to think about users and what they are looking for. User will see all of these titles - can be daunting - so take care to have good titles - at this point naming is inconsistent, e.g. "detnet" at start vs in the middle of title names.
 
 BV: Agree need work on titles. 
 
Andy Malis: As contributor to large docs, reading them is a chore. This split will help make this more approachable for newcomers. 
Mach Chen: Is split based on current 2 data plane drafts? Or consider other potential dataplane e.g. SRv6 sol'n? 
BV: This list is about splitting current two. That is where we have the structure. 
JF: Maybe discuss this in SRv6 slot? 
LB: Makes it easier to bring in new technologies having it split like this;, don't have to hold base document until all possible technologies have been covered. 
BV: We have identified these seven so far but not limiting to these. 

BV: MPLS data plane content should be ready for last call after split into multiple drafts. 


> 4  9:50    15      Title:  DetNet Flow Information Model draft
> Presenter:      Balázs Varga
> Draft:  https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-03

(No discussion) 

> 5  10:05   15      Title:  DetNet Configuration YANG and Topology YANG Model Updates
> Presenter:      Xuesong Geng / Mach Chen
> Draft:  https://tools.ietf.org/html/draft-ietf-detnet-yang-01
> Draft:  https://tools.ietf.org/html/draft-ietf-detnet-topology-yang-00

Xuesong Geng: Ask for help from group in defining YANG model, is complex. 
LB: Work with BV and flow info model since changes there will affect YANG model. OK to contact them individually, then post discussions/proposals to list. 

JF: (regarding structure re-organization of current Yang models): Which option do you prefer?
XG: Maybe option 3. 
LB: Need some reorganization, align with flow info model, e.g. service and forwarding layer separation. Will have to ripple down into YANG. Agree existing node-based organization needs to be improved. 
Sync with flow info, alignment with other drafts then may inform this. Also work going on in TEAS - don't want to repeat that work - can we augment or reference TEAS models? 
Still early, need to sync, which will clarify a direction for us. Early to say whether option 2 or 3. 
XG: Need more collaboration between WGs and between our WG draft teams. 
LB: Maybe we can get the groups together to talk this week. 

Yeon-cheol: Prefers option 3. Better aligned with existing Yang models.  
XG: Yeon-cheol has made useful comments on this draft. 

DB: Agree that either 2 and 3 are better than current node-centric of 1. 



> 6  10:20   10      Title:  DetNet Bounded Latency
> Presenter:      Ehsan Mohammadpour
> Draft:  https://tools.ietf.org/html/draft-finn-detnet-bounded-latency-02

LB: This is an informational doc to help implementers build detnet implementations, not prescriptive. But there was lots of interest in room last IETF so we thought it would be good to adopt it as a WG draft.
Who thinks interesting work for this WG: reasonable number
How many have read the draft: about the same
How many think is reasonable starting point for WG draft: More
How many don't think it is good: None.
OK we will take it to the list.  

> 7  10:30   10      Title:  DetNet Bounded Latency Requirements and Related IETF Work
> Presenter:      Liang Geng
> Draft:  https://tools.ietf.org/html/draft-geng-detnet-requirements-bounded-latency-01

Liang Geng: This is about considering issues for DetNet in large scale networks e.g. China Mobile. It is informational. Outline of problems we face to bring DetNet to large scale, e.g. TSN island interconnect troublesome for maintaining bounded latency.
JF: TSN is a layer 2 subset, so not part of DetNet work. 
LB: Appropriate to bring these operational considerations to DetNet. Raises issues with TSN technology, probably valid, but since owned by IEEE, we can't do anything about them here. Here all we can do is make sure we have constraints on what implementers do in using underlying technologies. So if you refactor the doc to "req'ts for scalability for DetNet" that would be helpful, generalizing but perhaps using TSN as an example; but in general if a given layer 2 technology (e.g. TSN) doesn't work for a given use case or application, then DetNet just can't use it for that. 
LG: Then at that point we don't have a solution. 
LB: We don't have to specify Q'ing technologies here, it is out of scope. Maybe if have local point-point MPLS link, with local Q'ing algo that can satisfy requirements. As long as it meets the operational requirements. Bringing your experience is great, but don't say it in the context of TSN because the answer is "go to TSN". 

DB: Lou are you overstating the context of TSN? I could read the criticisms in this doc in 2 ways: 1) Could read as "TSN doesn't solve all of our problems, IEEE could fix it". Or 2) "TSN was designed to solve some problems, but not all DetNet applications, so maybe something could be done outside of TSN to address these". Would encourage consideration of both perspectives.  
LB: First perspective doesn't belong in this room.  
DB: Agree, but want to make sure second is considered. 
LB: Maybe second could be done in other IETF areas, like your WG? (TSVWG)?
DB: We can have that discussion now or in a couple of drafts, when would you like? 
LB: Let's have this discussion at end of solutions document. 

NF: Appreciate your comments. Note that at next IEEE 802.1 it will be pointed out that cyclic methods in 802 may be more powerful than currently appears, particularly scalability. 
JF: DetNet doesn't go into synchronization details, we don't want to reinvent the wheel, just use time sync techniques as needed for deployments. At DetNet to TSN interface, there may need to be some time sync, but we are not going into those details here. 
LG: If long link, or large scale implementation, we can do it through time sync, but that is also a lot of work. We bring it up here to consider doing it with async case.  

> 8  10:40   10      Title:  Large Scale DetNet Update
> Presenter:      Cristina Qiang
> Draft:  https://tools.ietf.org/html/draft-qiang-detnet-large-scale-detnet-03

LB: Not clear on doc: Says informational, but then goes into Q'ing details, and comments on issues with TSN Q'ing mechanism - where are you going with this doc?
CQ: It is to provide a generic framework to deploy Q'ing mechanism at layer 3. A specific encapsulation to address the need for 2 bits of cycle identifier to meet QoS guarantee. So the Q'ing implementation is in the network. But the important thing is to justify the need for the 2 bit cycle ID. 
LB: Sounds like definition of Q'ing mechanism, which in IETF happens in Transport area. If you want to define support for a Q'ing mechanism, it has to be a standard Q'ing mechanism so have to run through TSV are first, and have them give us the answer for a Q'ing mechanism. Then determine if req'ts for Q'ing. 

Toerless Ekhard: (as co-author of this draft) We are trying to break the deadlock between what is defined by one WG vs another WG. Don't want to define a Q'ing mechanism, but want to define resulting per-hop behavior. We understand that for TSVGW to accept the work, need to have justification from other WG, so this draft is to express that we need that solution. 

SB: Agree with TE, this doc sets up the context of the problem. Then need work from Transport are to validate per-hop behavior. Then neeed to go to other groups to define marking in packet itself. Three pieces of work, so starting with this. 

LB: I understnd how the previous doc sets up req'ts, but this now looks more like a description of a solution - that should be in TSV working group. This is a nice sol'n proposal to bring to a group that defines Q'ing mechanisms. 

DB: Go back to Microburst slide: On this slide there isn't the word "Q" in the slide - but yet there is a behavioral spec that could be a foundation of a PHB, it starts from a time (oh, the word Q does appear there) sequenced stream, and we want to ensure it doesn't pile up and turn into uneven microbursts. That could be done by referencing some mention of time interval without the specifics of how the Q'ing works inside. That kind of careful teasing apart could get us to a PHB spec that doesn't tell the silicon people how to implement the Q's.  
LB: That makes sense but I would call it an Intserv flow spec rather than PHB since it is per flow not per class basis. 
DB: Needs longer discussion about this because I heard from authors that they are more interested in DiffServ framework. This chart provides the basis for on the wire behaviorable spec that gets you away from explaining how the Q's work in the silicon. 
LB: That would be fine then we would remove the Q'ing discussion from this doc then we'd have something useful here. When we get to Q'ing behavior we get outside of DetNet scope.
DB: Could put the Q'ing to give it context, but make sure it has word "example" in it somewhere
LB: But we didn't do that in Diffserv or Intserv so it makes me uncomfortable. 
DB: This one is a bit novel, doesn't hurt to have some details on how you could make it work, but point noted.
LB: Maybe an appendix as a compromise.

TE: If we haven't gotten the point over, then we need to improve either the text or slides. Saying Intserv per flow, the point is to not have per-flow state in midpoint P nodes, only state for class, so it can scale to more flows.  
LB: That is an aggregate flow, so it looks like one flow, but supports many other flows.

TE: No because you never have a situation where more user traffic creates more of these flows. The notion of a flow is something that has a relationship to application levels. 

LB: That's the place to focus - i.e. a discussion of how you propose to change our architecture to better support scaling. All we have today in or Arch to handle scaling is aggregation of flows. So if you want to move away from this model, that should be the focus of this draft. Throw out Q'ing pieces, discuss architectural implications, then we can talk about how to implement it. Q'ing is down in the guts, out of our scope. If the main focus is to get away from the aggregate model, that's new, cool, great to bring in, but make it the focus of the discussion. 

TE: By the way the whole IETF mindset of trying to eliminate discussion of anything internal to the router, I invite you to the next generation router discussion today, because that is exactly one of their bitching points. I don't know if TSN would have ever been implemented correctly if they had taken this stance. 
  
LB:We are not the IEEE and we don't want to step on their toes. 

TE: Not stepping on their toes, we are fine with structural stuff like appendix, but without an idea of how someone would have implemented it. I think people who wrote the PHB had examples in mind. 

LB: Yes in the days of IntServ I was there building solutions and Q'ing mechanisms, but IETF chose not to standardize them.  Implementers will always have an idea how to implement it, but IETF won't always standardize that, maybe some other SDO. 
But the notion of a different form of aggregation is something we should consider in this document. 

Ehsan Mohammadpour: In the slide for delay calculation, it is 2 times the parameter T. Is it the same T at every node? 
CQ: Yes. 
EM: Isn't it hard to have a lot of nodes all with the same T? Maybe different nodes need bigger T values due to number of ingress ports or flows entering the node? 

CQ: Yes, the same T is easier to achieve compared with time sync as used by other TSN technologies. 

CQ: For TSN it makes sense since you don't have many nodes, and you can synchronize so you can keep same T. But with large scale network it is hard to have the same T. Also if there is more than one T, how can you guarantee that there is only one packet per cycle - maybe there can be more? You assume maximum 2 packets from prev node, but if T is diff't then there will be more than that. So how to address this for large scale DetNet? 

CQ: Asynchronous shaping (ATS) can have this kind of problem, but ATS has another challenge to provide bounded jitter. 

EM: I'm not talking about ATS, I'm talking about this approach of LDN. Maybe there are some challenges in ATS, but the delay calculation in this doc is not accurate. I would like to see the results proven in some papers, and the results referenced in the draft, rather than have the mathematical proof in the draft. 

LB: Need to take details offline due to time constraints. Good to spend some more time offline with Stuart and David to discuss where to go next with this. 

SB: I think it is misleading to say we're treading on IEEE's toes, this is not the intent here. What we want is to solve this entirely at the packet layer, which is nowhere near IEEE, we want an independent sol'n at packet layer. Scope and range is larger than what IEEE is addressing. Also we are missing a catalog document together describing the set of Q'ing mechanisms so that people know which to pick for given application, its advantages and disadvantages. This is valid work and we do need to find a home for it. 

LB: Q'ing is within scope of IETF, just not in DetNet. 

SB: We need to do things in IETF, so we could incubate doc here, then figure out with ADs where to take it next, rather than the other way around. 

LB: I would like us to describe a new form of scaling strategy into our arch. Scaling has come up before, important to decide if it is important to include in a DetNet solution. Right now it is explicitly excluded, i.e. we only have aggregate flows.  
If need diff't than aggregate flows we need to address this. 

SB: It is, and is important to get to the next level of scaling. 

LB: So we need to get consensus that this is something we want to work on, not yet ready for Q'ing details. 

DB: (As TSVWG chair) TSVWG is happy to do work for others groups. However there needs to be relationship with the group that needs the work, so the decision needs to be made here that this is interesting work. We need scope and requirements. TSV can work out the details but first we need to define the forwarding behavior here. 

LB: This draft of the doc is more about a solution but with the concept of scaling without flow aggregation. The real question seems to be whether we need a better sol'n for scaling. I don't think we have such a solution, but the WG has to weigh in on this. 

TE: I hadn't heard the word "requirements". At 103 feedback was we should define requirements So should the doc address how to solve this problem? 
 
LB: Yes, previous doc was about requirements for large scale, title is requirements for large scale, that is what this draft should be about. 

TE: But do we have a separate requirements doc? 

NF: Bounded Latency draft points out that some specific Q'ing mechanisms (including some IEEE mechanisms) don't require any state in any node along the way. So allows rapid dynamic additions and deletions of traffic. So it is not wholly new to desire scaling that is not related to flow aggregation. Not clear that this is a new concept; not arguing for or against anything in the draft, just pointing it out. 

DB: Need to distinguish between scaling of flows, however aggregated, vs scaling in terms of network scope. 

LB: Lots of aggregation semantics, need to understand failings of current mechanism. 

DB: To the extent that there is a functional gap it seems to be in network scope, e.g. extend time sync to arbitrarily large networks, is there uniform time sync, or what happens on high-jitter links. 

LB: Need solutions for this so we want to translate those requirements to pass on to TSV for solutions. 

LB:Out of time, apologies for skipping 2 individual doc submissions, including SR, please read them on your own and discuss on list. Chairs need to work with our AD and SPRING to see where the SR work should take place. 














> 9  10:50   5       Title:  DetNet SRv6 Data Plane Encapsulation
> Presenter:      Xuesong Geng / Mach Chen
> Draft:  https://tools.ietf.org/html/draft-geng-detnet-dp-sol-srv6-00


> 10 10:55   5       Title:  DetNet VPN
> Presenter:      Zhe Chen
> Draft:  https://tools.ietf.org/html/draft-chen-detnet-det-vpn-00


> Adjourn         11:00
>