Re: [Detnet] IP dataplane

[Greg Mirsky <[e-mail]>]

Hi Toerless,
RE: aggregation in MPLS question.
The aggregation in MPLS can be achieved using a hierarchical LSP. RFC 6107
<https://www.rfc-editor.org/rfc/rfc6107.html> describes how GMPLS can be
used to signal dynamic hierarchical LSPs. As Pascal suggested for DetNet
flow aggregation over IP, the aggregate must be seen and treated as a new
DetNet flow.
What are your thoughts?

Regards,
Greg

On Thu, Nov 11, 2021 at 2:06 PM Toerless Eckert <[e-mail]> wrote:

> On Thu, Nov 11, 2021 at 09:05:21AM +0000, Pascal Thubert (pthubert) wrote:
> > We already spent quite a bit of effort on that. Would you kindly comment
> on https://sandbox.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh-06 ?
>
> wht is the teal with snadbox.ietf.org, it seems not to work for me,
> "rendering fails". Is this something for collaborative commenting/editing,
> or is there a github too ?
>
>
> As i mentioned in DetNet, i think it would be great if we could try to see
> if/how much unification across different data-planes we can get. With
> that thought in mind, it might be useful to split any work (like this
> document) into
>
> a) an encoding idependent part describing use-cases/scenarios,
>    AND information model. Where information model describes
>    which variables we want, and where/how each of them needs to be
>    examined.
>
> b) encoding spec. Which may be as lame as an IPv6 HbH heder, or multiple,
>    or maybe an extension header that can be shared across IPv6 and future
>    MPLS.
>
> > f) Aggregation/disaggregation is i think a problem we can punt up from
> IP layer
> >   to overall DetNet layer. Aka: We have no architectural design or
> solution of
> >   this for MPLS AFAIK. But we would need reference scenarios to work
> against them.
> >
> > IPv6 offers the capability to aggregate by encapsulating multiple
> streams in one tunnel.
> > The key for DetNet is that the outer tunnel must signal the needed
> information for the aggregation including a new sequencing information and
> packet treatment, independent of the inner signaling when tunnels, OAM or
> application flows are merged.
>
> Sure, but how would that be fundamentally different from aggregation in
> MPLS ?
> Which AFAIK, we have also not yet tackled in DetNet.
>
> > The trick is to determine how wider the aggregation tunnel must be vs
> the sum of inner flows to adapt the bounded latency, a problem that might
> be related to the wide area discussion.
>
> Sure, but thats not an encap issue, unless you are thinking only about
> the added packet header impact.
>
> And we also have the option to agregate even without tunneling. Just
> think about all the traffic to one destination, and you just instantice
> a per-destination traffic shaper on every hop, but let the controller
> calculate the correct shapper parameter for the aggregate at that hop.
> Not good for SP networks, but maybe for non-SP networks.
>
> Aka: I am not saying that we shouldn't figure out the information model
> for aggregation, but its a big new building block.
>
> > Enjoy the rest of the week and remember the 6MAM v6ops on Friday!
>
> Indeed!
>
> You to.
>
> Cheers
>     Toerless
> >
> > Keep safe,
> >
> > Pascal
> >
> > Cheers
> >    Toerless
> >
> > On Wed, Nov 10, 2021 at 01:48:29PM +0000, Pascal Thubert (pthubert)
> wrote:
> > Thanks to both Lou and David for rewording very correctly what I was
> trying to say at the meeting today.
> >
> > Effectively, the question is whether we need for a pure IP dataplane
> that can carry the DetNet information for Forwarding and Service sublayer.
> >
> > Arguments on the table:
> >
> > - Not all DetNet environments employ MPLS and pseudowires as a basic
> tool. Forcing such concepts beyond their domain may hinder adoption in pure
> IP (IT) and industrial (OT) spaces. A native IP solution is desirable. Note
> that IPv4 can be encapsulated in IPv6 so arguably we can live with IPv6
> signaling.
> > - Hardware operation (common ASICs) need the information very early in
> the packet. Digging after UDP may not be feasible in all cases. The DetNet
> information cannot be missed and should be very early after the IP header
> (before UDP if present).
> > - An IP solution is bound to other rules than MPLS, e.g., use of EH and
> encapsulation vs. stack of label. The properties of the solution might be
> different and IP may possibly express richer semantics. But as of now, the
> IP data plane is more limited than the MPLS one.
> > - There's a need with IPv6 to encapsulate when playing with merging,
> re-sourcing (for duplication and network coding), altering the destination
> (to an intermediate elimination node) or changing packet header information
> (e.g., sequencing); such encapsulation will hinder with the visibility of
> deep information (UDP and application data), which cannot be used for
> DetNet processing
> > - the elimination or decapsulation node may not be the destination, but
> it still needs to understand the DetNet signaling; the DetNet signaling
> should be 100% L3, fully independent of L4 and above, and should not imply
> that the transport is USP.
> > - the 5-6 tuple points on upper layer information for a flow. DetNet may
> aggregate flows (several times leading to multiple reencapsulations)
> disaggregate flows (decapsulations and separation) and OAM packets. We want
> the information that signals the dataplane processing independent of which
> application flow / already merged and encasulated application flows / and
> or OAM is transported.
> > - it would make sense to build a solution that integrates well with IPv6
> state of the art, especially SRv6, and very possibly HbH which is getting
> traction, see the discussion at 6MAN / v6ops on Friday.
> >
> > Bottom line: I disagree with adopting a document that would seem to
> indicate that we're done with IP. On the contrary I believer that there's a
> rich ground that we need to plow to deliver the best for IP networks.
> >
> > What do others think?
> >
> > Keep safe,
> >
> > Pascal Thubert
> >
> > _______________________________________________
> > detnet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet
> >
> > --
> > ---
> > [e-mail]
> >
> > _______________________________________________
> > detnet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
>