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

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

Hello Bala’zs

I understand the value of reusing building MPLS blocks when the end-to-end path may use a mix of IP and MPLS, so yes, I see the value in your approach. This way a single method is used end-to-end. My first question below was then, why not describe how to use RFC 7510 for DetNet; this would seem an even faster path to build converged DetNet (IP + MPLS) networks. I have not seen in your answer the value of not simply doing simply that. The point within the point being that in the case of a pure IPv6 network, it would be sad to have to live with the MPLS limitations.

I listed the limitations that I’d rather live without in my questions, that are found appended below.
In summary:
- The format of labels that is not self-describing, so finding and processing errors can be harder. Anything can reach a node over UDP.
- The format of the labels does not support a number of functions like, say, network coding where the same sequence is split in multiple sub packets that can be received in any order and must not be eliminated unless identical
- The UDP encapsulation that forces the hardware to dig deep in the packet, which comes at a cost for the ASIC.
- The forwarding decision is based on the flow using the 5/6 tuple. The flow is the application view, saying what the packet is, when what we need is routing information, that is the network view, saying what to do with this packet. This is confusing the water with the pipe and causes all the hassle we see with OAM, but also aggregation downstream in the network
- Then there’s the cost of that aggregation, which has to  end up UDP in UDP, since “flows” are merged in a bigger “flow”.

I’d like to see the minimum addition to RFC 7510 and then a real IPv6-native proposal. To Lou’s point, an MPLS stack will be a hard sell to RAW, and that’s not only RAW. It’s unclear to me whether MPLS would be needed and successful in other DetNet use cases such as factory Automation, Pro Audio, or cloud. I think both need to progress, one MPLS-friendly for SP networks, and one more generic and IPv6-native one for new use cases.

Makes sense?

Pascal


From: Balázs Varga A <balazs.a.varga=[e-mail]>
Sent: mercredi 4 août 2021 12:11
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]
Subject: RE: [Detnet] draft-varga-detnet-ip-preof

Hi Pascal,

Many thanks for the new comments.

Yes, forwarding between relay nodes (doing service sub-layer) is based on the 6-tuple.
Aggregated flows use the same UDP tunnel as defined in Section “4.4. Flow Aggregation”.

Regarding your concerns using UDP: It is the same for all UDP encapsulations. We have
not changed the rules of RFC9025, this draft reuses existing DetNet data plane building
blocks. :--)) It provides DetNet service sub-layer for IP with minimal effort (i.e., minimal
standardization and implementation effort). No new header fields are specified. It is a
generic IP solution, already available both for IPv6 and IPv4. And it does not require any
additional processing on transit nodes.

Thanks & Cheers
Bala’zs

From: Pascal Thubert (pthubert) <pthubert=[e-mail]<mailto:pthubert=[e-mail]>>
Sent: Monday, July 26, 2021 11:18 PM
To: Balázs Varga A <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Detnet] draft-varga-detnet-ip-preof

Hello Bala’zs

Many thanks for the clarification; I expected that the aggregation label would signal a common path but from your response it seems the draft still relies on the flow to find the path, based on the 5/6 tuple, correct ?
<BV> Yes, forwarding between relay nodes (doing service sub-layer) is based on the 6-tuple. Aggregated flows use the same UDP tunnel.


My bottom line stands though. Aggregation and PREOF may happen inside the network. And it means encapsulation. Going all the way to UDP will make the header to insert and read bigger.
<BV> Yes, this is the same for all UDP encapsulations.

 I understand now that you place only service layer information in there, but that still needs to happen at wire speed, and bigger headers can be counter productive for DetNet tput and latency, and be more complicated to implement in hardware.
<BV> We have not changed the rules of RFC9025, this draft reuses existing DetNet data plane building blocks. :--)) Scalability and aggregation


Do I miss anything ?

Pascal

Le 26 juil. 2021 à 23:00, Balázs Varga A <balazs.a.varga=[e-mail]<mailto:balazs.a.varga=[e-mail]>> a écrit :


Hi Pascal,

Many thanks for the clarification questions.

Please see my comments inline.

Cheers

Bala'zs





-----Original Message-----
From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 26, 2021 4:00 PM
To: Janos Farkas <[e-mail]<mailto:[e-mail]>>; Balázs Varga A <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: draft-varga-detnet-ip-preof



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?

<BV> No, this draft is not about putting the MPLS data plane into UDP.

This draft is about how to provide PREOF for the DetNet IP data plane in a simple way, with no new header or data plane definition; but leveraging existing ones. That’s why it is informational.

That is, this draft leverages RFC 9025, which leverages RFC 7510. It is applicable both to IPv4 and IPv6.

Key point in this draft is that DetNet PW (S-Label + d-CW) is placed in UDP. It is very important that there is *NO* label switching along the path.



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

<BV> No, the DetNet PW information is used only at relay nodes (as per rfc8655 those includes DetNet service sub-layer). Intermediate nodes (transit nodes) do not need service sub-layer specific information, so they do not need find anything “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?

<BV> As the DetNet PW information is used only by relay nodes, they know by configuration of the service sub-layer (e.g., PREOF) how to process the packet. From service sub-layer perspective it is the same concept used in rfc8964.



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

<BV> Aggregation just works fine. Any relay node can perform aggregation as UDP tunnels are span between relay nodes.



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?

<BV> Again, the DetNet PW information is used only at relay nodes (doing service sub-layer). Intermediate nodes (transit nodes) do not need service sub-layer specific information and do not “add and remove stuff”. Aggregation and the DetNet service reference model just works fine with this solution, which just (re)uses existing DetNet data plane.



Pascal


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