Re: [Detnet] IP dataplane

[Greg Mirsky <[e-mail]>]

Hi Toerless,
upon thinking it further, the Packet PW
<https://datatracker.ietf.org/doc/html/rfc6658> might offer a more suitable
solution for the DetNet MPLS aggregation than the hierarchical LSP. Yes,
the Packet PW requires an extra internal Ethernet header.

Regards,
Greg

On Fri, Nov 12, 2021 at 6:56 PM Greg Mirsky <[e-mail]> wrote:

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