Please add your name to the Virtual Blue sheet: Pat Thaler Lou Berger János Farkas Pascal Thubert Balazs Varga Stewart Bryant Ethan Grossman Loa Andersson Jouni Korhonen Andy Malis Dan Romascanu Toerless Eckert Vishnu N Ethan Grossman Bob Noseworthy Carsten Bormann Jeff Tantsura Recording: https://ietf.webex.com/ietf/ldr.php?RCID=e7277d9a7f34a607ec74693fb8ab021f > Agenda for DetNet Virtual Interim Meeting January 31, 2018 > > Session Information: > > Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2018-detnet-02 > Meeting Materials: https://datatracker.ietf.org/meeting/interim-2018-detnet-02/session/detnet > Webex: https://ietf.webex.com/ietf/j.php?MTID=m1fa30c1b4f7ba72a66fc177633cb9a04a > > The meeting will be held January 31 at 1400GMT. The meeting is > scheduled for 90 minutes and additional 30 minutes of extra > discussion time if needed. > > The agenda is: > - Administrativa (chairs) > - Draft update - covering deltas and open issues (authors) > see https://tools.ietf.org/html/draft-ietf-detnet-dp-sol > https://github.com/jounikor/draft-dt-detnet-dp-sol Slides: https://datatracker.ietf.org/doc/slides-interim-2018-detnet-02-sessa-data-plane-progress/ Lou: WRT need to ensure we stay in scope of charter, i.e., reusing existing formats Toreless: what happens if there is no solution, e.g., for IPv6 Lou: if the WG belives a new solution is needed, need to engage with the AD Stewart: Should we consider l2tpv3 Jouni: Did consider it but no-one willing to contribute. Lou: L2TPv3 This is a layer 2 sol'n, we already have a layer 2 sol'n. Toreless: is use of MPLS for TSN interconnect an official position Lou: This is where WG disucssion had led, but is not an official postion MPLS is a tunneled sol'n, IP is the DetNet routed solution. IP can operate over TSN and MPLS tunnels too. Lou: (as chair) Re #7 box level vs internal level: IETF doesn't typically describe interal implementation. So, agree internal is informative only. But if too much discussion on informative/implementation issues then should stay away from discussion. Stewart: No hidden text that would prevent distributed solution. Toreless: should be focusing on external interfaces, e.g. as described by YANG Jouni: want to esnure required behavior/text doesn't preclude known implementation approaches Stewart: Single chip soln degenerate case of bladed sol'n. So if describe bladed sol'n then from that could optimize into e.g. single chip. But need to beware statements that might Stewart: Prefer conceptual model that informs as to why things are done how they are. Stewart: Example of assumption that a node would do both rep and elim - but a node may just do one or the other. Don't want to take away flexibility, might want to deploy in new ways. Lou: Stay away from internal behavior. Stewart: But some implementations are easier on one implementation vs the other, and thus assumptions can creep in if you don't state the assumptions. Lou: Need to find right level of description. In bounds is on wire behavior. Out bounds is specific implementation. Some tension here and judgment to be made. Lou: Anyone opposed to consensus position on item #7. Stewart: Yes, should describe elim as a separate function from replication. Two separate things. Proposed corrected text is "Describe R & E function at box level". Andy: Agree with Stewart, two separate functrions. One can be implemented w/o the other in any given implementation. If always write "PREF" then people will assume they are joined at the hip. Lou: Agree this is decision of this discussion to keep R & E separately. Toreless: What if implementation text is contributed Lou: If WG accepts it, it can be included. Loa: Agrees with Stewart and Andy on current (R & E separate) phrasing. Andy: Re sec 9.1.1 in current text: Label ass't and distrib: Not supposed to talk about control plane yet. But because will be PW based, how will labels be assigned and distributed. Will this section stay in this doc? Ultimately need to decide how labels are distributed, e.g. by central controller. Lou: To summarize: This topic should be updated to say is out of scope for this document. Andy: Label distribution should be out of scope of this document. But to implement something that will actually work, need to supply this information. Lou: Once we have proposals and interest in the WG, we can discuss charter for control plane in WG and with AD/IESG. Lou: What is plan for topics from sec 7? How to distribute accross MPLS and IP sections. Jouni: Some will fall naturally into separate sections, e.g. class of service, bidirectional traffic fits under MPLS but not necc under IPv6. But may end up copy/paste w/ minor changes. May need separate doc for this in one place, not sure yet. Lou: Should not forget about this as part of doc split strategy. Might end up with a lot of duplicative text. Jouni: E.g. explicit routes will be different for diff't encapsulations. Jouni: Flow labels (as used for flow ID) have been wild west, but OK to rely on flow label since within controlled domain. But need OK from WG on this. Jouni: IPv6 disallows use of Dest addr in flow ID, i.e. intermediate routers can't peek at that. (?) but current text proposes use of Dest addr field (?) Stewart: Need more engagement with 6MAN in these discussions. HW restrictions around seg routing in IPv6 since headers are huge. Heard some high end implementatios that would find it hard to put more than 2 SR headers in a packet. Consequences of SR-type approach for v6. Depend more on loose source routing than might expect. Stewart: How to determine sequence of which option comes in which order? Many devils in details. Jouni: What is ID option you are referring to here? Stewart: Where does Seq num go? Jouni: Where is says to put it in RFC... Stewart: That is way back in the stack? Jouni: Can avoid SR and still do explicit routes - need to have more discusssion on this. Stewart: There are things we can do to address this in control plane but is out of scope. Lou: Process to response to Stewart: re things we can do in control plane. We do need to describe our assumptions about what will be done at control plane, but saying that it will be handled at control plane is in scope, e.g. "will be handled by YANG model". Lou: Re flow ID: assuming SR, there is a header tag, could use instead of flow label. Jouni: Don't want to rely on SR (?) Jouni: Reason we put this in was because if want intermediate node to do operations on it based on how it is done in IPv6 layer, e.g. want node to check options etc, use hop-by-hop option, or destination option. Otherwise doing things to packet that are outside of IPv6. That's why mention of Dest addr. Toerless: Can we at least write down why existing choices are bad, to justify taking new step. Then can decide if live with bad sol'n vs building something new. Stewart: There is a flow field every router touches: Combination of SADA pair plus trans (?) port. Can do with classic stuff. E.g. payload via UDP, so could use UDP port for flow ID. Lou: That was IPv4 proposal. Maybe also use for IPv6? Jouni: In practice will be RTP, have everything you need. Seq num, timestamps, SSRID (?), identifies flow. Toerless: Yes but existing 5-tuple doesn't do [what we need?] Lou: RSVP does 5-tuple Lou: Security issues with this? RTP vs 5 tuple? Jouni: Payload not encrypted above UDP Lou: There is a stated direction of IETF. Have to keep in mind for any sol'n we propose to IESG. Jouni: Any good ideas welcome on this. But need to have explicit routes encoded into packets. Toerless: Ripple headers are slow like IPv6 stuff, so maybe not suitable for high performance, but may be able to solve problem. Jouni: Current draft says edge node will add source routing Toerless: A lot of overhead for this. Stewart: IPv6 alternative called USR Jouni: Aware of this. But please give us this reference: Stewart: draft-bryant-mpls-unified-ip-sr-00 also competing draft should look at: draft-xu-mpls-unified-source-routing-instruction-00 Lou: Assume we'd go to 6MAN once we have a sol'n. Maybe better to go earlier and ask for help with a sol'n? Jouni: Would that be like saying "we give up"? If we go there to steer meaningful discussion, they would need to understand the whole concept. Jouni: But at the end we need their blessing. Stewart: Some aspects better suited to pushing to control plane even in IP. Lou: Don't have consenus that we're doing IPv6 over SR. Jouni: But current text Stewart: Moving to control plane is more implementation friendly. Jouni: But need to do stuff at IP layer. Lou: Q'ing or PREF? Jouni: As long as have flow ID part, Toerless: But doesn't provide IntServ Lou: Sumarizing: Can use control plan plus existing headers to do --- Lou: How to make sure we are documenting things beyond PREF? I.e. without having to agree on PREF issues? These other things affect all flows and are necessary - maybe not the hardest parts or most interesting, but we need to get there. Jouni: Contribution driven process. Would love it if someone would propose text for these things. Current draft has longlist of authors, please step up. Lou: Anyone interested in contributing here for MPLS or IP? Stewart: MPLS, yes. Balazs: Also some text from Norm Lou: Can you pull this into base document? Balazs: Will discuss. Lou: Need to document strategy for IPv4, even if just 5-tuple mapped to STewart: If need to do in v6, must also have to do in v4. Lou: Do you propose a separate v4 doc, or integrate into v6 draft? Stewart: Want to write a single clean doc, but should do it best way for each indiidually, not compromise one or the other. E.g. would 5-tuple be good enough for v6, if not then probably need separate draft. Lou: Need contribution for this. Affecrts timing of split. Is someone willing to put together IPv4 test. Stewart: Interested but needs time sanction to do it. Stewart: Much better to have a unified IPv4 and IPv6 sol'n, i.e. a single draft that is neutral on how it solves the problem. Jouni: Good point. Prob with IP is have been narrow focused on carrying DetNet info. But if can assume that in a DetNet domain for routed traffic, transport below is TSN or equivalent, e.g. MPLS, then what we do at IP layer is just routing or mapping flows into MPLS tunnels. An underlay and then just do routing. Lou: Is that assuming that PREF always done by e.g. TSN layer? Jouni: Yes. Jouni: Then starts looking like over PWs as we discussed earlier. Lou: Others find this approach acceptable? This proposal fits within our charter and process, and is more like what some hoped to see from our process. Do we, the people building the solution, like this approach or find it objectionable? Jouni: Starting to like this idea. Lou: So next rev of draft will propose largely common approach on v4 and v6, i.e. 5-tuple, depends on TSN and MPLS to provide transport and PREF functions? Jouni: Just do a lookup and find correct tunnel for it and off it goes. Allow re-ordering and everything to be done by transport. Stewart: Maybe USR would map nicely for this? Would allow explicit functions at each hop. Jouni: Have TSN islands and DetNet islands. Toerless: What about islands that use IPv6? Stewart: Use SR instead of normal MPLS. Need to put it on paper and see if it stands up. Lou: This sounds like a more attainable result. Stewart: If did this right, would need no standards interventions. DetNet flows over USR, over TSN, over . Would be separate subnets Lou: Great to document before IETF 101, and see how group reacts. Lou: Do we want another WG meeting to discuss that topic, or another topic? Stewart: We make more progress with these meetings. Lou: Agenda for next meeting in 2-4 weeks? Jouni: Have stable ground on MPLS side, but the IP side needs more time on it. Lou: Topics: 1) Lou: Propose Feb 14, at China friendly time. Pat: 10pm Pacific is 1am Eastern, 6am UK Lou: Proposal 6am GMT on Wed 14Feb18 > - Open issues not addressed in draft (authors) > - Plan for addressing open issues on the draft, including future meetings > - Open Discussion