Re: [Detnet] New Version Notification for draft-pthubert-detnet-ipv6-hbh-01.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello again Bala'zs

As promised, I published an 04 to cover your comments. You'll find a section on applicability where the needs and reasons to encapsulate are discussed further.

URL:            https://www.ietf.org/archive/id/draft-pthubert-detnet-ipv6-hbh-04.txt
Status:         https://datatracker.ietf.org/doc/draft-pthubert-detnet-ipv6-hbh/
Html:           https://www.ietf.org/archive/id/draft-pthubert-detnet-ipv6-hbh-04.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh
Diff:           https://www.ietf.org/rfcdiff?url2=draft-pthubert-detnet-ipv6-hbh-04

Many thanks again!

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: vendredi 18 juin 2021 13:37
> To: Balázs Varga A <balazs.a.varga=[e-mail]>; Pascal
> Thubert (pthubert) <pthubert=[e-mail]>; DetNet WG
> <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: RE: New Version Notification for draft-pthubert-detnet-ipv6-hbh-
> 01.txt
> 
> Hello Bala'zs
> 
> Many thanks for pointing out what might be unclear to the reader!
> 
> I'll update the draft to clarify the points you made there. I'm still
> answering inline to share with all what the intent is, and get feedback.
> 
> 
> > In general:
> > 1, Do You propose to use IPv6/UDP tunneling between DetNet relay nodes?
> > "... the DetNet information ... and can be added by a service instance
> > as part of the
> > >>> encapsulation by the Ingress of the DetNet path <<<."
> 
> The draft proposes a pure L3/RFC8200 DetNet/IPv6 signaling, using an IPv6
> EH. This is my reading of the intention of RFC 8200, as served by SRv6 or
> RPL today. To your question, and per RFC 8200:
> 
> - if the DetNet end points are the flow endpoints there is no
> encapsulation, and the HbH is placed by the flow source
> - else, if the DetNet path endpoints are routers they'll need to
> encapsulate
> 
> This makes DetNet fully inline with the IPv6 architecture and open to the
> progress / extensions done elsewhere for IPv6. E.g., if the DetNet path
> leverages SRv6 for some reason - there are plausible ones in RAW -, the
> SRH will also inserted at the ingress and readily accessible without DPI
> next to the HbH EH.
> 
> Note also that the sequence is determined by the DetNet ingress point for
> the path independent of the flows that are carried within the path. The
> drafts adds the important distinction of path and flows, which was missing
> from the earlier dataplane document but present in the 6TiSCH and RAW
> architectures (https://www.rfc-editor.org/rfc/rfc9030.html#name-on-tracks,
> https://www.ietf.org/archive/id/draft-pthubert-raw-architecture-
> 07.html#name-wireless-tracks), and can be signaled by RPL
> (https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-
> projection#section-9).
> 
> This distinction will make our OAM work easier, allowing non-IPPM OAM to
> traverse the same path as the flow(s) with the same treatment.
> 
> 
> > 2, Are the proposed options encoded in the tunnel IPv6 header?
> > " It can then be accessed by the intermediate DetNet routers
> > >>> without <<< the need of a deep packet inspection (e.g., >>> beyond
> > >>> UDP
> > <<<)."
> 
> Yes, the packet has src/dst the detnet endpoints and the HbH is found
> after the outer IPv6 header.
> See RFC8200 and https://www.rfc-editor.org/rfc/rfc9008.html#name-storing-
> mode for how that 's done in gory details.when the HbH being used is the
> RPL one. The draft extends the existing model to paths that would not be
> signaled using the RPL RPI (which signals a topology) but also using
> different path IDs.
> 
> 
> >
> > 3, All that DetNet functions need are FlowId and Sequence information.
> > Could You please clarify the role of the path option for DetNet
> functions?
> > Or path option is used by RAW (and not DetNet) specific functions?
> >
> 
> The "path" is a wrapper for one or more flows (signaled by 5/6 tuple) and
> OAM packets to incur the same forwarding treatment. It is a Track in the
> 6TiSCH/RAW/ROLL terminology. Apparently DetNet favors the term path; the
> intention in the other groups was to avoid the serial (A->B->C->D)
> assumption that comes with legacy formulations of a path.
> 
> Using a path matches the original intention in the DetNet architecture was
> that a "flow" was a abstract group of packets that must incur the same
> treatment.
> 
> DetNet IP Dataplane decided to signal a flow with the 5-6 tuple, which
> IMHO caused issues such as same treatment for multiple flows and including
> OAM, different transport and address families. With eth IP DP you have to
> wrap them all in a L4 wrapper like UDP, which defeats the purpose of
> operating at the network layer.
> 
> The draft restores the original abstract grouping signaled by a pure L3
> information and avoids reliance on the transport information. It also
> avoids the lookup of the transport header that can be deep in the packet
> and may cause issues when the hardware cannot parse deep enough down the
> IPv6 header chain.
> 
> > In particular:
> > 4, If a tunnel is used, why not to encode the information in
> > Destination Options header?
> 
> Because it is used by all hops to locate the forwarding information
> associated to the path.
> That's what HbH EH is about.
> 
> 
> > Sequence information is not used by DetNet Transit nodes.
> 
> RFC 8200 allows intermediate routers to ignore the HbH options they do not
> understand. That's encoded in the option type.
> 
> > " In that context, it makes sense to consider >>> Hop-by-Hop Options
> > <<< to transport the information that is relevant to DetNet."
> >
> > 5, Why are new sequence counter formats needed?
> > " ... and it is possible that the value 0 is reserved when wrapping,
> > to the option offers both possibilities, wrapping to either 0 or to 1."
> 
> There are some sequence counters that behave like that. This enables to
> embed them directly.
> 
> 
> > 6, Could You please clarify why time stamp is needed? For which DetNet
> > function?
> > " This specification also allows to use a time stamp for the packet
> > redundancy information, ..."
> 
> Timestamping is an alternate sequencing technique, that avoids maintaining
> per-path state at the path ingress. Which is quite cool if you think about
> it, considering that determinism comes with a very precise sense of time
> anyway.
> 
> As long as the time granularity is in the order of a few bytes
> transmission the system timestamp provides an absolute sense of ordering
> over a very long period across all paths for which this node is ingress,
> and thus within any of those. With no additional state to maintain. Just
> program the hardware timestaping to write the offset wherewhen the OH is
> located.
> 
> >
> > 7, R-Tag format and sequencing function is defined by 802.1CB-2017. It
> > is incremented by 1 when a packet is sent. Have I missed something here?
> > "... though it >>> cannot <<< be assumed that the R-Tag is
> > sequentially incremented; ..."
> 
> It cannot be assumed for 2 reasons:
> - only the last 2 bytes of 6 are incremented and the wrapping happens
> there. Knowing that fact is already a layer violation.
> - R-TAG it is owned by IEEE 802 and subject to redefinition there, as you
> are proposing at this very moment, wishing you the best on that.
> 
> The bottom line is that since we (IETF) do not own the properties of the
> 6-byte field, we cannot depend on its properties, beyond the fact that it
> is unique within a reasonable set of sequential packet so all packets with
> the same value (+ same tag) are redundant. The intension is that the
> values are stored in full and individually as opposed to considered as a
> range.
> 
> >
> > 8, Is the hybrid model used by a RAW function?
> > " This specification also allows for an >> hybrid model <<< with a
> > coarse grained packet sequence within a coarse grained time stamp."
> 
> No, but it is already used in draft-ietf-rift-rift; it is a very cool
> thing when the sense of time is derived from NTP as opposed to PTP.
> 
> 
> > 9, What DetNet state is meant her?
> > " When present, it is the information that MUST be used to select the
> > >>> DetNet state <<< at the DetNet forwarding sublayer.
> 
> That's the information as was configured by the PCE for the flow and that
> indicates the per flow behavior.
> 
> My deepest thanks Bala'zs for pointing out places where the draft is
> lacking clarity. I'll publish an improved version asap. If you agree with
> the principles I laid out here (including the OAM incorporation), please
> feel free to consider joining me in this effort.
> 
> Keep safe
> 
> Pascal
> >
> > Thanks
> > Bala'zs
> >
> > -----Original Message-----
> > From: detnet <[e-mail]> On Behalf Of Pascal Thubert
> > (pthubert)
> > Sent: Tuesday, June 8, 2021 2:23 PM
> > To: DetNet WG <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: [Detnet] FW: New Version Notification for
> > draft-pthubert-detnet- ipv6-hbh-01.txt
> >
> > Dear DetNet
> >
> > This new draft is an effort to equalize the work at RAW and DetNet in
> > terms of path signaling in the IPv6 dataplane, and provide the same
> > capabilities in the MPLS and the IPv6 for sequencing.
> > It recognizes and leverages the recent evolution at 6MAN which makes
> > the HBH OH more and more usable in the greater internet.
> >
> > Comments welcome!
> >
> > Pascal
> >
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: mardi 8 juin 2021 14:16
> > To: Pascal Thubert (pthubert) <[e-mail]>
> > Subject: New Version Notification for draft-pthubert-detnet-ipv6-hbh-
> > 01.txt
> >
> >
> > A new version of I-D, draft-pthubert-detnet-ipv6-hbh-01.txt
> > has been successfully submitted by Pascal Thubert and posted to the
> > IETF repository.
> >
> > Name:		draft-pthubert-detnet-ipv6-hbh
> > Revision:	01
> > Title:		IPv6 Hop-by-Hop Options for DetNet
> > Document date:	2021-06-08
> > Group:		Individual Submission
> > Pages:		10
> > URL:            https://www.ietf.org/archive/id/draft-pthubert-detnet-
> > ipv6-hbh-01.txt
> > Status:         https://datatracker.ietf.org/doc/draft-pthubert-detnet-
> > ipv6-hbh/
> > Html:           https://www.ietf.org/archive/id/draft-pthubert-detnet-
> > ipv6-hbh-01.html
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-pthubert-
> > detnet-ipv6-hbh
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-pthubert-detnet-
> > ipv6-hbh-01
> >
> > Abstract:
> >    RFC 8938, the Deterministic Networking Data Plane Framework relies on
> >    the 6-tuple to identify an IPv6 flow.  But the full DetNet operations
> >    require also the capabilities to signal meta-information such as a
> >    sequence within that flow, and to transport different types of
> >    packets along the same path with the same treatment, e.g.,
> >    Operations, Administration, and Maintenance packets and/or multiple
> >    flows with fate and resource sharing.  This document introduces new
> >    Hop-by-Hop header options that can signal that information to the
> >    intermediate relays.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> > _______________________________________________
> > detnet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet
> >
> > --
> > RAW mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/raw