January 10, 2018 Interim on Detnet Data Plane > Webex: https://ietf.webex.com/ietf/j.php?MTID=ma8f5e752b3d072bbb2bcfa12ef65d4d5 > Recording: https://ietf.webex.com/ietf/ldr.php?RCID=e5116bc7db254c24a7bb3217bf202301 > Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2018-detnet-01 > DataTracker: https://datatracker.ietf.org/meeting/interim-2018-detnet-01/session/detnet > > The DetNet Data Plane document is published at: > https://tools.ietf.org/html/draft-ietf-detnet-dp-sol > > The meeting will work through open issues on the draft, starting with where we left off at IETF 100, see [1] and [2]. > [1] https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3-detnet-data-plane-encapsulation-resolving-open-issues/ > [2] https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3a-detnet-data-plane-encapsulation-resolving-open-issues-pref/ > > The agenda is: > > - Administrivia, welcoming new co-chair (Chairs, 5 minutes) > - Plan for addressing open issues on the draft, including future interims (Chairs, 5 minutes) Lou: Future meetings: physical vs virtual? Stewart: Role for both Loa: this time not good for many in Asia Janos: Perhaps tied to the IETF Stewart: need to take care to follow IETF rules, perhaps Saturday Lou: Other options include an extra session, or Friday afternoon Loa: should look at all options, like Friday afternoon Janos: should make a decision soon Pat: Perhaps start planning for one now to be held between IETF 101 and 102 Lou: Agreed. Focusing on IETF101, extra 2.5 hour slot or Friday afternoon (poll, via chat) - Generally both, or either. (some Sunday, a request for remote participation either way) Lou: do we need another virtual interim before IETF101 - generally: yes > - Review of IETF100 conclusions, and related planned document updates Stewart: Should Arch doc be the place for considerations about differences between encapsulations? Lou: We had decided to keep implementation out of Arch doc? Contents of Arch doc not open to debate now? Predates DP Soln doc, preparing to WGLC. Jouni: Still looking at packet contents. If need more, e.g. "glue" bet encapsulations. Lou: So keep one doc until need to split. Postpone decision until needed. Norm: Want to avoid duplication , but don't see that happening. Lou: OK to wait on split decision ? Stewart: Would get expertise sooner if split out MPLS / IPV6 earlier. Not being seen by the right people yet. Loa: Concern about keeping one doc for now. Would be two mixed together, better to separate earlier. Lou (as chair): We will do a split, need authors to tell us when to split. Can't split before authors are ready. Propose: Split as soon as authors are ready. Stewart: Ready to write MPLS text. Lou: There is MPLS text, add to that or write new draft? Stewart: Maybe new text. Jouni: One version to clean up current version, incorporate recent decisions. Then start new versions. Lou: When would that happen ? 3 months is too long. Lou: New version is 3-4 weeks, then confirm it is time to do a split Jouni: Need to have doc read in time for next interim. Stewart: Agree. Doc out before interim, then split out after that. Lou: Sounds good. Pat: Good idea. Jouni: Maybe need some discussions on mailing list to establish draft cleanup conclusions. Pascal: Sooner we do split, sooner can get MPLS vs IPv6 people involved. E.g. Pascal would do IP but not MPLS. Stewart: Exactly my point, agreed. Stewart: Does seq num space need to be part of arch invariant? Why 16-bit? Jouni: Some existing are hard coded with 16 bit? Jouni: Need to decide how much to maintain compatibility with existing: Norm: No fundamental arch reason to keep 16-bit. But have brownfield, need to interwork xlation w/ existing 16-bit. Have discussed in ieee, e.g. 5g in mind. No use case yet where need 64k packets buffered in network - at that point not "real time". If that use case arrives, then needs to support more than 16. Stewart: Could also be rogue packets that arrive in the window. e.g. fast reroute. Norm: What is really relevant to DetNet network. Can we constrain the problem space? Stewart: Wouldn't have fast reroute in DetNet plane but could be in platform that DetNet is running on. Norm: Can't solve all possible problems with packet sequencing. I am not. Lou: Agree w/ Norm - not part of Arch. Is this part of Soln space? Arch allows for any. Need to be specific about sol'n e.g. MPLS vs IP. Andy Malis: When we did PW control word data rates were lower so could use 16 bits. Is this enough to prevent wraparound? Maybe can virtualize? Norm: Something in MacSec - both sides know is big number, but only some bits carried in frame . Won't interop with brownfield 16 bits. Stewart: Need 16 bit legacy mode. Do we need to specify from control plane or data plane adifferent number. Norm: Do we need to spend time designing a larger space? Will a new space encourage adoption? Until we have a clear use case, propose we don't do that, it will push people away from implementing it. Jouni: 802.1CB HW rarely keeps all 16 bits of history anyway - uses sliding window. HW doesn' have enough buffer space. Stewart: Yet many counters will be 64 bit. Jouni: When doing PREF need to have history of seen packets, thousands. If have 32 or 64 interfaces, 64k packets each, that's a lot of memory. So use sliding window of seq num. Stewart: So only need history of one packet? Jouni: No that won't work for PREF. Norm: Don't want to xmit any packet twice. Norm: Packets are arriving on diff't paths at diff't rate. So if miss packet on fast path, sometime later on slow path, see a missed packet so must xmit it. Could be several of them. Must keep track of all packets in recent memory, each one so can pass on ones that are making up the holes in the sequence. Lots of memory. Stewart: In DP we don't normally do that. Norm: This is the only function we have for this sequence number. Jouni - there's already silicon forthis. Stewart: Varying views on whether to give preference to existing designs. Lou: so Stewart's question is: is 2^16 enough? Or is one last packet enough? Stewart: Rogue packets could be sent later due to being held due to perturbation. Assumed eliminating those packets. If trying to put what transport does in the middle of network. If so not sure which platforms could do this? Norm: Back to basic question of whether 16 bits is enough. Pat: Want to set up a network where packets are delivered in time. Not worrying about ancient packets. We gave them bandwidth, don't randomly reroute them if link goes down. Point is to deliver in bounded time. Stewart: If run over specific network, OK. But pictures show generalized network. Norm: Discussed in 802.1CB standard (which is complete). What about ancient packets or recovering from reset of xmitter. In CB so far, were not thinking of huge network where things could hang around longer than 16 bits. E.g. Internet. Stewart: Like 5g services. Norm: Shouldn't need more than 16 even there. Won't arrive at tech sol'n in this meeting. Jouni: Could put in control plane, length of seq num. Painful for HW impl. But if power of 2, maybe OK. Deserves some thinking. Stewart: Small window size, but maybe application specific. Agree need legacy mode. Need signalling sol'n between ends that agree on packet type or whatever. Jouni: Assume have variable length seq num. Agreed between peers on network endpoints. Lou: Agree, if done by SDN controller or whoever. Also security implications, e.g. rogue packets. Stewart - known ISIS attack of sending rogue packet with strange seq numbers. Jean-Yves: Is security aspect related to space of seq number? Lou: Require validating using hard authenticated Stewar: Not going to get existing systems to do good authentication. Could do in SW but bad for performance. Jouni: Many channels of e.g. MACSEC is expensive. Stewart: Needs to be affordable. Lou: Just need to make sure security draft covers this. #4 Jouni: Agreed that we don't require backwards compato for existing DPs. STewart: Some PW things to retain e.g. OAM system utilities. Norm: Sure. Jouni: Limit of how much new stuff, implementers get nervous. #5,6,7 Stewart: Replication easy, e.g. multicast, but elim difficult for some platforms. Jouni: Yes e.g. multi-die soln's hard to do elim. Jouni: Definition of PREF difficult but do-able. 802.1CB has sol'n for TSN so can even check pseudocode for example implementation. On-wire formats: Jouni: Assumed use Segment Routing (SR) for IPv6. Need discussion on this. Lou: Discussion in 6MAN about flow labels? Stewart: e.g. purpose of label. Does label sit behind CW or as extension. Jouni: Put flow ID into flow label. Pascal: Have rules about this in 6MAN. If label is set, shouldn't change it. but not secured so don't know if it ws changed. If OK to use random values, could do as in 6MAN. Jouni: If non-zero shouldn't change label. If Stewart: Are we doing just greenfield or adding better "on top of" brownfield? Lou: Both. Stewart: If new network, can define all. In old, have some new devices e.g. at edges, and live with properties in between. Jouni: So that is only as good as weak link - can't call that reliable. Norm: On flow ID, have a field, but maybe different opinions on meaning of that field. We think we can make it work for our purposes, but if others are expecting e.g. using it for entropy, need to design our spaces for that, someone has to work that out. Would rather use flow ID and define our use of it, rather than have it be narrow RFC owned property. If we can't define it, then Stewart: Many systems using it for ECMP. This will result in differnet path. Lou: Solution should be driven by what we are finding solution for. Sol'ns for both flow label and SR - not sure we want to exclude one or the other. Are we doing one or the other or both? Jouni: They don't do the same thing. Flow identification vs destination addr (?) Stewart: Flow label will choose next destination. If mulitple equal cost ways, then choose next hop based on multiple packet propertes, one of which may be flow label. Jouni: But doesn't require SR? Stewart: Look at source, dest, xport header ports, hash to pick one of n hops. ECMP dangerous for DetNet? Stewart: If on a specially designed network, can turn off ECMP. Lou: Charter says it is over a constrained environment, meaning we can make restriction distinctions vs general internet. But doesn't mean we can disallow any technology. Stewart: In 5G expecting to use this - need to consider implications of such restrictions. Lou: Looking at either SR or flow label, only. So that's some progress. Lou: At end of 90 minutes. Propose 2 hours earlier (i.e. 6am PST, 10PM China, i.e. 1400 GMT), would help those in Asia. Propose Jan 31, 3 weeks from today. Is this OK with authors? Loa: OK but has had issues in the past with late calls to China. Maybe provide options? Lou: Ask about 9 or 10 at night or 6 or 8 am. ??: Probably 10pm in China is OK, as proposed above. Andy Malis: Daylight savings will help. Adjourned. > (TBD) > Reference: https://datatracker.ietf.org/doc/minutes-100-detnet/ > - Open issues discussion (Lead TBD) Virtual Blue Sheet: Lou Berger Balázs Varga Jean-Yves Le Boudec János Farkas Pat Thaler Andy Malis Stewart Bryant Pascal Thubert Loa Andersson Norman Finn Jouni Korhonen Ethan Grossman Yuji Tochio Damien Saucez Stephen Bush