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

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

Hello Yangfan

Many thanks for your support!

Please see below:

> Regarding the term path, it is a new perspective, not explicitly defined in DetNet architecture.

Actually it is explicitly discussed, e.g., the architecture describe the operation to “identify DetNet flows and assign them to specific paths through a network”. Confusing the flow and the path is like confusing the water and the pipes.

The architecture does not discuss how the path is signaled, and the current IP dataplane document assumes that it is implicit based on the flow id. This is one way of doing it, but the architecture does not have such limitation. This draft signals the path explicitly, with a number of benefits.

Note: The term path is actually an overused term throughout IETF documents to the point that it can only be taken in a very wide acceptance. In the detnet architecture, the term path is also used in a very loose manner. Sometimes it is the end to end multipath, sometimes it is a leg of that graph. OTOH, RAW uses the term Track for the graph) and Segment for a serial leg within the graph. This conforms ROLL/RPL and 6TiSCH; I believe that we’d all benefit from synchronizing also DetNet on that more specific terminology.


> 1) if both flow ID and path ID are required for DetNet?



There’s no “DetNet flow ID”. The dataplane derives a flow ID from upper layer  protocol (ULP) information (the 6 tuple), so it’s doable though not ideal to use that to make a forwarding decision. If a flow is placed in a path and the path ID is indicated early in the packet, then DetNet can operate at the path level and can safely ignore the flow identification that is derived from opaque ULP information.



> 2) if there are mapping states maintained at relay nodes, or as draft said state is required by all nodes?



The draft has a strict path information and a loose one. By the IPv6 specification, the ACT bits in the option type command the behavior of the intermediate router. For a strict case, all hops must be configured with the path, and nodes that either cannot understand the option or are not programmed with that path will send an ICMP error to the source.



Classical DetNet is always strict at the forwarding layer and can ne loose at the service layer - RAW can do loose at both layers, in which case latency guarantees cannot be obtained. Meaning that with DetNet there must be a state at each L3 hop for the forwarding layer, and there may (or may not) be a state for the service layer as well. This is why, with the draft, the strict path option cannot be ignored while the redundancy information can, see the act bits setting in https://www.ietf.org/archive/id/draft-pthubert-detnet-ipv6-hbh-04.html#name-new-hop-by-hop-options



> 3) if all the nodes should be aware of the path and states, why not just maintain the states based on flow, as flow aggregation is considered for sake of scalability?



Because a path can be followed by all sorts of packets including OAM which do not necessarily qualify  as a “flow”, and by more than one flow, as long as the aggregate packets fit within the reserved resources. It’s easier to process one path ID than multiple flow IDs plus exceptions for non-flow packets. Also the HbH EH must be placed right after the IPv6 header (RFC 8200), so it’s easier to locate and process by a silicon forwarder.



> can I understand DetNet flow identifies DetNet service sublayer, and path is used to identify the forwarding sublayer?

No, the flow is really an upper layer construct, either L4 or L5, in which case its identification is even deeper in the packet. The path is a pure L3 construct. . With the draft, the forwarding layer uses the path ID only, and the path ID is a forwarding (sub)layer information.

The service layer uses the redundancy information for PREOF, which is a service (sub) layer information.

But the service layer also needs the path ID as an opaque indication for the name space (the domain of uniqueness) of the redundancy information. So the service layer uses the path ID as an opaque prefix to the redundancy information to determine if 2 packets are the same or not.

Keep safe,

Pascal

From: Yangfan (IP Standard) <[e-mail]>
Sent: mercredi 23 juin 2021 15:23
To: Pascal Thubert (pthubert) <[e-mail]>; Balázs Varga A <[e-mail]>; DetNet WG <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: 答复: New Version Notification for draft-pthubert-detnet-ipv6-hbh-01.txt


Hi Pascal,



Thanks for the draft, I am happy to see and expect IPv6 EHs could bring more progress and benefits to DetNet. Only speaking of IPv6, leveraging IPv6 EHs to carry meta info for DetNet is pretty neat, no matter in HbH, SRH or DOH, may depend on the use cases. In fact, ACH6<https://datatracker.ietf.org/doc/html/draft-yang-rtgwg-ipv6-associated-channel-00> is also saying the same idea, and I believe DetNet could be one of use cases.



Regarding the term path, it is a new perspective, not explicitly defined in DetNet architecture. I doubt whether it would bring substantial changes to DetNet. For example:

1) if both flow ID and path ID are required for DetNet?

2) if there are mapping states maintained at relay nodes, or as draft said state is required by all nodes?

3) if all the nodes should be aware of the path and states, why not just maintain the states based on flow, as flow aggregation is considered for sake of scalability?



can I understand DetNet flow identifies DetNet service sublayer, and path is used to identify the forwarding sublayer?

But for one thing I must admit it path concept definitely brings benefits to DetNet OAM.



Regards,

Fan





-----邮件原件-----
发件人: detnet [mailto:[e-mail]] 代表 Pascal Thubert (pthubert)
发送时间: 2021年6月18日 19:37
收件人: Balázs Varga A <balazs.a.varga=[e-mail]<mailto:balazs.a.varga=[e-mail]>>; Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:pthubert=[e-mail]>>; DetNet WG <[e-mail]<mailto:[e-mail]>>
抄送: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
主题: Re: [Detnet] 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]<mailto:[e-mail]>> On Behalf Of Pascal Thubert

> (pthubert)

> Sent: Tuesday, June 8, 2021 2:23 PM

> To: DetNet WG <[e-mail]<mailto:[e-mail]>>

> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

> Sent: mardi 8 juin 2021 14:16

> To: Pascal Thubert (pthubert) <[e-mail]<mailto:[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]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/detnet

>

> --

> RAW mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/raw



_______________________________________________

detnet mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/detnet