Subject: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

From: Jeong-dong Ryoo <[email-masked]>
Date: Tue, 02 Jun 2020 16:10:11 +0900 (KST)

Dear Bala’zs,

Thank you for your email.&nbsp;I am glad to know that current MPLS data plane document is intended to support the PREOF in relay nodes as in the architecture document.&nbsp;

Regarding your updated text I have two comments:
1) I don’t think the second sentence of the second paragraph in Section 4.5.1 is for a DetNet edge node. That seems for a relay node. In my view, the sentence needs to be replaced with:
The mapping of ingress DetNet app-flow to egress DetNet member&nbsp;
flow segment may be statically or dynamically configured.

2) In the first sentence of the second paragraph of Section 4.5.2, I would add “ingress” before “DetNet member flow” to make clearer:&nbsp;
During elimination and the replication process&nbsp;
the sequence number of the ingress DetNet member flow MUST be&nbsp;
preserved and copied to the egress DetNet member flow.

I have another issue related to our current discussion. Current MPLS data plane document seems to assume that only one S-Label value is used for all duplicated packets during replication process. Considering the fact that S-Labels are local to each node and advertised to its upstream nodes, an edge or relay node that performs the packet replication may push different S-Label values for different outgoing duplicates. In Figure 1 of RFC 8655 (DetNet Architecture), when the right-most node and two middle relay nodes assign different S-Label values, the left-most node, which generates duplicates towards two relay nodes, would have to push different S-Labels for different relay nodes.&nbsp;
In order to make a clarification on this issue, I would like to propose to add following text after the second sentence of the third paragraph in Section 4.2.3.1:
The S-Label value in each copy of the outgoing packet&nbsp;
may be different from each other when duplicated packets&nbsp;
are forwarded to different relay nodes.

Thank you for your consideration.

Best regards,

Jeong-dong

-----Original Message-----
From: "Balázs Varga A" &lt;[email-masked]&gt;
To: "[email-masked]" &lt;[email-masked]&gt;; "DetNet WG" &lt;[email-masked]&gt;;
Cc: "'DetNet Chairs'" &lt;[email-masked]&gt;; "[email-masked]" &lt;[email-masked]&gt;;
Sent: 2020-05-30 (토) 00:12:49 (UTC+09:00)
Subject: RE: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Hi Jeong-dong,
&nbsp;
Thanks for your fresh eyes. I think this is an editorial issue. The draft contains at many points explicitly that Relay Nodes operate at both sub-layer (service and forwarding).
However it is never too late to make the text clearer, therefore some editorial changes were made on the sections You have referred. Thank You for the review.
&nbsp;
Please, check the editorial changes on the Github:
https://github.com/detnet-wg/data-plane-drafts/pull/99/files https://github.com/detnet-wg/data-plane-drafts/pull/99/files
&nbsp;
UPDATED Text:
4.5.1. Edge Node Processing
An edge node is responsible for matching ingress packets to the
service they require and encapsulating them accordingly. An edge
node may participate in the packet replication and duplicate packet
elimination.
&nbsp;
The DetNet-aware forwarder selects the egress DetNet member flow
segment based on the flow identification. The mapping of ingress
DetNet member flow segment to egress DetNet member flow segment may
be statically or dynamically configured. Additionally the DetNet-
aware forwarder does duplicate frame elimination based on the flow
identification and the sequence number combination. The packet
replication is also done within the DetNet-aware forwarder.

