Re: [Detnet] Transport sub-layer name change (Was Re: Tsvart last call review of draft-ietf-detnet-architecture-08)

Greg Mirsky <gregimirsky@gmail.com> Fri, 07 December 2018 18:10 UTC

Return-Path: <gregimirsky@gmail.com>
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 B3231130F78; Fri, 7 Dec 2018 10:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=ham 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 Q77JT2tUopiM; Fri, 7 Dec 2018 10:10:41 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 A1972130F7F; Fri, 7 Dec 2018 10:10:40 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id 83-v6so4304157ljf.10; Fri, 07 Dec 2018 10:10:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c83ptpXpNwhysJmoVFFCrNPwXXYkNaMhbn3n32Hmuu4=; b=RseGB+QZCxBPRjy9x5bloRe15rLwUJeFqpGBV60NhV7ch1NkOm6cJ82NKxKjW9vL+4 yepdywdEQS40O4pXxI9pJ/k9tk/uOofUA5cgQ/Taql3WznTgYq1QWKkx5KhDygHNYcpO /tBC0lM2oW3s69ACkVo2gQFVEfbqOMsPv59Shn1jpY/X+yQXiXjwqRgYeCAAvkUfPvs2 2zbErZOnlvtHfZi8OygcRX3v1cItElk4sOR7HCmiqnfxgXnWZZgdrnq0UOEP2/dnNGyV SXMW060ubZit8eGVjJabALaF14KKxVcofERzd0xRc1mukpZ/KJC1R4xE59MJnDgAi7qi 28uQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c83ptpXpNwhysJmoVFFCrNPwXXYkNaMhbn3n32Hmuu4=; b=dy7/jQSskhu0YHMT2K39tRsrqE4gLEKOgGev+LUAW8s172KDykwSfGaliEJ5IugNqz OufQ/rFiVx4L4/4BGkwjeSP6mycR1jd/XFK+IxA6EGOrGnptKsPSB0xtixft5TJE6kBs uViStFScxYRdSJvf+IXy+vAnppJ7jr5qU4AGNUcj0GW2lpWGDNcI7TtO3JqH5T03owQQ VVwqX6rruWm9/D7farM5GFWQ30cvE4SEKuqF2HjOVPHXab+1U2oSWJ8wdgI6Dxzq289f vxsPnhFqxt0w204Wi1JWXAhEvTIYiyzgUE/jUwvOX3qUwTW9DQ2o4fSkB5rI9hkiUzhW nILg==
X-Gm-Message-State: AA+aEWbsTysevTeLnvhlvBxCWQkWO5ZknINY1JDMaV3XdbcXFe5HYR1e pc7KWIweR9PSoDv64SbWpKUvOfpWgSjYiJ28x2M=
X-Google-Smtp-Source: AFSGD/Wf3KuxJENZ1W1PeaYIv3tRF0VNpspoP3A94VIJmFzw003kuycNZRohW6NYdHDkFB0zahkM6O9KdWs2z74fAWc=
X-Received: by 2002:a2e:4819:: with SMTP id v25-v6mr2110657lja.2.1544206238545; Fri, 07 Dec 2018 10:10:38 -0800 (PST)
MIME-Version: 1.0
References: <153817345967.27205.135001179751151278@ietfa.amsl.com> <fdf872d6-08a6-2c33-de21-9dd1506c1d21@labn.net> <6EC6417807D9754DA64F3087E2E2E03E2D16A4D3@rznt8114.rznt.rzdir.fht-esslingen.de> <e38ab4d6-0924-ab60-b1dc-4ac26600044c@labn.net> <16c050e436f342bb94b1ec9d1a38da3e@XCH-RCD-001.cisco.com> <3adfa63a-e6de-b899-f7ce-79d8f668d40f@labn.net> <dfea900c1cb54ee88a953f22a9c7e639@XCH-RCD-001.cisco.com> <BL0PR06MB4548D6E06909D74F227C84E6C4D90@BL0PR06MB4548.namprd06.prod.outlook.com> <CAA=duU3uw2kb1cMT9ys-WQ23=VDhOm3YO+rC1pbmksNC5pRcVQ@mail.gmail.com> <2086b964-4115-21b4-00d1-079f22d0a399@labn.net> <38afc693-1a98-50e4-907a-6cc5ec178ac6@ericsson.com> <e0196813-7647-1d14-5c82-3cd0786a099e@labn.net> <CAA=duU3Moyccof4HNa5AGQZfMnqh9T58aKzAo4BcABudYdEW+g@mail.gmail.com>
In-Reply-To: <CAA=duU3Moyccof4HNa5AGQZfMnqh9T58aKzAo4BcABudYdEW+g@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 07 Dec 2018 10:10:28 -0800
Message-ID: <CA+RyBmUfYcd5VwOwsqcGm1wNWRyMH0ihENaX7U0DAJ2fhosLuw@mail.gmail.com>
To: "Andrew G. Malis" <agmalis@gmail.com>
Cc: Lou Berger <lberger@labn.net>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Michael.Scharf@hs-esslingen.de, draft-ietf-detnet-architecture.all@ietf.org, János Farkas <janos.farkas@ericsson.com>, "Grossman, Ethan A." <eagros@dolby.com>, DetNet WG <detnet@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004efcc4057c728860"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/hOQU3gQCvviHqO2ngJzdGlc7ZS0>
Subject: Re: [Detnet] Transport sub-layer name change (Was Re: Tsvart last call review of draft-ietf-detnet-architecture-08)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2018 18:10:44 -0000

