Re: [RTG-DIR] [Detnet] RtgDir review: draft-ietf-detnet-ip-04.txt

Lou Berger <lberger@labn.net> Sun, 26 January 2020 16:12 UTC

Return-Path: <lberger@labn.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBF5120091 for <rtg-dir@ietfa.amsl.com>; Sun, 26 Jan 2020 08:12:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 qK9HmQjWxLiv for <rtg-dir@ietfa.amsl.com>; Sun, 26 Jan 2020 08:12:55 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876DE120018 for <rtg-dir@ietf.org>; Sun, 26 Jan 2020 08:12:55 -0800 (PST)
Received: from cmgw14.unifiedlayer.com (unknown [10.9.0.14]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id ED853175E24 for <rtg-dir@ietf.org>; Sun, 26 Jan 2020 09:12:51 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id vkWpibrSDccM1vkWpifk3C; Sun, 26 Jan 2020 09:12:51 -0700
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=JMoVTfCb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=Jdjhy38mL1oA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=174xjjHKAAAA:20 a=48vgC7mUAAAA:8 a=wgclrd7RZa1UIoa-Aq8A:9 a=S6dlDmLSOG4z5qDU:21 a=6RbU56wAGF-ZXuHg:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=SiC7jx0SFpwwBh63F0a9NJvOj1iZZPmY92eaKjFcAnU=; b=ba3IiuR6b04b3MgnsymRD5uZ8f SdmkG87e+4woxCRSuVWe4zq7h15eBqcImG92zjLVh/SslG0CYs1hezjC4zpm91o8l0RuExRlQCSrq AKziMAUeS+Oa4PUputHwqCsuh;
Received: from [127.0.0.1] (port=43681 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <lberger@labn.net>) id 1ivkWp-0023Yf-I8; Sun, 26 Jan 2020 09:12:51 -0700
To: Stig Venaas <stig@venaas.com>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org, detnet@ietf.org, draft-ietf-detnet-ip.all@ietf.org
References: <CAHANBt+QghyZbPzcABMjMuV8Q-u5_Amww=KrMJpcDtaaV0_SpQ@mail.gmail.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <96990892-49f5-e043-1f23-26f9587f87b7@labn.net>
Date: Sun, 26 Jan 2020 11:12:50 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <CAHANBt+QghyZbPzcABMjMuV8Q-u5_Amww=KrMJpcDtaaV0_SpQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 127.0.0.1
X-Source-L: Yes
X-Exim-ID: 1ivkWp-0023Yf-I8
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:43681
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/UGEfq-Qvw3T4d4c4PzSpP_KemO8>
Subject: Re: [RTG-DIR] [Detnet] RtgDir review: draft-ietf-detnet-ip-04.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jan 2020 16:12:59 -0000

Hi,

     Thank you for the comments.  Please see below for specific responses.

Changes related to your comments can also be found at 
https://github.com/detnet-wg/data-plane-drafts/pull/70/files

BTW I'm responding as a document contributor.

On 12/20/2019 8:33 PM, Stig Venaas wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about
> the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
>
> Document: draft-ietf-detnet-ip-04.txt
> Reviewer: Stig Venaas
> Review Date: 2019-12-20
> IETF LC End Date:
> Intended Status: Standards Track
>
> Summary:
> I have some minor concerns about this document that I think should be
> resolved before publication.
>
> Comments:
> The document is fairly easy to read and of good quality. But I still
> have some very minor issues that I think need to be resolved. There
> are also some nits. I'm not that familiar with DetNet, some things
> might be more clear if familiar with the technology.
>
> Major Issues:
> No major issues found.
>
> Minor Issues:
> In section 3:
> It is slightly confusing that the text discusses 6-tuples, and then
> references RFC 3670 regarding 5-tuples. It would be good to mention
> how the 6-tuples here relate to the 5-tuples in RFC 3670.

Does the addition of the final sentence address this comment:

     The DetNet IP data plane primarily uses "6-tuple" based flow
     identification, where 6-tuple refers to information carried in IP and
     higher layer protocol headers.  The 6-tuple referred to in this
     document is the same as that defined in [RFC3290]. Specifically
     6-tuple is (destination address, source address, IP protocol, source
     port, destination port, and differentiated services (DiffServ) code
     point (DSCP).  General background on the use of IP headers, and
     5-tuples, to identify flows and support Quality of Service (QoS) can
     be found in [RFC3670].  [RFC7657] also provides useful background on
     the delivery of DiffServ and "tuple" based flow identification.  Note
     that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP
     component.

> It says:
>     Note: The sub-network can represent a TSN, MPLS or IP network
>     segment.
>
> This document only covers IP, right? Or does it cover IP with these
> sub-network technologies as well? I don't know if it is is good to list
> the other options here. Perhaps new ones may be added later in other
> ocuments? Maybe rephrase it so they are examples rather than a complete
> list?

Here's the proposed revised text.

         Note: The sub-network can represent a TSN, MPLS network or other
         network technology that can carry DetNet IP traffic.


>
> In section 4.1:
>     In order to maximize reuse of existing mechanisms, DetNet-aware
>     applications and end systems SHOULD NOT mix DetNet and non-DetNet
>     traffic within a single 5-tuple.
>
> Should this be 6-tuple? If not, please be specific what the 5-tuple
> is here. Same as in RFC 3670? I see the 5-tuple is also mentioned at
> the end of section 4.2.

We believe this clarified by the first change mentioned above. Note we 
don't see this document as the authoritative source of the 5-tuple 
definition, we're merely trying to use that quite mature definition.

>
> In section 4.2:
>     As a general rule, DetNet IP domains need to be able to forward any
>     DetNet flow identified by the IP 6-tuple.  Doing otherwise would
>     limit the number of 6-tuple flow ID combinations that could be used
>     by the end systems.  From a practical standpoint this means that all
>     nodes along the end-to-end path of DetNet flows need to agree on what
>     fields are used for flow identification, and the transport protocols
>     (e.g., TCP/UDP/IPsec) which can be used to identify 6-tuple protocol
>     ports.
>
> What does protocol ports mean? Is it which transport protocol includes the
> source and destination port number in the 6-tuple? This should be rephrased
> I think, since e.g. IPsec SPI may be used. I guess you may be saying that
> the SPI indirectly identify the ports?

You're right, this is unnecessary and confusing language. We propose the 
following revision as the way to address your comment:

         From a practical standpoint this means that all nodes along the 
end-to-end path of DetNet flows need....
OLD
           to agree on what fields are used for flow identification, and the
           transport protocols (e.g., TCP/UDP/IPsec) which can be used to
           identify 6-tuple protocol ports.
NEW
          to agree on what fields are used for flow identification.
> Nits:
> In section 1:
> layer is used to provides
>                    ^^^^^^^
> In 2.2.  Abbreviations
> It seems random which ones have a period at the end. I'm sure the
> RFC Editor can help, but maybe add or remove it everywhere?
>
> Section 5.3:
>     Implementations if this document
> Should be of      ^^^^

All accepted, thanks!

> Some references are outdated according to idnits.

This will be picked up on the next round of publication

Please let us know if you see any additional outstanding issues.

Thanks again for the review

Lou (and co-authors)

> Regards,
> Stig
>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet
>