Minutes interim-2018-detnet-01: Wed 16:00
minutes-interim-2018-detnet-01-201801101600-00

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)