DetNet IETF100 (Singapore) Nov 07, 2017 0930-1200 Morning Session I, Sophia Slides: https://datatracker.ietf.org/meeting/100/materials#detnet Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-detnet Audio recording: https://www.ietf.org/audio/ietf100/ietf100-sophia-20171116-0930.mp3 YouTube: https://www.youtube.com/watch?v=WhFqlWurUuQ Jabber: xmpp:detnet@jabber.ietf.org?join # Start Time Information 0) 9:30 10 Title: Intro, WG Status, Draft Status Lou goes through the agenda and document status. Three documents (Architecture, problems statement, use cases) close to completion. The interesting thing is that keeping documents alive allows us finetune them. This is good as new people come in and they do not necessarily always see / understand all topics are we (old timers) do. 1) 9:40 10 Title: Use Cases Presenter: Ethan Grossman Draft: https://tools.ietf.org/html/draft-ietf-detnet-use-cases 00:08:40 on the audio recording. Greg Mirsky: agree that net slicing has a part (one out of three) that has strict requirements but other 3GPP identified scenarios may not require DetNet. Lou: Greg if you have any proposal for changes and enhancing the text post them to the list and we'll add them. Greg: I'll suggest some text on the list. Toerless Eckert: Not clear if slices needs DetNet. Ethan: Good point. One way it was phrased DetNet is a candidate technology for use in infrastructure of network slicing. It is not pure use case. Stewart Bryant: Having reviewed Network Slicing requirements, it is a clear use case for DetNet and it would be a mistake to remove it as a Use Case. It is perfect use case for something that is needed in 5G. 2) 9:50 15 Title: Security Considerations Presenter: Tal Mizrahi Draft: https://tools.ietf.org/html/draft-ietf-detnet-security 00:24:00 on the audio recording Greg Mirsky: what about attacks on OAM. OAM will be used for SLA assurance. If someone skews your measurements that will cause a false negative. While not specific to DetNet, should it be mentioned? Tal Mizrahi: good point, is there something unique to DetNet here? Greg: It depends on impact of OAM, e.g., Inadvertent unnecessary switch over. Issue with attack on Performance measurements. In some networks perf. measurements are only done for billing here I would envision they are also done to find out whether there is a need to reroute. Tal: This is feedback we are looking for. Stewart Bryant: Also impacts delay and jitter. Lou: OK to have meetings of authors. Suggest to publish times of meetings to make them open to the WG. Any decision taken by authors/subgroup is not final. Must be discussed with WG to ensure consensus, e.g., via list. When reading the document for the first time or just reviewing, look at whether the text is in scope or out of scope, e.g. control plane not in scope now. Don't lose good text, e.g., move such things into an appendix, but the core should focus on current scope of WG. 3) 10:05 45 Title: DetNet Data Plane Encapsulation -- Resolving open issues Presenter: Jouni Korhonen (remote)/Norm Finn Draft: https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-00 00:39:00 on the audio recording Lou: Means of implementing low loss could be implemented using other means than PREF, e.g. Network Coding. Such other methods are also in scope and may be considered in the future. Pascal Thubert: Network coding is in the architecture document, it can be defined at a later date. Slide 6: (Prologue to unified service layer solutions) Stewart B: Do we need to support others besides IPv6 and MPLS? IPv4? Customers need IPv4, we should support it. Jouni Korhonen: Interworking solution fine but defining IPv4 as a transport like IPv6 no. Lou: Do we view IPv4 as E2E DetNet service or 'just' another TSN service supported over DetNet? So far we've taken the latter position. But we can do something different. Stewart: Do use cases specify this? Lou: No, they are higher level. Jouni: Current solution has a separate implementation for IPv6 and MPLS, and going separate ways, but basic processing should be same. Lou: So the question (on the slide) is do we change directions back to provide a unified on-wire format? So far no objection to this. Anyone objections? (Questions #1) Norm Finn: Great to have both formats. There's also a legitimate question whether there needs to be separate drafts to both solutions. Lou: No objections to keeping current strategy? No objection in the room, need to take to list to confirm. - No objections in room. Greg Mirsky: Expect DetNet layer in one doc, then "detnet over different technologies" in separate docs. Segment routing done this way, IPv6 vs MPLS. Jouni: Question #3 to split documents between IPv6 and MPLS. Pat: I heard 3 documents suggested: overview doc and each encapsulation? Or just two drafts? We already have an architecture document as an overview. Jouni: Likes 2 docs. The PREF part that Norm is going to present later on may change the situation in the future i.e. that becoming a separate document. Loa Anderson: Maybe delay split until core issues are resolved. Lou: Authors discretion on when to split, should add a comment that the intent is to split the draft and start noting that split is coming, and which draft each part goes in. Pascal: Think about layering. There are aspects that won't fit into just 2 or three drafts. Jumping ahead what Norm and I am going to talk there are things that do not really fit into transport. Lou: we will still have multiple drafts that cover aspects e.g. layers Slides 9 and 10 Stewart: Do you need to put anything other than Ethernet over this service? Issue of skip 0 not catastrophic, just reduces range by 1. 4448 OK. In terms of using EVPN, there is no SPE. But SPE is the wrong concept, so perhaps add a new construct. Lou: Are you saying that PW constructs are not providing a lot of value and may be wrong in the DetNet context? Stewart: SPEs are wrong Lou: Which were the main motivation for using PWs Stewart: T-PEs may still be fine. Depends on types of traffic that will be covered. Jouni: 6658, any packet over PW. SPE question is our question #7. Norm will have to say when it comes to functions of SPE, replication and elimination. Issue of interworking with existing technologies. Seq # already in payload of other existing technology. Pat: If don't skip 0 can use same on as used in Layer 2. Norm: Skipping 0 can be an issue, if every 64K packets delivered twice, not terrible. But if drop one instead that would be bad. Reusing technology (and implementation) is way more useful than reusing existing specifications. Reusing gates is important, reusing documents is nice. Lou: Find right tech solution then back it up in our docs. Do the authors have a position on this question? Jouni: My opinion, it is okay to define something new, but better to reuse gates. Easier in the end to not skip 0. Norm: Possible rathole, many opinions. Should allow for 0, just another seq num. Pascal: Layer violation if lower layers put semantics on something defined in upper layers. Lou: if allow 0 might be able to send fewer bits on the wire. So it is an optimization. Andy Malis: As PALS co-chair - No reason why can't define new DetNet PW with whatever behavior is desired. Lou: Do we want to be constrained by existing PW definition that skip 0? Current feeling is should allow 0 as valid value? Any objections in the room? POLL: No objections Stewart: Just define a new PW and it will 'just work'. Lou: So the next question is do we care if we model this as PWs, EVPN, or something else? Stewart: PWs use 16-bit seq num. Maybe underlying techs use e.g. 32 bits? We can define whatever is needed. Jouni: Question #6: Jouni: points out that PW and EVPN on-wire encoding look the same from the pipeline point of view. Lou: A documentation question not a wire question. This is more of a documentation issue, since they will be different even if the on-wire looks the same. Norm: Prefers DetNet Wire and define what it is. Looking at what does TSN want from DetNet? Doesn't always want an Ethernet connection, we want a routed connection? Can't make a bridged network large enough. Don't want a PW that just extends Ethernet to expand volume of broadcast space. Should be defining what DetNet data plane is, not new PW. Lou: You want to focus on just what the definition of what a detnet data plane looks like -- Wouldn't call it a "wire", just a DetNet data plane. Stewart: Most important to design the right thing for the job. Maybe reuse OAM and other things. Lou: Using existing data plane, just about how we describe it. It sounds like the opinion voiced in the room is don't worry about being tied to existing constructs like PW or EVPN, and just focus on DteNet data plane and describe it in whatever way makes most sense for detnet. Any objections? POLL: No objections in the room. Document this in the notes as the decision. Jouni: Now he (Jouni) has clear guidance, good. PREF section presented by Norm: 01:41:00 on the audio recording, 1:15:30 on youtube. Layers of detnet via nested CWs. Enables multiple layers of PREF for e.g. aggregation. Loa: If break in small ring in upper right wouldn't traffic go the other way? Norm: DetNet doesn't respond to failure by creating new path. Not a ring that depends on direction. Lou: Lots of us are familiar with rings in usual. Really this is 1+1 end to end protection Kireeti Kompella: Replicated both up and down? Norm: Yes, get eliminated as they crisscross. Lou: So far talking about end to end protection? Why now rings Norman, Pascal: Ladder has been in arch since the beginning. This is what is in the drafts now, not something new. Currently have thing in center of box that sees duplicate and does forwarding. Kireeti: We should be describing what we want and if it's not implemented, than don't use that box Lou: We have been describing at the box level up until this point vs topologies/rings, we should focus on the function. Norm: Have been receiving comments related to how it's been described. Lou: Not describing internal behavior, could be implemented various ways. Stewart: Should separate Replicators and Eliminators. Replication is on Ingress function, elimination is on egress. Lou: I think we just made a decision to not describe internal behavior, but rather defined box level function. Norm: Easiest way to draw is associating with ingress/egress. Lou: Normative should be box level, associated description on internal behavior is informative. Norm: agree that we should require a specific implementation within a box Toerless Eckert: This is on the right track for doc, is it on track for implementation? Would be clearer if there were YANG models? There's prior knowledge that can be leveraged. Lou: Yes it would be great to get some YANG model proposals that leverage past experience. Toerless Eckert: is adding sequence numbers assumed? Lou: Yes, but can be layered. David Black: From requirements perspective: If replicate but fail to eliminate one, what happens? Lou: violates spec. David: [so must specify that] At egress, duplicates must not exist. 4) 10:50 15 Title: DetNet Flow Information Model Based on TSN Presenter: Balázs Varga Draft: https://tools.ietf.org/html/draft-farkas-detnet-flow-information-model-02 02:15:43 on the audio recording Lou: Should we adopt? Poll: How many have read document? Not great, but not bad How many think this document is a reasonable starting point? More Will take to list. 5) 11:05 15 Title: Transport Layer for Deterministic Networks Presenter: Pascal Thubert Draft: https://tools.ietf.org/html/draft-thubert-tsvwg-detnet-transport 02:23:15 on the audio recording Lou: Won't do Transport layer here, do in TSV WG. Google doing work on this. David Black: Clarification needed as to what is transport, i.e., belongs in the transport area? Link based flow control is something else. David: Link layer flow control should stay here. Lou: Chairs agree. Lou: Maybe PREF is confusing, David: Router should do this. Not a transport functions. Is a ring protection mechanism. Lou: But in Routing we call that transport. David: Terminology overload. Tease out what is used in IETF as Transport. Pat: PREF could be done at router or endpoint, but is at Layer 3 not 4. Toerless: flow control can be on transport tunnels as well Pascal: proposing minor changes to arch to enable (?) Lou: Out of time for this topic, please bring this to the list. Lou: Having an interim meeting on data plane has just been proposed privately, this topic could also be covered there. - but don't wait, please start discussion on list. 6 11:20 15 Title: DetNet Bounded Latency Presenter: Norm Finn Draft: https://tools.ietf.org/html/draft-finn-bounded-latency-00 02:41:08 on the audio recording Lou: Need from WG - proposed YANG model that specifies DetNet services in an abstract fashion. Then this draft would describe how to implement this. Balazs: There is version 00 for a YANG model (https://tools.ietf.org/html/draft-geng-detnet-conf-yang) Lou: Think about presenting this at next meeting. 7 11:35 25 Title: Information and data model considerations: Applicability of Network Calculus to DetNet Presenter: Jean-Yves Le Boudec Reference: 02:47:30 on the audio recording Mirsky: Look at work in SFC WG on alternate WG method and measuring nodal and sub-nodal residence time, contribute to jitter. There is an idea of how to do proactive resident time so can use this to characterize latency in real networks Norm: Characterization of Queuing methods are not characterized well in TSN in a usable form for DetNet, this will improve everything. JY: For DetNet, don't want to specify (characterize) a specific scheduler. ???: Do you have any hypothesis on the flow arrival process JY: No, in order to provide bounds can enforce arrival constraint Lou: Following on Norm's point, we do not look at specific queueing technologies. We do look at how to characterize nodal and service behaviors, so if can help develop abstract parameters, which can be passed around by control plane. If you want to submit some text we will find out which draft to put it in so you don't have burden of editing (XML). Norm: I'll be happy to help put together a draft Lou: (Closing meeting) We ran out of time to cover Pascal's comments on architecture, please work this among the authors Lou: Interest in Interim for Data Plane discussion? Remote, physical? (Some interest in both in room) (Someone offered to host (who?) Adjourn 12:00 100th IETF DetNet WG NOTE TAKERS: Ethan Grossman Pat Thaler Jouni Korhonen (post processing)