4.5.2. Relay Node Processing
A DetNet Relay node operates in the DetNet forwarding sub-layer and
service sub-layer. For DetNet using MPLS forwarding processing is
performed on the F-Label. This processing is done within an extended
forwarder function. Whether an ingress DetNet member flow receives
DetNet specific processing depends on how the forwarding is
programmed. Some relay nodes may be DetNet service aware for certain
DetNet services, while for other DetNet services the node may perform
as unmodified LSRs that only understand how to switch MPLS-TE LSPs,
i.e., as a transit node, see Section 4.4. Again, this is entirely up
to how the forwarding has been programmed.
&nbsp;
During elimination and the replication process the sequence number of
the DetNet member flow MUST be preserved and copied to the egress
DetNet member flow. Specifically, a relay node sends the same
sequence number in an outgoing packet of a DetNet member flow that is
received in the corresponding incoming packet of a DetNet compound
flow. This is true whether or not PREOF is performed at the relay
node.
&nbsp;
The internal design of a relay node is out of scope of this document.
However the reader’s attention is drawn to the need to make any PREOF
state available to the packet processor(s) dealing with packets to
which the PREOF functions must be applied, and to maintain that state
is such as way that it is available to the packet processor operation
on the next packet in the DetNet flow (which may be a duplicate, a
late packet, or the next packet in sequence.
&nbsp;
END of UPDATED Text:
&nbsp;
Thanks &amp; Cheers
Bala’zs
&nbsp;
&nbsp;
From: [email-masked] &lt;[email-masked]&gt;Sent: Thursday, May 28, 2020 10:11 AMTo: DetNet WG &lt;[email-masked]&gt;Cc: 'DetNet Chairs' &lt;[email-masked]&gt;; [email-masked]: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655
&nbsp;
Dear DetNet experts,
&nbsp;
In Sections 4.5.1 and 4.5.2 of DetNet MPLS data plane draft,&nbsp;draft-ietf-detnet-mpls-06, processing of edge and relay nodes is described from the perspective of the service sub-layer.&nbsp;
&nbsp;
It seems that current text supports a network scenario that only two edge nodes perform FREOF functions and relay nodes between them are just acting as transit nodes. In other words, the very first figure of DetNet architecture document, RFC 8655, is not supported by current DetNet MPLS data plane draft.&nbsp;
&nbsp;
On the other hand, I see the following text from the second paragraph of Section 4.5.1, which describes processing of edge nodes:&nbsp;
“During elimination and the replication process the sequence number of the
DetNet member flow MUST be preserved and copied to the egress DetNet
member flow.”
I am wondering whether the quoted text should apply to relay nodes, not edge nodes, because edge nodes, which add or remove d-CWs and S-Labels, do not have to pass the sequence number outside.&nbsp;
&nbsp;
Anyway, in my opinion, Figure 1 of RFC 8655 should be supported in the DetNet MPLS data plane document, and I would like to propose the following text, which reuses current text as much as possible, for Sections 4.5.1 and 4.5.2:&nbsp;
%%% BEGIN %%%
&nbsp;
4.5.1. Edge Node Processing
&nbsp;
An edge node is responsible for matching ingress packets to the
service they require&nbsp;and encapsulating them accordingly. An edge
node may participate in the packet replication and duplicate packet
elimination.
&nbsp;
The DetNet-aware forwarder in the DetNet edge node selects the&nbsp;
egress DetNet member flow segment based on the flow identification.&nbsp;
The mapping of ingress DetNet app-flow to egress DetNet member&nbsp;
flow segment may be statically or dynamically configured.
Additionally, the DetNet-aware forwarder does duplicate frame&nbsp;
elimination based on the sequence number in the d-CW.&nbsp;
The packet replication&nbsp;is also done within the DetNet-aware forwarder.
&nbsp;
4.5.2. Relay Node Processing
&nbsp;
A DetNet Relay node operates in the DetNet service sub-layer.
For DetNet using MPLS this processing is performed on the S-Label.
A relay node may participate in the packet replication and&nbsp;
duplicate packet elimination.
&nbsp;
The DetNet-aware forwarder in the DetNet relay node selects the&nbsp;
egress DetNet member flow segment based on the ingress S-Label.
The mapping of ingress to egress S-Label may be statically&nbsp;
or dynamically configured. Additionally, the DetNet-aware&nbsp;
forwarder does duplicate frame elimination based on the sequence&nbsp;
number in the d-CW. The packet replication is also done within the&nbsp;
DetNet-aware forwarder. During elimination and the replication&nbsp;
process the sequence number of the DetNet member flow MUST be&nbsp;
preserved and copied to the egress DetNet member flow.
&nbsp;
%%% End %%%
&nbsp;
&nbsp;
Please, note that the third paragraph of Section 4.5.1 does not appear in the text proposed above.&nbsp;I think that paragraph should be moved before Section 4.5.1 since it can apply to both edge and relay nodes.
&nbsp;
I would appreciate if you can review the proposed text and provide your feedbacks.
&nbsp;
Best regards,
&nbsp;
Jeong-dong
&nbsp;
&nbsp;

&nbsp;

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 2 Jun 2020 14:43:57 +0000

Hi Jeong-dong, thanks. Replies inline. Cheers Bala’zs

From: [email-masked] <[email-masked]>
Sent: Tuesday, June 2, 2020 9:10 AM
To: DetNet WG <[email-masked]>; Balázs Varga A <[email-masked]>
Cc: 'DetNet Chairs' <[email-masked]>; [email-masked]
Subject: RE: RE: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Dear Bala’zs,

Thank you for your email. I am glad to know that current MPLS data plane document is intended to support the PREOF in relay nodes as in the architecture document.

The mapping of ingress DetNet app-flow to egress DetNet member
flow segment may be statically or dynamically configured.
<Balazs> This applies to both edge nodes and relay nodes. This sentence intends to say, that the configuration of ingress flow mapping to egress flow may be static or dynamic.

2) In the first sentence of the second paragraph of Section 4.5.2, I would add “ingress” before “DetNet member flow” to make clearer:

During elimination and the replication process

the sequence number of the ingress DetNet member flow MUST be

<Balazs> OK.

I have another issue related to our current discussion. Current MPLS data plane document seems to assume that only one S-Label value is used for all duplicated packets during replication process. Considering the fact that S-Labels are local to each node and advertised to its upstream nodes, an edge or relay node that performs the packet replication may push different S-Label values for different outgoing duplicates. In Figure 1 of RFC 8655 (DetNet Architecture), when the right-most node and two middle relay nodes assign different S-Label values, the left-most node, which generates duplicates towards two relay nodes, would have to push different S-Labels for different relay nodes.

The S-Label value in each copy of the outgoing packet

may be different from each other when duplicated packets

are forwarded to different relay nodes.
<Balazs> This section is dealing with the F-labels. S-labels are covered in “4.2.2. S-Labels”.
Last sentence of the first paragraph covers your text explicitly: “Relay nodes MAY swap
S-Label values when processing an app-flow.” Second sentence of 4.2.3.1 also refers to
the possible swap operation on S-Labels.

Best regards,

Jeong-dong

-----Original Message-----
From: "Balázs Varga A" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "DetNet WG" <[email-masked]<mailto:[email-masked]>>;
Cc: "'DetNet Chairs'" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>;
Sent: 2020-05-30 (토) 00:12:49 (UTC+09:00)
Subject: RE: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Hi Jeong-dong,

https://github.com/detnet-wg/data-plane-drafts/pull/99/files<https://protect2.fireeye.com/v1/url?k=9d0b81e9-c3ab43af-9d0bc172-86fc6812c361-5d99876ed374018f&q=1&e=eb95bc20-c35e-44d2-b998-e13f3a290f60&u=https%3A%2F%2Fgithub.com%2Fdetnet-wg%2Fdata-plane-drafts%2Fpull%2F99%2Ffiles>

UPDATED Text:

elimination.

node.

END of UPDATED Text:

Thanks & Cheers

Bala’zs

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 28, 2020 10:11 AM
To: DetNet WG <[email-masked]<mailto:[email-masked]>>
Cc: 'DetNet Chairs' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Dear DetNet experts,

In Sections 4.5.1 and 4.5.2 of DetNet MPLS data plane draft, draft-ietf-detnet-mpls-06, processing of edge and relay nodes is described from the perspective of the service sub-layer.

