[Detnet] draft-varga-detnet-ip-preof

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

Hello Balázs, János, and Andy:

In prep for next Friday meeting I went through https://datatracker.ietf.org/doc/html/draft-varga-detnet-ip-preof-00. I have a few questions that might be too much for the mike, and considering the short time we have, I thought we should start here.
 
- At first glance the draft seems to be placing the DetNet MPLS dataplane within UDP. If that is the intention, what are the benefits vs. using RFC 7510?

- Some of the labels in there are needed at every hop to select one or more next hop(s) along the DetNet path. Can it be a problem to find that information deep inside the packet?

- There can be variations of the label stack, e.g., fig 3 vs fig 4. Are the labels self-describing? Else, how does the forwarding node know what shape of stack to expect?

- I'm concerned about the aggregation scenario. Contrary to MPLS, an IPv6 intermediate node is not allowed to insert headers, in particular not after the UDP header. So it seems that the aggregation proposed is always done at the end points. Is that correct?

Please consider the following picture from RFC 8655:

   DetNet                                                     DetNet
   End System                                                 End System
      _                                                             _
     / \     +----DetNet-UNI (U)                                   / \
    /App\    |                                                    /App\
   /-----\   |                                                   /-----\
   | NIC |   v         ________                                  | NIC |
   +--+--+   _____    /        \             DetNet-UNI (U) --+  +--+--+
      |     /     \__/          \                             |     |
      |    / +----+    +----+    \_____                       |     |
      |   /  |    |    |    |          \_______               |     |
      +------U PE +----+ P  +----+             \          _   v     |
          |  |    |    |    |    |              |     ___/ \        |
          |  +--+-+    +----+    |       +----+ |    /      \_      |
          \     |                |       |    | |   /         \     |
           \    |   +----+    +--+-+  +--+PE  |------         U-----+
            \   |   |    |    |    |  |  |    | |   \_      _/
             \  +---+ P  +----+ P  +--+  +----+ |     \____/
              \___  |    |    |    |           /
                  \ +----+__  +----+     DetNet-1    DetNet-2
      |            \_____/  \___________/                           |
      |                                                             |
      |      |     End-to-End Service         |     |         |     |
      <------------------------------------------------------------->
      |      |     DetNet Service             |     |         |     |
      |      <------------------------------------------------>     |
      |      |                                |     |         |     |

          (RFC 8655) Figure 5: DetNet Service Reference Model (Multidomain)

You'll note that the DetNet architecture allows for endpoints that are not service-aware, in which case the service layer information is logically owned by the PEs. A PE should be able to add / remove stuff that is relevant either within its domain (e.g., PREOF using SRv6 with Xuesong's SPRING draft) and / or within the DetNet Service Domain (across domains 1 and 2 above), e.g., redundancy information, excluding the End Systems which may encrypt their payload and may not provide anything usable for redundancy anyway.

As a specific example, the aggregation should be feasible between DetNet-1 egress PE and Detnet-2 ingress PE. In IPv6 this means encapsulation, and it makes sense to minimize the incremental size. UDP in UDP seems a lot doesn't it?  

My bottom line is that if we want intermediate nodes to add and remove stuff, it has to be thought in terms of matching encapsulation and decapsulation. IPv6 has EHs that are designed to fit in such encapsulation, possibly together, like an RH for replication and a HbH for path and redundancy information.

What do you think?

Pascal