From nobody Fri Nov 12 19:46:07 2021 Return-Path: X-Original-To: detnet@ietfa.amsl.com Delivered-To: detnet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7613A102E for ; Fri, 12 Nov 2021 19:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.903 X-Spam-Level: ** X-Spam-Status: No, score=2.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWLxSQIxy4Ho for ; Fri, 12 Nov 2021 19:46:00 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6613F3A102C for ; Fri, 12 Nov 2021 19:46:00 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id c8so45106546ede.13 for ; Fri, 12 Nov 2021 19:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cfbzwiIzoz/PnLg2SQGTYqtEcj2uGPK+kSsety/pb0c=; b=a4jj4GMpXx+tlGGZB0WKzV77cBmqfP90H3HOeUYjQLHaXOOrMKats6bl4UcnFFY/Wt a9/GcLMyxr91wXIoZ1vW+Z/YzvCnXxZg7fSiuLh4FNnufpCjnRrvb8ACS4/qVYHFHIw3 j/1NNNjrC5GRh+hBa37jk0Dxo5ud0i2PTfpbED+iQ5iO0QAsArmAbADKJD5IR72g0JNz 483JQ0oPOYGJqPDJWnQwZ6zjsd9OV3Q6MWfjpjtxk4eoszBKwcGvOqGnaXcT7bDy3LqT kNN7f/0WO/TqL0tM3i53xKWq0qN+oCwDaL6tUe4vOY7sCkj6a30WqKjzmUYrGNlKSpwa iUKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cfbzwiIzoz/PnLg2SQGTYqtEcj2uGPK+kSsety/pb0c=; b=coZ0GBt6hBBoUaCxdrkx+G7Yh6BlZ94y60bag55REougVplQeqz3xoTy9U/8JjSxr+ mtog7FPJvVJ3muuiLgD15LpHu9aTOumTC6XsP+MX6Igy6ZEHi1gZR3jgJmDBibSnECgZ JH2oapdBPnai5nJMPBZWzxcgPEG2g7bmD+c9AsFLsQpjeOjoG2BEfY3jskOP3xW097yt 8SMuozv0V8orH6nQz2n6ru3ESLhhucQfPdy5hOx8FRz0CNUPMjctPr7pnBZTs+tp9mq0 wXfoCt69g/6Eo6XoEqz3fG8v4ZW2U2GEiv/vyCvHeqjH4jcRzQml+pnzHP/cGjdh7wvm F9ow== X-Gm-Message-State: AOAM53276XsnMWqjbSHQADHoXJXA+wWswcpOywwhEF5zQocVyU6iuu4A OPSHIntFZVeg990cWsgjgFCs3PLzi5tzSQJZyWC3Vv6v X-Google-Smtp-Source: ABdhPJzDYT7usHg0XyEnFrr7LiiCdG5oTIy0B1AjmDvIHNXp2DqvCSMSYlxtGkBJD9vfoHJZIgvV3rXWagtxEbvHHJ4= X-Received: by 2002:a17:907:7e83:: with SMTP id qb3mr25830290ejc.469.1636775157033; Fri, 12 Nov 2021 19:45:57 -0800 (PST) MIME-Version: 1.0 References: <4B0C152D-69D0-41C4-A466-3800A8CB0B11@cisco.com> In-Reply-To: From: Greg Mirsky Date: Fri, 12 Nov 2021 19:45:45 -0800 Message-ID: To: Toerless Eckert Cc: "Pascal Thubert (pthubert)" , "Pascal Thubert (pthubert)" , "detnet@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cfed8b05d0a36918" Archived-At: Subject: Re: [Detnet] IP dataplane X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2021 03:46:06 -0000 --000000000000cfed8b05d0a36918 Content-Type: text/plain; charset="UTF-8" Hi Toerless, upon thinking it further, the Packet PW 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 wrote: > Hi Toerless, > RE: aggregation in MPLS question. > The aggregation in MPLS can be achieved using a hierarchical LSP. RFC 6107 > 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 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 >> > detnet@ietf.org >> > https://www.ietf.org/mailman/listinfo/detnet >> > >> > -- >> > --- >> > tte@cs.fau.de >> > >> > _______________________________________________ >> > detnet mailing list >> > detnet@ietf.org >> > https://www.ietf.org/mailman/listinfo/detnet >> >> -- >> --- >> tte@cs.fau.de >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >> > --000000000000cfed8b05d0a36918 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Toerless,
upon thinking it further, the Packet PW might offer a = more suitable solution for the DetNet MPLS aggregation than the hierarchica= l LSP. Yes, the Packet PW requires an extra internal Ethernet header.
=

