Minutes interim-2018-detnet-02: Wed 14:00
minutes-interim-2018-detnet-02-201801311400-00

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

<rough notes taken in etherpad during the session, please see recording for
full/more accurate version> 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