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

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

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 ?

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.

 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.

Do I miss anything ?

Pascal

Le 26 juil. 2021 à 23:00, Balázs Varga A <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]
https://www.ietf.org/mailman/listinfo/detnet