Regards,
Greg

On Fri, Nov 12, 2021 at 6:= 56 PM Greg Mirsky <gregimirsky@= gmail.com> wrote:
Hi Toerless,
RE: aggregation in MPLS questi= on.
The aggregation in MPLS can be achieved using a hierarchical = LSP. RFC 6107=C2=A0describes how GMPLS can be used to signal dynamic hie= rarchical LSPs. As Pascal suggested for DetNet flow aggregation=C2=A0over I= P, the aggregate must be seen and treated as a new DetNet flow.
W= hat are your thoughts?

Regards,
Greg

On Thu, Nov 11, 2021 at 2:06 PM Toerless Eckert <tte@cs.fau.de> wrote:
On Thu, Nov 11, 2021 at 09:05:21= AM +0000, Pascal Thubert (pthubert) wrote:
> We already spent quite a bit of effort on that. Would you kindly comme= nt on https://sandbox.ietf.org/do= c/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<= br> 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,
=C2=A0 =C2=A0AND information model. Where information model describes
=C2=A0 =C2=A0which variables we want, and where/how each of them needs to b= e
=C2=A0 =C2=A0examined.

b) encoding spec. Which may be as lame as an IPv6 HbH heder, or multiple, =C2=A0 =C2=A0or maybe an extension header that can be shared across IPv6 an= d future
=C2=A0 =C2=A0MPLS.

> f) Aggregation/disaggregation is i think a problem we can punt up from= IP layer
>=C2=A0 =C2=A0to overall DetNet layer. Aka: We have no architectural des= ign or solution of
>=C2=A0 =C2=A0this for MPLS AFAIK. But we would need reference scenarios= to work against them.
>
> IPv6 offers the capability to aggregate by encapsulating multiple stre= ams in one tunnel.
> The key for DetNet is that the outer tunnel must signal the needed inf= ormation for the aggregation including a new sequencing information and pac= ket treatment, independent of the inner signaling when tunnels, OAM or appl= ication flows are merged.

Sure, but how would that be fundamentally different from aggregation in MPL= S ?
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 b= e 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
=C2=A0 =C2=A0 Toerless
>
> Keep safe,
>
> Pascal
>
> Cheers
>=C2=A0 =C2=A0 Toerless
>
> On Wed, Nov 10, 2021 at 01:48:29PM +0000, Pascal Thubert (pthubert) wr= ote:
> Thanks to both Lou and David for rewording very correctly what I was t= rying to say at the meeting today.
>
> Effectively, the question is whether we need for a pure IP dataplane t= hat 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 t= ool. 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 si= gnaling.
> - 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 an= d 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 mergin= g, re-sourcing (for duplication and network coding), altering the destinati= on (to an intermediate elimination node) or changing packet header informat= ion (e.g., sequencing); such encapsulation will hinder with the visibility = of deep information (UDP and application data), which cannot be used for De= tNet processing
> - the elimination or decapsulation node may not be the destination, bu= t it still needs to understand the DetNet signaling; the DetNet signaling s= hould be 100% L3, fully independent of L4 and above, and should not imply t= hat the transport is USP.
> - the 5-6 tuple points on upper layer information for a flow. DetNet m= ay aggregate flows (several times leading to multiple reencapsulations) dis= aggregate flows (decapsulations and separation) and OAM packets. We want th= e information that signals the dataplane processing independent of which ap= plication flow / already merged and encasulated application flows / and or = OAM is transported.
> - it would make sense to build a solution that integrates well with IP= v6 state of the art, especially SRv6, and very possibly HbH which is gettin= g traction, see the discussion at 6MAN / v6ops on Friday.
>
> Bottom line: I disagree with adopting a document that would seem to in= dicate that we're done with IP. On the contrary I believer that there&#= 39;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
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet >
> --
> ---
> tte@cs.fau.de >
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet
--
---
tte@cs.fau.de

_______________________________________________
detnet mailing list
detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet
--000000000000cfed8b05d0a36918--