Dear All,
my first choice would be "DetNet Transport Network sub-layer" but would
agree with "DetNet Forwarding sub-layer".
On a side note, for the sake of completeness, we may add SRv6 to the list
in Figure 4 and refer to SR over MPLS data plane as SR-MPLS.

Regards,
Greg

On Fri, Dec 7, 2018 at 9:49 AM Andrew G. Malis <agmalis@gmail.com> wrote:

> I also support DetNet Forwarding sub-layer. Unlike Lou, I've always
> regarded queuing as a fundamental part of an overall forwarding
> architecture.
>
> Cheers,
> Andy
>
>
> On Fri, Dec 7, 2018 at 11:13 AM Lou Berger <lberger@labn.net> wrote:
>
>> Hi,
>>
>> Focusing on the proposal:
>>
>> > In order to have another alternative on the table I propose renaming
>> > "DetNet Transport sub-layer" to "DetNet Forwarding sub-layer"
>> This is a bit of a new usage for 'Forwarding' but not totally --
>> thinking about FIBs.  My main reservation is that forwarding is usually
>> considered separately from queuing, while this sub-layer embodies both.
>> I do accept that TE usually considers both forwarding/steering and
>> queuing, and that some assume that sophisticated queuing is required for
>> TE -- which is actually service dependent.
>>
>> Even with this caveat and my personal preference for the 'TE' option, I
>> (as contributor) can live with "DetNet Forwarding sub-layer".
>>
>> Lou
>>
>> On 12/7/2018 10:45 AM, János Farkas wrote:
>> > Hi,
>> >
>> > I have a similar concern with the change. It of course depends on the
>> > definition of Traffic Engineering, but the term "DetNet TE sub-layer"
>> > may imply to the reader that Traffic Engineering is a must even for
>> > DetNet transit nodes. As far as I recall, the intention is to make
>> > possible that DetNet transit nodes can be kept simple. Depending on the
>> > actual DetNet service provided, DetNet transit nodes can be actually
>> simple.
>> >
>> > The idea behind the introduction of the two DetNet sub-layers was to
>> > make it easier to tackle the problem. The lower layer provides simpler
>> > packet forwarding related functions, the higher DetNet Service sub-layer
>> > provides more complex DetNet service related functions.
>> >
>> > In order to have another alternative on the table I propose renaming
>> > "DetNet Transport sub-layer" to "DetNet Forwarding sub-layer"
>> >
>> > Best regards,
>> > Janos
>> >
>> >
>> > On 11/20/2018 10:10 PM, Lou Berger wrote:
>> >> On 11/20/2018 3:11 PM, Andrew G. Malis wrote:
>> >>> This terminology is certainly appropriate for TEAS. For DetNet, this
>> >>> seems to make the assertion that the DetNet underlay is always
>> >>> traffic-engineered, even if IPv4 or IPv6 (which is certainly possible
>> >>> using TE extensions for the IGPs).
>> >> This is certainly a fair point and one that does lead me to have a
>> >> slight reservation about the change, that said, it seems the benefit
>> >> out ways the downsides.
>> >>
>> >>> As long as people are OK with this assertion, then I'm OK with it as
>> >>> well. That should be made clear in the architecture spec where the
>> >>> term "DetNet TE sub-layer" is introduced/defined.
>> >> agreed.
>> >>
>> >> Lou
>> >>
>> >>> Cheers,
>> >>> Andy
>> >>>
>> >>> On Tue, Nov 20, 2018 at 1:29 PM Grossman, Ethan A. <eagros@dolby.com
>> >>> <mailto:eagros@dolby.com>> wrote:
>> >>>
>> >>>      I like it.
>> >>>      Ethan.
>> >>>
>> >>>      -----Original Message-----
>> >>>      From: Pascal Thubert (pthubert) <pthubert@cisco.com
>> >>>      <mailto:pthubert@cisco.com>>
>> >>>      Sent: Tuesday, November 20, 2018 10:27 AM
>> >>>      To: Lou Berger <lberger@labn.net <mailto:lberger@labn.net>>;
>> >>>      Scharf, Michael <Michael.Scharf@hs-esslingen.de
>> >>>      <mailto:Michael.Scharf@hs-esslingen.de>>
>> >>>      Cc: detnet@ietf.org <mailto:detnet@ietf.org>;
>> >>>      draft-ietf-detnet-architecture.all@ietf.org
>> >>>      <mailto:draft-ietf-detnet-architecture.all@ietf.org>
>> >>>      Subject: RE: Transport sub-layer name change (Was Re: [Detnet]
>> >>>      Tsvart last call review of draft-ietf-detnet-architecture-08)
>> >>>
>> >>>      I support this change;
>> >>>
>> >>>      Pascal
>> >>>
>> >>>      > -----Original Message-----
>> >>>      > From: Lou Berger <lberger@labn.net <mailto:lberger@labn.net>>
>> >>>      > Sent: mardi 20 novembre 2018 19:19
>> >>>      > To: Pascal Thubert (pthubert) <pthubert@cisco.com
>> >>>      <mailto:pthubert@cisco.com>>; Scharf, Michael
>> >>>      > <Michael.Scharf@hs-esslingen.de
>> >>>      <mailto:Michael.Scharf@hs-esslingen.de>>
>> >>>      > Cc: detnet@ietf.org <mailto:detnet@ietf.org>;
>> >>>      draft-ietf-detnet-architecture.all@ietf.org
>> >>>      <mailto:draft-ietf-detnet-architecture.all@ietf.org>
>> >>>      > Subject: Transport sub-layer name change (Was Re: [Detnet]
>> >>>      Tsvart last
>> >>>      > call review of draft-ietf-detnet-architecture-08)
>> >>>      >
>> >>>      > ALL,
>> >>>      >
>> >>>      > There is a desire to replace the word "Transport" from the
>> DetNet
>> >>>      > Transport sub-layer to avoid confusion with L$ Transport
>> >>> protocols.
>> >>>      >
>> >>>      > In the TEAS WG we had a similar discussion and we replaced
>> >>>      "Transport"
>> >>>      > with "Traffic Engineered (TE) ".
>> >>>      >
>> >>>      > While a bit more verbose, what do people think about this
>> change?
>> >>>      >
>> >>>      > To be clear, the suggestion is:
>> >>>      >
>> >>>      > OLD
>> >>>      >
>> >>>      >                     .
>> >>>      >                     .
>> >>>      >       +----------------------------+
>> >>>      >       |  DetNet Service sub-layer  | PW, UDP, GRE
>> >>>      >       +----------------------------+
>> >>>      >       | DetNet Transport sub-layer | IPv6, IPv4, MPLS TE LSPs,
>> >>>      MPLS SR
>> >>>      >       +----------------------------+
>> >>>      >                     .
>> >>>      >                     .
>> >>>      >
>> >>>      >                   Figure 4: DetNet adaptation to data plane
>> >>>      >
>> >>>      > NEW
>> >>>      >
>> >>>      >                     .
>> >>>      >                     .
>> >>>      >       +----------------------------+
>> >>>      >       |  DetNet Service sub-layer  | PW, UDP, GRE
>> >>>      >       +----------------------------+
>> >>>      >       |      DetNet TE sub-layer   | IPv6, IPv4, MPLS TE LSPs,
>> >>>      MPLS SR
>> >>>      >       +----------------------------+
>> >>>      >                     .
>> >>>      >                     .
>> >>>      >
>> >>>      >                   Figure 4: DetNet adaptation to data plane
>> >>>      >
>> >>>      > Lou
>> >>>
>> >> _______________________________________________
>> >> detnet mailing list
>> >> detnet@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/detnet
>> >
>>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet
>