It seems that current text supports a network scenario that only two edge nodes perform FREOF functions and relay nodes between them are just acting as transit nodes. In other words, the very first figure of DetNet architecture document, RFC 8655, is not supported by current DetNet MPLS data plane draft.

On the other hand, I see the following text from the second paragraph of Section 4.5.1, which describes processing of edge nodes:

member flow.”

I am wondering whether the quoted text should apply to relay nodes, not edge nodes, because edge nodes, which add or remove d-CWs and S-Labels, do not have to pass the sequence number outside.

Anyway, in my opinion, Figure 1 of RFC 8655 should be supported in the DetNet MPLS data plane document, and I would like to propose the following text, which reuses current text as much as possible, for Sections 4.5.1 and 4.5.2:

%%% BEGIN %%%

elimination.

The DetNet-aware forwarder in the DetNet edge node selects the

egress DetNet member flow segment based on the flow identification.

The mapping of ingress DetNet app-flow to egress DetNet member

Additionally, the DetNet-aware forwarder does duplicate frame

elimination based on the sequence number in the d-CW.

The packet replication is also done within the DetNet-aware forwarder.

A relay node may participate in the packet replication and

The DetNet-aware forwarder in the DetNet relay node selects the

The mapping of ingress to egress S-Label may be statically

or dynamically configured. Additionally, the DetNet-aware

forwarder does duplicate frame elimination based on the sequence

number in the d-CW. The packet replication is also done within the

DetNet-aware forwarder. During elimination and the replication

process the sequence number of the DetNet member flow MUST be

%%% End %%%

Please, note that the third paragraph of Section 4.5.1 does not appear in the text proposed above. I think that paragraph should be moved before Section 4.5.1 since it can apply to both edge and relay nodes.

Best regards,

Jeong-dong

[https://gov-dooray.com/mail-receipts?img=3431765056546f50-255f338911948417-26398ea52d3696d1-263993826fbe1ade.gif]

[https://gov-dooray.com/mail-receipts?img=6b7076734f456535-255f338911948417-2646529c54918f5d-264657a2d24dbfef.gif]

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Wed, 03 Jun 2020 00:24:31 +0900 (KST)

Bala'zs, thank you for the&nbsp;reply.

Please, see my response starting with [JR]

Best regards,

Jeong-dong

-----Original Message-----
From: "Balázs Varga A" &lt;[email-masked]&gt;
To: "[email-masked]" &lt;[email-masked]&gt;; "DetNet WG" &lt;[email-masked]&gt;;
Cc: "'DetNet Chairs'" &lt;[email-masked]&gt;; "[email-masked]" &lt;[email-masked]&gt;;
Sent: 2020-06-02 (화) 23:44:05 (UTC+09:00)
Subject: RE: RE: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Hi Jeong-dong, thanks. Replies inline. Cheers Bala’zs
&nbsp;
From: [email-masked] &lt;[email-masked]&gt;Sent: Tuesday, June 2, 2020 9:10 AMTo: DetNet WG &lt;[email-masked]&gt;; Balázs Varga A &lt;[email-masked]&gt;Cc: 'DetNet Chairs' &lt;[email-masked]&gt;; [email-masked]: RE: RE: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655
&nbsp;
Dear Bala’zs,
&nbsp;
Thank you for your email. I am glad to know that current MPLS data plane document is intended to support the PREOF in relay nodes as in the architecture document.&nbsp;
&nbsp;
Regarding your updated text I have two comments:
1) I don’t think the second sentence of the second paragraph in Section 4.5.1 is for a DetNet edge node. That seems for a relay node. In my view, the sentence needs to be replaced with:
The mapping of ingress DetNet app-flow to egress DetNet member&nbsp;
flow segment may be statically or dynamically configured.

&lt;Balazs&gt; This applies to both edge nodes and relay nodes. This sentence intends to say, that the configuration of ingress flow mapping to egress flow may be static or dynamic.
[JR] I don't think any DetNet MPLS edge node would have both ingress DetNet member flow segment and egress DetNet member flow segment. It is a relay node that can have both.
&nbsp;
ingress
DetNet member flow segment&nbsp;

2) In the first sentence of the second paragraph of Section 4.5.2, I would add “ingress” before “DetNet member flow” to make clearer:&nbsp;
During elimination and the replication process&nbsp;
the sequence number of the ingress DetNet member flow MUST be&nbsp;
preserved and copied to the egress DetNet member flow.
&lt;Balazs&gt; OK.
[JR] ^^
&nbsp;
I have another issue related to our current discussion. Current MPLS data plane document seems to assume that only one S-Label value is used for all duplicated packets during replication process. Considering the fact that S-Labels are local to each node and advertised to its upstream nodes, an edge or relay node that performs the packet replication may push different S-Label values for different outgoing duplicates. In Figure 1 of RFC 8655 (DetNet Architecture), when the right-most node and two middle relay nodes assign different S-Label values, the left-most node, which generates duplicates towards two relay nodes, would have to push different S-Labels for different relay nodes.&nbsp;
In order to make a clarification on this issue, I would like to propose to add following text after the second sentence of the third paragraph in Section 4.2.3.1:
The S-Label value in each copy of the outgoing packet&nbsp;
may be different from each other when duplicated packets&nbsp;
are forwarded to different relay nodes.
&lt;Balazs&gt; This section is dealing with the F-labels. S-labels are covered in “4.2.2. S-Labels”.&nbsp;
Last sentence of the first paragraph covers your text explicitly: “Relay nodes MAY swap&nbsp;
S-Label values when processing an app-flow.” Second sentence of 4.2.3.1 also refers to
the possible swap operation on S-Labels.
 [JR] The issue I raised above cannot be resolved by swap operation. We need to cover&nbsp;the situation that S-Label value of one outgoing copy can be different from that of the other outgoing copy if those two copies are forwarded to two different relay nodes. &nbsp;
&nbsp;

&nbsp;

