Skip to main content

(Untitled)
agenda-interim-2018-detnet-03-detnet-01-02

The information below is for an old version of the document.
Meeting Agenda Deterministic Networking (detnet) WG Snapshot
Date and time 2018-02-14 15:00
Title (None)
State Active
Other versions plain text
Last updated 2018-03-08

agenda-interim-2018-detnet-03-detnet-01-02
Please add your name to the Virtual Blue sheet:
    Lou Berger
    Stewart Bryant
    Balazs Varga
    Jouni Korhonen
    Loa Andersson
    Toerless Eckert
    Jean-Yves Le Boudec
    Hao Wang
    Pascal Thubert
    Dan Romascanu
    Ethan Grossman
    Norman Finn
    János Farkas
    Damien Saucez
Vishnu.N

<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=e5116bc7db254c24a7bb3217bf202301

> Agenda for DetNet Virtual Interim Meeting February 14, 2018
>
> Session Information:
>
> Webex:
>    https://ietf.webex.com/ietf/j.php?MTID=mca0b929db5297a5867bc7585429ad35b
> Etherpad:
>    http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2018-detnet-03
> Online Agenda and Slides at:
>    https://datatracker.ietf.org/meeting/interim-2018-detnet-03/session/detnet
>
> Duration: 90 min with 30 minute extra discussion time if needed
>
> The agenda is:
> - Administrativa (chairs)
> - Draft status update (authors)
>    see https://tools.ietf.org/html/draft-ietf-detnet-dp-sol
>        https://github.com/jounikor/draft-dt-detnet-dp-sol
Agenda Bash

Balasz contrib is about MPLS over IP which doesn't address point to point which
is the main agenda this session so he will present second. Norm would like to
talk Architetcure

> - Contributions to address open issues (contributors)
<chair slides>
Lou: How to do end to end. CW as way to support PRE.F.
Lou: 3 services all part of DetNet. Simplification to support IPv4
Norm: Transit node is PREF unaware
Pascal :Transit node doing transport, relay node doing service
Norm: PREF aware != DetNet aware - use phrase carefully
Stewart: BW, Latency, just need alternate path (i.e. not necc PREF?)
Pascal: Could provide transport services at higher layer but outside DetNet
scope Loa: Should be "transport network" - to revisit in arch doc Lou:
Expecting to be just presenting existing arch. TSN over DetNet slide: Lou: TSN
over DetNet CW work not done yet. Norm: Do these cases cover subnet on each
end, but detnet does not provide L2 connectivity - network too big to be
bridged, want routed. Lou: That is IPvX end to end slide case. A DetNet relay
node is always a router. Norm: No interworking? Lou: Don't need for DP-SOL.
Currently focusing on how to do IP end to end. Stewart: Why interworking not
just working? Lou: topic for later discusssion Toerless: Complexity is that IP
can't use CW, only MPLS can, so always have to deal with two systems Lou: Proxy
maps TSN CW into DetNet CW. Don't have spec for that proxy yet. Norm: OK to put
that off for now. Lou: Good topic for future discussion once we have basics
defined. Janos: Support Lou on doing basics first. Lou: Have DetNet CW and MPLS
so can be used in both pictures. But as long as service is provided, don't
absolutely have to use CW, e.g. router with dedicated service. Balazs:
    Lou: Not req'd to have MPLS. In IP wouldn't have PREF but could be provided
    at higher layer.
