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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Jun 2021 12:23:02 +0000

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: [email-masked] <[email-masked]> 
Sent: mardi 8 juin 2021 14:16
To: Pascal Thubert (pthubert) <[email-masked]>
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

---

From: Balázs Varga A <[email-masked]>
Date: Fri, 18 Jun 2021 08:22:26 +0000

Hi Pascal,

thanks for the draft. I have some questions for clarification on it.
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 <<<." 

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 <<<)."

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?

In particular:
4, If a tunnel is used, why not to encode the information in Destination Options header?
Sequence information is not used by DetNet Transit nodes.
" 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."

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, ..."

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; ..."

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."

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.

Thanks
Bala'zs

-----Original Message-----
From: detnet <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, June 8, 2021 2:23 PM
To: DetNet WG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [Detnet] FW: New Version Notification for draft-pthubert-detnet-ipv6-hbh-01.txt

Dear DetNet

Comments welcome!

Pascal

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: mardi 8 juin 2021 14:16
To: Pascal Thubert (pthubert) <[email-masked]>
Subject: New Version Notification for draft-pthubert-detnet-ipv6-hbh-01.txt

Abstract:

The IETF Secretariat

_______________________________________________
detnet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Jun 2021 11:37:08 +0000

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.

> >>> 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.

> >>> 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. 

> 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. 

> 4, If a tunnel is used, why not to encode the information in Destination

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."
> 
> " ... 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.

> 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?

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.	

> 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.

> " 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
> 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
> 
> --
> RAW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/raw

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Jun 2021 10:05:06 +0000

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

> From: Pascal Thubert (pthubert)
> Sent: vendredi 18 juin 2021 13:37
> To: Balázs Varga A <balazs.a.varga=[email-masked]>; Pascal
> Thubert (pthubert) <pthubert=[email-masked]>; DetNet WG
> <[email-masked]>
> Subject: RE: New Version Notification for draft-pthubert-detnet-ipv6-hbh-
> 01.txt
> 
> Hello Bala'zs
> 
> 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:
> 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
> 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.
> 
> 
> > >>> without <<< the need of a deep packet inspection (e.g., >>> beyond
> > >>> UDP
> > <<<)."
> 
> 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.
> 
> 
> >
> 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:
> 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."
> >
> > " ... 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."
> 
> 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?
> - 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.
> 
> >
> > " 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.
> 
> 
> > " When present, it is the information that MUST be used to select the
> 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
> >
> > Subject: [Detnet] FW: New Version Notification for
> > draft-pthubert-detnet- ipv6-hbh-01.txt
> >
> > Dear DetNet
> >
> > 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
> >

---

From: "Yangfan (IP Standard)" <[email-masked]>
Date: Wed, 23 Jun 2021 13:22:49 +0000

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:[email-masked]] 代表 Pascal Thubert (pthubert)
发送时间: 2021年6月18日 19:37
收件人: Balázs Varga A <balazs.a.varga=[email-masked]>; Pascal Thubert (pthubert) <pthubert=[email-masked]>; DetNet WG <[email-masked]>
抄送: [email-masked]; [email-masked]
主题: Re: [Detnet] New Version Notification for draft-pthubert-detnet-ipv6-hbh-01.txt

Hello Bala'zs

> "... the DetNet information ... and can be added by a service instance

> as part of the

> 4, If a tunnel is used, why not to encode the information in

> Destination Options header?

> 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, ..."

> "... though it >>> cannot <<< be assumed that the R-Tag is

> sequentially incremented; ..."

Keep safe

Pascal

> From: detnet <[email-masked]<mailto:[email-masked]>> On Behalf Of Pascal Thubert

> (pthubert)

> To: DetNet WG <[email-masked]<mailto:[email-masked]>>

> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

> To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>

> Subject: New Version Notification for draft-pthubert-detnet-ipv6-hbh-

> has been successfully submitted by Pascal Thubert and posted to the

> IETF repository.

> 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

> [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

detnet mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 23 Jun 2021 14:57:05 +0000

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) <[email-masked]>
Sent: mercredi 23 juin 2021 15:23
To: Pascal Thubert (pthubert) <[email-masked]>; Balázs Varga A <[email-masked]>; DetNet WG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: 答复: New Version Notification for draft-pthubert-detnet-ipv6-hbh-01.txt

Hi Pascal,

Regards,

Fan

-----邮件原件-----
发件人: detnet [mailto:[email-masked]] 代表 Pascal Thubert (pthubert)
发送时间: 2021年6月18日 19:37
收件人: Balázs Varga A <balazs.a.varga=[email-masked]<mailto:balazs.a.varga=[email-masked]>>; Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>; DetNet WG <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [Detnet] New Version Notification for draft-pthubert-detnet-ipv6-hbh-01.txt

Hello Bala'zs

Keep safe

Pascal

detnet mailing list