&nbsp;

-----Original Message-----

From: "Balázs Varga A" &lt;[email-masked] mailto:[email-masked]&gt;

To: "[email-masked] mailto:[email-masked]" &lt;[email-masked] mailto:[email-masked]&gt;; "DetNet WG" &lt;[email-masked] mailto:[email-masked]&gt;;

Cc: "'DetNet Chairs'" &lt;[email-masked] mailto:[email-masked]&gt;; "[email-masked] mailto:[email-masked]" &lt;[email-masked] mailto:[email-masked]&gt;;

&nbsp;

Hi Jeong-dong,
&nbsp;
https://github.com/detnet-wg/data-plane-drafts/pull/99/files https://protect2.fireeye.com/v1/url?k=9d0b81e9-c3ab43af-9d0bc172-86fc6812c361-5d99876ed374018f&amp;q=1&amp;e=eb95bc20-c35e-44d2-b998-e13f3a290f60&amp;u=https://github.com/detnet-wg/data-plane-drafts/pull/99/files
From: &nbsp;[email-masked] mailto:[email-masked] &lt;[email-masked] mailto:[email-masked]&gt;Sent: Thursday, May 28, 2020 10:11 AMTo: DetNet WG &lt;[email-masked] mailto:[email-masked]&gt;Cc: 'DetNet Chairs' &lt;[email-masked] mailto:[email-masked]&gt;; [email-masked] mailto:[email-masked]: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

&nbsp;

&nbsp;

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 3 Jun 2020 10:52:59 +0000

Hi Jeong-dong, thanks. Replies/clarifications inline. Cheers Bala’zs

Sent: Tuesday, June 2, 2020 5:25 PM

Bala'zs, thank you for the reply.

Best regards,

Jeong-dong

-----Original Message-----
From: "Balázs Varga A" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "DetNet WG" <[email-masked]<mailto:[email-masked]>>;
Cc: "'DetNet Chairs'" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>;
Sent: 2020-06-02 (화) 23:44:05 (UTC+09:00)
Subject: RE: RE: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

To: DetNet WG <[email-masked]<mailto:[email-masked]>>; Balázs Varga A <[email-masked]<mailto:[email-masked]>>

Dear Bala’zs,

 <Balazs> Text in the draft refers (intentionally and correct) to ingress DetNet app-flow and not member flow.
Edge node maps of ingress DetNet app-flow to egress DetNet member flow segment.
Relay node maps of ingress DetNet member flow to egress DetNet member flow segment.

ingress
DetNet member flow segment

<Balazs> OK.

[JR] ^^

[JR] The issue I raised above cannot be resolved by swap operation. We need to cover the situation that S-Label value of one outgoing copy can be different from that of the other outgoing copy if those two copies are forwarded to two different relay nodes.

 <Balazs> That is an internal implementation question, what we do not intend to define.
You may implement replication before S-label swap. Order of functions in a given
implementation is out-of-scope for the draft.

Best regards,

Jeong-dong

-----Original Message-----

Hi Jeong-dong,

UPDATED Text:

elimination.

node.

END of UPDATED Text:

Thanks & Cheers

Bala’zs

Dear DetNet experts,

member flow.”

%%% BEGIN %%%

elimination.

%%% End %%%

Best regards,

Jeong-dong

