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

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

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