(Focus Today's Discussion slide)

Jouni slides:
    https://datatracker.ietf.org/doc/slides-interim-2018-detnet-03-sessa-ip-based-e2e-detnet-ts-flow-over-detnet-subnets/
Norm: If separate flows arrive separately do they have to have same seq num?
Jouni: Somehow have to understand they are the same flow so would use TSN
methods e.g. PREF Norm: Just making sure seq numbering is done before
replication. Agree? Jouni: Yes. Stewart: Why interworking not just tunneling
over MPLS? Norm: Not interworking. Jouni: At some point, we need to address how
to handle two routers interconnecting IP subnets when replicated packets arrive
at different routers Ethan: I though your were saying on a singl router could
interconnect the routed subnets Stewart: Could bring multiple flows through
domains? Isn't seq num put in by source? Lou: Agreed to table complex
discussion of IP based PREF to the future. Do we need IP PREF to start? Can we
go forward w/o IP PREF? Toerless: How would an IP application do PREF? Lou:
Only within blue clouds, each may have its own PREF mechanism, independent of
each other. Norm: Dual-homed host could generate two flows but would need seq
numbering Stewart: Why do we need PREF in MPLS but not needed in IP? Lou: Issue
is complexity of PREF over IP - just trying to simplify for now to go forward.
Pascal - Could do at Layer 4 Jouni: Assuming DetNet aware endstation vs TSN
aware endstation? At edge of domain, have weakness since not overall end to end
reliability, but within domain can be made reliable. With this simplification
is easier to make it work. Toerless: W/o sender providing control word how can
it send redundant streams? Lou: Two separate flows, done at transport.
Toerless: How is that then part of DetNet service? Pascal: Part of service at
layer 3, part at layer 4 Lou: Simplified version that works with IPv4/6
Toerless: Not worth discussing if orthogonal to DetNet. Get redundant
transmission over diff't path - this could be done w/o control word. Only
end-to-end service is Norm: Can do that now Toerless: Current in-scope solution
- can't claim end to end sol'n w/o seq num Lou: Can provide rest of DetNet,
just not guarantee end to end. Toerless: If can check timestamps can check if
packets delivered on time. Else not. Lou: Congestion protection and explicit
routes - our claim is that in this version we could do these two out of three.
Toerless: If had timestamp like RTP could verify, not currently possible over
MPLS. Want to make clear which services can be provided and which not Balazs:
In figure, 3 domains. If each domain has its own seq num, can't PREF accorss
domains. IF do have have seq num then can go across domains. Would prefer
global option to place R&E anywhere - ultimate goal. Could have independent
paths, only endpoints couild do elimination. If can correlate seq nums between
domains then could coordinate. Norm: Agree with Balazs, this is interworking.
End station in TSN station is doing IP, may or may not know if local cloud is
bridged or routed - just puts packets onto ethernet. End station could put seq
num into IP encap, 802.1CB fine with that. Could enable CB to . If not talking
about seq num just have to recognize the flow. Lou: Fundamental question for
group: Do we focus on delivering 2 of 3 services (congestion protection,
latency control, explicit routes)(no pref, no in order delivery). Advantage we
don't have to modify IP. Do we want to do that? Norm: DetNet doesn't have to do
explicit routes, lots of that out there. Regarding latency bounds, done by
IntServ long time ago. Balazs: If pushing Stewart: Concerned about too much
complexity, should be doing layered sol'n. Independent of other layers. Agree
already some already widely deployed, and issues in routing layer to make them
usable and manageable. Norm: Do we need to do that? Stewart: Someone in IETF,
maybe not us. Jouni: At left (in IPvx e-e service slide) . Is DetNet End 
system at left TSN aware? Lou: If want end to end guarantee then I Balazs:
Layer 4 is only end to end systems Jouni: In this picture only have IP addr
that system knows how to map to transport. End system is TSN aware. Assume for
now transports are TSN aware. So packet goes out with duplicate streams. Hit
first router, talks TSN to left, MPLS to right. Is that MPLS DetNet aware? Lou:
Understands how to do congestion protection ,but doesn't know CW Jouni: So each
domain would have own seq number? Norm: Duplicating at TSN layer at source,
elim at end station? Jouni: Not neccessarily - would have to happen before exit
domain. Norm: Guy who does elim has to be peer of who does sequencing. Either
same encapsulation or interworking Stewart: Or proxy that helps. Norm: Can't
replicate before adding seq num. Jouni: Restriction is have to terminate at
single point before exit domain.
 Lou: Dotted lines are PREF domains. Dupl at ingress, elim at egress. That is
 the point of this picture (ipvx e-e service slide) Stewart: Need to call out
 layers individually, getting too munged together in these diagrams. Lou:
 Marked L4 transport to make it clearer. Pascal: in this topology ingress and
 egress routers are single point of failure. Jouni: Yes, but that gets hard to
 fix, and doesn't require header additions. Lou: So is this limitation
 acceptable for initial DetNet sol'n? Stewart: Exact proposal is? Lou: Jounis
 from last session. Service protection only provided within subnet. Stewart:
 Could have e-e PREF, everything, going through relay nodes. Lou: Could do that
 in follow-on. Stewart: Can do PREF etc within domains.
Pat: Question being asked is can we get by without an end to end solution for
service protection. Stewart: Could do at layer 4. Lou: yes, thus not part of
DetNet. Just because doing it at layer 4 doesn't mean we don't do it in DetNet
Jouni: For IPv6 have extensions that are handled at L4. That started to look
ugly particularly with IPv4, that's why we came here. Stewart: IP extension
headers are layer 3. Jouni: Trying to cover IPv4 thus had to drop use of
extension headers. Pascal: DetNet incapsulating one flow inside another. IP
matches transport services. If L4 provides service layer, then if tunnel that
through MPLS which is DetNet aware and provides service, then fits nicely.
Norm: Agree, saying that for IP only not doing PREF, seq numbers.  OK with
that. No conflict with L4 xport, people can use dual paths at L4, we are not
making that illegal, but not part of DetNet. OK with our DP sol'n not including
PREF and seq num aspects of DetNet. Pascal: Yes, agree.

(Balazs slides)
https://datatracker.ietf.org/doc/slides-interim-2018-detnet-03-sessa-ip-psns/
Balazs: (slide 3) RFC3985
Stewart : How to carry IP over MPLS?
Balazs: Have encapsulation w/ magic enet addrs + CW.
Stewart: Encapsulate IP over Ethernet, then Ethernet over MPLS. Is that the
best thing? Assume OK for now. Lou: Think there is a defintion of IP w/ control
word but no Ethernet Stewart: Not sure but could create it. That RFC was done
to solve a different problem. Balazs: Do we need different DN PW format for IP
and MPLS? Why? Balazs: Industrial example: Don't already have MPLS. Would like
to put PREF points anywhere. Don't need interworking at border of domains.
Stewart: With PW, a connection accross MPLS domain, know context of Seq Num. Do
we know this in IP PSN example? Balazs: Edge node will create CW and seq num.
Stewart: Creating a point to point tunnel so have all context Balazs: Yes
Stewart: Stitch tunnels across domains. Lou: Don't care how tunnel across
networks? Could aggregate or have flow per tunnel. Janos: As Lou explains, has
boundaries at edge of domains. Pascal: Packet source/dest IP from source
    Balazs: In
    Lou: green triangle is not edge node - is PE. So how to get e-e DetNet
    service? Balazs: If in single box then get this service. Lou: If have a LAN
    with DetNet aware hosts, single IP subnet - do we get e-e service, one hop?
    Balazs: Yes, using PW and CW Lou: Where is PW CW get inserted? B: Between
    application and IP L: So socket would have param to specify this? Norm:
    Wherever you do sequencing has to either have encapsulation or
    interworking. Can have either peers or interworking. Multiple layers
    involved in sequencing and elim. Janos: Agree Norm: Likes IP over CW Lou:
    We are doing DetNet CW so just context and CW. Moved away from this kind of
    complexity on host. Norm: If want end station must do seq num before
    replicate. I.e. has to do encaps. Stewart: Agree. Lou: Existing encaps
    include CW, label, always uses UDP? Stewart: If doing at PW layer need
    label. Lou: 64-bit wide field. Stewart: yes. Prob with upper (IP PSN)
    example: Firewall and NAT won't like it. Balazs: with firewall second
    example is better. But might be OK to assume no firewall given engineered
    network. Norm: App PDU contains IP header? Lou: Not if comes from "green
    triangle"
   Stewart: IP pushed to socket layer
   Norm: IP next fields says MPLS, IANA code point.
Lou: IP dest addrs is green triangle
Norm: what is label sequence:
. . . (?)
 Lou: Host stack harder to implement than router stack,
Norm: 802 has notion of encap shim - can tell host what encaps know how to
handle. Host will then use one of them. Taken care of stripping out before
hitting IP layer, e.g. seq num. Jouni: Balazs said appl PDU also contains IP
header? Balazs: Only true if ... Jouni: What happens if end system talks app
PDU over IP? LOU: Case where CW is stripped: PE reaches into packet? Why not
layer that? Please repeat:
    Balazs: PW and an MPLS label (3x32-bit?)
    Lou: Next protocol is MPLS?
      Stewart: Why not re-encapsulate? Would simplify?
      Jouni: Multiple flows into MPLS domain via diff't PEs, want to do PREF
      inside domain. Stewart: Would have to reach in to get CW? Janos: If appl
      puts seq num, then requires Stewart: Dangerous, better to do in separate
      layers Jouni: Then we're back to same proposal before this preso. Balazs:
      Same domain, then can do seq numbering. Norm: Yes, main reason to do
      this. But if doing e-e with source doing repl and end stn doing elim,
      don't need detnet, since other systems do this. Lou: Let's try to recap,
      get impressions of group

      Stewart: Only have 20 bits of PW, so need context as identifier
      Balazs: yes.
Lou:
    Unified ipvx e-e service slide.
    PREF domain end to end, multiple routers. Requires seq num
    Other sol'n means lose PREF but no change required to host in terms of data
    plane.  Would need control plane changes. Layer 4 not the domain of DetNet.
    Could be used but we don't specify here, now. Opinions from the group:
        Options: Which to focus on? Put response in chat: Focus on end systems.
            unified (8 for slide 8)  (modified host, CW + PW, but get e-e and
            nested, laddered service protection). simplified (7 slide 7) can do
            7 now 8 later (no mods to host DP, no e-e service protection, only
            sausage approach)
Norm: If doing 7, do we need to specify anything at all?
Lou: Service params to be specified on host, maybe mapping to TSN
Pascal: D-CW is
Jouni: Sol'n 8 is original proposal.
Janos: Yes. As proposed by design team.
Stewart: Does 8 require interaraction between domains? So vote for 8 doesn't
commit to poking around in packet to make it work? Lou: correct, just more
discussion. (some votes not cast yet, meeting time is over). Jouni: For HW
based stack is harder. (NIC w/ HW offload) Stewart: Suspect will have to do 7
then do 8 as perf agreement. 8 is complex, should push this out. Norm: Would
not do 8 w/o 7. Lou: Can we live with "only" 7? If only had one, could you live
with it? Norm: Doesn't make sense - are we saying end station can't provide a
seq num? Lou: Agree, that was a failed idea. Add new option: 7 now 8 later.
Stewart. If do 7 only, then any end station can do what they want at appl layer
e.g. PREF. Norm: But can't do e.g. Ladder. Pascal: But is much nicer if network
can provide e-e service. Stewart: Only peek as far as the ports. So go deeper
than just 5 tuple Norm: Must do 7 no matter what. Do we do 8 now or later?
Stewart: If 8 done at L4, we're done Norm: Don't need to define that in DetNet,
various ways to do it. Norm: Do we do 8 now or later? Lou: Have not made enough
progress in our drafts, would prefer to complete 7 before doing 8. Norm: Agree.
Stewart: Why can't we leave service protection to L4? Norm: I'll explain it to
you later. Stewart: If we do 7 w/o accounting for 8 in advance will we risk
boxing ourselves into a corner? Norm: No, 8 is already in arch. Lou: Do authors
feel they have enough bandwidth to document 7? What text do you need? Lou: No
response from authors. do you want anything from anyone on the call to document
7? Jouni: Send me anything you have. Lou: Can we come back in 2 weeks and have
a proposal for 7? Jouni: Unlikely for Jouni to do alone, travelling one week.
Lou: Designate someone to take lead on 7? Balazs: Will take lead on 8 Lou:
Cutoff date for drafts is in 4 weeks. Can't hae another interim.  March 5
cutoff, during 802 meeting so no 802 people likely to work on it. Jouni to take
lead on 7 Jouni: OK. Lou: could do separate subsections for now, split doc
later. Norm: Anything to be done to Arch other than make sure network coding
back in, and separate PR and EF. Rename transport, need better term. Pascal:
Flow inside another flow - maybe could desrcribe that more? Norm: Mention that
must aggregate to scale Pascal: Jouni's doc adds more? Lou: Propose on list
Pascal: Already did? Norm: Don't want to add new concepts to Arch. Put
suggestions on list. Pascal: Endorsing what is in data plane draft. Norm: Is
this the last interim? Lou: Correct, no time according to IETF process. Lou: In
London, only on Friday, same day as regular session. Stewart: Clashes on time?
Lou: Told no clashes on what they requested. Norm: 802 Interim in Pittsburgh,
could join? Talk to Glenn Parsons to arrange? Pat: Would have to pay IEEE fee
for whole week, might be able to work out.   5 day meeting using all days.
Would have to be before or after. Just useful for co-location. Pat: Maybe
nearby hub city, e.g. Wash DC Janos: Could host in Budapest To be discussed
offline.

> - Next steps, including future meetings
>
> [1] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01
>
> [2] IETF 100 open issues:
>
https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3-detnet-data-plane-encapsulation-resolving-open-issues/
> > [3] IETF 100 open issues - PREF: >
https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3a-detnet-data-plane-encapsulation-resolving-open-issues-pref/
> > [4] 1st DetNet Interim: >
https://datatracker.ietf.org/meeting/interim-2018-detnet-01/session/detnet > >
[5] 2nd DetNet Interim: >
https://datatracker.ietf.org/meeting/interim-2018-detnet-02/session/detnet > > >