[https://gov-dooray.com/mail-receipts?img=684565716e535939-255f338911948417-264729299691fa2a-264739ecc71aa454.gif]

---

From: Lou Berger <[email-masked]>
Date: Wed, 3 Jun 2020 07:14:58 -0400

Hi,

I have a question, see below

On 6/3/2020 6:52 AM, Balázs Varga A wrote:
>
> I have another issue related to our current discussion. Current MPLS 
> data plane document seems to assume that only one S-Label value is 
> used for all duplicated packets during replication process. 
> Considering the fact that S-Labels are local to each node and 
> advertised to its upstream nodes, an edge or relay node that performs 
> the packet replication may push different S-Label values for different 
> outgoing duplicates. In Figure 1 of RFC 8655 (DetNet Architecture), 
> when the right-most node and two middle relay nodes assign different 
> S-Label values, the left-most node, which generates duplicates towards 
> two relay nodes, would have to push different S-Labels for different 
> relay nodes.
>
> In order to make a clarification on this issue, I would like to 
> propose to add following text after the second sentence of the third 
> paragraph in Section 4.2.3.1:
>
> [JR] The issue I raised above cannot be resolved by swap operation. We 
> need to cover the situation that S-Label value of one outgoing copy 
> can be different from that of the other outgoing copy if those two 
> copies are forwarded to two different relay nodes.
>
I don't see support in the document for having a single service send 
different S-Labels, for the *same* service, on two different member 
flows.  Nor do I see support for a single service being split into two 
services in the current document without an A-Label (and pop 
operation).  I'm not saying it's not possible, but rather that neither 
are part of the current definition.  Of course, I may have missed 
something in the text.

Jeong-dong (or anyone else),

     Can you point to where you see these S-Label operations being 
allowed for in the current document?

Thank you,

Lou

(as contributor)

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Thu, 04 Jun 2020 13:30:00 +0900 (KST)

Bala'zs, thank you for your replies.
Please, see inline starting with [JR].

Best regards,

Jeong-dong

-----Original Message-----
From: "Balázs Varga A" &lt;balazs.a.varga=[email-masked]&gt;
To: "[email-masked]" &lt;[email-masked]&gt;; "DetNet WG" &lt;[email-masked]&gt;;
Cc: "[email-masked]" &lt;[email-masked]&gt;; "'DetNet Chairs'" &lt;[email-masked]&gt;;
Sent: 2020-06-03 (수) 20:08:50 (UTC+09:00)
Subject: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Hi Jeong-dong, thanks. Replies/clarifications inline. Cheers Bala’zs
&nbsp;
From: [email-masked] &lt;[email-masked]&gt;Sent: Tuesday, June 2, 2020 5:25 PMTo: DetNet WG &lt;[email-masked]&gt;; Balázs Varga A &lt;[email-masked]&gt;Cc: 'DetNet Chairs' &lt;[email-masked]&gt;; [email-masked]: RE: RE: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655
&nbsp;
Bala'zs, thank you for the&nbsp;reply.

&nbsp;

&nbsp;

Best regards,

&nbsp;

Jeong-dong

&nbsp;

&nbsp;

&nbsp;

&nbsp;

-----Original Message-----

&nbsp;

From: &nbsp;[email-masked] mailto:[email-masked] &lt;[email-masked] mailto:[email-masked]&gt;Sent: Tuesday, June 2, 2020 9:10 AMTo: DetNet WG &lt;[email-masked] mailto:[email-masked]&gt;; Balázs Varga A &lt;[email-masked] mailto:[email-masked]&gt;Cc: 'DetNet Chairs' &lt;[email-masked] mailto:[email-masked]&gt;; [email-masked] mailto:[email-masked]: RE: RE: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

&lt;Balazs&gt; This applies to both edge nodes and relay nodes. This sentence intends to say, that the configuration of ingress flow mapping to egress flow may be static or dynamic.
[JR] I don't think any DetNet MPLS edge node would have both ingress DetNet&nbsp;member&nbsp;flow segment and egress DetNet&nbsp;member&nbsp;flow segment. It is a relay node that can have both.
&nbsp;&lt;Balazs&gt; Text in the draft refers (intentionally and correct) to ingress DetNet&nbsp;app-flow&nbsp;and not member flow. &nbsp;Edge node maps of ingress&nbsp;DetNet&nbsp;app-flow&nbsp;to&nbsp; egress&nbsp;DetNet&nbsp;member&nbsp;flow segment. &nbsp;Relay node maps of ingress&nbsp;DetNet&nbsp;member&nbsp;flow to&nbsp; egress&nbsp;DetNet&nbsp;member&nbsp;flow segment.
[JR] Thank you. I would appreciate if you can update the draft with the text you showed above.

&nbsp;

[JR] The issue I raised above cannot be resolved by swap operation. We need to cover the situation that S-Label value of one outgoing copy can be different from that of the other outgoing copy if those two copies are forwarded to two different relay nodes. &nbsp;
&nbsp;&lt;Balazs&gt; That is an internal implementation question, what we do not intend to define.  You may implement replication before S-label swap. Order of functions in a given &nbsp;implementation is out-of-scope for the draft.
[JR] For a relay node, swap operation can achieve two different S-label values for the outgoing duplicates being forwared to two different relay nodes. But, for an edge node, it doesn't seem possible to support Figure 1 of RFC 8655 without pushing two different S-labels.&nbsp;

&nbsp;

&nbsp;

-----Original Message-----

&nbsp;

Hi Jeong-dong,
&nbsp;
From: &nbsp; [email-masked] mailto:[email-masked] &lt;[email-masked] mailto:[email-masked]&gt;Sent: Thursday, May 28, 2020 10:11 AMTo: DetNet WG &lt;[email-masked] mailto:[email-masked]&gt;Cc: 'DetNet Chairs' &lt;[email-masked] mailto:[email-masked]&gt;; [email-masked] mailto:[email-masked]: Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

&nbsp;

&nbsp;

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

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Thu, 04 Jun 2020 13:42:09 +0900 (KST)

Lou,&nbsp;

My answer to your question:
I don't see, either.

If no new text on different S-Labels is added, my conclusion seems that current DetNet MPLS data plane document does NOT support Figure 1 of RFC 8655.
Do you agree?

Best regards,

Jeong-dong

&nbsp;

-----Original Message-----
From: "Lou Berger" &lt;[email-masked]&gt;
To: "Balázs Varga A" &lt;[email-masked]&gt;; "[email-masked]" &lt;[email-masked]&gt;; "DetNet WG" &lt;[email-masked]&gt;;
Cc: "[email-masked]" &lt;[email-masked]&gt;; "'DetNet Chairs'" &lt;[email-masked]&gt;;
Sent: 2020-06-03 (수) 20:30:42 (UTC+09:00)
Subject: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Hi,
I don't see support in the document for having a single service send different S-Labels, for the *same* service, on two different member flows. &nbsp;Nor do I see support for a single service being split into two services in the current document without an A-Label (and pop operation). &nbsp;I'm not saying it's not possible, but rather that neither are part of the current definition. &nbsp;Of course, I may have missed something in the text.&nbsp;
&nbsp; &nbsp; Can you point to where you see these S-Label operations being allowed for in the current document?
Thank you,
Lou
(as contributor)

---

From: Balázs Varga A <[email-masked]>
Date: Thu, 4 Jun 2020 13:04:21 +0000

Hi Jeong-dong,

I cannot agree with your conclusion. DetNet MPLS data plane document DOES support Figure 1 of RFC 8655.

Section “4.2.2. S-Labels” states explicitly how to use the S-label field.

   ...  MPLS-aware DetNet end systems and edge nodes, which are
   by definition MPLS ingress and egress nodes, MUST add and remove an
   app-flow specific d-CW and S-Label.

   ...  Note that S-Labels provide
   app-flow identification at the downstream DetNet service sub-layer
   receiver, not the sender.  As such, S-Labels MUST be allocated by the

   entity that controls the service sub-layer receiving node's label

   space ...

So, the edge node have to add an S-Label to the outgoing DetNet flow packet and the value of the
S-Label is defined by the receiver. So, if edge node performs replication there will be multiple
outgoing DetNet member flows. If these member flows have separate “receiver” they S-label
may be different. Label allocation solutions are out-of-scope in this document.

External nodal behavior fully defined, how it is implemented inside the box is up to implementation.
I hope that has clarified your concerns.

Thanks & Cheers
Bala’zs

From: [email-masked] <[email-masked]>
Sent: Thursday, June 4, 2020 6:42 AM
To: Balázs Varga A <[email-masked]>; DetNet WG <[email-masked]>; Lou Berger <[email-masked]>
Cc: [email-masked]; 'DetNet Chairs' <[email-masked]>
Subject: RE: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Lou,

Best regards,

Jeong-dong

-----Original Message-----
From: "Lou Berger" <[email-masked]<mailto:[email-masked]>>
To: "Balázs Varga A" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "DetNet WG" <[email-masked]<mailto:[email-masked]>>;
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "'DetNet Chairs'" <[email-masked]<mailto:[email-masked]>>;
Sent: 2020-06-03 (수) 20:30:42 (UTC+09:00)
Subject: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Hi,

I don't see support in the document for having a single service send different S-Labels, for the *same* service, on two different member flows.  Nor do I see support for a single service being split into two services in the current document without an A-Label (and pop operation).  I'm not saying it's not possible, but rather that neither are part of the current definition.  Of course, I may have missed something in the text.

    Can you point to where you see these S-Label operations being allowed for in the current document?

Thank you,

Lou

(as contributor)

_______________________________________________ detnet mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/detnet
[https://gov-dooray.com/mail-receipts?img=5453394e2f426276-255f338911948417-264b35988a5da498-264b3a3b2a909f0d.gif]

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Fri, 05 Jun 2020 11:33:02 +0900 (KST)

Dear Bala'zs,&nbsp;

Thank you for your email. It is good to confirm that the figure is intended to be supported.

In the same section, the following sentence states that only a single S-Label value can be used for a signle app-flow, which might have multiple member flows. Since the S-Label value is assigned by a "receiver," one might think that current document can only support the cases that relay nodes do not perform the replication function. &nbsp;&nbsp;
"The S-Label value MUST be provisioned per app-flow via configuration,&nbsp;e.g., via the controller plane described in [I-D.ietf-detnet-data-plane-framework]." 
I guess that you would see the aforementioned sentence in the scope of the receiver.
&nbsp;
From Lou's email, I guess that I am not the only person who reads the document differently from your intention.

Since we, as a group, are not changing any behavior already defined in the document, but are making it clearer, would you mind if you add the text you wrote in your email to the draft? Specifically, &nbsp; &nbsp;
"If a node performs replication there will be multiple outgoing DetNet member flows.&nbsp;
If these member flows have separate “receivers” their S-label&nbsp;values
may be different. Label allocation solutions are out-of-scope in this document."

Best regards,

Jeong-dong

-----Original Message-----
From: "Balázs Varga A" &lt;[email-masked]&gt;
To: "[email-masked]" &lt;[email-masked]&gt;; "DetNet WG" &lt;[email-masked]&gt;; "Lou Berger" &lt;[email-masked]&gt;;
Cc: "[email-masked]" &lt;[email-masked]&gt;; "'DetNet Chairs'" &lt;[email-masked]&gt;;
Sent: 2020-06-04 (목) 22:04:28 (UTC+09:00)
Subject: RE: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Hi Jeong-dong,
&nbsp;
I cannot agree with your conclusion. DetNet MPLS data plane document DOES support Figure 1 of RFC 8655.
&nbsp;
Section “4.2.2. S-Labels” states explicitly how to use the S-label field.
&nbsp;
&nbsp; &nbsp;... &nbsp;MPLS-aware DetNet end systems and&nbsp;edge nodes, which are
&nbsp; &nbsp;by definition MPLS ingress and egress nodes,&nbsp;MUST add&nbsp;and remove an
&nbsp; &nbsp;app-flow specific d-CW and&nbsp;S-Label.&nbsp;
&nbsp;
&nbsp; &nbsp;... &nbsp;Note that&nbsp;S-Labels provide
&nbsp; &nbsp;app-flow&nbsp;identification at&nbsp;the downstream DetNet service sub-layer
&nbsp; &nbsp;receiver, not the sender. &nbsp;As such,&nbsp;S-Labels MUST be allocated by&nbsp;the
&nbsp;&nbsp; entity that controls the service sub-layer receiving node's label&nbsp;&nbsp; space ... &nbsp;&nbsp;
So, the edge node have to add an S-Label to the outgoing DetNet flow packet and the value of the
S-Label is defined by the receiver. So, if edge node performs replication there will be multiple
outgoing DetNet member flows. If these member flows have separate “receiver” they S-label
may be different. Label allocation solutions are out-of-scope in this document.
&nbsp;
External nodal behavior fully defined, how it is implemented inside the box is up to implementation.
I hope that has clarified your concerns.
&nbsp;
Thanks &amp; Cheers
Bala’zs
&nbsp;
&nbsp;
From: [email-masked] &lt;[email-masked]&gt;Sent: Thursday, June 4, 2020 6:42 AMTo: Balázs Varga A &lt;[email-masked]&gt;; DetNet WG &lt;[email-masked]&gt;; Lou Berger &lt;[email-masked]&gt;Cc: [email-masked]; 'DetNet Chairs' &lt;[email-masked]&gt;Subject: RE: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655
&nbsp;
Lou,&nbsp;

&nbsp;

I don't see, either.

&nbsp;

Do you agree?

&nbsp;

Best regards,

&nbsp;

Jeong-dong

&nbsp;

&nbsp;

&nbsp;

&nbsp;

&nbsp;

-----Original Message-----

From: "Lou Berger" &lt;[email-masked] mailto:[email-masked]&gt;

To: "Balázs Varga A" &lt;[email-masked] mailto:[email-masked]&gt;; "[email-masked] mailto:[email-masked]" &lt;[email-masked] mailto:[email-masked]&gt;; "DetNet WG" &lt;[email-masked] mailto:[email-masked]&gt;;

Cc: "[email-masked] mailto:[email-masked]" &lt;[email-masked] mailto:[email-masked]&gt;; "'DetNet Chairs'" &lt;[email-masked] mailto:[email-masked]&gt;;

&nbsp;

Hi,

&nbsp;&lt;Balazs&gt; That is an internal implementation question, what we do not intend to define.  You may implement replication before S-label swap. Order of functions in a given &nbsp; implementation is out-of-scope for the draft.
_______________________________________________ detnet mailing list [email-masked] mailto:[email-masked] &nbsp;https://www.ietf.org/mailman/listinfo/detnet https://www.ietf.org/mailman/listinfo/detnet

&nbsp;

---

From: Balázs Varga A <[email-masked]>
Date: Fri, 5 Jun 2020 14:28:40 +0000

Hi Jeong-dong,

Ok, thanks for the clarification. I think even with your interpretation of the document
(i.e., having the same egress S-Label after replication) Figure 1 of RFC 8655 is supported.
It requires proper label allocation to work, but label allocation rules are out-of-scope in
the document.

I have sympathy with your proposed changes, but I am not sure whether it triggers further
changes in the document.

Any comments from the group is welcome.

Thanks & Cheers
Bala’zs

From: [email-masked] <[email-masked]>
Sent: Friday, June 5, 2020 4:33 AM
To: DetNet WG <[email-masked]>; Lou Berger <[email-masked]>; Balázs Varga A <[email-masked]>
Cc: [email-masked]; 'DetNet Chairs' <[email-masked]>
Subject: RE: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Dear Bala'zs,

In the same section, the following sentence states that only a single S-Label value can be used for a signle app-flow, which might have multiple member flows. Since the S-Label value is assigned by a "receiver," one might think that current document can only support the cases that relay nodes do not perform the replication function.
"The S-Label value MUST be provisioned per app-flow via configuration,
 e.g., via the controller plane described in [I-D.ietf-detnet-data-plane-framework]."
I guess that you would see the aforementioned sentence in the scope of the receiver.

Since we, as a group, are not changing any behavior already defined in the document, but are making it clearer, would you mind if you add the text you wrote in your email to the draft? Specifically,
"If a node performs replication there will be multiple outgoing DetNet member flows.
If these member flows have separate “receivers” their S-label values
may be different. Label allocation solutions are out-of-scope in this document."

Best regards,

Jeong-dong

-----Original Message-----
From: "Balázs Varga A" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "DetNet WG" <[email-masked]<mailto:[email-masked]>>; "Lou Berger" <[email-masked]<mailto:[email-masked]>>;
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "'DetNet Chairs'" <[email-masked]<mailto:[email-masked]>>;
Sent: 2020-06-04 (목) 22:04:28 (UTC+09:00)
Subject: RE: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Hi Jeong-dong,

   space ...

Thanks & Cheers

Bala’zs

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 4, 2020 6:42 AM
To: Balázs Varga A <[email-masked]<mailto:[email-masked]>>; DetNet WG <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 'DetNet Chairs' <[email-masked]<mailto:[email-masked]>>
Subject: RE: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Lou,

I don't see, either.

Do you agree?

Best regards,

Jeong-dong

-----Original Message-----

Hi,

Thank you,

Lou

(as contributor)

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

[https://gov-dooray.com/mail-receipts?img=444c4d7a48395531-255f338911948417-264d77cd28e33eb1-264d924eb9d2a9d4.gif]

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 Jun 2020 15:28:10 -0700

Hi Jeong-dong,
thank you for your detailed analysis of the replication function impact on
S-Label. I've followed the discussion and I think that I agree with Balazs'
interpretation of the text. In my opinion, Section 4.2.2
<https://tools.ietf.org/html/draft-ietf-detnet-mpls-05#section-4.2.2> points
to the scenario you've brought up for the discussion, i.e., processing of a
DetNEt flow by a transit DetNet node when replicating a DetNet packet as
part of PREOF. In the draft has been noted that:

Relay nodes MAY swap S-Label values when processing an app-flow.

I understand this sentence that each DetNet packet processed by a relay
node, which is the node performing replication function, MAY swap the
ingress S-Label to a different S-Label for each copy. What do you think?

Regards,
Greg

On Thu, Jun 4, 2020 at 7:39 PM Jeong-dong Ryoo <[email-masked]> wrote:

> In the same section, the following sentence states that only a single
> S-Label value can be used for a signle app-flow, which might have multiple
> member flows. Since the S-Label value is assigned by a "receiver," one
> might think that current document can only support the cases that relay
> nodes do not perform the replication function.
> From Lou's email, I guess that I am not the only person who reads the
> document differently from your intention.
>
> Since we, as a group, are not changing any behavior already defined in the
> document, but are making it clearer, would you mind if you add the text you
> wrote in your email to the draft? Specifically,
> From: "Balázs Varga A" <[email-masked]>
> To: "[email-masked]" <[email-masked]>; "DetNet WG" <[email-masked]>;
> "Lou Berger" <[email-masked]>;
> Cc: "[email-masked]" <
> [email-masked]>; "'DetNet Chairs'" <
> [email-masked]>;
> *From:* [email-masked] <[email-masked]>
> *Sent:* Thursday, June 4, 2020 6:42 AM
> *To:* Balázs Varga A <[email-masked]>; DetNet WG <
> [email-masked]>; Lou Berger <[email-masked]>
> *Cc:* [email-masked]; 'DetNet Chairs' <
> [email-masked]>
> *Subject:* RE: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes
> as shown in Figure 1 of RFC 8655
>
>
>
> Lou,
>
>
>
> If no new text on different S-Labels is added, my conclusion seems that
> current DetNet MPLS data plane document does NOT support Figure 1 of RFC
> 8655.
>
> Do you agree?
>
>
>
> Best regards,
>
>
>
> Jeong-dong
>
>
>
>
>
>
>
>
>
>
>
> From: "Lou Berger" <[email-masked]>
>
> To: "Balázs Varga A" <[email-masked]>; "[email-masked]" <
> [email-masked]>; "DetNet WG" <[email-masked]>;
>
> Cc: "[email-masked]" <
> [email-masked]>; "'DetNet Chairs'" <
> [email-masked]>;
>
> I have another issue related to our current discussion. Current MPLS data
> plane document seems to assume that only one S-Label value is used for all
> duplicated packets during replication process. Considering the fact that
> S-Labels are local to each node and advertised to its upstream nodes, an
> edge or relay node that performs the packet replication may push different
> S-Label values for different outgoing duplicates. In Figure 1 of RFC 8655
> (DetNet Architecture), when the right-most node and two middle relay nodes
> assign different S-Label values, the left-most node, which generates
> duplicates towards two relay nodes, would have to push different S-Labels
> for different relay nodes.
>
> In order to make a clarification on this issue, I would like to propose to
> add following text after the second sentence of the third paragraph in
> Section 4.2.3.1:
>
> need to cover the situation that S-Label value of one outgoing copy can be
> different from that of the other outgoing copy if those two copies are
> forwarded to two different relay nodes.
>
> different S-Labels, for the *same* service, on two different member flows.
> Nor do I see support for a single service being split into two services in
> the current document without an A-Label (and pop operation).  I'm not
> saying it's not possible, but rather that neither are part of the current
> definition.  Of course, I may have missed something in the text.
>
> _______________________________________________ detnet mailing list
> [email-masked]  https://www.ietf.org/mailman/listinfo/detnet
> <https://www.ietf.org/mailman/listinfo/detnet>
>
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: Jeong-dong Ryoo <[email-masked]>
Date: Thu, 11 Jun 2020 17:10:09 +0900 (KST)

Greg, thank you for your email.

I agree with you on that current text on the swap operatin can do the job for relay nodes.

However, if we consider an edge node, which does not perform swap operation, I don't see any text that indicates different S-Labels can be pushed on different member flows for the same sevice in the edge node. The text I quoted from the draft, "The S-Label value MUST be provisioned per app-flow via configuration ...,"&nbsp;tells me that a single S-Label value is used for one app-flow. It is difficult to imagine that multiple member flows departing from an edge node can have different S-Labels.&nbsp;Unless we assign a single S-Label value to all edge and relay nodes in the network, we cannot achieve the support of Figure 1.

I hope a DetNet MPLS data plane solution does not mandate the use of the same S-Label value in all the edge and relay nodes in the network.

Best regards,

Jeong-dong

&nbsp; &nbsp;

&nbsp; &nbsp;

-----Original Message-----
From: "Greg Mirsky" &lt;[email-masked]&gt;
To: "Jeong-dong Ryoo" &lt;[email-masked]&gt;;
Cc: "DetNet WG" &lt;[email-masked]&gt;; "Lou Berger" &lt;[email-masked]&gt;; "Balázs Varga A" &lt;[email-masked]&gt;; "[email-masked]" &lt;[email-masked]&gt;; "DetNet Chairs" &lt;[email-masked]&gt;;
Sent: 2020-06-09 (화) 07:28:30 (UTC+09:00)
Subject: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Hi&nbsp;Jeong-dong,thank you for your detailed analysis of the replication function impact on S-Label. I've followed the discussion and I think that I agree with Balazs' interpretation of the text. In my opinion, Section 4.2.2 https://tools.ietf.org/html/draft-ietf-detnet-mpls-05#section-4.2.2 points to the scenario you've brought up for the discussion, i.e., processing of a DetNEt flow by a transit DetNet node when replicating a DetNet packet as part of PREOF. In the draft has been noted that:
Relay nodes MAY swap S-Label values when processing an app-flow.
I understand this sentence that each DetNet packet processed by a relay node, which is the node performing replication function, MAY swap the ingress S-Label to a different S-Label for each copy. What do you think?
Regards,
Greg

On Thu, Jun 4, 2020 at 7:39 PM Jeong-dong Ryoo &lt;[email-masked] mailto:[email-masked]&gt; wrote:
Dear Bala'zs,&nbsp;

Best regards,

Jeong-dong

-----Original Message-----
From: "Balázs Varga A" &lt;[email-masked] mailto:[email-masked]&gt;
To: "[email-masked] mailto:[email-masked]" &lt;[email-masked] mailto:[email-masked]&gt;; "DetNet WG" &lt;[email-masked] mailto:[email-masked]&gt;; "Lou Berger" &lt;[email-masked] mailto:[email-masked]&gt;;
Cc: "[email-masked] mailto:[email-masked]" &lt;[email-masked] mailto:[email-masked]&gt;; "'DetNet Chairs'" &lt;[email-masked] mailto:[email-masked]&gt;;
Sent: 2020-06-04 (목) 22:04:28 (UTC+09:00)
Subject: RE: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655

Hi Jeong-dong,
&nbsp;
From: [email-masked] mailto:[email-masked] &lt;[email-masked] mailto:[email-masked]&gt;Sent: Thursday, June 4, 2020 6:42 AMTo: Balázs Varga A &lt;[email-masked] mailto:[email-masked]&gt;; DetNet WG &lt;[email-masked] mailto:[email-masked]&gt;; Lou Berger &lt;[email-masked] mailto:[email-masked]&gt;Cc: [email-masked] mailto:[email-masked]; 'DetNet Chairs' &lt;[email-masked] mailto:[email-masked]&gt;Subject: RE: Re: [Detnet] Support of FREOF in DetNet MPLS relay nodes as shown in Figure 1 of RFC 8655
&nbsp;
Lou,&nbsp;

&nbsp;

I don't see, either.

&nbsp;

Do you agree?

&nbsp;

Best regards,

&nbsp;

Jeong-dong

&nbsp;

&nbsp;

&nbsp;

&nbsp;

&nbsp;

-----Original Message-----

&nbsp;

Hi,

In order to make a clarification on this issue, I would like to propose to add following text after the second sentence of the third paragraph in Section 4.2.3.1 http://4.2.3.1:

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