Re: [Detnet] Issue on supporting PREOF in DetNet MPLS

Stewart, thank you for sharing your opinion on this.

I totally agree with you.

Best regards,

Jeong-dong

-----Original Message-----
From: "Stewart Bryant" &lt;stewart.bryant@gmail.com&gt;
To: "Jeong-dong Ryoo" &lt;ryoo@etri.re.kr&gt;;
Cc: "Stewart Bryant" &lt;stewart.bryant@gmail.com&gt;; "DetNet WG" &lt;detnet@ietf.org&gt;; "draft-ietf-detnet-mpls.authors@ietf.org" &lt;draft-ietf-detnet-mpls.authors@ietf.org&gt;; "DetNet Chairs" &lt;detnet-chairs@ietf.org&gt;;
Sent: 2020-06-23 (화) 23:06:04 (UTC+09:00)
Subject: Re: [Detnet] Issue on supporting PREOF in DetNet MPLS

If we are following the old MS-PW design, which I think was the original intent, a DetNet node would change the S label to the S label that the receiving DetNet node was expecting. Thus if a packet was sent to node A, then sent on to node B and C, it would arrive at node A with Sa and leave with Sb and Sc respectively. That dramatically simplifies the h/w changes since it is normal in MPLS for the receiver to set the value of the label and set the processing vector accordingly. Since the sender has to so a re-write and is geared up to write multiple labels in most chip sets it should be no problem for the hardware to do this.

The MPLS architecture takes the view that in the data plan the semantics of a label are unknown and are only resolved to the intended semantic in the receiver through a mapping provided by the control plane.

Therefore it seems right to me that we should swap the S label at the DetNet processing node and that the outgoing label should the one requested by the receiver.

StewartOn 22 Jun 2020, at 09:29, Jeong-dong Ryoo &lt;ryoo@etri.re.kr mailto:ryoo@etri.re.kr&gt; wrote:
Hi, all.

During the WG virtual interim meeting in June 11, we discussed what level of change would be needed to resolve the issue on supporting PREOF in the DetNet MPLS data plane draft, and decided to start with charifying text. The issue was originally raised to clarify how DetNet MPLS data plane can support Figure 1 of RFC 8655. See https://mailarchive.ietf.org/arch/browse/detnet/?q=FREOF https://mailarchive.ietf.org/arch/browse/detnet/?q=FREOF for the email discussion. According to the minutes, https://datatracker.ietf.org/doc/minutes-interim-2020-detnet-01-202006110900/ https://datatracker.ietf.org/doc/minutes-interim-2020-detnet-01-202006110900/, the options are&nbsp;as follows:
Option 1: clarify document -- i.e., no data plane change
Option 2: modify data-plane behavior to allow edge or relay to send different s-labels (on different member flows) for same service.

Assuming the text that Balazs agreed to change for Sections 4.5.1 and 4.5.2 is in place, I don't have any additional text to propose for Option 1.

If Option 1 should be chosen, we need to be aware of that the same S-Label needs to be used for a single service in a whole DetNet domain. If S-Labels have to be determined within the scope of each DetNet egress edge node's label space, then one F-Label must be used and the F-Label values should be chosen in a way that two different services with the same S-Label can be distinguished in a DetNet relay node even if the S-Labels are assigned per plaform label space. In other words, the values of F-Labels cannot be assigned independently from the S-Label values. This extra consideration in network configuration does not exist in MS-PW, on which DetNet MPLS solution is based.&nbsp;

For option 2, as we have&nbsp;discussed in the list, I propose to add the following text:
If an edge node or a relay 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

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet