Re: [Detnet-dp-dt] Quick notes from 4/11/17 call

[Jouni Korhonen <[e-mail]>]

I have been editing the solutions draft.. I am stuck again on the “native detnet flow”. I am not too happy about having two solutions for the sequencing part. IMHO is it a already enough we have two different PSNs. What we agreed below means:

+-------------------------+
| Payload e.g. UDP or TCP |
+-------------------------+
|   SeqNum DST(?) option  | (min 8 octets) -> not seen by the application
+-------------------------+
| IPv6 (flow label for id)|
+-------------------------+
|        Data-Link        |     
+—------------------------+
|        Physical         |     
+-------------------------+


Would it be desired to do PREF on each router how? Or only on desired designated hops? For the former the seqnum would be a HBH and the latter a DST option. A destination option could be replaced by a SR option’s TLVs. However, SR option as such is a monster and I would avoid a normative reference to it. I have also some difficulty seeing how this approach would work nicely with policy routing in a deployment where there are multiple replication/elimination points in the network between end hosts. You would need something like SR option for that to work and then your packet size would explode.

Using MPLS in IP encaps for the native detnet flow:

+-------------------------+
| Payload e.g. UDP or TCP |
/-------------------------\
H        DetNet CW        H (4 octets)  -> not seen by the application
+-------------------------+
H        PW Label         H (4 octets - redundant but for the consistency) -> not seen by the application
+-------------------------+
H     Optional Labels     H (0 to 4*n octets) -> not seen by the application
\-------------------------/
| IPv6 (flow label for id)|
+-------------------------+
|        Data-Link        |     
+—------------------------+
|        Physical         |     
+-------------------------+

No difference on the minimum overheads. 

Based on the fact that both approaches need “new stuff” they would fail equivalently on non-upgraded intermediates. The application programming model for the MPLS over IP is a bit different than usual, since the final “next header” is based on the bottom of the stack label, not the next header fields. I would say it is transparent to the developer, though.

Any thoughts?

- Jouni



-- 
Jouni Korhonen, Broadcom, Core Switching Group
[phone]



> On Apr 12, 2017, at 1:35 PM, Jouni Korhonen <[e-mail]> wrote:
> 
> Present: Jouni, Janos, Balazs, David, Loa, Norm, Yuanlong
> 
> Agenda:
> * recap of the IETF98 corridor discussions & descisions
> * list of things to do
> 
> Discussion & decision:
> * Jouni sent out RFC6621 pointer for Simplified Multicast Forwarding that does duplicate detection and elimination
> * Solutions draft:
> - update the PW encapsulation i.e., no Flow-ID and incoming PW labels have to be the same to trigger the duplicate detection. 
> - IPv6 use flow label for detnet flow identification, new extension header for seqnum.
> - on IPv6 path stitching policy routing, multicast with with proper distribution tree and segment routing were discussed as possible alternatives instead of tunneling. Needs more discussion.
> - no good solution for IPv4. Just left it out. One can use PWs to transport IPv4 as a packet PW.
> - CoS/QoS update to be done. CoS is “easier” to start with.. first describe how the TC or DSCP bits need to be brought all the down to the most outer level.
> * Alternatives draft (now expired):
> - update the conclusions to state PW + IPv6 (native IP mode) are way to go. No good solution for IPv4.
> * Problem Statement:
> - Norm will ship an update.
> * Webex time will change. It will be Tuesday 6AM Pacific starting from next call.
> * solutions and alternative draft updates hopefully out this week.
> 
> Next call:
> no call next week 4/18/17.
> 
> -- 
> Jouni Korhonen, Broadcom, Core Switching Group
> [phone]
> 
> 
>