Re: [Detnet] WG Last Call: draft-ietf-detnet-problem-statement-03

Kiran.Makhijani <Kiran.Makhijani@huawei.com> Thu, 03 May 2018 15:45 UTC

Return-Path: <Kiran.Makhijani@huawei.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 0D6D9124B0A for <detnet@ietfa.amsl.com>; Thu, 3 May 2018 08:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level:
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 0nQBKhJ-G5Bq for <detnet@ietfa.amsl.com>; Thu, 3 May 2018 08:45:53 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 6544112025C for <detnet@ietf.org>; Thu, 3 May 2018 08:45:53 -0700 (PDT)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 55BF1D8272F54; Thu, 3 May 2018 16:45:49 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 3 May 2018 16:45:50 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.34]) by SJCEML702-CHM.china.huawei.com ([169.254.4.62]) with mapi id 14.03.0382.000; Thu, 3 May 2018 08:45:46 -0700
From: "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, János Farkas <janos.farkas@ericsson.com>, DetNet WG <detnet@ietf.org>
Thread-Topic: [Detnet] WG Last Call: draft-ietf-detnet-problem-statement-03
Thread-Index: AQHT4jMXp9wUVMihIkeG4kYTlRD5qaQejtaA//+XMfA=
Date: Thu, 03 May 2018 15:45:45 +0000
Message-ID: <724FE0750664CC4BA0882B29E74557991E2FE7FC@sjceml521-mbx.china.huawei.com>
References: <12d4d02b-d8da-81b5-c610-50facc798c26@ericsson.com> <034a09e4-03a1-679f-91d4-d5c549de3996@gmail.com>
In-Reply-To: <034a09e4-03a1-679f-91d4-d5c549de3996@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.247.3]
Content-Type: multipart/alternative; boundary="_000_724FE0750664CC4BA0882B29E74557991E2FE7FCsjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/CwNjxDT1_VqEZoLtVbhpXAdMhbE>
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-problem-statement-03
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 03 May 2018 15:45:56 -0000

 o  the protection of the signaling protocol



SB> True, but isn't this currently out of scope (and not sure about the next point)
I had same question, but maybe this section mentions generic signaling relating to detnet (in the current scope SDN signaling from controller to nodes and/or even PCEP).

From: detnet <detnet-bounces@ietf.org> On Behalf Of Stewart Bryant
Sent: Thursday, May 3, 2018 7:57 AM
To: János Farkas <janos.farkas@ericsson.com>; DetNet WG <detnet@ietf.org>
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-problem-statement-03


This is basically ready, but I think a few items need attention before this goes to the IESG:

   As a result of this work, it will be possible to establish a multi-

   hop path over the IP network,



SB> I think that should be an IP or MPLS network



=============



  The goals of Deterministic Networking are to enable the migration of

   applications that use special-purpose fieldbus technologies (HDMI,

   CANbus, ProfiBus, etc... even RS-232!) to packet technologies in

   general, and the Internet Protocol in particular, and to support both

   these new applications, and existing packet network applications,

   over the same physical network.



SB> I think there should be some text here indicating that DN is

SB> required to support these migrations when there are critical

SB> timing and reliability issues.

SB>

SB> Where such issues are not critical, the Pseudowires or L2TP tunnels

SB> will normally be adequate. Indeed they have proved adequate for TDM

SB> and SDH emulation which are quite fickle services to emulate.



==============



       *  Need a packet loss ratio beyond the classical range for a

          particular medium, in the range of 10^-9 to 10^-12, or better,

          on Ethernet, and in the order of 10^-5 in Wireless Sensor Mesh

          Networks;



SB> I am worried whether or not we are setting unreasonable expectations

SB> here.  How many packet copies do we think we need to send

SB> to reduce the BER by 10?



===============



   4.  Robust defenses against misbehaving hosts, routers, or bridges,

SB> s/defenses/defences/

       both in the data and control planes, with guarantees that a

       critical flow within its guaranteed resources cannot be affected

       by other flows whatever the pressures on the network;



=================



These limits may depend in the technology that is used to

   seu th epath up, whether it is centralized or distributed.



SB> Hopefully no my fat fingers in my marked up copy, but it should be:

SB> "set the path"



=================



   3.  The path is installed using RSVP-TE, associated with flow

       identification, per-hop behavior such as replication and

       elimination, blocked resources, and flow timing information.



SB> This is too prescriptive on approach for a problem statement.

SB> There might well be an approach that surfaces from the Segment Routing

SB> or VPN+ work based on use of the IGP.





================



  Security must cover:



SB> I think should be "Security must also cover". If not the dynamic

SB> requirement which is unique to DN should be top of the list.



 o  the protection of the signaling protocol



SB> True, but isn't this currently out of scope (and not sure about the next point)





Best Regards



- Stewart