From nobody Fri Aug 3 07:41:06 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A1912DD85; Fri, 3 Aug 2018 07:40:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: detnet@ietf.org Message-ID: <153330725809.18503.12933109336624355090@ietfa.amsl.com> Date: Fri, 03 Aug 2018 07:40:58 -0700 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-architecture-07.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 14:40:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking Architecture Authors : Norman Finn Pascal Thubert Balázs Varga János Farkas Filename : draft-ietf-detnet-architecture-07.txt Pages : 41 Date : 2018-08-03 Abstract: Deterministic Networking (DetNet) provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency. Techniques used include: 1) reserving data plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes (e.g., bridges or routers) along the path of the flow; 2) providing explicit routes for DetNet flows that do not immediately change with the network topology; and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-architecture-07 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-architecture-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-architecture-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 3 08:39:31 2018 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 3738D13104F for ; Fri, 3 Aug 2018 08:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 sbfZ3GoxTPpb for ; Fri, 3 Aug 2018 08:39:22 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 8278D131050 for ; Fri, 3 Aug 2018 08:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533310758; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=x4J/IgK7BgajKMjTG00JAiVqWEtWTr45sfqQj2x8G/E=; b=QdgEgsgAP9aznYdX6q4AnxV/sSWAJs6gV06zXVQTYMNCp7LoqVwoW2QHr5rbxgeQ r5UDcE+Dms9GnzDDuEEPLeJrJnQ3ILw53+LQ3lmSA1Tqu3u+XJlq1noUs4nBfIBs 9PxtbEsZQ81/k2JqAVvpP4YpHo15Gqa2wXUxcQ44nNI=; X-AuditID: c1b4fb30-3cd869c0000055da-ce-5b64772629aa Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E1.B9.21978.627746B5; Fri, 3 Aug 2018 17:39:18 +0200 (CEST) Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 3 Aug 2018 17:39:13 +0200 Received: from [159.107.143.207] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.190) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 3 Aug 2018 17:39:13 +0200 To: DetNet WG , "BRUNGARD, DEBORAH A" , Lou Berger , "Black, David" , Greg Mirsky , "Andrew G. Malis" References: <99657d22-f9e4-8a1a-27de-6997900f727e@labn.net> <4900e61d-8399-8765-0ecb-181dc3c9ff5a@ericsson.com> <61d00506-b546-6c80-044f-b5bdb243ae23@ericsson.com> <3DF0466E9510274382F5B74499ACD6F8D383DD@DFWPML704-CHM.exmail.huawei.com> <164af982488.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: =?UTF-8?Q?J=c3=a1nos_Farkas?= CC: "draft-ietf-detnet-architecture@ietf.org" Message-ID: Date: Fri, 3 Aug 2018 17:39:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------05EDA65D858B1E878B60C855" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbG9XFetPCXaYO5vaYvTz0+xWXyctZjF 4nJXN7vF70+zWSw+fJvJYvFt2lNWi47mtywO7B4v++cwekyaOYPZY+esu+weS5b8ZPL4sKmZ LYA1issmJTUnsyy1SN8ugSvj9Ne9rAXzv/FXTJt5nLGBceputi5GTg4JAROJHfPeM3cxcnEI CRxllNh16hEjhPOVUWLH2Z/scJkdXRsZQVqEBbQkNuyZAFYlInCXUeLkmk9sEFVf2CVmnTnB AlLFJmAvcffSBmYQm1kgUmLtg3dMIDYvUPzmtdVgNSwCKhKnN4NM4uAQFYiRWN+XAFEiKHFy 5hOwEk6BQImzx+cxQYwJk7j75A2YLSSgJvHp7UP2CYwCs5C0zEJSBmFbSMycf54RwpaXaN46 mxnC1pBonTOXHVl8ASPbKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzAyDm45bfBDsaXzx0P MQpwMCrx8LLnpEQLsSaWFVfmHmKU4GBWEuF925kcLcSbklhZlVqUH19UmpNafIhRmoNFSZzX wm9zlJBAemJJanZqakFqEUyWiYNTqoHRJZLxxxWXcu9pvw9ZvxdO3iE3V0Jhb/nhT1evLNbt frf5217G37YzrefKH53VkL3FQE6czWv22oVV/NXf5h7mW8KwpYI50GFBjfDhvsUMxXcDb+/W PnaKzecQu/kZ1gnzl988bTD3cndRxvRs90SzcIc0W73+qz0Pb0a8892y7bUNj6TZ8k0eSizF GYmGWsxFxYkAjjmLnJgCAAA= Archived-At: Subject: [Detnet] draft-ietf-detnet-architecture-07 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Fri, 03 Aug 2018 15:39:29 -0000 --------------05EDA65D858B1E878B60C855 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, We have updated the architecture draft to resolve the extended WGLC comments. The current revision is v07: https://tools.ietf.org/html/draft-ietf-detnet-architecture-07. All WGLC comments have been addressed; most of them can be found below. Some further nits have been also resolved. The main changes: 1) Based on the last discussion item below, a new sentence has been added to congestion protection in section 3.1, where it is first described: "Note that congestion protection provided via congestion detection and notification is explicitly excluded from consideration in DetNet, as it serves a different set of applications." (Note that throttling/throttled has been already part of the text, there are three occurrences.) 2) Based on the discussion below, the following introductory text has been added to section 4.1: "DetNet functionality (Section 3) is implemented in two adjacent layers in the protocol stack: the DetNet service layer and the DetNet transport layer. The DetNet service layer provides DetNet service, e.g., service protection, to higher layers in the protocol stack and applications. The DetNet transport layer supports DetNet service in the underlying network, e.g., by providing explicit routes and congestion protection to DetNet flows." Consequently, the definition of DetNet service layer has been updated to: "The layer at which A DetNet service, e.g., service protection is provided." 3) Based on https://www.ietf.org/mail-archive/web/detnet/current/msg01577.html, the following sentence has been added to the OAM paragraph in section 4.1.1: "Active and hybrid OAM methods require additional bandwidth to perform fault management and performance monitoring of the DetNet domain. OAM may, for instance, generate special test probes or add OAM information into the data packet." 4) Based on the consensus reached at the DetNet session at IETF 102, Controller Plane Entity (CPE) has been replaced with Controller Plane Function (CPF). 5) In order to clarify, the last sentence of the introduction has been updated to: "DetNet can accommodate various time synchronization techniques and profiles that are defined elsewhere to address the needs of different market segments." 6) In order to clarify, the packet loss bullet in section 3.1 has been updated to: "Packet loss ratio, under various assumptions as to the operational states of the nodes and links." 7) DetNet t-aware has been updated to: "A DetNet transport-aware system. It knows about some TSN functions (e.g., reservation), but not about service protection." 8) DetNet s-aware has been updated to: "DetNet service-aware system. It supplies sequence numbers, but doesn’t know about zero congestion loss." Best regards, János On 7/19/2018 2:04 AM, Prof. Diego Dujovne wrote: > +1 > > El mié., 18 de jul. de 2018 19:53, Black, David > escribió: > > +1, Thanks, --David > > *From:*Lou Berger [mailto:lberger@labn.net ] > *Sent:* Wednesday, July 18, 2018 6:52 PM > *To:* Norman Finn; Janos Farkas; Black, David > *Cc:* DetNet WG > *Subject:* Re: [Detnet] WG Last Call: > draft-ietf-detnet-architecture-05 > > This sounds sensible to me... > > Lou > > ------------------------------------------------------------------------ > > On July 18, 2018 6:47:01 PM Norman Finn > > wrote: > > "Congestion loss protection" is better than "congestion > protection". That's good. > > It's a big change, and makes the document unnecessarily > wordy. That's bad. > > I would use "congestion protection" but explain somewhere that > we are not talking about source throttling. > > And if adding that explanation is difficult or controversial, > I would stick with "congestion protection". > > -- Norm > > ------------------------------------------------------------------------ > > *From:*detnet [detnet-bounces@ietf.org > ] on behalf of Janos Farkas > [Janos.Farkas@ericsson.com ] > *Sent:* Wednesday, July 18, 2018 2:26 PM > *To:* Black, David > *Cc:* DetNet WG > *Subject:* Re: [Detnet] WG Last Call: > draft-ietf-detnet-architecture-05 > > Both “congestion protection” and “congestion loss protection” > work for me. > > Note that the architecture document is quite populated with > the term “congestion protection”. I do not know the other > documents by heart. > > So it would be a bit of a change.. > > I’d like to have the group’s opinion before making such a > change, e.g., any objections? > > Thanks, > > Janos > > *From:*Black, David > > *Sent:* Wednesday, July 18, 2018 8:19 PM > *To:* Janos Farkas > > *Cc:* DetNet WG > > *Subject:* RE: [Detnet] WG Last Call: > draft-ietf-detnet-architecture-05 > > Hi Janos, > > That text works nicely. In briefly talking to Lou, a related > suggestion surfaced: “congestion protection” -> “congestion > loss protection” where possible (may need to be abbreviated in > the Figure) . > > This change would make it clearer that the primary focus is > protection from losses caused by congestion as opposed to > protection from all congestion. DetNet should be able to > tolerate some modest congestion (e.g., in nodes that don’t > have reserved DetNet resources) as long as delivery is > reliable and timely. > > Thanks, --David > > *From:*Janos Farkas [mailto:Janos.Farkas@ericsson.com] > *Sent:* Wednesday, July 18, 2018 11:45 AM > *To:* Black, David > *Cc:* DetNet WG > *Subject:* RE: [Detnet] WG Last Call: > draft-ietf-detnet-architecture-05 > > Hi David, > > This implies updating the definition of the DetNet service > layer, e.g., to: > > DetNet service layer > > The layer at which A DetNet Service, e.g., service protection > is provided. > > The definition of the DetNet transport layer remains the same: > > DetNet transport layer > > The layer that optionally provides congestion protection for > > DetNet flows over paths provided by the underlying network. > > Regards, > > Janos > > *From:*Black, David > > *Sent:* Monday, July 16, 2018 3:21 PM > *To:* Janos Farkas > > *Cc:* DetNet WG > > *Subject:* RE: [Detnet] WG Last Call: > draft-ietf-detnet-architecture-05 > > Don’t use “congestion protection” in the definitions for both > levels. > > Thanks, --David > > *From:*János Farkas [mailto:janos.farkas@ericsson.com] > *Sent:* Sunday, July 15, 2018 10:43 PM > *To:* Black, David > *Cc:* DetNet WG > *Subject:* Re: [Detnet] WG Last Call: > draft-ietf-detnet-architecture-05 > > Thank you David! > > I think we are set. :-) > > You got a point, we should update > "DetNet service layer is the layer at which A DetNet Service, > such as congestion or service protection is provided." > to > "DetNet service layer is the layer at which A DetNet Service, > such as congestion protection and/or service protection is > provided." > in the definitions as well to make it clear. > > Thanks, > Janos > > On 7/16/2018 3:03 AM, Black, David wrote: > > Moving the only two open items to the top … > > -- Section 4 > > > We could add some introductory text to 4.1 or 4.1.1, for > instance: > > The functionality needed for DetNet (Section 3) are > implemented in the DetNet layer which comprises the DetNet > service layer and the DetNet transport layer. > > > The DetNet service layer functions rely on flow > identification and sequencing. The DetNet transport layer > function may rely on flow identification. > > > > What do you think? > > I prefer functional (what it does) characterization to > mechanistic (how it works) characterization in an > overview, e.g., excerpting from what I originally wrote: > > ·The DetNet Service layer provides timely reliable > in-order DetNet flow delivery to applications that use DetNet. > > ·The DetNet Transport layer insulates DetNet flows from > interference by network mechanisms, primarily queuing and > routing > > I understand the principle. > > What about just copying the two definitions here: > DetNet service layer is the layer at which A DetNet > Service, such as congestion or service protection is provided. > DetNet transport layer optionally provides congestion > protection for DetNet flows over paths provided by the > underlying network. > > David> Yes, that works, although I don’t think > “congestion” was meant to be included in the first > definition … > > Many real-time networks rely on physical rings or > chains of two-port > > devices, with a relatively simple ring control protocol. > > How does a “ring control protocol” control “chains”? > Suggest: “ring control protocol” -> “control protocol” > > Also, are paired chains between common endpoints intended, > or a more general notion of chains? > > This text refers to typical factory deployment, which is > chain or ring.. > It seems better to keep “ring control protocol” because > they are often very different from generic control > protocols applicable to mesh networks. > > Would flipping chain and ring resolve your concern? > > Many real-time networks rely on physical chains or > rings of two-port > > devices, with a relatively simple ring control protocol. > > */[David>] /*It feels like “ring control protocol” is an > important phrase to retain. In the original text, would it > be reasonable to add “(applies to both rings and chains)” > to the end of the sentence? > > Well, I guess the point is that there are many specific > ring protocols, but we are looking for a generic solution. > What about deleting "chains" from the sentence? > > David> Yes, if the sentence is all about rings, it’s clear. > > Thanks, --David > > *From:*János Farkas [mailto:janos.farkas@ericsson.com] > *Sent:* Sunday, July 15, 2018 7:25 PM > *To:* Black, David > *Cc:* DetNet WG > *Subject:* Re: [Detnet] WG Last Call: > draft-ietf-detnet-architecture-05 > > Hi David, > > Please see in-line. > > Thank you! > Janos > > On 7/6/2018 11:50 PM, Black, David wrote: > > -- Bridged path definition > > > Or should we do something else? > > > There is only one occurrence of "bridged path" in the > text in brackets. > > That sounds like a better suggestion – change that > occurrence and remove the definition of “bridged path” > from the draft. That occurrence is in Section 4.1.1: > > Congestion protection > > The DetNet transport layer provides congestion protection. > > See Section 4.5. The actual queuing and shaping > mechanisms > > are typically provided by underlying subnet layers, > these can > > be closely associated with the means of providing > paths for > > DetNet flows (e.g., MPLS LSPs or bridged > paths), the path and > > the congestion protection are conflated in this figure. > > Perhaps: (e.g., MPLS LSPs or bridged paths) -> (MPLS > LSPs or other network paths) > > or just delete the entire parenthetical example. > > OK. Let's just delete the entire parenthetical example. > > -- Section 4 > > > We could add some introductory text to 4.1 or 4.1.1, > for instance: > > The functionality needed for DetNet (Section 3) are > implemented in the DetNet layer which comprises the > DetNet service layer and the DetNet transport layer. > > > The DetNet service layer functions rely on flow > identification and sequencing. The DetNet transport > layer function may rely on flow identification. > > > > What do you think? > > I prefer functional (what it does) characterization to > mechanistic (how it works) characterization in an > overview, e.g., excerpting from what I originally wrote: > > * The DetNet Service layer provides timely reliable > in-order DetNet flow delivery to applications that > use DetNet. > * The DetNet Transport layer insulates DetNet flows > from interference by network mechanisms, primarily > queuing and routing > > I understand the principle. > > What about just copying the two definitions here: > DetNet service layer is the layer at which A DetNet > Service, such as congestion or service protection is provided. > DetNet transport layer optionally provides congestion > protection for DetNet flows over paths provided by the > underlying network. > > > > Should we also rearrange, e.g., indent the text after > Figure 2 such that > > Packet sequencing, Duplicate elimination, Flow > replication, Flow merging, Packet encoding, and Packet > decoding get under Service layer > > and > > Congestion protection and Explicit routes get under > Transport layer? > > No, I don’t think that’s necessary – Figure 2 provides > sufficient structure. > > OK. > > Plus a few more minor comments inline … > > Thanks, --David > > *From:*János Farkas [mailto:janos.farkas@ericsson.com] > *Sent:* Wednesday, July 4, 2018 2:15 PM > *To:* Black, David > *Cc:* DetNet WG > *Subject:* Re: [Detnet] WG Last Call: > draft-ietf-detnet-architecture-05 > > Hi David, > > Thank you very much for your review and comments! > > Please see in-line. > > On 6/29/2018 4:10 PM, Black, David wrote: > > The -06 version of this draft is much improved > over the -05 version – lots of diligent work by > the authors is evident and appreciated. > > I have two minor content concerns and some smaller > editorial items. > > ** Content > > -- Section 2.2 > > The definition of “bridged path” looks like a > definition of “bridged forwarding” – the > definition needs to encompass the notion of a path > that involves more than one bridge. > > bridged path > > A VLAN bridge uses the VLAN ID and the > destination MAC > > address to select the outbound port > hence the path for a > > frame. > > You are right, it looks like the emphasis is on bridge > forwarding rather than path. > However, the superposition of the outbound ports > provides a path, which was tried to be captured by > "hence the path". > The idea was to keep it simple not dive into the > details, which are not necessary in this document. > > Would it be good to update to: > > bridged path > > A VLAN bridge uses the VLAN ID and the > destination MAC > > address to select the outbound port. The > superposition > > of the outbound ports is the path for a frame. > > ? > > Or should we do something else? > There is only one occurrence of "bridged path" in the > text in brackets. > > -- Section 4 > > Figure 2 in Section 4.1.1 introduces the Detnet > service and transport layers. The associated > text quickly dives into explaining the > functionality in those layers, but it would be > helpful to start with an initial high level > description of each of those layers that helps > motivate their separation. It appears that: > > - The DetNet Service layer provides timely > reliable in-order DetNet flow delivery to > applications that use DetNet. A DetNet flow at > the top of the DetNet Service layer may or may not > be a compound flow at the bottom of that layer. > > - The DetNet Transport layer insulates DetNet > flows (at the bottom of the DetNet Service layer) > from interference by network mechanisms, primarily > queuing and routing, where congestion is an > indication of queueing interference. A DetNet > flow at the top of the DetNet Transport layer may > or may not be a member flow that is part of a > compound flow, depending on what is done in the > DetNet Service layer. > > > You are right, section 4 jumps into the details > without much of an introduction. I guess we had a kind > of chicken and egg problem here. Figure 4 provides a > higher level view than Figure 2. However, Figure 4 > captures different aspects, dives into the details of > data plane options. So, it seems better to keep the order. > > We could add some introductory text to 4.1 or 4.1.1, > for instance: > The functionality needed for DetNet (Section 3) are > implemented in the DetNet layer which comprises the > DetNet service layer and the DetNet transport layer. > The DetNet service layer functions rely on flow > identification and sequencing. The DetNet transport > layer function may rely on flow identification. > > What do you think? > > Should we also rearrange, e.g., indent the text after > Figure 2 such that > Packet sequencing, Duplicate elimination, Flow > replication, Flow merging, Packet encoding, and Packet > decoding get under Service layer > and > Congestion protection and Explicit routes get under > Transport layer? > > There’s a related paragraph of text between > Figures 3 and 4 in Section 4.1.2, but it doesn’t > provide useful intuition about which functionality > belongs in which layer. > > ** Editorial > > -- Section 2.1 > > “expected” seems off in the definition of reservation: > > reservation > > The set of resources allocated between a source > and one or > > more destinations through transit nodes and subnets > > associated with a DetNet flow, to provide the > expected DetNet > > Service. > > Suggest either “to provide the provisioned DetNet > Service to that flow” > > I like this one, will update to this one. > > or “to provide the specified DetNet Service to > that flow.” > > -- Section 3.1 > > o An upper bound on out-of-order packet > delivery. It is worth > > noting that some DetNet applications are > unable to tolerate any > > out-of-order delivery. > > Is that a sequence bound or a time bound or both? > I suspect that a sequence bound (maximum degree of > reordering in a flow, independent of flow rate) > was intended. An analogous clarification would be > helpful in section 3.2.2.1 . > > It is intentionally kept high level in the > architecture draft. Details are to be provided by the > flow information model draft. Please see my previous > mail: > https://mailarchive.ietf.org/arch/msg/detnet/AWG2eemg_AWsvF2FwtREyd_xtC8. > > */[David>] /*OK. > > -- Section 3.2.3 > > I don’t understand “defined” in: > > Even the use of > > redundant paths through a network defined, > e.g., by [RFC6372] do not > > eliminate the chances of packet loss. > > Was “e.g., as defined by [RFC6372],” intended? > > Yes, this was the intention, will update to this one. > > Many real-time networks rely on physical rings > or chains of two-port > > devices, with a relatively simple ring control > protocol. > > How does a “ring control protocol” control > “chains”? Suggest: “ring control protocol” -> > “control protocol” > > Also, are paired chains between common endpoints > intended, or a more general notion of chains? > > This text refers to typical factory deployment, which > is chain or ring. > It seems better to keep “ring control protocol” > because they are often very different from generic > control protocols applicable to mesh networks. > > Would flipping chain and ring resolve your concern? > > Many real-time networks rely on physical chains or > rings of two-port > > devices, with a relatively simple ring control > protocol. > > */[David>] /*It feels like “ring control protocol” > is an important phrase to retain. In the > original text, would it be reasonable to add > “(applies to both rings and chains)” to the end of > the sentence? > > Well, I guess the point is that there are many specific > ring protocols, but we are looking for a generic solution. > What about deleting "chains" from the sentence? > > Explicit routes can be established various ways, > > established various -> established in various > > OK. > > This is > > irrespective of the distribution method used, > also applies to service > > protection over explicit routes. > > used, also -> used, and also > > OK. > > -- Figure 5 (Section 4.1.3) > > The UNI acronym is introduced without expansion or > definition – please correct that, e.g., by > defining UNI in Section 2.1. > > DetNet-UNI is there among the definitions. It seems > enough to me. > > */[David>] /*That’s fine – I overlooked that > definition, sorry. > > -- Figure 9 (Section 4.7.2) > > I think I understand what’s going on, but the use > of “add/remove” in the figure should be explained > in associated text. > > What about updating the sentence above Figure 9 to: > A packet with corresponding Flow-IDs is illustrated in > Figure 9, which also indicates where Flow-ID can be > added or removed. > > */[David>] /*Sure, with one minor edit: “where > Flow-ID” -> “where each Flow-ID” > > OK. > > Thanks, --David > > > Thank you! > Janos > > *From:*detnet [mailto:detnet-bounces@ietf.org] *On > Behalf Of *János Farkas > *Sent:* Thursday, June 28, 2018 9:09 PM > *To:* Lou Berger; Stewart Bryant; detnet@ietf.org > >> DetNet WG > *Subject:* Re: [Detnet] WG Last Call: > draft-ietf-detnet-architecture-05 > > Dear all, > > Off-line discussions among Lou, Stewart, and > authors followed the discussions to properly > address the WGLC comments, including the detailed > comments. > > A new revision of the draft has been uploaded: > draft-ietf-detnet-architecture-06. > > In addition to the changes already described in > this thread, the following bigger changes have > been made to the draft: > > > *Section 2.1 Terms used in this document* > > Some definitions refined as suggested by the > detailed comments > > New definitions have been added: > > "allocation > Resources are dedicated to support a > DetNet flow. Depending > on an implementation, the resource may > be reused by non- > DetNet flows when it is not used by the > DetNet flow. > > > PEF A Packet Elimination Function (PEF) > eliminates duplicate > copies of packets to prevent excess > packets flooding the > network or duplicate packets being sent > out of the DetNet > domain. PEF can be implemented by an > edge node, a relay > node, or an end system. > > PRF A Packet Replication Function (PRF) > replicates DetNet flow > packets and forwards them to one or > more next hops in the > DetNet domain. The number of packet > copies sent to each next > hop is a DetNet flow specific parameter > at the node doing the > replication. PRF can be implemented by > an edge node, a relay > node, or an end system. > > PREOF Collective name for Packet Replication, > Elimination, and > Ordering Functions. > > POF A Packet Ordering Function (POF) > re-orders packets within a > DetNet flow that are received out of > order. This function > can be implemented by an edge node, a > relay node, or an end > system. > > DetNet service proxy > Maps between App-flows and DetNet flows. > > bridged path > A VLAN bridge uses the VLAN ID and the > destination MAC > address to select the outbound port > hence the path for a > frame." > > > *Section 3.1 Primary goals defining the DetNet QoS* > > A new QoS aspect has been added: > "o An upper bound on out-of-order packet > delivery. It is worth > noting that some DetNet applications are > unable to tolerate any > out-of-order delivery." > > > The 3rd paragraph on loss on page 8 after the > bullet list has been extended to: > "After congestion, the most important > contributions to packet loss are > typically from random media errors and > equipment failures. Service > protection is the name for the mechanisms used > by DetNet to address > these losses. The mechanisms employed are > constrained by the > requirement to meet the users' latency > requirements. Packet > replication and elimination (Section 3.2.2) and > packet encoding > (Section 3.2.2.3) are described in this > document to provide service > protection; others may be found. For instance, > packet encoding can > be used to provide service protection against > random media errors, > packet replication and elimination can be used > to provide service > protection against equipment failures. This > mechanism distributes > the contents of DetNet flows over multiple > paths in time and/or > space, so that the loss of some of the paths > does need not cause the > loss of any packets." > > > *3.2.2. Service Protection* > > Service protection is used as a more generic term. > Introductory text added: > "Service protection aims to mitigate or > eliminate packet loss due to > equipment failures, random media and/or memory > faults. These types > of packet loss can be greatly reduced by > spreading the data over > multiple disjoint forwarding paths. Various > service protection > methods are described in [RFC6372], e.g., 1+1 > linear protection. > This section describes the functional details > of an additional method > in Section 3.2.2.2, which can be implemented as > described in > Section 3.2.2.3 or as specified in > [I-D.ietf-detnet-dp-sol-mpls] in > order to provide 1+n hitless protection. The > appropriate service > protection mechanism depends on the scenario > and the requirements." > > > New sub-section added: > > "3.2.2.1. In-Order Delivery > > Out-of-order packet delivery can be a side > effect of service > protection. Packets delivered out-of-order > impact the amount of > buffering needed at the destination to properly > process the received > data. Such packets also influence the jitter > of a flow. The DetNet > service includes maximum allowed misordering as > a constraint. Zero > misordering would be a valid service constraint > to reflect that the > end system(s) of the flow cannot tolerate any > out-of-order delivery. > Service protection may provide a mechanism to > support in-order > delivery." > > > *3.2.2.2. Packet Replication and Elimination* > > New bullet added as the last one: > "o The Packet Ordering Function (POF) uses the > sequencing information > to re-order a DetNet flow's packets that are > received out of > order." > > New sentence added after the bullet list: > "The order in which a node applies the PEF and the > PRF to a DetNet > flow is implementation specific." > > 2nd paragraph after the bullet list has been > updated to: > "Some service protection mechanisms rely on > switching from one flow to > another when a failure of a flow is detected. > Contrarily, packet > replication and elimination combines the DetNet > member flows sent > along multiple different paths, and performs a > packet-by-packet > selection of which to discard, e.g., based on > sequencing information." > > > *3.2.3. Explicit routes* > > Out-of-order aspect added to the first paragraph, > which is about distributed routing: > "Furthermore, out-of-order > packet delivery can be a side effect of route > changes." > > New sentence added to the 3rd paragraph: > "Explicit routes can be established various > ways, e.g., with RSVP-TE [RFC3209], with Segment > Routing (SR) > [I-D.ietf-spring-segment-routing], via a Software > Defined Networking > approach [RFC7426], with IS-IS [RFC7813], etc." > > New paragraph added: > "Out-of-order packet delivery can be a side > effect of distributing a > single flow over multiple paths especially when > there is a change > from one path to another when combining the > flow. This is > irrespective of the distribution method used, > also applies to service > protection over explicit routes. As described > in Section 3.2.2.1, > out-of-order packets influence the jitter of a > flow and impact the > amount of buffering needed to process the data; > therefore, DetNet > service includes maximum allowed misordering as > a constraint. The > use of explicit routes helps to provide > in-order delivery because > there is no immediate route change with the > network topology, but the > changes are plannable as they are between the > different explicit > routes." > > * > 4.1.1. Representative Protocol Stack Model* > > "Explicit routes" have been added to Figure 2 with > the corresponding explanation: > "Explicit routes > The DetNet transport layer provides > mechanisms to ensure that > fixed paths are provided for DetNet > flows. These explicit > paths avoid the impact of network > convergence." > > > Section 4.11 Connected islands vs. networks of v05 > has been deleted because it was just a leftover > from early drafts on what DetNet WG should do; > which are covered by the charter anyways. > > > References have been cleaned up and brought > up-to-date. > > > Refinements have been implemented in the draft > according to Lou's detailed comments. They are not > listed here because they are minor changes. > > > Best regards, > Janos > > On 6/12/2018 2:48 PM, Lou Berger wrote: > > > Balázs, > > Thanks for the response -- please see below. > > ---------- > On June 12, 2018 4:07:35 AM Balázs Varga A > > wrote: > > Hi Lou, Thanks for the comments. See > reactions inline. Document update in > progress. Cheers Bala'zs > > -----Original Message----- > From: detnet > On Behalf > Of Lou Berger > Sent: 2018. június 1. 22:42 > To: DetNet WG > ; > draft-ietf-detnet-architecture@ietf.org > > > Subject: [Detnet] Promised comments on > draft-ietf-detnet-architecture > > Hi, > > I have a number of high level > comments on the document that I'd like to > raise below. I also have a number of > more editorial/specific comments that I'd > like to review directly with the authors > and then have them report back on changes > -- if any turn out to be more substantive > discussions from the author's > perspective, I'll raise these on the list > separately. > > ... > > > - WRT Section 4.4.3, I think the inclusion > of a distributed control plane in the > "Network Plane" is inconsistent with other > functional definitions and conflates where > a function resides from the actual > function and that whether control is > implemented in a fully centralized, fully > distributed or some hybrid form doesn't > fundamentally change the control > function's role -- therefore I think the > sections 4..4.2 and .3 should be revised > accordingly > [Balázs Varga A] Agree in principal. Let's > discuss the details. > > Okay - I'll work with you off line and we can > report back the results/proposed changes. > > - In several places it's not clear that > DetNet service is always a L3 service > which is controlled using L3 identifiers, > i.e., IP addresses -- this is true even in > the MPLS service case and the TSN over > MPLS case. I think this is an important > point to be clear on in the document. > [Balázs Varga A] I am not sure. DetNet > service is always provided over a L3 > network (IP or MPLS), that is fine. > However the service itself can be L2 or > L3. In case of TSN Ethernet frames are > transported, so it is a L2 service. In > case of IP end systems IP packets are > transported so it is a L3 service. > > > Humm - While I agree that DetNet is providing > an (enhanced) L2VPN service, it is not itself > providing control or service of L2 devices -- > this is TSN's job. The fact that DetNet is > all about behavior of L3 nodes (i.e., IP and > PW/MPLS) and not L2 nodes (i.e., TSN bridges) > is something the architecture should make > unambiguous. > > Thanks, > Lou > > Please let me know what you think. > > Cheers, > > 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 > > > > On 6/12/2018 6:27 PM, Stewart Bryant wrote: > > Dear Bala'zs > > Thank you your for your consideration of these > points. I will just pick up a few that need > some further thought: > > DetNet transit node > > A node operating at the DetNet transport > layer, that utilizes > > link layer and/or network layer switching > across multiple > > links and/or sub-networks to provide paths > for DetNet service > > layer functions. Optionally provides > congestion protection > > over those paths. An MPLS LSR is an > example of a DetNet > > transit node. > > SB> In that example it would have to be a > DetNet enable/aware LSR. An > > SB> ordinary LSR would not know anything > about DetNet. > > [Balázs Varga A] No, A DetNet aware LSR > would be a relay node (S-PE). > > > I think the confusion is what "DetNet > Transport Layer" means. This > technology touches on Transport Layer in the > L4 sense, and the > Transport Network Layer as in the packet > network that carries > L3 packets. > > So I think that we need to clarify whether a > DetNet transit node > is an S-PE (i.e. a a transit node in the > DetNet layer), or a P node > (i.e. a transit node that is carrying DetNet > packets but could be > carrying any sort of MPLS packet) > > ============ > > These three techniques can be applied > independently, giving eight > > possible combinations, including none (no > DetNet), although some > > combinations are of wider utility than > others. This separation keeps > > the protocol stack coherent and maximizes > interoperability with > > existing and developing standards in this > (IETF) and other Standards > > Development Organizations. Some examples > of typical expected > > combinations: > > o Explicit routes plus service protection > are exactly the techniques > > employed by [HSR-PRP]. Explicit routes are > achieved by limiting > > the physical topology of the network, and > the sequentialization, > > replication, and duplicate elimination are > facilitated by packet > > tags added at the front or the end of > Ethernet frames. > > SB> ER can be done virtually as well as > physically. RSVP is a type of > > SB> ER, as is Adj-SID based SR, and we can > design other types. > > [Balázs Varga A] Agree, but these are > examples. Statement is for HSR-PRP. > > So the question is whether we should expand > the set of examples, particularly > to more accessible ones. > > ============ > > Packet replication and elimination > > > > > > > > > > > relay > > > > > > > > > > > /------------+ R node E +------------\ > > > > / v + ^ \ > > > end R + v | ^ + E end > > system + v | ^ + system > > > \ v + ^ / > > > > \------------+ R relay E +-----------/ > > > > > > > > > > > > node > > > > > > > > > > Figure 1 > > Packet replication and elimination does > not react to and correct > > failures; it is entirely passive. Thus, > intermittent failures, > > SB> I think it copes with intermittent > failures OK. > > [Balázs Varga A] Yes, PRF and PEF can > eliminate the effect of such failures. But > text > > intends to say that it is passive. It is > not reacting to such failures. No change > in text. > > > You say that PREF does not correct failures. I > would contend that is exactly > what it does. Sure it does not react but it > does correct, and it does > address intermittent failures. > > =========== > > transported between the peer end systems. > Therefore, the following > > possible types / formats of a DetNet flow > are distinguished in this > > document: > > o App-flow: native format of a DetNet > flow. It does not contain any > > DetNet related attributes. > > o DetNet-t-flow: specific format of a > DetNet flow. Only requires > > the congestion / latency features provided > by the Detnet transport > > layer. > > o DetNet-s-flow: specific format of a > DetNet flow. Only requires > > the replication/elimination feature > ensured by the DetNet service > > layer. > > o DetNet-st-flow: specific format of a > DetNet flow. It requires > > both DetNet service layer and DetNet > transport layer functions > > during forwarding. > > SB> I find the relisting of these types > confusing. Wheren't they defined > > SB> in the section above? > > [Balázs Varga A] This is inline with the > previous section " Grouping of end systems ". > > Surely if we have defined them we never need > to do anything but name them in > later sections. Redefinition is never a good > idea because it often leads to > conflicting definitions. > > ============ > > [HSR-PRP] IEC, "High availability > seamless redundancy (HSR) is a > > further development of the PRP approach, > although HSR > > functions primarily as a protocol for > creating media > > redundancy while PRP, as described in the > previous > > section, creates network redundancy. PRP > and HSR are both > > described in the IEC 62439 3 standard.", > > > artnum/046615!opendocument>. > > SB> Not available at the time of this > review, but my recollection is > > SB> that this is not readily available > without paying a large fee. > > > If we decide that this is essential as a key > reference, there needs to be > some suitable text, as this will get raised a > number of times between > here an publication as first the directorates > and then the ADs run > into this. > > =========== > > [ISA95] ANSI/ISA, "Enterprise-Control > System Integration Part 1: > > Models and Terminology", 2000, > > . > > SB> Should that be 2000, or 2010. > > SB> Note that this seems to be a very > expensive document to access. > > You did not comment on the correctness of the > reference. > > > Best Regards > > Stewart > > _______________________________________________ > 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 > --------------05EDA65D858B1E878B60C855 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi,

We have updated the architecture draft to resolve the extended WGLC comments. The current revision is v07: https://tools.ietf.org/html/draft-ietf-detnet-architecture-07.

All WGLC comments have been addressed; most of them can be found below. Some further nits have been also resolved.

The main changes:

1)
Based on the last discussion item below, a new sentence has been added to congestion protection in section 3.1, where it is first described:
"Note that congestion
protection provided via congestion detection and notification is
explicitly excluded from consideration in DetNet, as it serves a
different set of applications."

(Note that throttling/throttled has been already part of the text, there are three occurrences.)

2)
Based on the discussion below, the following introductory text has been added to section 4.1:
"DetNet functionality (Section 3) is implemented in two adjacent
layers in the protocol stack: the DetNet service layer and the DetNet
transport layer. The DetNet service layer provides DetNet service,
e.g., service protection, to higher layers in the protocol stack and
applications. The DetNet transport layer supports DetNet service in
the underlying network, e.g., by providing explicit routes and
congestion protection to DetNet flows."

Consequently, the definition of DetNet service layer has been updated to:
"The layer at which A DetNet service, e.g., service protection
is provided."

3)
Based on https://www.ietf.org/mail-archive/web/detnet/current/msg01577.html, the following sentence has been added to the OAM paragraph in section 4.1.1:
"Active and hybrid OAM
methods require additional bandwidth to perform fault management and
performance monitoring of the DetNet domain. OAM may, for instance,
generate special test probes or add OAM information into the data
packet."

4)
Based on the consensus reached at the DetNet session at IETF 102, Controller Plane Entity (CPE) has been replaced with Controller Plane Function (CPF).

5)
In order to clarify, the last sentence of the introduction has been updated to:
"DetNet can
accommodate various time synchronization techniques and profiles that
are defined elsewhere to address the needs of different market
segments."

6)
In order to clarify, the packet loss bullet in section 3.1 has been updated to:
"Packet loss ratio, under various assumptions as to the operational
states of the nodes and links."

7)
DetNet t-aware has been updated to:
"A DetNet transport-aware system. It knows about
some TSN functions (e.g., reservation), but not about service
protection."

8)
DetNet s-aware has been updated to:
"DetNet service-aware system. It supplies
sequence numbers, but doesn’t know about zero congestion loss."


Best regards,
János


On 7/19/2018 2:04 AM, Prof. Diego Dujovne wrote:
+1

El mié., 18 de jul. de 2018 19:53, Black, David <David.Black@dell.com> escribió:

+1, Thanks, --David

 

From: Lou Berger [mailto:lberger@labn.net]
Sent: Wednesday, July 18, 2018 6:52 PM
To: Norman Finn; Janos Farkas; Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

 

This sounds sensible to me...

Lou

On July 18, 2018 6:47:01 PM Norman Finn <norman.finn@mail01.huawei.com> wrote:

"Congestion loss protection" is better than "congestion protection".  That's good.

 

It's a big change, and makes the document unnecessarily wordy.  That's bad.

 

I would use "congestion protection" but explain somewhere that we are not talking about source throttling.

 

And if adding that explanation is difficult or controversial, I would stick with "congestion protection".

 

-- Norm

 

From: detnet [detnet-bounces@ietf.org] on behalf of Janos Farkas [Janos.Farkas@ericsson.com]
Sent: Wednesday, July 18, 2018 2:26 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Both “congestion protection” and “congestion loss protection” work for me.

 

Note that the architecture document is quite populated with the term “congestion protection”. I do not know the other documents by heart.

 

So it would be a bit of a change..

 

I’d like to have the group’s opinion before making such a change, e.g., any objections?

 

Thanks,

Janos

 

 

From: Black, David <David.Black@dell.com>
Sent: Wednesday, July 18, 2018 8:19 PM
To: Janos Farkas <Janos.Farkas@ericsson.com>
Cc: DetNet WG <detnet@ietf.org>
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

 

Hi Janos,

 

That text works nicely.  In briefly talking to Lou, a related suggestion surfaced: “congestion protection” -> “congestion loss protection” where possible (may need to be abbreviated in the Figure) .

 

This change would make it clearer that the primary focus is protection from losses caused by congestion as opposed to protection from all congestion.  DetNet should be able to tolerate some modest congestion (e.g., in nodes that don’t have reserved DetNet resources) as long as delivery is reliable and timely.

 

Thanks, --David

 

From: Janos Farkas [mailto:Janos.Farkas@ericsson.com]
Sent: Wednesday, July 18, 2018 11:45 AM
To: Black, David
Cc: DetNet WG
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

 

Hi David,

 

This implies updating the definition of the DetNet service layer, e.g., to:

DetNet service layer

The layer at which A DetNet Service, e.g., service protection is provided.

 

The definition of the DetNet transport layer remains the same:

DetNet transport layer

The layer that optionally provides congestion protection for

DetNet flows over paths provided by the underlying network.

 

Regards,

Janos

 

 

From: Black, David <David.Black@dell.com>
Sent: Monday, July 16, 2018 3:21 PM
To: Janos Farkas <Janos.Farkas@ericsson.com>
Cc: DetNet WG <detnet@ietf.org>
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

 

Don’t use “congestion protection” in the definitions for both levels.

 

Thanks, --David

 

From: János Farkas [mailto:janos.farkas@ericsson.com]
Sent: Sunday, July 15, 2018 10:43 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

 

Thank you David!

I think we are set. :-)

You got a point, we should update
"DetNet service layer is the layer at which A DetNet Service, such as congestion or service protection is provided."
to
"DetNet service layer is the layer at which A DetNet Service, such as congestion protection and/or service protection is provided."
in the definitions as well to make it clear.

Thanks,
Janos

On 7/16/2018 3:03 AM, Black, David wrote:

Moving the only two open items to the top …

 

-- Section 4

 

> We could add some introductory text to 4.1 or 4.1.1, for instance:
> The functionality needed for DetNet (Section 3) are implemented in the DetNet layer which comprises the DetNet service layer and the DetNet transport layer.

> The DetNet service layer functions rely on flow identification and sequencing. The DetNet transport layer function may rely on flow identification.
>
> What do you think?

 

I prefer functional (what it does) characterization to mechanistic (how it works) characterization in an overview, e.g., excerpting from what I originally wrote:

·         The DetNet Service layer provides timely reliable in-order DetNet flow delivery to applications that use DetNet.

·         The DetNet Transport layer insulates DetNet flows from interference by network mechanisms, primarily queuing and routing

I understand the principle.

What about just copying the two definitions here:
DetNet service layer is the layer at which A DetNet Service, such as congestion or service protection is provided.
DetNet transport layer optionally provides congestion protection for DetNet flows over paths provided by the underlying network.

 

David> Yes, that works, although I don’t think “congestion” was meant to be included in the first definition …

 

   Many real-time networks rely on physical rings or chains of two-port
   devices, with a relatively simple ring control protocol.

 

How does a “ring control protocol” control “chains”?  Suggest: “ring control protocol” -> “control protocol”

Also, are paired chains between common endpoints intended, or a more general notion of chains?

This text refers to typical factory deployment, which is chain or ring..
It seems better to keep “ring control protocol” because they are often very different from generic control protocols applicable to mesh networks.

Would flipping chain and ring resolve your concern?

   Many real-time networks rely on physical chains or rings of two-port
   devices, with a relatively simple ring control protocol.

 

[David>] It feels like “ring control protocol” is an important phrase to retain.   In the original text, would it be reasonable to add “(applies to both rings and chains)” to the end of the sentence?

Well, I guess the point is that there are many specific ring protocols, but we are looking for a generic solution.
What about deleting "chains" from the sentence?

 

David> Yes, if the sentence is all about rings, it’s clear.

 

Thanks, --David

 

From: János Farkas [mailto:janos.farkas@ericsson.com]
Sent: Sunday, July 15, 2018 7:25 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

 

Hi David,

Please see in-line.

Thank you!
Janos

On 7/6/2018 11:50 PM, Black, David wrote:

-- Bridged path definition

 

>  Or should we do something else?

> There is only one occurrence of "bridged path" in the text in brackets.

That sounds like a better suggestion – change that occurrence and remove the definition of “bridged path” from the draft.  That occurrence is in Section 4.1.1:

 

   Congestion protection

           The DetNet transport layer provides congestion protection.

           See Section 4.5.  The actual queuing and shaping mechanisms

           are typically provided by underlying subnet layers, these can

           be closely associated with the means of providing paths for

          DetNet flows (e.g., MPLS LSPs or bridged paths), the path and

           the congestion protection are conflated in this figure.

 

Perhaps: (e.g., MPLS LSPs or bridged paths) -> (MPLS LSPs or other network paths)

or just delete the entire parenthetical example.

OK. Let's just delete the entire parenthetical example.

 

-- Section 4

 

> We could add some introductory text to 4.1 or 4.1.1, for instance:
> The functionality needed for DetNet (Section 3) are implemented in the DetNet layer which comprises the DetNet service layer and the DetNet transport layer.

> The DetNet service layer functions rely on flow identification and sequencing. The DetNet transport layer function may rely on flow identification.
>
> What do you think?

 

I prefer functional (what it does) characterization to mechanistic (how it works) characterization in an overview, e.g., excerpting from what I originally wrote:

  • The DetNet Service layer provides timely reliable in-order DetNet flow delivery to applications that use DetNet.
  • The DetNet Transport layer insulates DetNet flows from interference by network mechanisms, primarily queuing and routing

I understand the principle.

What about just copying the two definitions here:
DetNet service layer is the layer at which A DetNet Service, such as congestion or service protection is provided.
DetNet transport layer optionally provides congestion protection for DetNet flows over paths provided by the underlying network.


> Should we also rearrange, e.g., indent the text after Figure 2 such that
> Packet sequencing, Duplicate elimination, Flow replication, Flow merging, Packet encoding, and Packet decoding get under Service layer
> and
> Congestion protection and Explicit routes get under Transport layer?

 

No, I don’t think that’s necessary – Figure 2 provides sufficient structure.

OK.

 

Plus a few more minor comments inline …

 

Thanks, --David

 

From: János Farkas [mailto:janos.farkas@ericsson.com]
Sent: Wednesday, July 4, 2018 2:15 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

 

Hi David,

Thank you very much for your review and comments!

Please see in-line.

On 6/29/2018 4:10 PM, Black, David wrote:

The -06 version of this draft is much improved over the -05 version – lots of diligent work by the authors is evident and appreciated.

 

I have two minor content concerns and some smaller editorial items.

 

** Content

 

-- Section 2.2

 

The definition of “bridged path” looks like a definition of “bridged forwarding” – the definition needs to encompass the notion of a path that involves more than one bridge.

 

   bridged path
           A VLAN bridge uses the VLAN ID and the destination MAC
           address to select the outbound port hence the path for a
           frame.

 

You are right, it looks like the emphasis is on bridge forwarding rather than path.
However, the superposition of the outbound ports provides a path, which was tried to be captured by "hence the path".
The idea was to keep it simple not dive into the details, which are not necessary in this document.

Would it be good to update to:

   bridged path
           A VLAN bridge uses the VLAN ID and the destination MAC
           address to select the outbound port. The superposition
           of the outbound ports is the path for a frame.

?

Or should we do something else?
There is only one occurrence of "bridged path" in the text in brackets.

-- Section 4

 

Figure 2 in Section 4.1.1 introduces the Detnet service and transport layers.   The associated text quickly dives into explaining the functionality in those layers, but it would be helpful to start with an initial high level description of each of those layers that helps motivate their separation.  It appears that:

- The DetNet Service layer provides timely reliable in-order DetNet flow delivery to applications that use DetNet.   A DetNet flow at the top of the DetNet Service layer may or may not be a compound flow at the bottom of that layer.

- The DetNet Transport layer insulates DetNet flows (at the bottom of the DetNet Service layer) from interference by network mechanisms, primarily queuing and routing, where congestion is an indication of queueing interference.  A DetNet flow at the top of the DetNet Transport layer may or may not be a member flow that is part of a compound flow, depending on what is done in the DetNet Service layer.


You are right, section 4 jumps into the details without much of an introduction. I guess we had a kind of chicken and egg problem here. Figure 4 provides a higher level view than Figure 2. However, Figure 4 captures different aspects, dives into the details of data plane options. So, it seems better to keep the order.

We could add some introductory text to 4.1 or 4.1.1, for instance:
The functionality needed for DetNet (Section 3) are implemented in the DetNet layer which comprises the DetNet service layer and the DetNet transport layer. The DetNet service layer functions rely on flow identification and sequencing. The DetNet transport layer function may rely on flow identification.

What do you think?

Should we also rearrange, e.g., indent the text after Figure 2 such that
Packet sequencing, Duplicate elimination, Flow replication, Flow merging, Packet encoding, and Packet decoding get under Service layer
and
Congestion protection and Explicit routes get under Transport layer?

 

There’s a related paragraph of text between Figures 3 and 4 in Section 4.1.2, but it doesn’t provide useful intuition about which functionality belongs in which layer.

 

** Editorial

-- Section 2.1

 

“expected” seems off in the definition of reservation:

 

   reservation

           The set of resources allocated between a source and one or

           more destinations through transit nodes and subnets

           associated with a DetNet flow, to provide the expected DetNet

           Service.

 

Suggest either “to provide the provisioned DetNet Service to that flow”

I like this one, will update to this one.

or “to provide the specified DetNet Service to that flow.”

 

-- Section 3.1

 

   o  An upper bound on out-of-order packet delivery.  It is worth
      noting that some DetNet applications are unable to tolerate any
      out-of-order delivery.

 

Is that a sequence bound or a time bound or both?   I suspect that a sequence bound (maximum degree of reordering in a flow, independent of flow rate) was intended.  An analogous clarification would be helpful in section 3.2.2.1 .

It is intentionally kept high level in the architecture draft. Details are to be provided by the flow information model draft. Please see my previous mail: https://mailarchive.ietf.org/arch/msg/detnet/AWG2eemg_AWsvF2FwtREyd_xtC8.

[David>] OK.

 

-- Section 3.2.3

 

I don’t understand “defined” in:

 

   Even the use of
   redundant paths through a network defined, e.g., by [RFC6372] do not
   eliminate the chances of packet loss.

 

Was “e.g., as defined by [RFC6372],” intended?

Yes, this was the intention, will update to this one.

   Many real-time networks rely on physical rings or chains of two-port
   devices, with a relatively simple ring control protocol.

 

How does a “ring control protocol” control “chains”?  Suggest: “ring control protocol” -> “control protocol”

Also, are paired chains between common endpoints intended, or a more general notion of chains?

This text refers to typical factory deployment, which is chain or ring.
It seems better to keep “ring control protocol” because they are often very different from generic control protocols applicable to mesh networks.

Would flipping chain and ring resolve your concern?

   Many real-time networks rely on physical chains or rings of two-port
   devices, with a relatively simple ring control protocol.

 

[David>] It feels like “ring control protocol” is an important phrase to retain.   In the original text, would it be reasonable to add “(applies to both rings and chains)” to the end of the sentence?

Well, I guess the point is that there are many specific ring protocols, but we are looking for a generic solution.
What about deleting "chains" from the sentence?

 

   Explicit routes can be established various ways,

 

established various -> established in various

OK.

 

   This is
   irrespective of the distribution method used, also applies to service
   protection over explicit routes.

 

used, also -> used, and also

OK.

 

-- Figure 5 (Section 4.1.3)

 

The UNI acronym is introduced without expansion or definition – please correct that, e.g., by defining UNI in Section 2.1.

DetNet-UNI is there among the definitions. It seems enough to me.

[David>] That’s fine – I overlooked that definition, sorry.

 

-- Figure 9 (Section 4.7.2)

 

I think I understand what’s going on, but the use of “add/remove” in the figure should be explained in associated text.

What about updating the sentence above Figure 9 to:
A packet with corresponding Flow-IDs is illustrated in Figure 9, which also indicates where Flow-ID can be added or removed.

[David>] Sure, with one minor edit: “where Flow-ID” -> “where each Flow-ID”

OK.

 

Thanks, --David


Thank you!
Janos

 

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of János Farkas
Sent: Thursday, June 28, 2018 9:09 PM
To: Lou Berger; Stewart Bryant; detnet@ietf.org >> DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

 

Dear all,

Off-line discussions among Lou, Stewart, and authors followed the discussions to properly address the WGLC comments, including the detailed comments.

A new revision of the draft has been uploaded: draft-ietf-detnet-architecture-06.

In addition to the changes already described in this thread, the following bigger changes have been made to the draft:


Section 2.1 Terms used in this document

Some definitions refined as suggested by the detailed comments

New definitions have been added:

   "allocation
           Resources are dedicated to support a DetNet flow.  Depending
           on an implementation, the resource may be reused by non-
           DetNet flows when it is not used by the DetNet flow.


   PEF     A Packet Elimination Function (PEF) eliminates duplicate
           copies of packets to prevent excess packets flooding the
           network or duplicate packets being sent out of the DetNet
           domain.  PEF can be implemented by an edge node, a relay
           node, or an end system.

  PRF     A Packet Replication Function (PRF) replicates DetNet flow
           packets and forwards them to one or more next hops in the
           DetNet domain.  The number of packet copies sent to each next
           hop is a DetNet flow specific parameter at the node doing the
           replication.  PRF can be implemented by an edge node, a relay
           node, or an end system.

   PREOF   Collective name for Packet Replication, Elimination, and
           Ordering Functions.

   POF     A Packet Ordering Function (POF) re-orders packets within a
           DetNet flow that are received out of order.  This function
           can be implemented by an edge node, a relay node, or an end
           system.

  DetNet service proxy
           Maps between App-flows and DetNet flows.

   bridged path
           A VLAN bridge uses the VLAN ID and the destination MAC
           address to select the outbound port hence the path for a
           frame."


Section 3.1 Primary goals defining the DetNet QoS

A new QoS aspect has been added:
   "o  An upper bound on out-of-order packet delivery.  It is worth
      noting that some DetNet applications are unable to tolerate any
      out-of-order delivery."


The 3rd paragraph on loss on page 8 after the bullet list has been extended to:
   "After congestion, the most important contributions to packet loss are
   typically from random media errors and equipment failures.  Service
   protection is the name for the mechanisms used by DetNet to address
   these losses.  The mechanisms employed are constrained by the
   requirement to meet the users' latency requirements.  Packet
   replication and elimination (Section 3.2.2) and packet encoding
   (Section 3.2.2.3) are described in this document to provide service
   protection; others may be found.  For instance, packet encoding can
   be used to provide service protection against random media errors,
   packet replication and elimination can be used to provide service
   protection against equipment failures.  This mechanism distributes
   the contents of DetNet flows over multiple paths in time and/or
   space, so that the loss of some of the paths does need not cause the
   loss of any packets."


3.2.2.  Service Protection

Service protection is used as a more generic term. Introductory text added:
   "Service protection aims to mitigate or eliminate packet loss due to
   equipment failures, random media and/or memory faults.  These types
   of packet loss can be greatly reduced by spreading the data over
   multiple disjoint forwarding paths.  Various service protection
   methods are described in [RFC6372], e.g., 1+1 linear protection.
   This section describes the functional details of an additional method
   in Section 3.2.2.2, which can be implemented as described in
   Section 3.2.2.3 or as specified in [I-D.ietf-detnet-dp-sol-mpls] in
   order to provide 1+n hitless protection.  The appropriate service
   protection mechanism depends on the scenario and the requirements."


New sub-section added:

"3.2.2.1.  In-Order Delivery

   Out-of-order packet delivery can be a side effect of service
   protection.  Packets delivered out-of-order impact the amount of
   buffering needed at the destination to properly process the received
   data.  Such packets also influence the jitter of a flow.  The DetNet
   service includes maximum allowed misordering as a constraint.  Zero
   misordering would be a valid service constraint to reflect that the
   end system(s) of the flow cannot tolerate any out-of-order delivery.
   Service protection may provide a mechanism to support in-order
   delivery."


3.2.2.2. Packet Replication and Elimination

New bullet added as the last one:
   "o  The Packet Ordering Function (POF) uses the sequencing information
      to re-order a DetNet flow's packets that are received out of
      order."

New sentence added after the bullet list:
"The order in which a node applies the PEF and the PRF to a DetNet
flow is implementation specific."

2nd paragraph after the bullet list has been updated to:
"Some service protection mechanisms rely on switching from one flow to
   another when a failure of a flow is detected.  Contrarily, packet
   replication and elimination combines the DetNet member flows sent
   along multiple different paths, and performs a packet-by-packet
   selection of which to discard, e.g., based on sequencing information."


3.2.3.  Explicit routes

Out-of-order aspect added to the first paragraph, which is about distributed routing:
"Furthermore, out-of-order
packet delivery can be a side effect of route changes."

New sentence added to the 3rd paragraph:
"Explicit routes can be established various
ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR)
[I-D.ietf-spring-segment-routing], via a Software Defined Networking
approach [RFC7426], with IS-IS [RFC7813], etc."

New paragraph added:
   "Out-of-order packet delivery can be a side effect of distributing a
   single flow over multiple paths especially when there is a change
   from one path to another when combining the flow.  This is
   irrespective of the distribution method used, also applies to service
   protection over explicit routes.  As described in Section 3.2.2.1,
   out-of-order packets influence the jitter of a flow and impact the
   amount of buffering needed to process the data; therefore, DetNet
   service includes maximum allowed misordering as a constraint.  The
   use of explicit routes helps to provide in-order delivery because
   there is no immediate route change with the network topology, but the
   changes are plannable as they are between the different explicit
   routes."


4.1.1. Representative Protocol Stack Model

"Explicit routes" have been added to Figure 2 with the corresponding explanation:
 "Explicit routes
           The DetNet transport layer provides mechanisms to ensure that
           fixed paths are provided for DetNet flows.  These explicit
           paths avoid the impact of network convergence."


Section 4.11 Connected islands vs. networks of v05 has been deleted because it was just a leftover from early drafts on what DetNet WG should do; which are covered by the charter anyways.


References have been cleaned up and brought up-to-date.


Refinements have been implemented in the draft according to Lou's detailed comments. They are not listed here because they are minor changes.


Best regards,
Janos

On 6/12/2018 2:48 PM, Lou Berger wrote:


Balázs,

Thanks for the response -- please see below.

----------
On June 12, 2018 4:07:35 AM Balázs Varga A <balazs.a.varga@ericsson.com> wrote:

Hi Lou, Thanks for the comments. See reactions inline. Document update in progress. Cheers Bala'zs

-----Original Message-----
From: detnet <detnet-bounces@ietf.org> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <detnet@ietf.org>; draft-ietf-detnet-architecture@ietf.org
Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

Hi,

     I have a number of high level comments on the document that I'd like to  raise below.  I also have a number of more editorial/specific comments that  I'd like to review directly with the authors and then have them report back  on changes -- if any turn out to be more substantive discussions from the  author's perspective, I'll raise these on the list separately.

...


- WRT Section 4.4.3, I think the inclusion of a distributed control plane in the "Network Plane" is inconsistent with other functional definitions and conflates where a function resides from the actual function and that whether control is implemented in a fully centralized, fully distributed or some hybrid form doesn't fundamentally change  the control function's role -- therefore I think the sections 4..4.2 and .3 should be revised accordingly
[Balázs Varga A] Agree in principal. Let's discuss the details.

Okay - I'll work with you off line and we can report back the results/proposed changes.

- In several places it's not clear that DetNet service is always a L3 service which is controlled using L3 identifiers, i.e., IP addresses -- this is true even in the MPLS service case and the TSN over MPLS case. I think this is an important point to be clear on in the document.
[Balázs Varga A] I am not sure. DetNet service is always provided over a L3 network (IP or MPLS), that is fine. However the service itself can be L2 or L3. In case of TSN Ethernet frames are transported, so it is a L2 service. In case of IP end systems IP packets are transported so it is a L3 service.


Humm - While I agree that DetNet is providing an (enhanced) L2VPN service, it is not itself providing control or service of L2 devices -- this is TSN's job.  The fact that DetNet is all about behavior of L3 nodes (i.e., IP and PW/MPLS) and not L2 nodes (i.e., TSN bridges) is something the architecture should make unambiguous.

Thanks,
Lou

Please let me know what you think.

Cheers,

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

 



On 6/12/2018 6:27 PM, Stewart Bryant wrote:

Dear Bala'zs

Thank you your for your consideration of these points. I will just pick up a few that need some further thought:

 

 

 

    DetNet transit node

           A node operating at the DetNet transport layer, that utilizes

           link layer and/or network layer switching across multiple

           links and/or sub-networks to provide paths for DetNet service

           layer functions.  Optionally provides congestion protection

           over those paths.  An MPLS LSR is an example of a DetNet

           transit node.

SB> In that example it would have to be a DetNet enable/aware LSR. An

SB> ordinary LSR would not know anything about DetNet.

 

[Balázs Varga A] No, A DetNet aware LSR would be a relay node (S-PE).


I think the confusion is what "DetNet Transport Layer" means. This
technology touches on Transport Layer in  the L4 sense, and the
Transport Network Layer as in the packet network that carries
L3 packets.

So I think that we need to clarify whether a DetNet transit node
is an S-PE (i.e. a a transit node in the DetNet layer), or a P node
(i.e. a transit node that is carrying DetNet packets but could be
carrying any sort of MPLS packet)

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

 

 

   These three techniques can be applied independently, giving eight

   possible combinations, including none (no DetNet), although some

   combinations are of wider utility than others.  This separation keeps

   the protocol stack coherent and maximizes interoperability with

   existing and developing standards in this (IETF) and other Standards

   Development Organizations.  Some examples of typical expected

   combinations:

 

   o  Explicit routes plus service protection are exactly the techniques

      employed by [HSR-PRP].  Explicit routes are achieved by limiting

      the physical topology of the network, and the sequentialization,

      replication, and duplicate elimination are facilitated by packet

      tags added at the front or the end of Ethernet frames.

 

SB> ER can be done virtually as well as physically. RSVP is a type of

SB> ER, as is Adj-SID based SR, and we can design other types.

 

[Balázs Varga A] Agree, but these are examples. Statement is for HSR-PRP.

So the question is whether we should expand the set of examples, particularly
to more accessible ones.

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

 

 

 

                    Packet replication and elimination

 

                > > > > > > > > > relay > > > > > > > >

               > /------------+ R node E +------------\ >

              > /                  v + ^               \ >

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

              > \                  v + ^               / >

               > \------------+ R relay E +-----------/ >

                > > > > > > > > >  node > > > > > > > >

 

                                 Figure 1

 

   Packet replication and elimination does not react to and correct

   failures; it is entirely passive.  Thus, intermittent failures,

 

SB> I think it copes with intermittent failures OK.

 

[Balázs Varga A] Yes, PRF and PEF can eliminate the effect of such failures. But text

intends to say that it is passive. It is not reacting to such failures. No change in text.

 


You say that PREF does not correct failures. I would contend that is exactly
what it does. Sure it does not react but it does correct, and it does
address intermittent failures.

 

===========

 

   transported between the peer end systems.  Therefore, the following

   possible types / formats of a DetNet flow are distinguished in this

   document:

 

   o  App-flow: native format of a DetNet flow.  It does not contain any

      DetNet related attributes.

 

   o  DetNet-t-flow: specific format of a DetNet flow.  Only requires

      the congestion / latency features provided by the Detnet transport

      layer.

 

   o  DetNet-s-flow: specific format of a DetNet flow.  Only requires

      the replication/elimination feature ensured by the DetNet service

      layer.

 

   o  DetNet-st-flow: specific format of a DetNet flow.  It requires

      both DetNet service layer and DetNet transport layer functions

      during forwarding.

SB> I find the relisting of these types confusing. Wheren't they defined

SB> in the section above?

 

[Balázs Varga A] This is inline with the previous section " Grouping of end systems ".

Surely if we have defined them we never need to do anything but name them in
later sections. Redefinition is never a good idea because it often leads to
conflicting definitions.

 

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

 

 

 

   [HSR-PRP]  IEC, "High availability seamless redundancy (HSR) is a

              further development of the PRP approach, although HSR

              functions primarily as a protocol for creating media

              redundancy while PRP, as described in the previous

              section, creates network redundancy.  PRP and HSR are both

              described in the IEC 62439 3 standard.",

              <http://webstore.iec.ch/webstore/webstore.nsf/

              artnum/046615!opendocument>.

 

SB> Not available at the time of this review, but my recollection is

SB> that this is not readily available without paying a large fee.


If we decide that this is essential as a key reference, there needs to be
some suitable text, as this will get raised a number of times between
here an publication as first the directorates and then the ADs run
into this.

 

===========

 

 

 

   [ISA95]    ANSI/ISA, "Enterprise-Control System Integration Part 1:

              Models and Terminology", 2000,

              <https://www.isa.org/isa95/>.

 

SB> Should that be 2000, or 2010.

SB> Note that this seems to be a very expensive document to access.

 

You did not comment on the correctness of the reference.

 


Best Regards

Stewart

 

 

 

 

_______________________________________________
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

--------------05EDA65D858B1E878B60C855-- From nobody Fri Aug 3 08:59:37 2018 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 95A8E131060 for ; Fri, 3 Aug 2018 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 UiO8jho2WR_s for ; Fri, 3 Aug 2018 08:59:23 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 6718113105F for ; Fri, 3 Aug 2018 08:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533311958; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DazQfWDLYkcwcfxVxTqW1smMvgh2xJVH2NjHsCJRiTs=; b=YBmYbUiBWOedGwSoUvmZ/+sr1nj7xU2JFHofnvE/CN+gVTXHujV/m5YQiS0ndiRY Fxm2YXGLYtkYTVwvhE7NS8upjONJ0lGbys35JhB9S8eu4L1z2gnONA231URh5I8S ESZ1yaja9xr5gv+RZ5xa4Ydr4Si4HFU3qlm9iR/ed74=; X-AuditID: c1b4fb25-b05ff70000006cb9-d9-5b647bd6192a Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AE.CA.27833.6DB746B5; Fri, 3 Aug 2018 17:59:18 +0200 (CEST) Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 3 Aug 2018 17:59:17 +0200 Received: from [159.107.143.207] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.191) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 3 Aug 2018 17:59:17 +0200 To: Vladimir Vassilev References: <153163104655.12797.4549822574205791661.idtracker@ietfa.amsl.com> <1671ad91-5627-fedf-ef1c-9a2a790accd4@transpacket.com> CC: "netmod@ietf.org" , , "ieee-ietf-coord@ietf.org" From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: Date: Fri, 3 Aug 2018 17:59:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1671ad91-5627-fedf-ef1c-9a2a790accd4@transpacket.com> Content-Type: multipart/alternative; boundary="------------FB280D5B0EFA0EC005ED21E8" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM2J7pe616pRog86nUha/P81msbi05h+T xfyLjawWp+Z/Y3Vg8Viy5CeTx9UPJ1kCmKK4bFJSczLLUov07RK4Mhbfu8BUMM2rYv0C0QbG k9ZdjJwcEgImEhcWzGDqYuTiEBI4yijxvfUXlPOVUeLevyUImQkb+5hAWoQFUiVWz77F2sXI wSEiYCCx+Yg1RE0bo8T0+z0sIDXMAsUSV9pegtWzCdhL3L20gRnE5gWyb89ZzgpiswioSNx9 tZINZI6oQIzE+r4EiBJBiZMzn4CN4RRwlpi9bQozSAmzQJjE5/3VIGEhATWJT28fsk9gFJiF pGMWQtUssBssJGbOP88IYctLbH87hxnC1pBonTOXHSbevHU28wJGtlWMosWpxUm56UbGeqlF mcnFxfl5enmpJZsYgeF+cMtv1R2Ml984HmIU4GBU4uGdlZUSLcSaWFZcmXuIUYKDWUmE921n crQQb0piZVVqUX58UWlOavEhRmkOFiVx3ofmm6OEBNITS1KzU1MLUotgskwcnFINjKmz25c3 suapfjs7s+NJR9o+noLIHee43F+mOfzf9OBmvonP/hpub4nz1clT3qsIvljQqNH7uoJNUlQ8 6UmoPH+i6Zmj9cdO3/uouPpHtcqiDoPjW+wmTfytznFXbGLhoi9ibpYp87dvO5z/zHvBBFF9 Z+kJr5K2eOhPKjnw2e7lfUXeux8Y/yuxFGckGmoxFxUnAgCWUQnEcwIAAA== Archived-At: Subject: Re: [Detnet] Fwd: New Version Notification for draft-vassilev-netmod-network-bridge-00.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Fri, 03 Aug 2018 15:59:25 -0000 --------------FB280D5B0EFA0EC005ED21E8 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Vladimir, Bridging including bridge management belong to IEEE 802.1: https://1.ieee802.org/. You may consider contributing to IEEE 802.1. The next Interim is hosed by your company in Oslo: https://1.ieee802.org/meetings. IEEE 802.1Qcp is the basic bridge management specification, which is an approved draft standard to be published soon: http://standards.ieee.org/findstds/standard/802.1Qcp-2018.html. (The archived web page of the finished project: https://1.ieee802.org/tsn/802-1qcp.) The pages of the ongoing projects are available via the TSN page: https://1.ieee802.org/tsn/#Ongoing_TSN_Projects, including P802.1Qcw (https://1.ieee802.org/tsn/802-1qcw/), which specifies YANG for various bridge scheduling mechanisms. Best regards, Janos On 7/17/2018 4:26 PM, Vladimir Vassilev wrote: > Hi, > > I have submitted a draft > https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/ > that proposes a model for network bridge management based on the > concept of flows. The model has 2 components 1. Forwarding based on > flows. 2. Scheduling/QoS based on gate controller topologies that > provide a new and very generic way of modeling and managing the actual > scheduler design and map the flows to scheduler topology inputs. > > There is similar work on the flow based forwarding in detnet however I > am not sure detnet is the right workgroup to be defining the flow > model. I think the flow concept is important and general. It is as > significant as the concept of interfaces and is not only relevant to > detnet. Let me know what is your opinion of the draft and the proposed > network bridge concept. > > Vladimir > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-vassilev-netmod-network-bridge-00.txt > Date: Sat, 14 Jul 2018 22:04:06 -0700 > From: internet-drafts@ietf.org > To: Vladimir Vassilev > > > > A new version of I-D, draft-vassilev-netmod-network-bridge-00.txt > has been successfully submitted by Vladimir Vassilev and posted to the > IETF repository. > > Name: draft-vassilev-netmod-network-bridge > Revision: 00 > Title: A YANG Data Model for Network Bridge Management > Document date: 2018-07-14 > Group: Individual Submission > Pages: 44 > URL: > https://www.ietf.org/internet-drafts/draft-vassilev-netmod-network-bridge-00.txt > Status: > https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/ > Htmlized: > https://tools.ietf.org/html/draft-vassilev-netmod-network-bridge-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-vassilev-netmod-network-bridge > > > Abstract: > This document introduces new YANG model of a network bridge. > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet --------------FB280D5B0EFA0EC005ED21E8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Vladimir,

Bridging including bridge management belong to IEEE 802.1: https://1.ieee802.org/. You may consider contributing to IEEE 802.1. The next Interim is hosed by your company in Oslo: https://1.ieee802.org/meetings.

IEEE 802.1Qcp is the basic bridge management specification, which is an approved draft standard to be published soon: http://standards.ieee.org/findstds/standard/802.1Qcp-2018.html. (The archived web page of the finished project: https://1.ieee802.org/tsn/802-1qcp.)

The pages of the ongoing projects are available via the TSN page: https://1.ieee802.org/tsn/#Ongoing_TSN_Projects, including P802.1Qcw (https://1.ieee802.org/tsn/802-1qcw/), which specifies YANG for various bridge scheduling mechanisms.

Best regards,
Janos


On 7/17/2018 4:26 PM, Vladimir Vassilev wrote:
Hi,

I have submitted a draft https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/ that proposes a model for network bridge management based on the concept of flows. The model has 2 components 1. Forwarding based on flows. 2. Scheduling/QoS based on gate controller topologies that provide a new and very generic way of modeling and managing the actual scheduler design and map the flows to scheduler topology inputs.

There is similar work on the flow based forwarding in detnet however I am not sure detnet is the right workgroup to be defining the flow model.  I think the flow concept is important and general. It is as significant as the concept of interfaces and is not only relevant to detnet. Let me know what is your opinion of the draft and the proposed network bridge concept.

Vladimir

-------- Forwarded Message --------
Subject:     New Version Notification for draft-vassilev-netmod-network-bridge-00.txt
Date:     Sat, 14 Jul 2018 22:04:06 -0700
From:     internet-drafts@ietf.org
To:     Vladimir Vassilev <vladimir@transpacket.com>



A new version of I-D, draft-vassilev-netmod-network-bridge-00.txt
has been successfully submitted by Vladimir Vassilev and posted to the
IETF repository.

Name:        draft-vassilev-netmod-network-bridge
Revision:    00
Title:        A YANG Data Model for Network Bridge Management
Document date:    2018-07-14
Group:        Individual Submission
Pages:        44
URL:            https://www.ietf.org/internet-drafts/draft-vassilev-netmod-network-bridge-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/
Htmlized:       https://tools.ietf.org/html/draft-vassilev-netmod-network-bridge-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vassilev-netmod-network-bridge


Abstract:
   This document introduces new YANG model of a network bridge.

                                                                                 

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

--------------FB280D5B0EFA0EC005ED21E8-- From nobody Fri Aug 3 09:04:01 2018 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 987F913105D for ; Fri, 3 Aug 2018 09:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 QvfMQZtA8IgY for ; Fri, 3 Aug 2018 09:03:55 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 A47F9131057 for ; Fri, 3 Aug 2018 09:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533312231; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SbsS9sbbd6w+H0Anzb1NCNdqAqadVPpuUvsmAi9paxE=; b=Dc2SauKNSM8gTy/flU/h0VPEsEuPPtjqWyknkyNzzd4cX2uHVl3xY6ga+bCBUgQT GHEDGm0fdSA9tIbkfj/Rz53fUP3ztQduZfcmH3pRrbSwdiUYqqLP19sFrnzBrzsD ZL8w0Xi5xujJrD36CjoZHKAhwFJfp4RJsts/sGJgr+s=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-16-5b647ce6789e Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 24.C4.22015.6EC746B5; Fri, 3 Aug 2018 18:03:51 +0200 (CEST) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 3 Aug 2018 18:03:48 +0200 Received: from [159.107.143.207] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.185) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 3 Aug 2018 18:03:47 +0200 To: DetNet WG , "BRUNGARD, DEBORAH A" , Lou Berger , "Black, David" , Greg Mirsky , "Andrew G. Malis" References: <99657d22-f9e4-8a1a-27de-6997900f727e@labn.net> <4900e61d-8399-8765-0ecb-181dc3c9ff5a@ericsson.com> <61d00506-b546-6c80-044f-b5bdb243ae23@ericsson.com> <3DF0466E9510274382F5B74499ACD6F8D383DD@DFWPML704-CHM.exmail.huawei.com> <164af982488.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> CC: "draft-ietf-detnet-architecture@ietf.org" From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <379f3d4f-f427-c159-be8e-1ba863fba98d@ericsson.com> Date: Fri, 3 Aug 2018 18:03:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------94226A4012DE1CC02F361C5F" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbG9XPd5TUq0wZQXLBann59is/g4azGL xeWubnaL359ms1h8+DaTxeLbtKesFh3Nb1kc2D1e9s9h9Jg0cwazx85Zd9k9liz5yeTxYVMz WwBrFJdNSmpOZllqkb5dAlfG8XMnmApWXBGoWDr/JUsD4779bF2MnBwSAiYSa16vZu1i5OIQ EjjKKDFxax+U85VRYuHZ7yxwmZZ/c5hBWoQFzCVuTjgNlhARuMsocXLNJzaIqmfsEm/nvASr YhaIlFj74B0TiM0mYC9x99IGsDgvkN104QHYchYBFYnGtk/sXYwcHKICMRLr+xIgSgQlTs58 wgJicwo4SJw42ckGMTJM4uK6C2C2kICaxKe3D9knMArMQtIyC0nZLKCpzEDbHmwtgwjLSzRv nc0MYetLXL9znxVZfAEj2ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwLg5uOW37g7G1a8d DzEKcDAq8fA65aREC7EmlhVX5h5ilOBgVhLhfduZHC3Em5JYWZValB9fVJqTWnyIUZqDRUmc V2/VnighgfTEktTs1NSC1CKYLBMHp1QDI0/QIrX48KV8QrO8Sl5EzNmisDNoSwjHiYf72z+m OR9Vqd/vPi1MLpJZpJTTp1nie3fz6im3BeIS/DWOm+2V3n/aP2jz8XqR9PUHCz59zrjsu8FT 9uHTaUadp/+6PYt5pjRbT/RqaM6i5ZPfODJMSYxYeE/LJu1KwMPDT0OPR3bVvFoc3RT3Xoml OCPRUIu5qDgRAB2ABy+XAgAA Archived-At: Subject: Re: [Detnet] draft-ietf-detnet-architecture-07 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Fri, 03 Aug 2018 16:04:01 -0000 --------------94226A4012DE1CC02F361C5F Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit I forgot to mention that the next step is gated by August vacations. Best regards, Jnos On 8/3/2018 5:39 PM, Jnos Farkas wrote: > Hi, > > We have updated the architecture draft to resolve the extended WGLC > comments. The current revision is v07: > https://tools.ietf.org/html/draft-ietf-detnet-architecture-07. > > All WGLC comments have been addressed; most of them can be found > below. Some further nits have been also resolved. > > The main changes: > > 1) > Based on the last discussion item below, a new sentence has been added > to congestion protection in section 3.1, where it is first described: > "Note that congestion > protection provided via congestion detection and notification is > explicitly excluded from consideration in DetNet, as it serves a > different set of applications." > > (Note that throttling/throttled has been already part of the text, > there are three occurrences.) > > 2) > Based on the discussion below, the following introductory text has > been added to section 4.1: > "DetNet functionality (Section 3) is implemented in two adjacent > layers in the protocol stack: the DetNet service layer and the DetNet > transport layer. The DetNet service layer provides DetNet service, > e.g., service protection, to higher layers in the protocol stack and > applications. The DetNet transport layer supports DetNet service in > the underlying network, e.g., by providing explicit routes and > congestion protection to DetNet flows." > > Consequently, the definition of DetNet service layer has been updated to: > "The layer at which A DetNet service, e.g., service protection > is provided." > > 3) > Based on > https://www.ietf.org/mail-archive/web/detnet/current/msg01577.html, > the following sentence has been added to the OAM paragraph in section > 4.1.1: > "Active and hybrid OAM > methods require additional bandwidth to perform fault management and > performance monitoring of the DetNet domain. OAM may, for instance, > generate special test probes or add OAM information into the data > packet." > > 4) > Based on the consensus reached at the DetNet session at IETF 102, > Controller Plane Entity (CPE) has been replaced with Controller Plane > Function (CPF). > > 5) > In order to clarify, the last sentence of the introduction has been > updated to: > "DetNet can > accommodate various time synchronization techniques and profiles that > are defined elsewhere to address the needs of different market > segments." > > 6) > In order to clarify, the packet loss bullet in section 3.1 has been > updated to: > "Packet loss ratio, under various assumptions as to the operational > states of the nodes and links." > > 7) > DetNet t-aware has been updated to: > "A DetNet transport-aware system. It knows about > some TSN functions (e.g., reservation), but not about service > protection." > > 8) > DetNet s-aware has been updated to: > "DetNet service-aware system. It supplies > sequence numbers, but doesnt know about zero congestion loss." > > > Best regards, > Jnos > > > On 7/19/2018 2:04 AM, Prof. Diego Dujovne wrote: >> +1 >> >> El mi., 18 de jul. de 2018 19:53, Black, David > > escribi: >> >> +1, Thanks, --David >> >> *From:*Lou Berger [mailto:lberger@labn.net >> ] >> *Sent:* Wednesday, July 18, 2018 6:52 PM >> *To:* Norman Finn; Janos Farkas; Black, David >> *Cc:* DetNet WG >> *Subject:* Re: [Detnet] WG Last Call: >> draft-ietf-detnet-architecture-05 >> >> This sounds sensible to me... >> >> Lou >> >> ------------------------------------------------------------------------ >> >> On July 18, 2018 6:47:01 PM Norman Finn >> > > wrote: >> >> "Congestion loss protection" is better than "congestion >> protection". That's good. >> >> It's a big change, and makes the document unnecessarily >> wordy. That's bad. >> >> I would use "congestion protection" but explain somewhere >> that we are not talking about source throttling. >> >> And if adding that explanation is difficult or controversial, >> I would stick with "congestion protection". >> >> -- Norm >> >> ------------------------------------------------------------------------ >> >> *From:*detnet [detnet-bounces@ietf.org >> ] on behalf of Janos Farkas >> [Janos.Farkas@ericsson.com ] >> *Sent:* Wednesday, July 18, 2018 2:26 PM >> *To:* Black, David >> *Cc:* DetNet WG >> *Subject:* Re: [Detnet] WG Last Call: >> draft-ietf-detnet-architecture-05 >> >> Both congestion protection and congestion loss protection >> work for me. >> >> Note that the architecture document is quite populated with >> the term congestion protection. I do not know the other >> documents by heart. >> >> So it would be a bit of a change.. >> >> Id like to have the groups opinion before making such a >> change, e.g., any objections? >> >> Thanks, >> >> Janos >> >> *From:*Black, David > > >> *Sent:* Wednesday, July 18, 2018 8:19 PM >> *To:* Janos Farkas > > >> *Cc:* DetNet WG > >> *Subject:* RE: [Detnet] WG Last Call: >> draft-ietf-detnet-architecture-05 >> >> Hi Janos, >> >> That text works nicely. In briefly talking to Lou, a related >> suggestion surfaced: congestion protection -> congestion >> loss protection where possible (may need to be abbreviated >> in the Figure) . >> >> This change would make it clearer that the primary focus is >> protection from losses caused by congestion as opposed to >> protection from all congestion. DetNet should be able to >> tolerate some modest congestion (e.g., in nodes that dont >> have reserved DetNet resources) as long as delivery is >> reliable and timely. >> >> Thanks, --David >> >> *From:*Janos Farkas [mailto:Janos.Farkas@ericsson.com] >> *Sent:* Wednesday, July 18, 2018 11:45 AM >> *To:* Black, David >> *Cc:* DetNet WG >> *Subject:* RE: [Detnet] WG Last Call: >> draft-ietf-detnet-architecture-05 >> >> Hi David, >> >> This implies updating the definition of the DetNet service >> layer, e.g., to: >> >> DetNet service layer >> >> The layer at which A DetNet Service, e.g., service protection >> is provided. >> >> The definition of the DetNet transport layer remains the same: >> >> DetNet transport layer >> >> The layer that optionally provides congestion protection for >> >> DetNet flows over paths provided by the underlying network. >> >> Regards, >> >> Janos >> >> *From:*Black, David > > >> *Sent:* Monday, July 16, 2018 3:21 PM >> *To:* Janos Farkas > > >> *Cc:* DetNet WG > >> *Subject:* RE: [Detnet] WG Last Call: >> draft-ietf-detnet-architecture-05 >> >> Dont use congestion protection in the definitions for both >> levels. >> >> Thanks, --David >> >> *From:*Jnos Farkas [mailto:janos.farkas@ericsson.com] >> *Sent:* Sunday, July 15, 2018 10:43 PM >> *To:* Black, David >> *Cc:* DetNet WG >> *Subject:* Re: [Detnet] WG Last Call: >> draft-ietf-detnet-architecture-05 >> >> Thank you David! >> >> I think we are set. :-) >> >> You got a point, we should update >> "DetNet service layer is the layer at which A DetNet Service, >> such as congestion or service protection is provided." >> to >> "DetNet service layer is the layer at which A DetNet Service, >> such as congestion protection and/or service protection is >> provided." >> in the definitions as well to make it clear. >> >> Thanks, >> Janos >> >> On 7/16/2018 3:03 AM, Black, David wrote: >> >> Moving the only two open items to the top >> >> -- Section 4 >> >> > We could add some introductory text to 4.1 or 4.1.1, for >> instance: >> > The functionality needed for DetNet (Section 3) are >> implemented in the DetNet layer which comprises the >> DetNet service layer and the DetNet transport layer. >> >> > The DetNet service layer functions rely on flow >> identification and sequencing. The DetNet transport layer >> function may rely on flow identification. >> > >> > What do you think? >> >> I prefer functional (what it does) characterization to >> mechanistic (how it works) characterization in an >> overview, e.g., excerpting from what I originally wrote: >> >> The DetNet Service layer provides timely reliable >> in-order DetNet flow delivery to applications that use >> DetNet. >> >> The DetNet Transport layer insulates DetNet flows from >> interference by network mechanisms, primarily queuing and >> routing >> >> I understand the principle. >> >> What about just copying the two definitions here: >> DetNet service layer is the layer at which A DetNet >> Service, such as congestion or service protection is >> provided. >> DetNet transport layer optionally provides congestion >> protection for DetNet flows over paths provided by the >> underlying network. >> >> David> Yes, that works, although I dont think >> congestion was meant to be included in the first >> definition >> >> Many real-time networks rely on physical rings or >> chains of two-port >> >> devices, with a relatively simple ring control protocol. >> >> How does a ring control protocol control chains? >> Suggest: ring control protocol -> control protocol >> >> Also, are paired chains between common endpoints >> intended, or a more general notion of chains? >> >> This text refers to typical factory deployment, which is >> chain or ring.. >> It seems better to keep ring control protocol because >> they are often very different from generic control >> protocols applicable to mesh networks. >> >> Would flipping chain and ring resolve your concern? >> >> Many real-time networks rely on physical chains or >> rings of two-port >> >> devices, with a relatively simple ring control protocol. >> >> */[David>] /*It feels like ring control protocol is an >> important phrase to retain. In the original text, would >> it be reasonable to add (applies to both rings and >> chains) to the end of the sentence? >> >> Well, I guess the point is that there are many specific >> ring protocols, but we are looking for a generic solution. >> What about deleting "chains" from the sentence? >> >> David> Yes, if the sentence is all about rings, its clear. >> >> Thanks, --David >> >> *From:*Jnos Farkas [mailto:janos.farkas@ericsson.com] >> *Sent:* Sunday, July 15, 2018 7:25 PM >> *To:* Black, David >> *Cc:* DetNet WG >> *Subject:* Re: [Detnet] WG Last Call: >> draft-ietf-detnet-architecture-05 >> >> Hi David, >> >> Please see in-line. >> >> Thank you! >> Janos >> >> On 7/6/2018 11:50 PM, Black, David wrote: >> >> -- Bridged path definition >> >> > Or should we do something else? >> >> > There is only one occurrence of "bridged path" in >> the text in brackets. >> >> That sounds like a better suggestion change that >> occurrence and remove the definition of bridged >> path from the draft. That occurrence is in Section >> 4.1.1: >> >> Congestion protection >> >> The DetNet transport layer provides congestion >> protection. >> >> See Section 4.5. The actual queuing and shaping >> mechanisms >> >> are typically provided by underlying subnet layers, >> these can >> >> be closely associated with the means of providing >> paths for >> >> DetNet flows (e.g., MPLS LSPs or bridged >> paths), the path and >> >> the congestion protection are conflated in this figure. >> >> Perhaps: (e.g., MPLS LSPs or bridged paths) -> (MPLS >> LSPs or other network paths) >> >> or just delete the entire parenthetical example. >> >> OK. Let's just delete the entire parenthetical example. >> >> -- Section 4 >> >> > We could add some introductory text to 4.1 or 4.1.1, >> for instance: >> > The functionality needed for DetNet (Section 3) are >> implemented in the DetNet layer which comprises the >> DetNet service layer and the DetNet transport layer. >> >> > The DetNet service layer functions rely on flow >> identification and sequencing. The DetNet transport >> layer function may rely on flow identification. >> > >> > What do you think? >> >> I prefer functional (what it does) characterization >> to mechanistic (how it works) characterization in an >> overview, e.g., excerpting from what I originally wrote: >> >> * The DetNet Service layer provides timely reliable >> in-order DetNet flow delivery to applications >> that use DetNet. >> * The DetNet Transport layer insulates DetNet flows >> from interference by network mechanisms, >> primarily queuing and routing >> >> I understand the principle. >> >> What about just copying the two definitions here: >> DetNet service layer is the layer at which A DetNet >> Service, such as congestion or service protection is >> provided. >> DetNet transport layer optionally provides congestion >> protection for DetNet flows over paths provided by the >> underlying network. >> >> >> > Should we also rearrange, e.g., indent the text >> after Figure 2 such that >> > Packet sequencing, Duplicate elimination, Flow >> replication, Flow merging, Packet encoding, and >> Packet decoding get under Service layer >> > and >> > Congestion protection and Explicit routes get under >> Transport layer? >> >> No, I dont think thats necessary Figure 2 >> provides sufficient structure. >> >> OK. >> >> Plus a few more minor comments inline >> >> Thanks, --David >> >> *From:*Jnos Farkas [mailto:janos.farkas@ericsson.com] >> *Sent:* Wednesday, July 4, 2018 2:15 PM >> *To:* Black, David >> *Cc:* DetNet WG >> *Subject:* Re: [Detnet] WG Last Call: >> draft-ietf-detnet-architecture-05 >> >> Hi David, >> >> Thank you very much for your review and comments! >> >> Please see in-line. >> >> On 6/29/2018 4:10 PM, Black, David wrote: >> >> The -06 version of this draft is much improved >> over the -05 version lots of diligent work by >> the authors is evident and appreciated. >> >> I have two minor content concerns and some >> smaller editorial items. >> >> ** Content >> >> -- Section 2.2 >> >> The definition of bridged path looks like a >> definition of bridged forwarding the >> definition needs to encompass the notion of a >> path that involves more than one bridge. >> >> bridged path >> >> A VLAN bridge uses the VLAN ID and the >> destination MAC >> >> address to select the outbound port >> hence the path for a >> >> frame. >> >> You are right, it looks like the emphasis is on >> bridge forwarding rather than path. >> However, the superposition of the outbound ports >> provides a path, which was tried to be captured by >> "hence the path". >> The idea was to keep it simple not dive into the >> details, which are not necessary in this document. >> >> Would it be good to update to: >> >> bridged path >> >> A VLAN bridge uses the VLAN ID and the >> destination MAC >> >> address to select the outbound port. The >> superposition >> >> of the outbound ports is the path for a frame. >> >> ? >> >> Or should we do something else? >> There is only one occurrence of "bridged path" in the >> text in brackets. >> >> -- Section 4 >> >> Figure 2 in Section 4.1.1 introduces the Detnet >> service and transport layers. The associated >> text quickly dives into explaining the >> functionality in those layers, but it would be >> helpful to start with an initial high level >> description of each of those layers that helps >> motivate their separation. It appears that: >> >> - The DetNet Service layer provides timely >> reliable in-order DetNet flow delivery to >> applications that use DetNet. A DetNet flow at >> the top of the DetNet Service layer may or may >> not be a compound flow at the bottom of that layer. >> >> - The DetNet Transport layer insulates DetNet >> flows (at the bottom of the DetNet Service layer) >> from interference by network mechanisms, >> primarily queuing and routing, where congestion >> is an indication of queueing interference. A >> DetNet flow at the top of the DetNet Transport >> layer may or may not be a member flow that is >> part of a compound flow, depending on what is >> done in the DetNet Service layer. >> >> >> You are right, section 4 jumps into the details >> without much of an introduction. I guess we had a >> kind of chicken and egg problem here. Figure 4 >> provides a higher level view than Figure 2. However, >> Figure 4 captures different aspects, dives into the >> details of data plane options. So, it seems better to >> keep the order. >> >> We could add some introductory text to 4.1 or 4.1.1, >> for instance: >> The functionality needed for DetNet (Section 3) are >> implemented in the DetNet layer which comprises the >> DetNet service layer and the DetNet transport layer. >> The DetNet service layer functions rely on flow >> identification and sequencing. The DetNet transport >> layer function may rely on flow identification. >> >> What do you think? >> >> Should we also rearrange, e.g., indent the text after >> Figure 2 such that >> Packet sequencing, Duplicate elimination, Flow >> replication, Flow merging, Packet encoding, and >> Packet decoding get under Service layer >> and >> Congestion protection and Explicit routes get under >> Transport layer? >> >> Theres a related paragraph of text between >> Figures 3 and 4 in Section 4.1.2, but it doesnt >> provide useful intuition about which >> functionality belongs in which layer. >> >> ** Editorial >> >> -- Section 2.1 >> >> expected seems off in the definition of >> reservation: >> >> reservation >> >> The set of resources allocated between a source >> and one or >> >> more destinations through transit nodes and subnets >> >> associated with a DetNet flow, to provide the >> expected DetNet >> >> Service. >> >> Suggest either to provide the provisioned DetNet >> Service to that flow >> >> I like this one, will update to this one. >> >> or to provide the specified DetNet Service to >> that flow. >> >> -- Section 3.1 >> >> o An upper bound on out-of-order packet >> delivery. It is worth >> >> noting that some DetNet applications are >> unable to tolerate any >> >> out-of-order delivery. >> >> Is that a sequence bound or a time bound or >> both? I suspect that a sequence bound (maximum >> degree of reordering in a flow, independent of >> flow rate) was intended. An analogous >> clarification would be helpful in section 3.2.2.1 . >> >> It is intentionally kept high level in the >> architecture draft. Details are to be provided by the >> flow information model draft. Please see my previous >> mail: >> https://mailarchive.ietf.org/arch/msg/detnet/AWG2eemg_AWsvF2FwtREyd_xtC8. >> >> */[David>] /*OK. >> >> -- Section 3.2.3 >> >> I dont understand defined in: >> >> Even the use of >> >> redundant paths through a network defined, >> e.g., by [RFC6372] do not >> >> eliminate the chances of packet loss. >> >> Was e.g., as defined by [RFC6372], intended? >> >> Yes, this was the intention, will update to this one. >> >> Many real-time networks rely on physical rings >> or chains of two-port >> >> devices, with a relatively simple ring control >> protocol. >> >> How does a ring control protocol control >> chains? Suggest: ring control protocol -> >> control protocol >> >> Also, are paired chains between common endpoints >> intended, or a more general notion of chains? >> >> This text refers to typical factory deployment, which >> is chain or ring. >> It seems better to keep ring control protocol >> because they are often very different from generic >> control protocols applicable to mesh networks. >> >> Would flipping chain and ring resolve your concern? >> >> Many real-time networks rely on physical chains or >> rings of two-port >> >> devices, with a relatively simple ring control >> protocol. >> >> */[David>] /*It feels like ring control >> protocol is an important phrase to retain. In >> the original text, would it be reasonable to add >> (applies to both rings and chains) to the end >> of the sentence? >> >> Well, I guess the point is that there are many specific >> ring protocols, but we are looking for a generic solution. >> What about deleting "chains" from the sentence? >> >> Explicit routes can be established various ways, >> >> established various -> established in various >> >> OK. >> >> This is >> >> irrespective of the distribution method used, >> also applies to service >> >> protection over explicit routes. >> >> used, also -> used, and also >> >> OK. >> >> -- Figure 5 (Section 4.1.3) >> >> The UNI acronym is introduced without expansion >> or definition please correct that, e.g., by >> defining UNI in Section 2.1. >> >> DetNet-UNI is there among the definitions. It seems >> enough to me. >> >> */[David>] /*Thats fine I overlooked that >> definition, sorry. >> >> -- Figure 9 (Section 4.7.2) >> >> I think I understand whats going on, but the use >> of add/remove in the figure should be explained >> in associated text. >> >> What about updating the sentence above Figure 9 to: >> A packet with corresponding Flow-IDs is illustrated >> in Figure 9, which also indicates where Flow-ID can >> be added or removed. >> >> */[David>] /*Sure, with one minor edit: where >> Flow-ID -> where each Flow-ID >> >> OK. >> >> Thanks, --David >> >> >> Thank you! >> Janos >> >> *From:*detnet [mailto:detnet-bounces@ietf.org] >> *On Behalf Of *Jnos Farkas >> *Sent:* Thursday, June 28, 2018 9:09 PM >> *To:* Lou Berger; Stewart Bryant; detnet@ietf.org >> >> DetNet WG >> *Subject:* Re: [Detnet] WG Last Call: >> draft-ietf-detnet-architecture-05 >> >> Dear all, >> >> Off-line discussions among Lou, Stewart, and >> authors followed the discussions to properly >> address the WGLC comments, including the detailed >> comments. >> >> A new revision of the draft has been uploaded: >> draft-ietf-detnet-architecture-06. >> >> In addition to the changes already described in >> this thread, the following bigger changes have >> been made to the draft: >> >> >> *Section 2.1 Terms used in this document* >> >> Some definitions refined as suggested by the >> detailed comments >> >> New definitions have been added: >> >> "allocation >> Resources are dedicated to support a >> DetNet flow. Depending >> on an implementation, the resource may >> be reused by non- >> DetNet flows when it is not used by >> the DetNet flow. >> >> >> PEF A Packet Elimination Function (PEF) >> eliminates duplicate >> copies of packets to prevent excess >> packets flooding the >> network or duplicate packets being >> sent out of the DetNet >> domain. PEF can be implemented by an >> edge node, a relay >> node, or an end system. >> >> PRF A Packet Replication Function (PRF) >> replicates DetNet flow >> packets and forwards them to one or >> more next hops in the >> DetNet domain. The number of packet >> copies sent to each next >> hop is a DetNet flow specific >> parameter at the node doing the >> replication. PRF can be implemented by an edge >> node, a relay >> node, or an end system. >> >> PREOF Collective name for Packet >> Replication, Elimination, and >> Ordering Functions. >> >> POF A Packet Ordering Function (POF) >> re-orders packets within a >> DetNet flow that are received out of >> order. This function >> can be implemented by an edge node, a >> relay node, or an end >> system. >> >> DetNet service proxy >> Maps between App-flows and DetNet flows. >> >> bridged path >> A VLAN bridge uses the VLAN ID and the >> destination MAC >> address to select the outbound port >> hence the path for a >> frame." >> >> >> *Section 3.1 Primary goals defining the DetNet QoS* >> >> A new QoS aspect has been added: >> "o An upper bound on out-of-order packet >> delivery. It is worth >> noting that some DetNet applications are >> unable to tolerate any >> out-of-order delivery." >> >> >> The 3rd paragraph on loss on page 8 after the >> bullet list has been extended to: >> "After congestion, the most important >> contributions to packet loss are >> typically from random media errors and >> equipment failures. Service >> protection is the name for the mechanisms used >> by DetNet to address >> these losses. The mechanisms employed are >> constrained by the >> requirement to meet the users' latency >> requirements. Packet >> replication and elimination (Section 3.2.2) >> and packet encoding >> (Section 3.2.2.3) are described in this >> document to provide service >> protection; others may be found. For >> instance, packet encoding can >> be used to provide service protection against >> random media errors, >> packet replication and elimination can be used >> to provide service >> protection against equipment failures. This >> mechanism distributes >> the contents of DetNet flows over multiple >> paths in time and/or >> space, so that the loss of some of the paths >> does need not cause the >> loss of any packets." >> >> >> *3.2.2. Service Protection* >> >> Service protection is used as a more generic >> term. Introductory text added: >> "Service protection aims to mitigate or >> eliminate packet loss due to >> equipment failures, random media and/or memory >> faults. These types >> of packet loss can be greatly reduced by >> spreading the data over >> multiple disjoint forwarding paths. Various >> service protection >> methods are described in [RFC6372], e.g., 1+1 >> linear protection. >> This section describes the functional details >> of an additional method >> in Section 3.2.2.2, which can be implemented >> as described in >> Section 3.2.2.3 or as specified in >> [I-D.ietf-detnet-dp-sol-mpls] in >> order to provide 1+n hitless protection. The >> appropriate service >> protection mechanism depends on the scenario >> and the requirements." >> >> >> New sub-section added: >> >> "3.2.2.1. In-Order Delivery >> >> Out-of-order packet delivery can be a side >> effect of service >> protection. Packets delivered out-of-order >> impact the amount of >> buffering needed at the destination to >> properly process the received >> data. Such packets also influence the jitter >> of a flow. The DetNet >> service includes maximum allowed misordering >> as a constraint. Zero >> misordering would be a valid service >> constraint to reflect that the >> end system(s) of the flow cannot tolerate any >> out-of-order delivery. >> Service protection may provide a mechanism to >> support in-order >> delivery." >> >> >> *3.2.2.2. Packet Replication and Elimination* >> >> New bullet added as the last one: >> "o The Packet Ordering Function (POF) uses >> the sequencing information >> to re-order a DetNet flow's packets that >> are received out of >> order." >> >> New sentence added after the bullet list: >> "The order in which a node applies the PEF and >> the PRF to a DetNet >> flow is implementation specific." >> >> 2nd paragraph after the bullet list has been >> updated to: >> "Some service protection mechanisms rely on >> switching from one flow to >> another when a failure of a flow is detected. >> Contrarily, packet >> replication and elimination combines the >> DetNet member flows sent >> along multiple different paths, and performs a >> packet-by-packet >> selection of which to discard, e.g., based on >> sequencing information." >> >> >> *3.2.3. Explicit routes* >> >> Out-of-order aspect added to the first paragraph, >> which is about distributed routing: >> "Furthermore, out-of-order >> packet delivery can be a side effect of route >> changes." >> >> New sentence added to the 3rd paragraph: >> "Explicit routes can be established various >> ways, e.g., with RSVP-TE [RFC3209], with Segment >> Routing (SR) >> [I-D.ietf-spring-segment-routing], via a Software >> Defined Networking >> approach [RFC7426], with IS-IS [RFC7813], etc." >> >> New paragraph added: >> "Out-of-order packet delivery can be a side >> effect of distributing a >> single flow over multiple paths especially >> when there is a change >> from one path to another when combining the >> flow. This is >> irrespective of the distribution method used, >> also applies to service >> protection over explicit routes. As described >> in Section 3.2.2.1, >> out-of-order packets influence the jitter of a >> flow and impact the >> amount of buffering needed to process the >> data; therefore, DetNet >> service includes maximum allowed misordering >> as a constraint. The >> use of explicit routes helps to provide >> in-order delivery because >> there is no immediate route change with the >> network topology, but the >> changes are plannable as they are between the >> different explicit >> routes." >> >> * >> 4.1.1. Representative Protocol Stack Model* >> >> "Explicit routes" have been added to Figure 2 >> with the corresponding explanation: >> "Explicit routes >> The DetNet transport layer provides >> mechanisms to ensure that >> fixed paths are provided for DetNet >> flows. These explicit >> paths avoid the impact of network >> convergence." >> >> >> Section 4.11 Connected islands vs. networks of >> v05 has been deleted because it was just a >> leftover from early drafts on what DetNet WG >> should do; which are covered by the charter anyways. >> >> >> References have been cleaned up and brought >> up-to-date. >> >> >> Refinements have been implemented in the draft >> according to Lou's detailed comments. They are >> not listed here because they are minor changes. >> >> >> Best regards, >> Janos >> >> On 6/12/2018 2:48 PM, Lou Berger wrote: >> >> >> Balzs, >> >> Thanks for the response -- please see below. >> >> ---------- >> On June 12, 2018 4:07:35 AM Balzs Varga A >> >> wrote: >> >> Hi Lou, Thanks for the comments. See >> reactions inline. Document update in >> progress. Cheers Bala'zs >> >> -----Original Message----- >> From: detnet >> On >> Behalf Of Lou Berger >> Sent: 2018. jnius 1. 22:42 >> To: DetNet WG >> ; >> draft-ietf-detnet-architecture@ietf.org >> >> >> Subject: [Detnet] Promised comments on >> draft-ietf-detnet-architecture >> >> Hi, >> >> I have a number of high level >> comments on the document that I'd like to >> raise below. I also have a number of >> more editorial/specific comments that >> I'd like to review directly with the >> authors and then have them report back >> on changes -- if any turn out to be more >> substantive discussions from the >> author's perspective, I'll raise these >> on the list separately. >> >> ... >> >> >> - WRT Section 4.4.3, I think the >> inclusion of a distributed control plane >> in the "Network Plane" is inconsistent >> with other functional definitions and >> conflates where a function resides from >> the actual function and that whether >> control is implemented in a fully >> centralized, fully distributed or some >> hybrid form doesn't fundamentally change >> the control function's role -- therefore >> I think the sections 4..4.2 and .3 should >> be revised accordingly >> [Balzs Varga A] Agree in principal. >> Let's discuss the details. >> >> Okay - I'll work with you off line and we can >> report back the results/proposed changes. >> >> - In several places it's not clear that >> DetNet service is always a L3 service >> which is controlled using L3 identifiers, >> i.e., IP addresses -- this is true even >> in the MPLS service case and the TSN over >> MPLS case. I think this is an important >> point to be clear on in the document. >> [Balzs Varga A] I am not sure. DetNet >> service is always provided over a L3 >> network (IP or MPLS), that is fine. >> However the service itself can be L2 or >> L3. In case of TSN Ethernet frames are >> transported, so it is a L2 service. In >> case of IP end systems IP packets are >> transported so it is a L3 service. >> >> >> Humm - While I agree that DetNet is providing >> an (enhanced) L2VPN service, it is not itself >> providing control or service of L2 devices -- >> this is TSN's job. The fact that DetNet is >> all about behavior of L3 nodes (i.e., IP and >> PW/MPLS) and not L2 nodes (i.e., TSN bridges) >> is something the architecture should make >> unambiguous. >> >> Thanks, >> Lou >> >> Please let me know what you think. >> >> Cheers, >> >> 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 >> >> >> >> On 6/12/2018 6:27 PM, Stewart Bryant wrote: >> >> Dear Bala'zs >> >> Thank you your for your consideration of >> these points. I will just pick up a few that >> need some further thought: >> >> DetNet transit node >> >> A node operating at the DetNet transport >> layer, that utilizes >> >> link layer and/or network layer switching >> across multiple >> >> links and/or sub-networks to provide >> paths for DetNet service >> >> layer functions. Optionally provides >> congestion protection >> >> over those paths. An MPLS LSR is an >> example of a DetNet >> >> transit node. >> >> SB> In that example it would have to be a >> DetNet enable/aware LSR. An >> >> SB> ordinary LSR would not know anything >> about DetNet. >> >> [Balzs Varga A] No, A DetNet aware LSR >> would be a relay node (S-PE). >> >> >> I think the confusion is what "DetNet >> Transport Layer" means. This >> technology touches on Transport Layer in the >> L4 sense, and the >> Transport Network Layer as in the packet >> network that carries >> L3 packets. >> >> So I think that we need to clarify whether a >> DetNet transit node >> is an S-PE (i.e. a a transit node in the >> DetNet layer), or a P node >> (i.e. a transit node that is carrying DetNet >> packets but could be >> carrying any sort of MPLS packet) >> >> ============ >> >> These three techniques can be applied >> independently, giving eight >> >> possible combinations, including none (no >> DetNet), although some >> >> combinations are of wider utility than >> others. This separation keeps >> >> the protocol stack coherent and maximizes >> interoperability with >> >> existing and developing standards in this >> (IETF) and other Standards >> >> Development Organizations. Some examples >> of typical expected >> >> combinations: >> >> o Explicit routes plus service >> protection are exactly the techniques >> >> employed by [HSR-PRP]. Explicit routes >> are achieved by limiting >> >> the physical topology of the network, and >> the sequentialization, >> >> replication, and duplicate elimination >> are facilitated by packet >> >> tags added at the front or the end of >> Ethernet frames. >> >> SB> ER can be done virtually as well as >> physically. RSVP is a type of >> >> SB> ER, as is Adj-SID based SR, and we >> can design other types. >> >> [Balzs Varga A] Agree, but these are >> examples. Statement is for HSR-PRP. >> >> So the question is whether we should expand >> the set of examples, particularly >> to more accessible ones. >> >> ============ >> >> Packet replication and elimination >> >> > > > > > > > > > relay > > > > > > > > >> >> > /------------+ R node E +------------\ > >> >> > / v + ^ \ > >> >> end R + v | ^ + E end >> >> system + v | ^ + system >> >> > \ v + ^ / > >> >> > \------------+ R relay E +-----------/ > >> >> > > > > > > > > > node > > > > > > > > >> >> Figure 1 >> >> Packet replication and elimination does >> not react to and correct >> >> failures; it is entirely passive. Thus, >> intermittent failures, >> >> SB> I think it copes with intermittent >> failures OK. >> >> [Balzs Varga A] Yes, PRF and PEF can >> eliminate the effect of such failures. >> But text >> >> intends to say that it is passive. It is >> not reacting to such failures. No change >> in text. >> >> >> You say that PREF does not correct failures. >> I would contend that is exactly >> what it does. Sure it does not react but it >> does correct, and it does >> address intermittent failures. >> >> =========== >> >> transported between the peer end systems. >> Therefore, the following >> >> possible types / formats of a DetNet flow >> are distinguished in this >> >> document: >> >> o App-flow: native format of a DetNet >> flow. It does not contain any >> >> DetNet related attributes. >> >> o DetNet-t-flow: specific format of a >> DetNet flow. Only requires >> >> the congestion / latency features >> provided by the Detnet transport >> >> layer. >> >> o DetNet-s-flow: specific format of a >> DetNet flow. Only requires >> >> the replication/elimination feature >> ensured by the DetNet service >> >> layer. >> >> o DetNet-st-flow: specific format of a >> DetNet flow. It requires >> >> both DetNet service layer and DetNet >> transport layer functions >> >> during forwarding. >> >> SB> I find the relisting of these types >> confusing. Wheren't they defined >> >> SB> in the section above? >> >> [Balzs Varga A] This is inline with the >> previous section " Grouping of end systems ". >> >> Surely if we have defined them we never need >> to do anything but name them in >> later sections. Redefinition is never a good >> idea because it often leads to >> conflicting definitions. >> >> ============ >> >> [HSR-PRP] IEC, "High availability >> seamless redundancy (HSR) is a >> >> further development of the PRP approach, >> although HSR >> >> functions primarily as a protocol for >> creating media >> >> redundancy while PRP, as described in the >> previous >> >> section, creates network redundancy. PRP >> and HSR are both >> >> described in the IEC 62439 3 standard.", >> >> > >> artnum/046615!opendocument>. >> >> SB> Not available at the time of this >> review, but my recollection is >> >> SB> that this is not readily available >> without paying a large fee. >> >> >> If we decide that this is essential as a key >> reference, there needs to be >> some suitable text, as this will get raised a >> number of times between >> here an publication as first the directorates >> and then the ADs run >> into this. >> >> =========== >> >> [ISA95] ANSI/ISA, "Enterprise-Control >> System Integration Part 1: >> >> Models and Terminology", 2000, >> >> . >> >> SB> Should that be 2000, or 2010. >> >> SB> Note that this seems to be a very >> expensive document to access. >> >> You did not comment on the correctness of the >> reference. >> >> >> Best Regards >> >> Stewart >> >> _______________________________________________ >> 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 >> > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet --------------94226A4012DE1CC02F361C5F Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit I forgot to mention that the next step is gated by August vacations.

Best regards,
Jnos

On 8/3/2018 5:39 PM, Jnos Farkas wrote:
Hi,

We have updated the architecture draft to resolve the extended WGLC comments. The current revision is v07: https://tools.ietf.org/html/draft-ietf-detnet-architecture-07.

All WGLC comments have been addressed; most of them can be found below. Some further nits have been also resolved.

The main changes:

1)
Based on the last discussion item below, a new sentence has been added to congestion protection in section 3.1, where it is first described:
"Note that congestion
protection provided via congestion detection and notification is
explicitly excluded from consideration in DetNet, as it serves a
different set of applications."

(Note that throttling/throttled has been already part of the text, there are three occurrences.)

2)
Based on the discussion below, the following introductory text has been added to section 4.1:
"DetNet functionality (Section 3) is implemented in two adjacent
layers in the protocol stack: the DetNet service layer and the DetNet
transport layer. The DetNet service layer provides DetNet service,
e.g., service protection, to higher layers in the protocol stack and
applications. The DetNet transport layer supports DetNet service in
the underlying network, e.g., by providing explicit routes and
congestion protection to DetNet flows."

Consequently, the definition of DetNet service layer has been updated to:
"The layer at which A DetNet service, e.g., service protection
is provided."

3)
Based on https://www.ietf.org/mail-archive/web/detnet/current/msg01577.html, the following sentence has been added to the OAM paragraph in section 4.1.1:
"Active and hybrid OAM
methods require additional bandwidth to perform fault management and
performance monitoring of the DetNet domain. OAM may, for instance,
generate special test probes or add OAM information into the data
packet."

4)
Based on the consensus reached at the DetNet session at IETF 102, Controller Plane Entity (CPE) has been replaced with Controller Plane Function (CPF).

5)
In order to clarify, the last sentence of the introduction has been updated to:
"DetNet can
accommodate various time synchronization techniques and profiles that
are defined elsewhere to address the needs of different market
segments."

6)
In order to clarify, the packet loss bullet in section 3.1 has been updated to:
"Packet loss ratio, under various assumptions as to the operational
states of the nodes and links."

7)
DetNet t-aware has been updated to:
"A DetNet transport-aware system. It knows about
some TSN functions (e.g., reservation), but not about service
protection."

8)
DetNet s-aware has been updated to:
"DetNet service-aware system. It supplies
sequence numbers, but doesnt know about zero congestion loss."


Best regards,
Jnos


On 7/19/2018 2:04 AM, Prof. Diego Dujovne wrote:
+1

El mi., 18 de jul. de 2018 19:53, Black, David <David.Black@dell.com> escribi:

+1, Thanks, --David

From: Lou Berger [mailto:lberger@labn.net]
Sent: Wednesday, July 18, 2018 6:52 PM
To: Norman Finn; Janos Farkas; Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

This sounds sensible to me...

Lou

On July 18, 2018 6:47:01 PM Norman Finn <norman.finn@mail01.huawei.com> wrote:

"Congestion loss protection" is better than "congestion protection". That's good.

It's a big change, and makes the document unnecessarily wordy. That's bad.

I would use "congestion protection" but explain somewhere that we are not talking about source throttling.

And if adding that explanation is difficult or controversial, I would stick with "congestion protection".

-- Norm

From: detnet [detnet-bounces@ietf.org] on behalf of Janos Farkas [Janos.Farkas@ericsson.com]
Sent: Wednesday, July 18, 2018 2:26 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Both congestion protection and congestion loss protection work for me.

Note that the architecture document is quite populated with the term congestion protection. I do not know the other documents by heart.

So it would be a bit of a change..

Id like to have the groups opinion before making such a change, e.g., any objections?

Thanks,

Janos

From: Black, David <David.Black@dell.com>
Sent: Wednesday, July 18, 2018 8:19 PM
To: Janos Farkas <Janos.Farkas@ericsson.com>
Cc: DetNet WG <detnet@ietf.org>
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Hi Janos,

That text works nicely. In briefly talking to Lou, a related suggestion surfaced: congestion protection -> congestion loss protection where possible (may need to be abbreviated in the Figure) .

This change would make it clearer that the primary focus is protection from losses caused by congestion as opposed to protection from all congestion. DetNet should be able to tolerate some modest congestion (e.g., in nodes that dont have reserved DetNet resources) as long as delivery is reliable and timely.

Thanks, --David

From: Janos Farkas [mailto:Janos.Farkas@ericsson.com]
Sent: Wednesday, July 18, 2018 11:45 AM
To: Black, David
Cc: DetNet WG
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Hi David,

This implies updating the definition of the DetNet service layer, e.g., to:

DetNet service layer

The layer at which A DetNet Service, e.g., service protection is provided.

The definition of the DetNet transport layer remains the same:

DetNet transport layer

The layer that optionally provides congestion protection for

DetNet flows over paths provided by the underlying network.

Regards,

Janos

From: Black, David <David.Black@dell.com>
Sent: Monday, July 16, 2018 3:21 PM
To: Janos Farkas <Janos.Farkas@ericsson.com>
Cc: DetNet WG <detnet@ietf.org>
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Dont use congestion protection in the definitions for both levels.

Thanks, --David

From: Jnos Farkas [mailto:janos.farkas@ericsson.com]
Sent: Sunday, July 15, 2018 10:43 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Thank you David!

I think we are set. :-)

You got a point, we should update
"DetNet service layer is the layer at which A DetNet Service, such as congestion or service protection is provided."
to
"DetNet service layer is the layer at which A DetNet Service, such as congestion protection and/or service protection is provided."
in the definitions as well to make it clear.

Thanks,
Janos

On 7/16/2018 3:03 AM, Black, David wrote:

Moving the only two open items to the top

-- Section 4

> We could add some introductory text to 4.1 or 4.1.1, for instance:
> The functionality needed for DetNet (Section 3) are implemented in the DetNet layer which comprises the DetNet service layer and the DetNet transport layer.

> The DetNet service layer functions rely on flow identification and sequencing. The DetNet transport layer function may rely on flow identification.
>
> What do you think?

I prefer functional (what it does) characterization to mechanistic (how it works) characterization in an overview, e.g., excerpting from what I originally wrote:

The DetNet Service layer provides timely reliable in-order DetNet flow delivery to applications that use DetNet.

The DetNet Transport layer insulates DetNet flows from interference by network mechanisms, primarily queuing and routing

I understand the principle.

What about just copying the two definitions here:
DetNet service layer is the layer at which A DetNet Service, such as congestion or service protection is provided.
DetNet transport layer optionally provides congestion protection for DetNet flows over paths provided by the underlying network.

David> Yes, that works, although I dont think congestion was meant to be included in the first definition 

 Many real-time networks rely on physical rings or chains of two-port
 devices, with a relatively simple ring control protocol.

How does a ring control protocol control chains? Suggest: ring control protocol -> control protocol

Also, are paired chains between common endpoints intended, or a more general notion of chains?

This text refers to typical factory deployment, which is chain or ring..
It seems better to keep ring control protocol because they are often very different from generic control protocols applicable to mesh networks.

Would flipping chain and ring resolve your concern?

 Many real-time networks rely on physical chains or rings of two-port
 devices, with a relatively simple ring control protocol.

[David>] It feels like ring control protocol is an important phrase to retain. In the original text, would it be reasonable to add (applies to both rings and chains) to the end of the sentence?

Well, I guess the point is that there are many specific ring protocols, but we are looking for a generic solution.
What about deleting "chains" from the sentence?

David> Yes, if the sentence is all about rings, its clear.

Thanks, --David

From: Jnos Farkas [mailto:janos.farkas@ericsson.com]
Sent: Sunday, July 15, 2018 7:25 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Hi David,

Please see in-line.

Thank you!
Janos

On 7/6/2018 11:50 PM, Black, David wrote:

-- Bridged path definition

> Or should we do something else?

> There is only one occurrence of "bridged path" in the text in brackets.

That sounds like a better suggestion change that occurrence and remove the definition of bridged path from the draft. That occurrence is in Section 4.1.1:

Congestion protection

The DetNet transport layer provides congestion protection.

See Section 4.5. The actual queuing and shaping mechanisms

are typically provided by underlying subnet layers, these can

be closely associated with the means of providing paths for

DetNet flows (e.g., MPLS LSPs or bridged paths), the path and

the congestion protection are conflated in this figure.

Perhaps: (e.g., MPLS LSPs or bridged paths) -> (MPLS LSPs or other network paths)

or just delete the entire parenthetical example.

OK. Let's just delete the entire parenthetical example.

-- Section 4

> We could add some introductory text to 4.1 or 4.1.1, for instance:
> The functionality needed for DetNet (Section 3) are implemented in the DetNet layer which comprises the DetNet service layer and the DetNet transport layer.

> The DetNet service layer functions rely on flow identification and sequencing. The DetNet transport layer function may rely on flow identification.
>
> What do you think?

I prefer functional (what it does) characterization to mechanistic (how it works) characterization in an overview, e.g., excerpting from what I originally wrote:

  • The DetNet Service layer provides timely reliable in-order DetNet flow delivery to applications that use DetNet.
  • The DetNet Transport layer insulates DetNet flows from interference by network mechanisms, primarily queuing and routing

I understand the principle.

What about just copying the two definitions here:
DetNet service layer is the layer at which A DetNet Service, such as congestion or service protection is provided.
DetNet transport layer optionally provides congestion protection for DetNet flows over paths provided by the underlying network.


> Should we also rearrange, e.g., indent the text after Figure 2 such that
> Packet sequencing, Duplicate elimination, Flow replication, Flow merging, Packet encoding, and Packet decoding get under Service layer
> and
> Congestion protection and Explicit routes get under Transport layer?

No, I dont think thats necessary Figure 2 provides sufficient structure.

OK.

Plus a few more minor comments inline

Thanks, --David

From: Jnos Farkas [mailto:janos.farkas@ericsson.com]
Sent: Wednesday, July 4, 2018 2:15 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Hi David,

Thank you very much for your review and comments!

Please see in-line.

On 6/29/2018 4:10 PM, Black, David wrote:

The -06 version of this draft is much improved over the -05 version lots of diligent work by the authors is evident and appreciated.

I have two minor content concerns and some smaller editorial items.

** Content

-- Section 2.2

The definition of bridged path looks like a definition of bridged forwarding the definition needs to encompass the notion of a path that involves more than one bridge.

 bridged path
 A VLAN bridge uses the VLAN ID and the destination MAC
 address to select the outbound port hence the path for a
 frame.

You are right, it looks like the emphasis is on bridge forwarding rather than path.
However, the superposition of the outbound ports provides a path, which was tried to be captured by "hence the path".
The idea was to keep it simple not dive into the details, which are not necessary in this document.

Would it be good to update to:

 bridged path
 A VLAN bridge uses the VLAN ID and the destination MAC
 address to select the outbound port. The superposition
 of the outbound ports is the path for a frame.

?

Or should we do something else?
There is only one occurrence of "bridged path" in the text in brackets.

-- Section 4

Figure 2 in Section 4.1.1 introduces the Detnet service and transport layers. The associated text quickly dives into explaining the functionality in those layers, but it would be helpful to start with an initial high level description of each of those layers that helps motivate their separation. It appears that:

- The DetNet Service layer provides timely reliable in-order DetNet flow delivery to applications that use DetNet. A DetNet flow at the top of the DetNet Service layer may or may not be a compound flow at the bottom of that layer.

- The DetNet Transport layer insulates DetNet flows (at the bottom of the DetNet Service layer) from interference by network mechanisms, primarily queuing and routing, where congestion is an indication of queueing interference. A DetNet flow at the top of the DetNet Transport layer may or may not be a member flow that is part of a compound flow, depending on what is done in the DetNet Service layer.


You are right, section 4 jumps into the details without much of an introduction. I guess we had a kind of chicken and egg problem here. Figure 4 provides a higher level view than Figure 2. However, Figure 4 captures different aspects, dives into the details of data plane options. So, it seems better to keep the order.

We could add some introductory text to 4.1 or 4.1.1, for instance:
The functionality needed for DetNet (Section 3) are implemented in the DetNet layer which comprises the DetNet service layer and the DetNet transport layer. The DetNet service layer functions rely on flow identification and sequencing. The DetNet transport layer function may rely on flow identification.

What do you think?

Should we also rearrange, e.g., indent the text after Figure 2 such that
Packet sequencing, Duplicate elimination, Flow replication, Flow merging, Packet encoding, and Packet decoding get under Service layer
and
Congestion protection and Explicit routes get under Transport layer?

Theres a related paragraph of text between Figures 3 and 4 in Section 4.1.2, but it doesnt provide useful intuition about which functionality belongs in which layer.

** Editorial

-- Section 2.1

expected seems off in the definition of reservation:

reservation

The set of resources allocated between a source and one or

more destinations through transit nodes and subnets

associated with a DetNet flow, to provide the expected DetNet

Service.

Suggest either to provide the provisioned DetNet Service to that flow

I like this one, will update to this one.

or to provide the specified DetNet Service to that flow.

-- Section 3.1

 o An upper bound on out-of-order packet delivery. It is worth
 noting that some DetNet applications are unable to tolerate any
 out-of-order delivery.

Is that a sequence bound or a time bound or both? I suspect that a sequence bound (maximum degree of reordering in a flow, independent of flow rate) was intended. An analogous clarification would be helpful in section 3.2.2.1 .

It is intentionally kept high level in the architecture draft. Details are to be provided by the flow information model draft. Please see my previous mail: https://mailarchive.ietf.org/arch/msg/detnet/AWG2eemg_AWsvF2FwtREyd_xtC8.

[David>] OK.

-- Section 3.2.3

I dont understand defined in:

 Even the use of
 redundant paths through a network defined, e.g., by [RFC6372] do not
 eliminate the chances of packet loss.

Was e.g., as defined by [RFC6372], intended?

Yes, this was the intention, will update to this one.

 Many real-time networks rely on physical rings or chains of two-port
 devices, with a relatively simple ring control protocol.

How does a ring control protocol control chains? Suggest: ring control protocol -> control protocol

Also, are paired chains between common endpoints intended, or a more general notion of chains?

This text refers to typical factory deployment, which is chain or ring.
It seems better to keep ring control protocol because they are often very different from generic control protocols applicable to mesh networks.

Would flipping chain and ring resolve your concern?

 Many real-time networks rely on physical chains or rings of two-port
 devices, with a relatively simple ring control protocol.

[David>] It feels like ring control protocol is an important phrase to retain. In the original text, would it be reasonable to add (applies to both rings and chains) to the end of the sentence?

Well, I guess the point is that there are many specific ring protocols, but we are looking for a generic solution.
What about deleting "chains" from the sentence?

 Explicit routes can be established various ways,

established various -> established in various

OK.

 This is
 irrespective of the distribution method used, also applies to service
 protection over explicit routes.

used, also -> used, and also

OK.

-- Figure 5 (Section 4.1.3)

The UNI acronym is introduced without expansion or definition please correct that, e.g., by defining UNI in Section 2.1.

DetNet-UNI is there among the definitions. It seems enough to me.

[David>] Thats fine I overlooked that definition, sorry.

-- Figure 9 (Section 4.7.2)

I think I understand whats going on, but the use of add/remove in the figure should be explained in associated text.

What about updating the sentence above Figure 9 to:
A packet with corresponding Flow-IDs is illustrated in Figure 9, which also indicates where Flow-ID can be added or removed.

[David>] Sure, with one minor edit: where Flow-ID -> where each Flow-ID

OK.

Thanks, --David


Thank you!
Janos

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Jnos Farkas
Sent: Thursday, June 28, 2018 9:09 PM
To: Lou Berger; Stewart Bryant; detnet@ietf.org >> DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Dear all,

Off-line discussions among Lou, Stewart, and authors followed the discussions to properly address the WGLC comments, including the detailed comments.

A new revision of the draft has been uploaded: draft-ietf-detnet-architecture-06.

In addition to the changes already described in this thread, the following bigger changes have been made to the draft:


Section 2.1 Terms used in this document

Some definitions refined as suggested by the detailed comments

New definitions have been added:

"allocation
Resources are dedicated to support a DetNet flow. Depending
on an implementation, the resource may be reused by non-
DetNet flows when it is not used by the DetNet flow.


PEF A Packet Elimination Function (PEF) eliminates duplicate
copies of packets to prevent excess packets flooding the
network or duplicate packets being sent out of the DetNet
domain. PEF can be implemented by an edge node, a relay
node, or an end system.

PRF A Packet Replication Function (PRF) replicates DetNet flow
packets and forwards them to one or more next hops in the
DetNet domain. The number of packet copies sent to each next
hop is a DetNet flow specific parameter at the node doing the
replication. PRF can be implemented by an edge node, a relay
node, or an end system.

PREOF Collective name for Packet Replication, Elimination, and
Ordering Functions.

POF A Packet Ordering Function (POF) re-orders packets within a
DetNet flow that are received out of order. This function
can be implemented by an edge node, a relay node, or an end
system.

DetNet service proxy
Maps between App-flows and DetNet flows.

bridged path
A VLAN bridge uses the VLAN ID and the destination MAC
address to select the outbound port hence the path for a
frame."


Section 3.1 Primary goals defining the DetNet QoS

A new QoS aspect has been added:
"o An upper bound on out-of-order packet delivery. It is worth
noting that some DetNet applications are unable to tolerate any
out-of-order delivery."


The 3rd paragraph on loss on page 8 after the bullet list has been extended to:
"After congestion, the most important contributions to packet loss are
typically from random media errors and equipment failures. Service
protection is the name for the mechanisms used by DetNet to address
these losses. The mechanisms employed are constrained by the
requirement to meet the users' latency requirements. Packet
replication and elimination (Section 3.2.2) and packet encoding
(Section 3.2.2.3) are described in this document to provide service
protection; others may be found. For instance, packet encoding can
be used to provide service protection against random media errors,
packet replication and elimination can be used to provide service
protection against equipment failures. This mechanism distributes
the contents of DetNet flows over multiple paths in time and/or
space, so that the loss of some of the paths does need not cause the
loss of any packets."


3.2.2. Service Protection

Service protection is used as a more generic term. Introductory text added:
"Service protection aims to mitigate or eliminate packet loss due to
equipment failures, random media and/or memory faults. These types
of packet loss can be greatly reduced by spreading the data over
multiple disjoint forwarding paths. Various service protection
methods are described in [RFC6372], e.g., 1+1 linear protection.
This section describes the functional details of an additional method
in Section 3.2.2.2, which can be implemented as described in
Section 3.2.2.3 or as specified in [I-D.ietf-detnet-dp-sol-mpls] in
order to provide 1+n hitless protection. The appropriate service
protection mechanism depends on the scenario and the requirements."


New sub-section added:

"3.2.2.1. In-Order Delivery

Out-of-order packet delivery can be a side effect of service
protection. Packets delivered out-of-order impact the amount of
buffering needed at the destination to properly process the received
data. Such packets also influence the jitter of a flow. The DetNet
service includes maximum allowed misordering as a constraint. Zero
misordering would be a valid service constraint to reflect that the
end system(s) of the flow cannot tolerate any out-of-order delivery.
Service protection may provide a mechanism to support in-order
delivery."


3.2.2.2. Packet Replication and Elimination

New bullet added as the last one:
"o The Packet Ordering Function (POF) uses the sequencing information
to re-order a DetNet flow's packets that are received out of
order."

New sentence added after the bullet list:
"The order in which a node applies the PEF and the PRF to a DetNet
flow is implementation specific."

2nd paragraph after the bullet list has been updated to:
"Some service protection mechanisms rely on switching from one flow to
another when a failure of a flow is detected. Contrarily, packet
replication and elimination combines the DetNet member flows sent
along multiple different paths, and performs a packet-by-packet
selection of which to discard, e.g., based on sequencing information."


3.2.3. Explicit routes

Out-of-order aspect added to the first paragraph, which is about distributed routing:
"Furthermore, out-of-order
packet delivery can be a side effect of route changes."

New sentence added to the 3rd paragraph:
"Explicit routes can be established various
ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR)
[I-D.ietf-spring-segment-routing], via a Software Defined Networking
approach [RFC7426], with IS-IS [RFC7813], etc."

New paragraph added:
"Out-of-order packet delivery can be a side effect of distributing a
single flow over multiple paths especially when there is a change
from one path to another when combining the flow. This is
irrespective of the distribution method used, also applies to service
protection over explicit routes. As described in Section 3.2.2.1,
out-of-order packets influence the jitter of a flow and impact the
amount of buffering needed to process the data; therefore, DetNet
service includes maximum allowed misordering as a constraint. The
use of explicit routes helps to provide in-order delivery because
there is no immediate route change with the network topology, but the
changes are plannable as they are between the different explicit
routes."


4.1.1. Representative Protocol Stack Model

"Explicit routes" have been added to Figure 2 with the corresponding explanation:
"Explicit routes
The DetNet transport layer provides mechanisms to ensure that
fixed paths are provided for DetNet flows. These explicit
paths avoid the impact of network convergence."


Section 4.11 Connected islands vs. networks of v05 has been deleted because it was just a leftover from early drafts on what DetNet WG should do; which are covered by the charter anyways.


References have been cleaned up and brought up-to-date.


Refinements have been implemented in the draft according to Lou's detailed comments. They are not listed here because they are minor changes.


Best regards,
Janos

On 6/12/2018 2:48 PM, Lou Berger wrote:


Balzs,

Thanks for the response -- please see below.

----------
On June 12, 2018 4:07:35 AM Balzs Varga A <balazs.a.varga@ericsson.com> wrote:

Hi Lou, Thanks for the comments. See reactions inline. Document update in progress. Cheers Bala'zs

-----Original Message-----
From: detnet <detnet-bounces@ietf.org> On Behalf Of Lou Berger
Sent: 2018. jnius 1. 22:42
To: DetNet WG <detnet@ietf.org>; draft-ietf-detnet-architecture@ietf.org
Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

Hi,

I have a number of high level comments on the document that I'd like to raise below. I also have a number of more editorial/specific comments that I'd like to review directly with the authors and then have them report back on changes -- if any turn out to be more substantive discussions from the author's perspective, I'll raise these on the list separately.

...


- WRT Section 4.4.3, I think the inclusion of a distributed control plane in the "Network Plane" is inconsistent with other functional definitions and conflates where a function resides from the actual function and that whether control is implemented in a fully centralized, fully distributed or some hybrid form doesn't fundamentally change the control function's role -- therefore I think the sections 4..4.2 and .3 should be revised accordingly
[Balzs Varga A] Agree in principal. Let's discuss the details.

Okay - I'll work with you off line and we can report back the results/proposed changes.

- In several places it's not clear that DetNet service is always a L3 service which is controlled using L3 identifiers, i.e., IP addresses -- this is true even in the MPLS service case and the TSN over MPLS case. I think this is an important point to be clear on in the document.
[Balzs Varga A] I am not sure. DetNet service is always provided over a L3 network (IP or MPLS), that is fine. However the service itself can be L2 or L3. In case of TSN Ethernet frames are transported, so it is a L2 service. In case of IP end systems IP packets are transported so it is a L3 service.


Humm - While I agree that DetNet is providing an (enhanced) L2VPN service, it is not itself providing control or service of L2 devices -- this is TSN's job. The fact that DetNet is all about behavior of L3 nodes (i.e., IP and PW/MPLS) and not L2 nodes (i.e., TSN bridges) is something the architecture should make unambiguous.

Thanks,
Lou

Please let me know what you think.

Cheers,

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



On 6/12/2018 6:27 PM, Stewart Bryant wrote:

Dear Bala'zs

Thank you your for your consideration of these points. I will just pick up a few that need some further thought:

DetNet transit node

A node operating at the DetNet transport layer, that utilizes

link layer and/or network layer switching across multiple

links and/or sub-networks to provide paths for DetNet service

layer functions. Optionally provides congestion protection

over those paths. An MPLS LSR is an example of a DetNet

transit node.

SB> In that example it would have to be a DetNet enable/aware LSR. An

SB> ordinary LSR would not know anything about DetNet.

[Balzs Varga A] No, A DetNet aware LSR would be a relay node (S-PE).


I think the confusion is what "DetNet Transport Layer" means. This
technology touches on Transport Layer in the L4 sense, and the
Transport Network Layer as in the packet network that carries
L3 packets.

So I think that we need to clarify whether a DetNet transit node
is an S-PE (i.e. a a transit node in the DetNet layer), or a P node
(i.e. a transit node that is carrying DetNet packets but could be
carrying any sort of MPLS packet)

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

These three techniques can be applied independently, giving eight

possible combinations, including none (no DetNet), although some

combinations are of wider utility than others. This separation keeps

the protocol stack coherent and maximizes interoperability with

existing and developing standards in this (IETF) and other Standards

Development Organizations. Some examples of typical expected

combinations:

o Explicit routes plus service protection are exactly the techniques

employed by [HSR-PRP]. Explicit routes are achieved by limiting

the physical topology of the network, and the sequentialization,

replication, and duplicate elimination are facilitated by packet

tags added at the front or the end of Ethernet frames.

SB> ER can be done virtually as well as physically. RSVP is a type of

SB> ER, as is Adj-SID based SR, and we can design other types.

[Balzs Varga A] Agree, but these are examples. Statement is for HSR-PRP.

So the question is whether we should expand the set of examples, particularly
to more accessible ones.

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

Packet replication and elimination

> > > > > > > > > relay > > > > > > > >

> /------------+ R node E +------------\ >

> / v + ^ \ >

end R + v | ^ + E end

system + v | ^ + system

> \ v + ^ / >

> \------------+ R relay E +-----------/ >

> > > > > > > > > node > > > > > > > >

Figure 1

Packet replication and elimination does not react to and correct

failures; it is entirely passive. Thus, intermittent failures,

SB> I think it copes with intermittent failures OK.

[Balzs Varga A] Yes, PRF and PEF can eliminate the effect of such failures. But text

intends to say that it is passive. It is not reacting to such failures. No change in text.


You say that PREF does not correct failures. I would contend that is exactly
what it does. Sure it does not react but it does correct, and it does
address intermittent failures.

===========

transported between the peer end systems. Therefore, the following

possible types / formats of a DetNet flow are distinguished in this

document:

o App-flow: native format of a DetNet flow. It does not contain any

DetNet related attributes.

o DetNet-t-flow: specific format of a DetNet flow. Only requires

the congestion / latency features provided by the Detnet transport

layer.

o DetNet-s-flow: specific format of a DetNet flow. Only requires

the replication/elimination feature ensured by the DetNet service

layer.

o DetNet-st-flow: specific format of a DetNet flow. It requires

both DetNet service layer and DetNet transport layer functions

during forwarding.

SB> I find the relisting of these types confusing. Wheren't they defined

SB> in the section above?

[Balzs Varga A] This is inline with the previous section " Grouping of end systems ".

Surely if we have defined them we never need to do anything but name them in
later sections. Redefinition is never a good idea because it often leads to
conflicting definitions.

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

[HSR-PRP] IEC, "High availability seamless redundancy (HSR) is a

further development of the PRP approach, although HSR

functions primarily as a protocol for creating media

redundancy while PRP, as described in the previous

section, creates network redundancy. PRP and HSR are both

described in the IEC 62439 3 standard.",

<http://webstore.iec.ch/webstore/webstore.nsf/

artnum/046615!opendocument>.

SB> Not available at the time of this review, but my recollection is

SB> that this is not readily available without paying a large fee.


If we decide that this is essential as a key reference, there needs to be
some suitable text, as this will get raised a number of times between
here an publication as first the directorates and then the ADs run
into this.

===========

[ISA95] ANSI/ISA, "Enterprise-Control System Integration Part 1:

Models and Terminology", 2000,

<https://www.isa.org/isa95/>.

SB> Should that be 2000, or 2010.

SB> Note that this seems to be a very expensive document to access.

You did not comment on the correctness of the reference.


Best Regards

Stewart

_______________________________________________
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



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

--------------94226A4012DE1CC02F361C5F-- From nobody Fri Aug 3 09:15:53 2018 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 C1B1D131006 for ; Fri, 3 Aug 2018 09:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 jIOa9QgiomrG for ; Fri, 3 Aug 2018 09:15:50 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 979A3130EC2 for ; Fri, 3 Aug 2018 09:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533312947; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qcAGzCixKgUND5O+ybPgF6rBRterVRYm5fu//k1SQzs=; b=T0SjMhEncWzenMaTdN+K4i03uE+OUCTp9waJZIFx5p8PVZD52/Pp3b7GPBS0HvjK kTChR57ublRb0TaMWSrfZeQIKFtciDZi3nPaLX6jinFxl3fyapzuBIIhkv4dKSwb UZaoKUKiGePj1V68LqQwRFDRmG8QBYojF/WQXIqV8ow=; X-AuditID: c1b4fb2d-223ff700000055ff-62-5b647fb33ff8 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 93.76.22015.3BF746B5; Fri, 3 Aug 2018 18:15:47 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 3 Aug 2018 18:15:46 +0200 Received: from [159.107.143.207] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.186) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Fri, 3 Aug 2018 18:15:46 +0200 To: "siwar.benhadjsaid@gmail.com" References: <152234044690.9048.14873584059539163778.idtracker@ietfa.amsl.com> <97D2C41722FBFE4A9A8389D07F0AC0070311A0D2@EXDAG0-B2.intra.cea.fr> CC: Rodney Cummings , BEN HADJ SAID Siwar , "detnet@ietf.org" , BOC Michael , Karen O'Donoghue , "ieee-ietf-coord@ietf.org" From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <76d0dab4-8fac-7bff-ecf9-09003faef8be@ericsson.com> Date: Fri, 3 Aug 2018 18:15:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM2J7ue7m+pRog/YJCha/P81msbi05h+T xd2zVxgtPn9ZzGxxc8Y2NovXG56yWHxb+YDNgd3j8NuLjB47Z91l91iy5CeTx/Uz25kCWKK4 bFJSczLLUov07RK4MmZ0hRcs1K+4/5SjgfGQehcjB4eEgInEnnblLkYuDiGBo4wSnU8nsnQx cgI5XxklGiZ5wSU+bbrDCJIQFoiTuPhgKiuILSJgL7H4xXJmiKIXjBLTu06zgzjMAm1MEo9e bmMCqWIDqrp7aQMziM0LZF98vZMNZDWLgIrE4i8+IKaoQIzE+r4EiApBiZMzn4AdwSmQKPGy F2IXs4CFxMz55xkhbHmJ5q2zmSEOVZP49PYh+wRGwVlI2mchaZmFpGUBI/MqRtHi1OLi3HQj Y73Uoszk4uL8PL281JJNjMCAP7jlt+4OxtWvHQ8xCnAwKvHwOuWkRAuxJpYVV+YeYpTgYFYS 4X3bmRwtxJuSWFmVWpQfX1Sak1p8iFGag0VJnFdv1Z4oIYH0xJLU7NTUgtQimCwTB6dUA2Pb veav+gacx8sVZa8euLD2YL1uVd/BM1Ie1t1buSyiUz8/CAy/1lJ+xKDC/P6ldTfVXjz/FvWg 0obxydN929cdXHFUyi7/+zH1+V1MR3XTb/Kc25rG9c3rfFZ00r3VrkJRHzvClvwrO9KbvZMr e2W6VlVgUfnKSdMnXFgcuHGbzgTRv4cddvAqsRRnJBpqMRcVJwIA6Bpj1HQCAAA= Archived-At: Subject: Re: [Detnet] New Version Notification for draft-benhadjsaid-detnet-gptp-yang-00.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Fri, 03 Aug 2018 16:15:53 -0000 Hi Siwar, I second Rodney. Thank you very much for your efforts on working with IEEE 802.1AS YANG! IEEE 802.1AS belongs to IEEE 802.1 ( http://ieee802.org/1 ). IEEE 802.1AS YANG will be done in IEEE 802.1. It would be great if you could contribute to IEEE 802.1. Best regards, János On 4/9/2018 9:13 PM, Rodney Cummings wrote: > Hello Siwar, > > It is good to hear that you see a need for YANG for IEEE 802.1AS. I agree. > > The fundamental issue is that IEEE 802 working groups have assumed the > responsibility for developing YANG modules for IEEE 802 standards, > including 802.1AS. For example, this site is being used for 802 > coordination on YANG: > https://1.ieee802.org/yangsters/ > > Therefore, your proposal is best targeted as a proposal > to the IEEE 802.1 working group, and not an IETF working group. > > I notice that your YANG is supporting the published IEEE Std 802.1AS-2011. > Although I don't speak for the 802.1 working group, I think the assumption > there was that YANG would be more desired for the upcoming revision of > 802.1AS. Since the revision of 802.1AS is still a work in progress, that > is one of the reasons why 802.1 currently has no YANG project for 802.1AS. > > If you need YANG for 802.1AS-2011, you could certainly bring that as a > request to the 802.1 working group. If we move forward with a project > for that, I would recommend doing it as an augment to: > https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/ > That 1588-2008 project is getting closer to IESG Last Call (I hope), > so I doubt that using it as the basis for a new 802.1AS-2011 project > would be a problem. > > Rodney > >> -----Original Message----- >> From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of BEN HADJ SAID >> Siwar >> Sent: Thursday, March 29, 2018 11:38 AM >> To: detnet@ietf.org >> Cc: BOC Michael ; siwar.benhadjsaid@gmail.com >> Subject: [Detnet] TR: New Version Notification for draft-benhadjsaid- >> detnet-gptp-yang-00.txt >> >> Hi detnet WG, >> >> >> >> This mail is to announce that we have just uploaded this 802.1AS YANG >> model. >> >> >> >> We know that there is a big effort In IEEE 802.1 TSN to have IEEE 802.1AS- >> rev published with its YANG model. However, for our own internal projects >> we were in need for 802.1AS YANG model so that our SDN controller can >> manage the time synchronization configuration. This allows us to manage >> all TSN mechanisms via the same approach ( using YANG models). >> >> >> >> We are open to your comments. >> >> >> >> Siwar >> >> >> >> >> >> >> >> -----Message d'origine----- >> >> De : internet-drafts@ietf.org >> >> Envoyé : jeudi 29 mars 2018 18:21 >> >> À : BEN HADJ SAID Siwar ; BOC Michael >> ; BEN HADJ SAID Siwar ; BOC >> Michael >> >> Objet : New Version Notification for draft-benhadjsaid-detnet-gptp-yang- >> 00.txt >> >> >> >> >> >> A new version of I-D, draft-benhadjsaid-detnet-gptp-yang-00.txt >> >> has been successfully submitted by Siwar Ben Hadj Said and posted to the >> IETF repository. >> >> >> >> Name: draft-benhadjsaid-detnet-gptp-yang >> >> Revision: 00 >> >> Title: YANG Model of IEEE 802.1AS >> >> Document date: 2018-03-29 >> >> Group: Individual Submission >> >> Pages: 43 >> >> URL: https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dbenhadjsaid-2Ddetnet-2Dgptp- >> 2Dyang- >> 2D00.txt&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o >> 7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=n5OvszTEhiWz0g6qm-OrYwGBAI- >> faJpmTLdYd2jAKp4&s=iRw_tqi_ipXdc9JwGjwIX4JElx60XoudgGIzfW3sGGI&e= >> >> Status: https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__datatracker.ietf.org_doc_draft-2Dbenhadjsaid-2Ddetnet-2Dgptp- >> 2Dyang_&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7 >> Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=n5OvszTEhiWz0g6qm-OrYwGBAI- >> faJpmTLdYd2jAKp4&s=jGlbzT71EK9oOFZDn_wUFEXPoTtSSAIOVEKD50eZnRo&e= >> >> Htmlized: https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__tools.ietf.org_html_draft-2Dbenhadjsaid-2Ddetnet-2Dgptp-2Dyang- >> 2D00&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7 >> CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=n5OvszTEhiWz0g6qm-OrYwGBAI- >> faJpmTLdYd2jAKp4&s=Dzm-cZFDO8X3B9dXa3Px8D-Vo_Ml3yuZoqoF2ymNg5k&e= >> >> Htmlized: https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__datatracker.ietf.org_doc_html_draft-2Dbenhadjsaid-2Ddetnet-2Dgptp- >> 2Dyang&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7D >> w7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=n5OvszTEhiWz0g6qm-OrYwGBAI- >> faJpmTLdYd2jAKp4&s=uUnjcClGH-V3bVIcxjJHvNekFiyJqBKjE5iLmvQp9Rc&e= >> >> >> >> >> >> Abstract: >> >> This document describes a YANG data model for the management of IEEE >> >> 802.1AS module in network devices. This data model includes >> >> configuration data and state data (status information and counters >> >> for the collection of statistics). >> >> >> >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https- >> 3A__www.ietf.org_mailman_listinfo_detnet&d=DwIGaQ&c=I_0YwoKy7z5LMTVdyO6YCi >> E2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=n5Ov >> szTEhiWz0g6qm-OrYwGBAI- >> faJpmTLdYd2jAKp4&s=7p0iTNuPmr9FNPccGa9s8cxd7Hr0__QN6auqCVkfRMY&e= > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Mon Aug 6 14:20:24 2018 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 5B368130E3F for ; Mon, 6 Aug 2018 14:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=TxJrKbbt; dkim=pass (1024-bit key) header.d=ericsson.com header.b=TEqReFtg 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 mrahrrITwKTg for ; Mon, 6 Aug 2018 14:20:19 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 D98B2128BAC for ; Mon, 6 Aug 2018 14:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1533590417; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=X87ZjN+J0gI9aJmZEy99qF9uw+WzdYtzXQA0CiJjaik=; b=TxJrKbbtcYfbuwRYeQugclIPGfpDNmLYqUIl7eEA41eSrERXQHxHMOh5W3MAvm2S Stv2rp9GckA5BNS0ulEQ9JyNDtSyeSFCHUGipHWOCqjq2HEr8FBlfHEFT6IDxZgb WDqxzMUQvAn6ZtCJ72bZ72YbOppdxt1B5UAl5xcIPpY=; X-AuditID: c1b4fb3a-481ff7000000145f-52-5b68bb919a6b Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.37.05215.19BB86B5; Mon, 6 Aug 2018 23:20:17 +0200 (CEST) Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 6 Aug 2018 23:20:16 +0200 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 6 Aug 2018 23:20:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X87ZjN+J0gI9aJmZEy99qF9uw+WzdYtzXQA0CiJjaik=; b=TEqReFtg3ej8F1GcWMYL3fmu63K64eyVtfw7A1EiMfVdf8qeWhVdhIhVY3Dq+Zv+b7MN+s/qh0qG0N2hHvDCI5LSoSphbuyUmybeMrZKiZppNhSCK3z3b87XKOAQK5b3s56fcopzg1y/pTJJoJv+9ZJIDn2N+bWGQ+AWxNLJET4= Received: from HE1PR0701MB2457.eurprd07.prod.outlook.com (10.168.128.139) by HE1PR0701MB2570.eurprd07.prod.outlook.com (10.168.187.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.15; Mon, 6 Aug 2018 21:20:14 +0000 Received: from HE1PR0701MB2457.eurprd07.prod.outlook.com ([fe80::a89f:af8b:b78a:b04c]) by HE1PR0701MB2457.eurprd07.prod.outlook.com ([fe80::a89f:af8b:b78a:b04c%9]) with mapi id 15.20.1038.013; Mon, 6 Aug 2018 21:20:13 +0000 From: Janos Farkas To: Janos Farkas , "detnet@ietf.org" , "STDS-802-1-L@LISTSERV.IEEE.ORG" , "ieee-ietf-coord@ietf.org" CC: "detnet-chairs@ietf.org" Thread-Topic: =?utf-8?B?RGV0TmV0IOKAkyBUU04gam9pbnQgc2Vzc2lvbiBpbiBCYW5na29r?= Thread-Index: AQHUKKj/ViQc3AA7gkKWNL0VnpsOHKSzP7kg Date: Mon, 6 Aug 2018 21:20:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:ab88:5082:1880:ed09:5ca4:4711:7be4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2570; 6:wuD/Z+BKlVAoDBsz35JKN09Pi4zGvtRgIXgUaXzfmBpwfcWmcIp96ZJ/PRVmaiX9n/ZKEPNT+SPWjgapSkA5dXFp6vSpHm2BiRLa1AVanX6DpM3hVB2DOfDO12MfNJawwCodh/i9AXCl3JQhkmJelhyocaTSvAcaPpJyONs4c89IXzRIvl92HYWhvlnd1C0Lg4z6fOkrp2S8ZtZ5cP2ZC+h6xuaOKsSp4SnKN9EgtJlUJLg/sMuYEBAonYFlWdk91Ky8UXoD82SANc3BXWi0QH0r6lQ5B7VYTgZz4MVaiPuTlEnCGkp4VRtT7gmjiaWcUgAIqzkN9yczeAfMjWrX2szbksQyH52YSPIpNJ7zGJTGm5bhRdGdcOEvFDEiDR9hcrBQnyzjcXpbtUEtzxgR49+2YV5apxQVtd/sCD4SB6KpibpZ0acBR7PBJ2oX3M0MnwXkFr/ksgYy6WSdYnAuhg==; 5:G8Wzvf/4PYkZ7dZ/BQNAPMmzNagbumdtgFg3geLy5GL81cqRxS34Dnem6HgIlSY9/wEW2bUjHP746MiDc8avABjiFY8th9hAqhV4wrwuufbft94SYymf9oKZYeB0ohjVgJ5ifhDOpPKeSFdAQy0cWZHpxbohlvOH73K4u0nZGF8=; 7:kilppzdj4LpkWFR/hGVT9xvkEfdnhN+7W9xu83TgG9Q7iYxlS/e0W914G4wXjLpT/+m7L7J0mZQuvzQB9h+9xvxM7prdkrKcQW2/hd1HtHkZ4YJAEQMHEwrMr8/C18tsBwk+BoF0TiK0M/SzjBwmoWl+CjUpK2qA0UfN8FbZvrNy70s+J50FHIdhoaRI7qkEnprpztX8AcJM8ezrCyG7FbWhTrYOHm4Mvpim8sFCBBTn7OOHjL6NxzkLtFaihDNL x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(376002)(136003)(396003)(13464003)(497574002)(50854003)(55885003)(199004)(45074003)(189003)(46003)(76176011)(106356001)(7696005)(55016002)(68736007)(14454004)(966005)(97736004)(6116002)(53546011)(6506007)(229853002)(9686003)(102836004)(110136005)(6306002)(316002)(486006)(478600001)(476003)(72206003)(25786009)(4326008)(305945005)(74316002)(7736002)(2201001)(86362001)(99286004)(2906002)(2501003)(5250100002)(53936002)(33656002)(6436002)(11346002)(105586002)(446003)(14444005)(256004)(53376002)(81166006)(1720100001)(2900100001)(5660300001)(6246003)(81156014)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2570; H:HE1PR0701MB2457.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-office365-filtering-correlation-id: f1c921df-98e9-4848-a656-08d5fbe265bd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB2570; x-ms-traffictypediagnostic: HE1PR0701MB2570: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Janos.Farkas@ericsson.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(823301020)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:HE1PR0701MB2570; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB2570; x-forefront-prvs: 07562C22DA received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: xMnT1oUCE9IccQEYcAsVgQD1Ylm4RFW/i7EY2SgbXunC6z6lKvv4ZkwnirBeffEf2U4LgqxzoFon/idsW/NHo1xmJ+hA1rgEmzDpqt1Mq+Vyw2g8QapKgGqgxy5R+dpyFfwEajLAnRSUfIr+FeHHQuYF23WP3TgIrVQE2M72E34VUnEvPOal6c8N75ZIPyJQ+M2tFQsQThucXz12rHO6GKey+Q+GIfyXx0Cp/Mc5ZcNTiB+Rals09uWkotri6YyDKp7ao1ShP7c7v3KwSPAjD0dYnYETXByJ8nz65HPk4fb1ZV5GGAuBs3uqzVu+JL1zzI+XG5w0AyD4mN57sGYonCOQObgGrp3Nbu+1lClG+RU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f1c921df-98e9-4848-a656-08d5fbe265bd X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2018 21:20:12.8809 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2570 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42KZGbG9THfi7oxog4fXeSyu9f9gsfj9aTaL xaU1/5gsVt/ydmDxWLLkJ5NHy7dTzAFMUVw2Kak5mWWpRfp2CVwZ87YlFnzRqTjTfZu5gfGB dhcjJ4eEgIlE0/0NLCC2kMBRRolvLVldjFxA9ldGiS97OhghnMVMEs0n57GAOCwCE5glnu1a zQyRmc4k0bXmK1TZU0aJvz0vmECGsQnoSUy9OYsdJCEicJFRYs2JlYwgCWYBU4kf73Yyg9jC AoESr18/YwOxRQT8JGa8ameCsI0k5u5tYgWxWQRUJA5dewkW5xVIkPgw/x9QnANom73E/o/i IGFOAQeJp0uWg41kFBCT+H5qDRPEKnGJW0/mM0E8KiCxZM95ZghbVOLl43+sELa1xIa2fhYI W1bi0vxusGckBA6wS7zd084GkTCUOL5yPzNEYhGbxOnXK6Cm+kps+PaKFSLRwyhxc/4bqFE6 Ep2NnYwQJ8VIfHg8EaohX+L05NVQq2Mkeq+dZ5rAaDgLybWzgJ5jFtCUWL9LHyKsKDGl+yH7 LLD/BSVOznzCsoCRZRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYCo5uOW31Q7Gg88dDzEK cDAq8fD+WJgRLcSaWFZcmXuIUYKDWUmElzcTKMSbklhZlVqUH19UmpNafIhRmoNFSZzXKc0i SkggPbEkNTs1tSC1CCbLxMEp1cDILWyizftXNz6nZ0MKQxzrXTmmEE7DSsGcY9e2xyyarJax 7OIKxRW8ghnJs9uef5v2NnnPnmSR+z4lj9bOOvs3Rsqc5S9vyI75Sxzcj02a89vzWZDTb5tL CzfJBV4PuVB4ftn7+hNvjxm/MPeoFbEV+rBf4aAny9ITwStyA2NVpSStFQpu5zArsRRnJBpq MRcVJwIAEPY3xyEDAAA= Archived-At: Subject: Re: [Detnet] =?utf-8?q?DetNet_=E2=80=93_TSN_joint_session_in_Bangkok?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Mon, 06 Aug 2018 21:20:22 -0000 SGksDQoNClBsZWFzZSBub3RlIHRoYXQgaG90ZWwgcmVzZXJ2YXRpb24gZm9yIElFVEYgMTAzIGlz IHBvc3NpYmxlOiBodHRwczovL3d3dy5pZXRmLm9yZy9ob3cvbWVldGluZ3MvMTAzL2hvdGVsLy4N Cg0KTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgY2FuY2VsbGF0aW9uIHBvbGljeSBmb3IgcmVzZXJ2 YXRpb25zIGF0IEJhbmdrb2sgTWFycmlvdHQgTWFycXVpcyBRdWVlbidzIFBhcmsgaXMgdGhhdCBj YW5jZWxsYXRpb24gaXMgZnJlZSB1cCB0byA3MiBob3VycyBwcmlvciB0byBhcnJpdmFsLCBob3dl dmVyLCBpdCBpcyBub3QgcG9zc2libGUgdG8gY2hhbmdlIHRoZSByZXNlcnZhdGlvbi4gSSBtYXkg YmUgd3JvbmcuIChUaGlzIGlzIHdoYXQgSSBzYXcgYWZ0ZXIgbWFraW5nIGEgcmVzZXJ2YXRpb24u KQ0KDQpOb3RlIHRoYXQgaG90ZWwgcm9vbSBib29raW5nIHZpYSBJRUVFIDgwMiBpcyBuZWVkZWQg aW4gb3JkZXIgdG8gZ2V0IGEgZGlzY291bnQgZnJvbSB0aGUgSUVFRSA4MDIgUGxlbmFyeSByZWdp c3RyYXRpb24gZmVlLiBBdCBsZWFzdCBvbmUgbmlnaHQgaXMgbmVlZGVkLiAoQXMgZmFyIGFzIEkg cmVjYWxsLCB0aGUgZGlzY291bnQgaXMgdXN1YWxseSBVU0QgMzAwLikNCg0KSUVFRSA4MDIgaG90 ZWwgcmVzZXJ2YXRpb24gaXMgbm90IHlldCBhdmFpbGFibGUsIGJ1dCBpdCB3aWxsIGJlIHNvb246 IGh0dHA6Ly84MDJ3b3JsZC5vcmcvcGxlbmFyeS9pZWVlLTgwMi1ncm91cC1ob3RlbC8NCg0KQmVz dCByZWdhcmRzLA0KSsOhbm9zDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBK w6Fub3MgRmFya2FzIDxqYW5vcy5mYXJrYXNAZXJpY3Nzb24uY29tPiANClNlbnQ6IFR1ZXNkYXks IEp1bHkgMzEsIDIwMTggMTA6MzIgQU0NClRvOiBkZXRuZXRAaWV0Zi5vcmc7IFNURFMtODAyLTEt TEBMSVNUU0VSVi5JRUVFLk9SRw0KQ2M6IGRldG5ldC1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6 IERldE5ldCDigJMgVFNOIGpvaW50IHNlc3Npb24gaW4gQmFuZ2tvaw0KDQpIaSwNCg0KV2Ugd2ls bCBoYXZlIGEgRGV0TmV0IOKAkyBUU04gam9pbnQgc2Vzc2lvbiBpbiBCYW5na29rIG9uIE5vdmVt YmVyIDExIFN1bmRheSwgd2hpY2ggaXMgYmV0d2VlbiBJRVRGIDEwMyBhbmQgdGhlIElFRUUgODAy IFBsZW5hcnkuIFRoZSB0d28gbWVldGluZ3MgYXJlIGJhY2sgdG8gYmFjayBpbiB0aGUgc2FtZSBo b3RlbDogTWFycmlvdHQgTWFycXVpcyBRdWVlbuKAmXMgUGFyaywgQmFuZ2tvaywgVGhhaWxhbmQg KGh0dHBzOi8vd3d3LmlldGYub3JnL2hvdy9tZWV0aW5ncy91cGNvbWluZywNCmh0dHA6Ly84MDJ3 b3JsZC5vcmcvcGxlbmFyeS9mdXR1cmUtcGxlbmFyeS1zZXNzaW9ucykuDQpUaGUgam9pbnQgc2Vz c2lvbiB3aWxsIGJlIGZyb20gOWFtIHRvIDVwbSB3aXRoIGEgbHVuY2ggYnJlYWsuDQpNZWV0aW5n IHJvb20gaXMgYmVpbmcgYXJyYW5nZWQgYnkgSUVFRSA4MDIuDQpUaGVyZSB3aWxsIGJlIGEgd2Vi IHBhZ2UgZm9yIHJlZ2lzdHJhdGlvbi4gUmVnaXN0cmF0aW9uIHdpbGwgYmUgcmVxdWlyZWQ7IHdv cmsgaXMgb25nb2luZyB0byBtYWtlIGl0IGZyZWUuDQoNCldlIHByb3Bvc2UgdGhlIGZvbGxvd2lu ZyB0b3BpY3MgZm9yIHRoZSBqb2ludCBzZXNzaW9uIGJvdGggZm9yIERldE5ldCBhbmQgVFNOOg0K LSBjdXJyZW50IHN0YXR1cw0KLSBvbmdvaW5nIHdvcmsNCi0gZnV0dXJlIHBsYW5zDQotIHJlbGF0 ZWQgYWN0aXZpdGllcywgZS5nLiwgVEVBUywgSW9UIGZvciBEZXROZXQ7IElFQywgSUVFRSBmb3Ig VFNODQoNClBsZWFzZSBzZW5kIGFnZW5kYSByZXF1ZXN0cyB0byBkZXRuZXQtY2hhaXJzQGlldGYu DQoNCkFnZW5kYSB3aWxsIGJlIHdvcmtlZCBhZnRlciBBdWd1c3QgaG9saWRheXMuDQoNCldlIHdp bGwgcHJvdmlkZSB1cGRhdGVzLCBlLmcuLCBvbiByZWdpc3RyYXRpb24sIGFnZW5kYSwgZXRjLiwg YXMgdGhleSBiZWNvbWUgYXZhaWxhYmxlLg0KDQpUaGUgY28tbG9jYXRlZCBtZWV0aW5ncyBnaXZl IHRoZSBvcHBvcnR1bml0eSB0byBwYXJ0aWNpcGF0ZSB0aGUgbWVldGluZyBvZiB0aGUgb3RoZXIg Z3JvdXAsIHRoZSBncm91cCBvbmUgdXN1YWxseSBub3QgYXR0ZW5kcyBvciBoYXZlbuKAmXQgYXR0 ZW5kZWQgeWV0LiBXZSBoYXZlIGNvbGxlY3RlZCBzb21lIGluZm9ybWF0aW9uIHRvIGhlbHAgbmF2 aWdhdGlvbiwgbWFraW5nIGRlY2lzaW9uLCBlLmcuLCBhZ2VuZGFzIG9mIHRoZSBsYXN0IG1lZXRp bmdzLg0KDQpJRVRGIERldE5ldCBXRyBpbmZvOg0KV2ViIHBhZ2U6IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvd2cvZGV0bmV0L2Fib3V0Lw0KRG9jdW1lbnRzOiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL3dnL2RldG5ldC9kb2N1bWVudHMvDQpEZXROZXQgV0cgYXQgSUVURiAxMDI6 DQogICAgLSBBZ2VuZGE6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvZGV0bmV0L2Rv Y3VtZW50cy8NCiAgICAtIFByZXNlbnRhdGlvbnM6IA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9tZWV0aW5nLzEwMi9zZXNzaW9uL2RldG5ldA0KICAgIC0gTWludXRlczogaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy0xMDItZGV0bmV0Lw0KSUVURiAxMDIgb3Zl cmFsbCBhZ2VuZGE6IA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMi9h Z2VuZGEuaHRtbA0KSUVURiAxMDIgZ2VuZXJhbCBpbmZvcm1hdGlvbjogaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaG93L21lZXRpbmdzLzEwMi8NCklFVEYgMTAzIHJlZ2lzdHJhdGlvbjogaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaG93L21lZXRpbmdzLzEwMy8NCg0KSUVFRSA4MDIuMVRTTiBURyBpbmZvOg0K V2ViIHBhZ2U6IGh0dHA6Ly9pZWVlODAyLm9yZy8xL3Rzbg0KRG9jdW1lbnRzIGFyZSBhdmFpbGFi bGUgdmlhIHRoZSBsaW5rcyBwcm92aWRlZCBhdCB0aGUgVEcgcGFnZSwgZS5nLiwgdmlhIHRoZSBw cm9qZWN0IHBhZ2VzLg0KVFNOIFRHIGF0IHRoZSBKdWx5IDIwMTggSUVFRSA4MDIgUGxlbmFyeToN CiAgICAtIEFnZW5kYTogDQpodHRwczovLzEuaWVlZTgwMi5vcmcvanVseS0yMDE4LXBsZW5hcnkt bWVldGluZy1pbi1zYW4tZGllZ28tY2EtdXNhLXRzbi10Zy1hZ2VuZGEvIA0KDQogICAgLSBQcmVz ZW50YXRpb25zIGFyZSBsaW5rZWQgZnJvbSB0aGUgYWdlbmRhDQogICAgLSBNaW51dGVzOiBodHRw czovLzEuaWVlZTgwMi5vcmcvY2F0ZWdvcnkvY3VycmVudC1hbmQtZm9ybWVyLW1lZXRpbmdzLw0K SUVFRSA4MDIgUGxlbmFyeSBvdmVyYWxsIHNjaGVkdWxlOiANCmh0dHA6Ly9zY2hlZHVsZS44MDJ3 b3JsZC5jb20vc2NoZWR1bGUvc2NoZWR1bGUvc2hvdyMsIEp1bHkgUGxlbmFyeSBpcyBzYXZlZCBh dDogDQpodHRwOi8vd3d3LmllZWU4MDIub3JnLzEvZmlsZXMvcHVibGljL2RvY3MyMDE4L2FkbWlu LTgwMi1zY2hlZHVsZS0wNzE4LnBkZi4pDQpJRUVFIDgwMiBQbGVuYXJ5IGdlbmVyYWwgaW5mb3Jt YXRpb246IGh0dHA6Ly84MDJ3b3JsZC5vcmcvcGxlbmFyeS8gSUVFRQ0KODAyIFBsZW5hcnkgcmVn aXN0cmF0aW9uOiANCmh0dHA6Ly84MDJ3b3JsZC5vcmcvcGxlbmFyeS9yZWdpc3RyYXRpb24taW5m b3JtYXRpb24vDQpOb3RlIHRoYXQgdGhlIFBsZW5hcnkgcGFnZXMgc2hvdyB0aGUgSnVseSBQbGVu YXJ5IGF0IHRoZSBtb21lbnQ7IHRoZXkgd2lsbCBiZSB1cGRhdGVkIHRvIHRoZSBOb3ZlbWJlciBQ bGVuYXJ5IGFzIHdlIGFyZSBnZXR0aW5nIGNsb3Nlci4NCg0KSWYgeW91IGFyZSBuZXcgdG8gVFNO LCB0aGVuIHRoZSBJRUMvSUVFRSA2MDgwMiBKb2ludCBQcm9qZWN0IG1heSBiZSBvZg0KaW50ZXJl c3Q6IA0KaHR0cDovL2llZWU4MDIub3JnLzEvdHNuL2llYy1pZWVlLTYwODAyLXRzbi1wcm9maWxl LWZvci1pbmR1c3RyaWFsLWF1dG9tYXRpb24uIA0KVGhlIEpvaW50IFByb2plY3QgaGFzIGJlZW4g Zm9ybWVkIHRvIHNwZWNpZnkgaG93IHRvIHVzZSBUU04gZm9yIGluZHVzdHJpYWwgYXV0b21hdGlv bi4gVGhlIG1lZXRpbmdzIG9mIHRoZSBqb2ludCBwcm9qZWN0IGFyZSBsaXN0ZWQgb24gdGhlIHdl YiBwYWdlLiBUaGUgam9pbnQgcHJvamVjdCB3aWxsIG1lZXQgTm92ZW1iZXIgMTItMTQgaW4gQmFu Z2tvay4NCg0KSWYgeW91IGhhdmUgcXVlc3Rpb25zLCBkb27igJl0IGhlc2l0YXRlIHRvIGFzayB1 cy4NCg0KQmVzdCByZWdhcmRzLA0KSsOhbm9zIGFuZCBMb3UNCg0K From nobody Tue Aug 7 08:17:52 2018 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 C88FF130E47; Tue, 7 Aug 2018 08:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 qUUPdy1e_v6U; Tue, 7 Aug 2018 08:17:34 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F6E130E54; Tue, 7 Aug 2018 08:17:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4C5E61561735; Tue, 7 Aug 2018 17:17:31 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Srwd0ETsFbP8; Tue, 7 Aug 2018 17:17:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 1E0E61561733; Tue, 7 Aug 2018 17:17:31 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NGkk4FihiVw3; Tue, 7 Aug 2018 17:17:31 +0200 (CEST) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id E54A21561730; Tue, 7 Aug 2018 17:17:30 +0200 (CEST) To: =?UTF-8?Q?J=c3=a1nos_Farkas?= Cc: "netmod@ietf.org" , detnet@ietf.org, "ieee-ietf-coord@ietf.org" References: <153163104655.12797.4549822574205791661.idtracker@ietfa.amsl.com> <1671ad91-5627-fedf-ef1c-9a2a790accd4@transpacket.com> From: Vladimir Vassilev Message-ID: Date: Tue, 7 Aug 2018 17:17:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Detnet] Fwd: New Version Notification for draft-vassilev-netmod-network-bridge-00.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Tue, 07 Aug 2018 15:17:38 -0000 Hi Janos, The concept defined in this draft goes outside the scope of 802.1Q.=20 Taking a subset of the OpenFlow 1.0 spec and defining corresponding=20 node-side YANG model with transactional flow table (/flows) and=C2=A0=20 optional support for controller introducing single RPC (transmit-packet)=20 and notification (packet-received) corresponding to OFPT_PACKET_OUT and=20 OFPT_PACKET_IN messages seemed like a natural evolution of the SDN=20 concept for the specification of alternative to OpenFlow southbound=20 protocol (e.g. over NETCONF). With OpenFlow-derived flow model=20 addressing 1. forwarding (switching) and adding a=C2=A0 2. flexible sched= uler=20 model referencing the flows a complete bridge model is presented. It can=20 be implemented seamlessly on all OpenFlow 1.0 and above supporting=20 hardware and more importantly extensions (to flow forwarding or=20 scheduling) to the OpenFlow spec can be specified in YANG. A device implementing this model can implement the 802.1Q family of=20 models with proper controller software (STP, LLDP etc. which is readily=20 available) but it is not limited to that. We have been following closely the models developed by the IEEE TSN and=20 we have both reused terminology and ensured all of those standard=20 solutions can be represented with the generic scheduler model part of=20 this draft. The IEEE YANG model is great reference but is not suitable=20 for all applications especially when more flexibility is required and=20 being able to augment a module to document our vendor specific=20 extensions. The 802.1Q are limited in certain ways to 802.1Q (for=20 example fixed to 8 traffic classes either priority or time slots). Attempts to make 802.1Q configuration more generic and a subset to a=20 more generic forwarding configuration mechanism are not unprecedented=C2=A0= =20 (see=20 https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/=20 ). Here virtual interfaces instead of flows are introduced. IMO a standard flows model is needed starting from something with=20 running software and trying to find consensus. I see this goal is=20 already part of the detnet focus=20 https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model and=20 https://datatracker.ietf.org/doc/draft-geng-detnet-conf-yang Requesting comments on the ietf netmod list seemed like a good place to=20 start to allow for open discussion and if we manage to identify anything=20 that falls into the scope of IEEE 802.1Q except the name "bridge" I=20 would be glad to contribute there. Same goes for the detnet WG. Vladimir On 08/03/2018 05:59 PM, J=C3=A1nos Farkas wrote: > Hi Vladimir, > > Bridging including bridge management belong to IEEE 802.1:=20 > https://1.ieee802.org/. You may consider contributing to IEEE 802.1.=20 > The next Interim is hosed by your company in Oslo:=20 > https://1.ieee802.org/meetings. > > IEEE 802.1Qcp is the basic bridge management specification, which is=20 > an approved draft standard to be published soon:=20 > http://standards.ieee.org/findstds/standard/802.1Qcp-2018.html. (The=20 > archived web page of the finished project:=20 > https://1.ieee802.org/tsn/802-1qcp.) > > The pages of the ongoing projects are available via the TSN page:=20 > https://1.ieee802.org/tsn/#Ongoing_TSN_Projects, including P802.1Qcw=20 > (https://1.ieee802.org/tsn/802-1qcw/), which specifies YANG for=20 > various bridge scheduling mechanisms. > > Best regards, > Janos > > > On 7/17/2018 4:26 PM, Vladimir Vassilev wrote: >> Hi, >> >> I have submitted a draft=20 >> https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/= =20 >> that proposes a model for network bridge management based on the=20 >> concept of flows. The model has 2 components 1. Forwarding based on=20 >> flows. 2. Scheduling/QoS based on gate controller topologies that=20 >> provide a new and very generic way of modeling and managing the=20 >> actual scheduler design and map the flows to scheduler topology inputs= . >> >> There is similar work on the flow based forwarding in detnet however=20 >> I am not sure detnet is the right workgroup to be defining the flow=20 >> model.=C2=A0 I think the flow concept is important and general. It is = as=20 >> significant as the concept of interfaces and is not only relevant to=20 >> detnet. Let me know what is your opinion of the draft and the=20 >> proposed network bridge concept. >> >> Vladimir >> >> -------- Forwarded Message -------- >> Subject:=C2=A0=C2=A0=C2=A0=C2=A0 New Version Notification for=20 >> draft-vassilev-netmod-network-bridge-00.txt >> Date:=C2=A0=C2=A0=C2=A0=C2=A0 Sat, 14 Jul 2018 22:04:06 -0700 >> From: internet-drafts@ietf.org >> To:=C2=A0=C2=A0=C2=A0=C2=A0 Vladimir Vassilev >> >> >> >> A new version of I-D, draft-vassilev-netmod-network-bridge-00.txt >> has been successfully submitted by Vladimir Vassilev and posted to the >> IETF repository. >> >> Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-vassilev-netmod-= network-bridge >> Revision:=C2=A0=C2=A0=C2=A0 00 >> Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A YANG Data Model for= Network Bridge Management >> Document date:=C2=A0=C2=A0=C2=A0 2018-07-14 >> Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individual Submission >> Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 44 >> URL:=20 >> https://www.ietf.org/internet-drafts/draft-vassilev-netmod-network-bri= dge-00.txt >> Status:=20 >> https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/ >> Htmlized:=20 >> https://tools.ietf.org/html/draft-vassilev-netmod-network-bridge-00 >> Htmlized:=20 >> https://datatracker.ietf.org/doc/html/draft-vassilev-netmod-network-br= idge >> >> >> Abstract: >> =C2=A0=C2=A0 This document introduces new YANG model of a network brid= ge. >> >> >> >> Please note that it may take a couple of minutes from the time of=20 >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet > From nobody Sun Aug 12 14:44:42 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBA2130E48; Sun, 12 Aug 2018 14:44:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lberger@labn.net, detnet@ietf.org, db3546@att.com, detnet-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153411027986.11934.17692935292232560996.idtracker@ietfa.amsl.com> Date: Sun, 12 Aug 2018 14:44:39 -0700 Archived-At: Subject: [Detnet] detnet - New Meeting Session Request for IETF 103 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2018 21:44:40 -0000 A new meeting session request has just been submitted by Lou Berger, a Chair of the detnet working group. --------------------------------------------------------- Working Group Name: Deterministic Networking Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: pce teas ccamp netmod mpls Second Priority: rtgwg pals bess lsr tsvwg Third Priority: nvo3 People who must be present: Lou Berger David L. Black Deborah Brungard Janos Farkas Ethan Grossman Resources Requested: Special Requests: Later in the week is preferred as we have the joint meeting with IEEE on Sunday following IETF. --------------------------------------------------------- From nobody Tue Aug 14 12:16:50 2018 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 409BA124BE5; Tue, 14 Aug 2018 12:16:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: <3GPPLiaison@etsi.org> Cc: TEAS Discussion List , l2sm-chairs@ietf.org, rtg-ads@ietf.org, teas-chairs@ietf.org, Adrian Farrel , DetNet Discussion List , detnet-chairs@ietf.org, ops-ads@ietf.org, Qin Wu , zoulan@huawei.com, L2VPN Service Model Discussion List X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153427420818.27176.13203359648572620433.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2018 12:16:48 -0700 Archived-At: Subject: [Detnet] New Liaison Statement, "Further Information About IETF Work Relevant to Network Slicing" X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 19:16:48 -0000 Title: Further Information About IETF Work Relevant to Network Slicing Submission Date: 2018-08-14 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1595/ From: Adrian Farrel To: 3GPPLiaison@etsi.org Cc: zoulan@huawei.com,Adrian Farrel ,Qin Wu ,l2sm-chairs@ietf.org ,teas-chairs@ietf.org ,detnet-chairs@ietf.org ,ops-ads@ietf.org ,rtg-ads@ietf.org ,DetNet Discussion List ,L2VPN Service Model Discussion List ,TEAS Discussion List Response Contacts: Adrian Farrel ,Qin Wu Technical Contacts: Adrian Farrel ,Qin Wu Purpose: In response Referenced liaison: Reply LS on IETF work related to the management and orchestration of network slicing (https://datatracker.ietf.org/liaison/1588/) Body: Thank you for your liaison statement "Reply LS on IETF work related to the management and orchestration of network slicing" from 3GPP-TSG-SA-WG5 dated 7/23/18. This has been passed to the chairs of the IETF's L2SM working group to coordinate a response. Our understanding of the 3GPP's definition of a "Transport Network" is that it covers any network that underlies and provides connectivity for 3GPP networks or services. There are, of course, many other definitions of "Transport Network" so it is important that we are clear on this. The IETF works on IP and MPLS dataplane technologies as well as higher layer encapsulations such as UDP, TCP, and HTTP all of which may be applicable to your requirements. Additionally, the IETF works on control and management plane specifications applicable to all technology layers including IP and sub-IP transport networks. You may be interested in the work of the DetNet working group [1] which is collaborating with the IEEE802.1 TSN task group to develop mechanisms to provide deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability. These features may prove to be particularly useful in supporting connectivity (or slices) for 5G services. The DetNet Architecture is largely complete and is described in [2]. DetNet's use of the IP [3] and MPLS [4] date planes is still being defined in the working group. You may also be interested in early work on configuration control in [5]. With regard to your specific enquiry about management interfaces there are several layers of interaction that you should consider: - The L2VPN and L3VPN service models ([6] and [7]) are intended to allow a customer to request a VPN connectivity service from an operator. These models may be used as a 'paper procedure' allowing a common format for service requests, or may facilitate automation so that one software component may make requests to another component responsible for orchestrating the underlying network. The services described by these two models would normally be provided by IP or MPLS networks, but the details of how the service is provided are deliberately out of scope. Thus, direct control of transport resources do not fall within the scope of these service models. What is in scope are the points of attachment (connection end points), the type of attachment circuit, and the quality of connectivity that is required (such as bandwidth and quality of service). The way that service models fit into the management of networks is described in RFC 8309 [8]. - VPN delivery models are being specified in the BESS working group [9]. These models allow an operator to manage a network for the delivery of a VPN connectivity service, and would normally be provided by IP or MPLS networks. These models describe the details of how the service is implemented within the network. Examples include the YANG Data Model for MPLS-based L2VPN [10], the YANG Data Model for BGP/MPLS L3 VPNs [11], and the YANG Data Model for EVPN [12]. - The TEAS working group [13] is developing a YANG model for the configuration and management of Traffic Engineering (TE) interfaces, tunnels and Label Switched Paths (LSPs) [14]. While this is a service delivery model, it closely matches the corresponding service model for 'connectivity as a service'. - The TEAS working group is also working on the Abstraction and Control of Traffic Engineered Networks (ACTN) [15]. This approach allows a network user to request and manipulate 'topology' in the form of a virtual network and is accessed through YANG models such as [16] and [17]. This is applicable to all forms of traffic engineered network from MPLS through Ethernet, TDM, and OTN, to WDM. Virtual network creation and operation may be similar to 'network slicing' that you describe: this is discussed in an individual contribution Internet-Draft [18], while a further individual document [19] describes an architecture for data model driven network management of virtual networks. Further dialogue is needed around the topic of traffic isolation in network slicing in particular with respect to its application to shared packet or frame networks. The IETF has developed techniques to protect against misdelivery of traffic and to secure customer traffic as it is transmitted over the network. Similarly, there are protocol mechanisms to reserve and dedicate network resources to specific traffic flows or to provide statistical accounting that, combined with traffic policing, ensure that network resources are not over-committed. Nevertheless, it has to be understood that packet and frame networks are essentially shared-media networks where separation or isolation of traffic is logical not physical. It is often hard to provide a firm roadmap for delivery of IETF specifications as the work only completes when it is technically sound and has sufficient consensus for publication: it is not tied to any formal schedule. However, we can suggest the following information: - [2] Still needs work: may be an RFC within 12 months - [3] Unknown timing - [4] Unknown timing - [5] Unknown timing - [6] Complete and in RFC Editor processing: likely to be an RFC within two months - [7] Already an RFC - [8] Already an RFC - [10] Still needs work: may be an RFC within 12 months - [11] Still needs work: may be an RFC within 12 months - [12] Still needs work: may be an RFC within 12 months - [14] Still needs work: may be an RFC within 6 months - [15] Complete and in RFC Editor processing: likely to be an RFC within two months - [16] Still needs work: may be an RFC within 6 months - [17] Still needs work: may be an RFC within 6 months - [18] Unknown timing - [19] Unknown timing Best regards, Adrian Farrel and Qin Wu (IETF L2SM Working Group chairs) [1] https://datatracker.ietf.org/wg/detnet/about/ [2] https://tools.ietf.org/html/draft-ietf-detnet-architecture [3] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-ip [4] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-mpls [5] https://tools.ietf.org/html/draft-geng-detnet-conf-yang [6] https://www.ietf.org/id/draft-ietf-l2sm-l2vpn-service-model-10.txt [7] https://www.rfc-editor.org/rfc/rfc8299.txt [8] https://www.rfc-editor.org/rfc/rfc8309.txt [9] https://datatracker.ietf.org/wg/bess/about/ [10] https://www.ietf.org/id/draft-ietf-bess-l2vpn-yang-08.txt [11] https://www.ietf.org/id/draft-ietf-bess-l3vpn-yang-03.txt [12] https://www.ietf.org/id/draft-ietf-bess-evpn-yang-05.txt [13] https://datatracker.ietf.org/wg/teas/about/ [14] https://www.ietf.org/id/draft-ietf-teas-yang-te-16.txt [15] https://www.ietf.org/id/draft-ietf-teas-actn-framework-15.txt [16] https://www.ietf.org/id/draft-ietf-teas-actn-yang-01.txt [17] https://www.ietf.org/id/draft-ietf-teas-actn-vn-yang-01.txt [18] https://www.ietf.org/id/draft-king-teas-applicability-actn-slicing-03.txt [19] https://www.ietf.org/id/draft-wu-model-driven-management-virtualization-01.txt Attachments: Microsoft Word version of this LS https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-08-14-l2sm-3gpp-tsg-sa-wg5-further-information-about-ietf-work-relevant-to-network-slicing-attachment-1.doc From nobody Tue Aug 14 12:55:04 2018 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 D7112130EC7; Tue, 14 Aug 2018 12:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 V7Y4FWq41Z-y; Tue, 14 Aug 2018 12:55:01 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 81D9A130EB9; Tue, 14 Aug 2018 12:55:01 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id h14-v6so18194223wrw.13; Tue, 14 Aug 2018 12:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=1p5qVkjwJlK6ZrUNIDjIsXYpQO5hQ4f9B9wXLQykSgc=; b=f67VGG0Rv4V4ZHHZ+1KKJfXO3ep4mmBi5MkbWZgypI9GxjDk+G0n4lWVJIIFpIc18x MJKmLWzfLXAWlgfGoxYCTfKPmzH7ddooJGwBQ+wqjFsZAgiTIw7BPcEEdjtlgrm5LilG udn7eswYbGe3HWYDvXfjxH2juaMfDJPOs9XlZxQtApavL6i3ppqjTfAI6Q0oi3oDjC63 p7veAyavQhbgUbuvqBOEMRfhwsXiEcdVtX793KQfSNzJaz9DFLrlH0v9APhAby6fClTJ gGr7XzNTbnXy22o8mRjdyvF9lKjUCGZtIJlrj2jTTvpE2upjXav5Mbzgqs/e6H/fmvEG BQCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=1p5qVkjwJlK6ZrUNIDjIsXYpQO5hQ4f9B9wXLQykSgc=; b=G6+fsk7+K6CTbZC6zyN6Z6bgvlndy3u1f3hG5cyWWjY4IOLD1id5pq8lMZxeqipqsj 9k70Dl9AqdikYApzhZCX8ftW+inX04wxDTyQXxYpxTHfeerjpnDYDXm1ej8RkBKp8e5Z hiYKWePsGLcCEfRgVrOIBTwrzC2BasoReKUXABHDQFKnHiyq8wfK5WWZ200XTu72VFPN GAA+x704y1xp8sUINwweJNwq7/22XPmZPGBGWi6b28SgXAgn94mCcQYIVU/voaJERDPJ h7gDmwxxdm+vFVgBsDXiwevgrsHLWjFhvgP7gvT9VrYRdaOp1TNOsL5PR6rv6Al6KUEo r3ow== X-Gm-Message-State: AOUpUlG12Z+YszA/eBYQuou8rF32DEP29omNS88i/NG6Jp6BjrTSnF0H eZT3MZOR5LxbQgumzsf/b1YRS+zO X-Google-Smtp-Source: AA+uWPy1Im1lLIFXOb+aBdc2/vDiSciE12BcS6XgPrs62P9tF7w0W5aufegKIao3qnVmqa7AYw6yKg== X-Received: by 2002:adf:aadb:: with SMTP id i27-v6mr14756894wrc.149.1534276499675; Tue, 14 Aug 2018 12:54:59 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id t19-v6sm8673479wmi.42.2018.08.14.12.54.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 12:54:59 -0700 (PDT) To: Janos Farkas , "detnet@ietf.org" , "STDS-802-1-L@LISTSERV.IEEE.ORG" , "ieee-ietf-coord@ietf.org" Cc: "detnet-chairs@ietf.org" References: From: Stewart Bryant Message-ID: Date: Tue, 14 Aug 2018 20:54:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Detnet] =?utf-8?q?DetNet_=E2=80=93_TSN_joint_session_in_Bangkok?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Tue, 14 Aug 2018 19:55:04 -0000 Hi Where are we with registering for the joint session, i.e. just registering for the Sunday. I have booked Sat/Sun on the IETF scheme to attend the meeting, I hope that IEEE are not going to require that we make split bookings to get a good rate (ideally free) at the joint session. Thanks Stewart. On 06/08/2018 22:20, Janos Farkas wrote: > Hi, > > Please note that hotel reservation for IETF 103 is possible: https://www.ietf.org/how/meetings/103/hotel/. > > My understanding of the cancellation policy for reservations at Bangkok Marriott Marquis Queen's Park is that cancellation is free up to 72 hours prior to arrival, however, it is not possible to change the reservation. I may be wrong. (This is what I saw after making a reservation.) > > Note that hotel room booking via IEEE 802 is needed in order to get a discount from the IEEE 802 Plenary registration fee. At least one night is needed. (As far as I recall, the discount is usually USD 300.) > > IEEE 802 hotel reservation is not yet available, but it will be soon: http://802world.org/plenary/ieee-802-group-hotel/ > > Best regards, > János > > -----Original Message----- > From: János Farkas > Sent: Tuesday, July 31, 2018 10:32 AM > To: detnet@ietf.org; STDS-802-1-L@LISTSERV.IEEE.ORG > Cc: detnet-chairs@ietf.org > Subject: DetNet – TSN joint session in Bangkok > > Hi, > > We will have a DetNet – TSN joint session in Bangkok on November 11 Sunday, which is between IETF 103 and the IEEE 802 Plenary. The two meetings are back to back in the same hotel: Marriott Marquis Queen’s Park, Bangkok, Thailand (https://www.ietf.org/how/meetings/upcoming, > http://802world.org/plenary/future-plenary-sessions). > The joint session will be from 9am to 5pm with a lunch break. > Meeting room is being arranged by IEEE 802. > There will be a web page for registration. Registration will be required; work is ongoing to make it free. > > We propose the following topics for the joint session both for DetNet and TSN: > - current status > - ongoing work > - future plans > - related activities, e.g., TEAS, IoT for DetNet; IEC, IEEE for TSN > > Please send agenda requests to detnet-chairs@ietf. > > Agenda will be worked after August holidays. > > We will provide updates, e.g., on registration, agenda, etc., as they become available. > > The co-located meetings give the opportunity to participate the meeting of the other group, the group one usually not attends or haven’t attended yet. We have collected some information to help navigation, making decision, e.g., agendas of the last meetings. > > IETF DetNet WG info: > Web page: https://datatracker.ietf.org/wg/detnet/about/ > Documents: https://datatracker.ietf.org/wg/detnet/documents/ > DetNet WG at IETF 102: > - Agenda: https://datatracker.ietf.org/wg/detnet/documents/ > - Presentations: > https://datatracker.ietf.org/meeting/102/session/detnet > - Minutes: https://datatracker.ietf.org/doc/minutes-102-detnet/ > IETF 102 overall agenda: > https://datatracker.ietf.org/meeting/102/agenda.html > IETF 102 general information: https://www.ietf.org/how/meetings/102/ > IETF 103 registration: https://www.ietf.org/how/meetings/103/ > > IEEE 802.1TSN TG info: > Web page: http://ieee802.org/1/tsn > Documents are available via the links provided at the TG page, e.g., via the project pages. > TSN TG at the July 2018 IEEE 802 Plenary: > - Agenda: > https://1.ieee802.org/july-2018-plenary-meeting-in-san-diego-ca-usa-tsn-tg-agenda/ > > - Presentations are linked from the agenda > - Minutes: https://1.ieee802.org/category/current-and-former-meetings/ > IEEE 802 Plenary overall schedule: > http://schedule.802world.com/schedule/schedule/show#, July Plenary is saved at: > http://www.ieee802.org/1/files/public/docs2018/admin-802-schedule-0718.pdf.) > IEEE 802 Plenary general information: http://802world.org/plenary/ IEEE > 802 Plenary registration: > http://802world.org/plenary/registration-information/ > Note that the Plenary pages show the July Plenary at the moment; they will be updated to the November Plenary as we are getting closer. > > If you are new to TSN, then the IEC/IEEE 60802 Joint Project may be of > interest: > http://ieee802.org/1/tsn/iec-ieee-60802-tsn-profile-for-industrial-automation. > The Joint Project has been formed to specify how to use TSN for industrial automation. The meetings of the joint project are listed on the web page. The joint project will meet November 12-14 in Bangkok. > > If you have questions, don’t hesitate to ask us. > > Best regards, > János and Lou > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Tue Aug 14 14:03:16 2018 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 3D17C130DD1; Tue, 14 Aug 2018 14:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 hmHnM_742zNE; Tue, 14 Aug 2018 14:03:12 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 3283A1286E3; Tue, 14 Aug 2018 14:03:12 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id k12-v6so36241874oiw.8; Tue, 14 Aug 2018 14:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y39r4wcf74L4AiTFtWq3CtASDS3gh3ecnkgfJgImLGY=; b=kvgnIj8Trk+F0ShGGOwPsqqdC/Er9bX1PbrNo9OpvLPFAJvmhWS2X3r9hz4Sdy+dIq trEhcaUiHNjGzb75pIUmbYVno+MV7nn0FyQw/IxB1B2KYMlmO/Ul7UGgW7FfD2ZatYgc OD55L+OnLUXnxyt8NEvfX40Z3MdDMtXYfcfGoZtNEfyZOdkF0W8EzYoBdvj8Ox7PRK41 1yuQZ5uxs/+L6OQBYgFfkw/uqQ9aD9FIpx4yEz0qm3nwsOKSOWz1IJdcd3FFQMo7GLQH ESAJh7KqXhanb8bEEOMig9DMEfMOTODKZy5pvxNYrIfKL1T0kNYtAinkE6O7ZPKDtQcf n3gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y39r4wcf74L4AiTFtWq3CtASDS3gh3ecnkgfJgImLGY=; b=hV7vOHuFHCo6E9jS9B7wzarv+EDa/yBL67Qa0lSspp414MnRxBM/UxRoK74tOlF8NR E4c0JlI8GurdpRWjLGX1+p+tjByR616R2Fq3VBupRNmpSnmB5HcUcSAY56BRwBZGDjh2 6Wj58Kr27acAK/0P2rS7TZF5tqUeLGcfxXCUb2ZxlHaAm61j7QBMG//ZEcqOHoBkd93e 7mPoJpB4z3HM3tapg/4veVkhHkA0/OKlzUupz6R+QVPNQAN63Hrx7aqRnIDU5BLRr5l2 9C5kCWFENEaVT5s8omBSCDmkdWVibWm6sPMVZkODRfQB+zjOEOmxkNl8A/rmxexYD4To wJsg== X-Gm-Message-State: AOUpUlFokBkhUAzcumpUDWBGNLZeCT2oM2ux1LY+mKC5mPM5yNt41IZl 7xmNHgb7iIswVZJK1QlKjKMVtfhhxliNROihMg0= X-Google-Smtp-Source: AA+uWPxLd4NZLEx1IsdupbFa99mubCFrjfPx4nMOv++gRCnPmrFq8Np63ndOcK6zmvx11zmYbBvwn7eudpBkoMNQ1cE= X-Received: by 2002:aca:dec6:: with SMTP id v189-v6mr25080137oig.98.1534280591548; Tue, 14 Aug 2018 14:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:30c2:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 14:02:51 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 14 Aug 2018 17:02:51 -0400 Message-ID: To: Stewart Bryant Cc: Janos Farkas , "detnet@ietf.org" , "STDS-802-1-L@LISTSERV.IEEE.ORG" , "ieee-ietf-coord@ietf.org" , "detnet-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a5283005736b89a1" Archived-At: Subject: Re: [Detnet] =?utf-8?q?DetNet_=E2=80=93_TSN_joint_session_in_Bangkok?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Tue, 14 Aug 2018 21:03:15 -0000 --000000000000a5283005736b89a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Stewart, I also made reservations at the IETF rate to check out on Monday. Let=E2=80= =99s hope that=E2=80=99s acceptable to the joint meeting hosts. Cheers, Andy On Tue, Aug 14, 2018 at 3:54 PM, Stewart Bryant wrote: > Hi > > Where are we with registering for the joint session, i.e. just registerin= g > for the Sunday. > > I have booked Sat/Sun on the IETF scheme to attend the meeting, I hope > that IEEE are not going to require that we make split bookings to get a > good rate (ideally free) at the joint session. > > Thanks > > Stewart. > > > > On 06/08/2018 22:20, Janos Farkas wrote: > >> Hi, >> >> Please note that hotel reservation for IETF 103 is possible: >> https://www.ietf.org/how/meetings/103/hotel/. >> >> My understanding of the cancellation policy for reservations at Bangkok >> Marriott Marquis Queen's Park is that cancellation is free up to 72 hour= s >> prior to arrival, however, it is not possible to change the reservation.= I >> may be wrong. (This is what I saw after making a reservation.) >> >> Note that hotel room booking via IEEE 802 is needed in order to get a >> discount from the IEEE 802 Plenary registration fee. At least one night = is >> needed. (As far as I recall, the discount is usually USD 300.) >> >> IEEE 802 hotel reservation is not yet available, but it will be soon: >> http://802world.org/plenary/ieee-802-group-hotel/ >> >> Best regards, >> J=C3=A1nos >> >> -----Original Message----- >> From: J=C3=A1nos Farkas >> Sent: Tuesday, July 31, 2018 10:32 AM >> To: detnet@ietf.org; STDS-802-1-L@LISTSERV.IEEE.ORG >> Cc: detnet-chairs@ietf.org >> Subject: DetNet =E2=80=93 TSN joint session in Bangkok >> >> Hi, >> >> We will have a DetNet =E2=80=93 TSN joint session in Bangkok on November= 11 >> Sunday, which is between IETF 103 and the IEEE 802 Plenary. The two >> meetings are back to back in the same hotel: Marriott Marquis Queen=E2= =80=99s Park, >> Bangkok, Thailand (https://www.ietf.org/how/meetings/upcoming, >> http://802world.org/plenary/future-plenary-sessions). >> The joint session will be from 9am to 5pm with a lunch break. >> Meeting room is being arranged by IEEE 802. >> There will be a web page for registration. Registration will be required= ; >> work is ongoing to make it free. >> >> We propose the following topics for the joint session both for DetNet an= d >> TSN: >> - current status >> - ongoing work >> - future plans >> - related activities, e.g., TEAS, IoT for DetNet; IEC, IEEE for TSN >> >> Please send agenda requests to detnet-chairs@ietf. >> >> Agenda will be worked after August holidays. >> >> We will provide updates, e.g., on registration, agenda, etc., as they >> become available. >> >> The co-located meetings give the opportunity to participate the meeting >> of the other group, the group one usually not attends or haven=E2=80=99t= attended >> yet. We have collected some information to help navigation, making >> decision, e.g., agendas of the last meetings. >> >> IETF DetNet WG info: >> Web page: https://datatracker.ietf.org/wg/detnet/about/ >> Documents: https://datatracker.ietf.org/wg/detnet/documents/ >> DetNet WG at IETF 102: >> - Agenda: https://datatracker.ietf.org/wg/detnet/documents/ >> - Presentations: >> https://datatracker.ietf.org/meeting/102/session/detnet >> - Minutes: https://datatracker.ietf.org/doc/minutes-102-detnet/ >> IETF 102 overall agenda: >> https://datatracker.ietf.org/meeting/102/agenda.html >> IETF 102 general information: https://www.ietf.org/how/meetings/102/ >> IETF 103 registration: https://www.ietf.org/how/meetings/103/ >> >> IEEE 802.1TSN TG info: >> Web page: http://ieee802.org/1/tsn >> Documents are available via the links provided at the TG page, e.g., via >> the project pages. >> TSN TG at the July 2018 IEEE 802 Plenary: >> - Agenda: >> https://1.ieee802.org/july-2018-plenary-meeting-in-san-diego >> -ca-usa-tsn-tg-agenda/ >> >> - Presentations are linked from the agenda >> - Minutes: https://1.ieee802.org/category >> /current-and-former-meetings/ >> IEEE 802 Plenary overall schedule: >> http://schedule.802world.com/schedule/schedule/show#, July Plenary is >> saved at: >> http://www.ieee802.org/1/files/public/docs2018/admin-802- >> schedule-0718.pdf.) >> IEEE 802 Plenary general information: http://802world.org/plenary/ IEEE >> 802 Plenary registration: >> http://802world.org/plenary/registration-information/ >> Note that the Plenary pages show the July Plenary at the moment; they >> will be updated to the November Plenary as we are getting closer. >> >> If you are new to TSN, then the IEC/IEEE 60802 Joint Project may be of >> interest: >> http://ieee802.org/1/tsn/iec-ieee-60802-tsn-profile-for-indu >> strial-automation. >> The Joint Project has been formed to specify how to use TSN for >> industrial automation. The meetings of the joint project are listed on t= he >> web page. The joint project will meet November 12-14 in Bangkok. >> >> If you have questions, don=E2=80=99t hesitate to ask us. >> >> Best regards, >> J=C3=A1nos and 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 > --000000000000a5283005736b89a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stewart,

I also made reservations at th= e IETF rate to check out on Monday. Let=E2=80=99s hope that=E2=80=99s accep= table to the joint meeting hosts.

Cheers,
Andy


On Tue, Aug 14, 2018 at 3:54 PM, Stewart Bryant <= stewart.bryant@gmail.com> wrote:
Hi

Where are we with registering for the joint session, i.e. just registering = for the Sunday.

I have booked Sat/Sun on the IETF scheme to attend the meeting, I hope that= IEEE are not going to require that we make split bookings to get a good ra= te (ideally free) at the joint session.

Thanks

Stewart.



On 06/08/2018 22:20, Janos Farkas wrote:
Hi,

Please note that hotel reservation for IETF 103 is possible: https://www.ietf.org/how/meetings/103/hotel/.

My understanding of the cancellation policy for reservations at Bangkok Mar= riott Marquis Queen's Park is that cancellation is free up to 72 hours = prior to arrival, however, it is not possible to change the reservation. I = may be wrong. (This is what I saw after making a reservation.)

Note that hotel room booking via IEEE 802 is needed in order to get a disco= unt from the IEEE 802 Plenary registration fee. At least one night is neede= d. (As far as I recall, the discount is usually USD 300.)

IEEE 802 hotel reservation is not yet available, but it will be soon: http://802world.org/plenary/ieee-802-group-hotel/

Best regards,
J=C3=A1nos

-----Original Message-----
From: J=C3=A1nos Farkas <janos.farkas@ericsson.com>
Sent: Tuesday, July 31, 2018 10:32 AM
To: detnet@ietf.org; STDS= -802-1-L@LISTSERV.IEEE.ORG
Cc: detnet-chai= rs@ietf.org
Subject: DetNet =E2=80=93 TSN joint session in Bangkok

Hi,

We will have a DetNet =E2=80=93 TSN joint session in Bangkok on November 11= Sunday, which is between IETF 103 and the IEEE 802 Plenary. The two meetin= gs are back to back in the same hotel: Marriott Marquis Queen=E2=80=99s Par= k, Bangkok, Thailand (https://www.ietf.org/how/meetin= gs/upcoming,
http://802world.org/plenary/future-plenary-s= essions).
The joint session will be from 9am to 5pm with a lunch break.
Meeting room is being arranged by IEEE 802.
There will be a web page for registration. Registration will be required; w= ork is ongoing to make it free.

We propose the following topics for the joint session both for DetNet and T= SN:
- current status
- ongoing work
- future plans
- related activities, e.g., TEAS, IoT for DetNet; IEC, IEEE for TSN

Please send agenda requests to detnet-chairs@ietf.

Agenda will be worked after August holidays.

We will provide updates, e.g., on registration, agenda, etc., as they becom= e available.

The co-located meetings give the opportunity to participate the meeting of = the other group, the group one usually not attends or haven=E2=80=99t atten= ded yet. We have collected some information to help navigation, making deci= sion, e.g., agendas of the last meetings.

IETF DetNet WG info:
Web page: https://datatracker.ietf.org/wg/detnet/a= bout/
Documents: https://datatracker.ietf.org/wg/det= net/documents/
DetNet WG at IETF 102:
=C2=A0 =C2=A0 =C2=A0- Agenda: https://datatracker.i= etf.org/wg/detnet/documents/
=C2=A0 =C2=A0 =C2=A0- Presentations:
https://datatracker.ietf.org/meeting/102= /session/detnet
=C2=A0 =C2=A0 =C2=A0- Minutes: https://datatrack= er.ietf.org/doc/minutes-102-detnet/
IETF 102 overall agenda:
https://datatracker.ietf.org/meeting/102/ag= enda.html
IETF 102 general information: https://www.ietf.org/how/meetings/102/
IETF 103 registration: https://www.ietf.org/how/meetings/= 103/

IEEE 802.1TSN TG info:
Web page: http://ieee802.org/1/tsn
Documents are available via the links provided at the TG page, e.g., via th= e project pages.
TSN TG at the July 2018 IEEE 802 Plenary:
=C2=A0 =C2=A0 =C2=A0- Agenda:
https://1.ieee802.= org/july-2018-plenary-meeting-in-san-diego-ca-usa-tsn-tg-agenda/<= /a>

=C2=A0 =C2=A0 =C2=A0- Presentations are linked from the agenda
=C2=A0 =C2=A0 =C2=A0- Minutes: https://1.= ieee802.org/category/current-and-former-meetings/
IEEE 802 Plenary overall schedule:
http://schedule.802world.com/schedule/sched= ule/show#, July Plenary is saved at:
http://www.ieee802.org/1/f= iles/public/docs2018/admin-802-schedule-0718.pdf.)
IEEE 802 Plenary general information: http://802world.org/plenary/ I= EEE
802 Plenary registration:
http://802world.org/plenary/registration-i= nformation/
Note that the Plenary pages show the July Plenary at the moment; they will = be updated to the November Plenary as we are getting closer.

If you are new to TSN, then the IEC/IEEE 60802 Joint Project may be of
interest:
http://ieee802.org/1/ts= n/iec-ieee-60802-tsn-profile-for-industrial-automation.
The Joint Project has been formed to specify how to use TSN for industrial = automation. The meetings of the joint project are listed on the web page. T= he joint project will meet November 12-14 in Bangkok.

If you have questions, don=E2=80=99t hesitate to ask us.

Best regards,
J=C3=A1nos and 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

--000000000000a5283005736b89a1-- From nobody Tue Aug 14 14:06:03 2018 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 D9F051286E3 for ; Tue, 14 Aug 2018 14:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=U032HYv8; dkim=pass (1024-bit key) header.d=ericsson.com header.b=mMey6DbC 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 0cJ_MvGfhAgi for ; Tue, 14 Aug 2018 14:05:56 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 8C92D130DCF for ; Tue, 14 Aug 2018 14:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1534280751; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SdVL5fnRxBcsiqxzI0RteK+9OwFlHFulsbqREsr6LHc=; b=U032HYv8NiQq/QB66Z2wgM9Tj2uomZCoMNufJZNR9Ds0537RgOXtIccBGOvBDqG3 eNOptzZtLxyjjzIaugZUwP/yJC2KRMRRzXRgsEHGoGJKvlrfgHCoY8R22VPS9xUo Isz1gFoB1ijquON4PpmrgHdbgf+w02bhCH1JilCdaYo=; X-AuditID: c1b4fb25-b1dff70000006cb9-8b-5b73442fe883 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 5D.EC.27833.F24437B5; Tue, 14 Aug 2018 23:05:51 +0200 (CEST) Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESSMB501.ericsson.se (153.88.183.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 14 Aug 2018 23:05:51 +0200 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 14 Aug 2018 23:05:51 +0200 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 14 Aug 2018 23:05:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SdVL5fnRxBcsiqxzI0RteK+9OwFlHFulsbqREsr6LHc=; b=mMey6DbCbAlwIgfJ4HIEkWbIUBM/btS3RwUbBR3gNLH4cl+9rYnHRjUsNExq8qeVnU3fpI6hZ5dnqi9D3H1svSuZpmswreuMyEnOAlXJs8BB4atJwVmtiSOH38MpPPeLDMV0CLbLFL4Dod/I8MwisaQ5C23BkvY5RXIVpgGNYP0= Received: from HE1PR0701MB2457.eurprd07.prod.outlook.com (10.168.128.139) by HE1PR0701MB1738.eurprd07.prod.outlook.com (10.167.246.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.14; Tue, 14 Aug 2018 21:05:49 +0000 Received: from HE1PR0701MB2457.eurprd07.prod.outlook.com ([fe80::b4e8:5c39:783b:a8cb]) by HE1PR0701MB2457.eurprd07.prod.outlook.com ([fe80::b4e8:5c39:783b:a8cb%6]) with mapi id 15.20.1059.010; Tue, 14 Aug 2018 21:05:49 +0000 From: Janos Farkas To: Stewart Bryant CC: "detnet@ietf.org" , "STDS-802-1-L@LISTSERV.IEEE.ORG" , "ieee-ietf-coord@ietf.org" , "detnet-chairs@ietf.org" Thread-Topic: =?utf-8?B?W0RldG5ldF0gRGV0TmV0IOKAkyBUU04gam9pbnQgc2Vzc2lvbiBpbiBCYW5n?= =?utf-8?Q?kok?= Thread-Index: AQHUKKj/ViQc3AA7gkKWNL0VnpsOHKSzP7kggAyATICAABKqEA== Date: Tue, 14 Aug 2018 21:05:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Janos.Farkas@ericsson.com; x-originating-ip: [2a02:ab88:5082:1880:4553:ec1c:ff32:b0d5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB1738; 6:1bVdCnNA4UqNMjHkpNR53EemJBcZfg5XGWRskNqnD/xkzxf6ir244c6+7VtNNw07vrpuqtT9tSgY2ttFYDP3ordCgLoCiseA/sp/497tgDKHKGcusPEEusDfQLI1Xklg/CjfRt0Aa09t2R2zlRoGkZBUATACuEejFNJ7HO/czyfm2QT5r+a6TQUl5rBtPEJqY+bM7ROPpgAOvNsxSTfrQfxfN6pHwhXnNZXZpt3PHIPO9Ey4EJDcvY3Y+THRPm6NLx/SLJkhTuN6GifjFu2j4BoP4Ej3LmxyrBiHrKGbh/L7czq9KmtIz0xBla7JwFK8NNZj748VjgY1medLTljav5cilnNd/3u6Aohp7mjl0bHOzmPtqdDfBH0YbFdz2nnF4SNkGlKkC5UDWxa3rZH1bjVQ87Ksb66l9UESUHKZjsHjQlF+784ZvxjMf3Fk2iHG67TX6E5WLUZ1YmvnQyql4A==; 5:JXet3IBAlVJscTQUTYTnIXTtdLKnsQHQCM1qdBmMrwwFUF6sQvCmMzf81ZcpELc6Tq+8udPKFbxYZONSpAo616B1E2AKLvsIFwVVEShLVhFMqNsdjnFeirAVeWczlvR36D5ib2vSV1t2Yh/0AF9IG+utfTbQQb3X4AqWdb6Qm1w=; 7:7SOGlJncYWSoZJ1/OxBQgolCXdzDm66v3cbXwwJdMfMwyLkmom+iXxPi0wS7NNHuKq+gtvuPuYkNDNejMJ+U+mIF76nmMQ7CgU9nYg9TKiDMmi+PFW+2lSptf6+7oNzr6PgZecqqcVdX2PeCDNHsm6FzU4Rxq14CW5cM13S6QWBw8ILx/LSHkqKoXqNnHnZgULxR6JBcgxaZeBl6AB4gGTEgdFlkiDS2vh81AjNsXSsC4Azx5d1eBr5k0U6k3eNH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 798c784f-5fc4-473d-6f0e-08d60229b614 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR0701MB1738; x-ms-traffictypediagnostic: HE1PR0701MB1738: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(85827821059158)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:HE1PR0701MB1738; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB1738; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(136003)(366004)(396003)(189003)(199004)(497574002)(55885003)(13464003)(45074003)(50854003)(4326008)(229853002)(99286004)(7736002)(7696005)(81166006)(25786009)(39060400002)(54906003)(5660300001)(316002)(53376002)(6246003)(74316002)(5250100002)(14454004)(2906002)(81156014)(8936002)(305945005)(6116002)(966005)(72206003)(76176011)(6916009)(478600001)(186003)(14444005)(106356001)(46003)(9686003)(6306002)(53936002)(6436002)(105586002)(11346002)(2900100001)(97736004)(53546011)(486006)(55016002)(256004)(86362001)(33656002)(68736007)(102836004)(476003)(6506007)(446003)(1720100001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB1738; H:HE1PR0701MB2457.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: SX+50NGcbERZ/T4kV934nWm3YWv7pKq6pXGNUIba/62j6bA8i+L55Vlb5Tp/vyFTG1TzmmkOYzA5FpmhWUeYDU5cYJqnnMCWXep5z7z7PDmyAQWt0wSTHhnkdCFTDKP0xOxuh+B1tuaXA6HD6uXRyCzAvmfjL+hk933sd1Cem6L7HD7nuhQigMyxuCtJtdQS5Wl8HvbqbVhsrC1WgflZs0QiJsqtxdZ9sGiFbTBYuvpOBZdXxCt99R3Crd3BXBnqVv8FNgWgw93+VYAH+lwKefPbt+7Z/YehuB/35nQW/SurJknUNf74n/shvBXeVEbosvpj/+5TErIEWQdX52KWNe6whkQAZhuSomlxVFU1emY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 798c784f-5fc4-473d-6f0e-08d60229b614 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2018 21:05:49.0117 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB1738 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUyM2J7ua6+S3G0wfJnFhbX+n+wWPz+NJvF 4tKaf0wWq295W5x6kOjA6rFz1l12jyVLfjJ5tHw7xRzAHMVlk5Kak1mWWqRvl8CV0f0kqKDN uuJpwwTGBsYjll2MHBwSAiYSHWfsuhg5OYQEjjJK/NtZ38XIBWR/Y5SYNPMNK5xz9fJ8Zoiq JUwS/y96gCRYBCYwS+yZ9Z0Fomomk8TtaTfZIJxnjBLTV/wHa2ET0JOYenMWO4gtIqArsebX a7AiZoEbjBIrV38BKxIWSJeYtPE1C8hRIgIZEms3CUDUO0l82/KTFcRmEVCVONV5EqycVyBB 4smLlVCbTzJKbDp6HSzBKWArcWvRBrBljAJiEt9PrWECsZkFxCVuPZkPZksICEgs2XOeGcIW lXj5+B8rRH2MxIfHE6FqrCWm7GligbBlJS7N72aEsA+wS3zaEwFh60p8mDqVGRKQvhK/L4qD 3CMBcs/EqyB7QeI6ElPeeUGU50t0f73PBmHnSLw9u5BlAqPRLCTXzQLqYBbQlFi/Sx8irCgx pfsh+yywjwUlTs58wrKAkWUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmBSObjlt+oOxstv HA8xCnAwKvHwChoURwuxJpYVV+YeYpTgYFYS4ZVhBArxpiRWVqUW5ccXleakFh9ilOZgURLn fWi+OUpIID2xJDU7NbUgtQgmy8TBKdXAqHSn13tTTvfPj8+f8N7K47b++P5sed1Lj1/Wd81q ljmv7ejd/eFN/YzDyXtWrfm3JJnZ4abKpKveBxV69jwMVVSd8CReK1vQyFjl/OcNKbaVN+U1 VsxcLJ3czrFe/r3O3gtGM9K9/u+/aSAULJttcfluiumSEDanzurQv3vuPvHWrvtRP/XlcyWW 4oxEQy3mouJEAPU8lWomAwAA Archived-At: Subject: Re: [Detnet] =?utf-8?q?DetNet_=E2=80=93_TSN_joint_session_in_Bangkok?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Tue, 14 Aug 2018 21:05:58 -0000 SGkgU3Rld2FydCwNCg0KTm8gdXBkYXRlIHlldCBvbiBhbnkgb2YgdGhlIGRldGFpbHMuDQpXZSBh cmUgd29ya2luZyBvbiBtYWtpbmcgdGhlIGpvaW50IHNlc3Npb24gZnJlZS4NCkFzICBmYXIgYXMg SSB1bmRlcnN0YW5kLCBJRUVFIGhvdGVsIGJvb2tpbmcgaXMgcmVxdWlyZWQgdG8gZ2V0IHRoZSBk aXNjb3VudCBpZiBvbmUgcmVnaXN0ZXJzIGZvciB0aGUgSUVFRSA4MDIgUGxlbmFyeTsgdGhlIFN1 bmRheSBqb2ludCBzZXNzaW9uIGlzIGEgZGlmZmVyZW50IHN0b3J5Lg0KDQpSZWdhcmRzLA0KSmFu b3MNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXdhcnQgQnJ5YW50IDxz dGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+IA0KU2VudDogVHVlc2RheSwgQXVndXN0IDE0LCAyMDE4 IDk6NTUgUE0NClRvOiBKYW5vcyBGYXJrYXMgPEphbm9zLkZhcmthc0Blcmljc3Nvbi5jb20+OyBk ZXRuZXRAaWV0Zi5vcmc7IFNURFMtODAyLTEtTEBMSVNUU0VSVi5JRUVFLk9SRzsgaWVlZS1pZXRm LWNvb3JkQGlldGYub3JnDQpDYzogZGV0bmV0LWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtEZXRuZXRdIERldE5ldCDigJMgVFNOIGpvaW50IHNlc3Npb24gaW4gQmFuZ2tvaw0KDQpIaQ0K DQpXaGVyZSBhcmUgd2Ugd2l0aCByZWdpc3RlcmluZyBmb3IgdGhlIGpvaW50IHNlc3Npb24sIGku ZS4ganVzdCByZWdpc3RlcmluZyBmb3IgdGhlIFN1bmRheS4NCg0KSSBoYXZlIGJvb2tlZCBTYXQv U3VuIG9uIHRoZSBJRVRGIHNjaGVtZSB0byBhdHRlbmQgdGhlIG1lZXRpbmcsIEkgaG9wZSB0aGF0 IElFRUUgYXJlIG5vdCBnb2luZyB0byByZXF1aXJlIHRoYXQgd2UgbWFrZSBzcGxpdCBib29raW5n cyB0byBnZXQgYSBnb29kIHJhdGUgKGlkZWFsbHkgZnJlZSkgYXQgdGhlIGpvaW50IHNlc3Npb24u DQoNClRoYW5rcw0KDQpTdGV3YXJ0Lg0KDQoNCk9uIDA2LzA4LzIwMTggMjI6MjAsIEphbm9zIEZh cmthcyB3cm90ZToNCj4gSGksDQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgaG90ZWwgcmVzZXJ2YXRp b24gZm9yIElFVEYgMTAzIGlzIHBvc3NpYmxlOiBodHRwczovL3d3dy5pZXRmLm9yZy9ob3cvbWVl dGluZ3MvMTAzL2hvdGVsLy4NCj4NCj4gTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgY2FuY2VsbGF0 aW9uIHBvbGljeSBmb3IgcmVzZXJ2YXRpb25zIGF0IA0KPiBCYW5na29rIE1hcnJpb3R0IE1hcnF1 aXMgUXVlZW4ncyBQYXJrIGlzIHRoYXQgY2FuY2VsbGF0aW9uIGlzIGZyZWUgdXAgDQo+IHRvIDcy IGhvdXJzIHByaW9yIHRvIGFycml2YWwsIGhvd2V2ZXIsIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBj aGFuZ2UgDQo+IHRoZSByZXNlcnZhdGlvbi4gSSBtYXkgYmUgd3JvbmcuIChUaGlzIGlzIHdoYXQg SSBzYXcgYWZ0ZXIgbWFraW5nIGEgDQo+IHJlc2VydmF0aW9uLikNCj4NCj4gTm90ZSB0aGF0IGhv dGVsIHJvb20gYm9va2luZyB2aWEgSUVFRSA4MDIgaXMgbmVlZGVkIGluIG9yZGVyIHRvIGdldCBh IA0KPiBkaXNjb3VudCBmcm9tIHRoZSBJRUVFIDgwMiBQbGVuYXJ5IHJlZ2lzdHJhdGlvbiBmZWUu IEF0IGxlYXN0IG9uZSANCj4gbmlnaHQgaXMgbmVlZGVkLiAoQXMgZmFyIGFzIEkgcmVjYWxsLCB0 aGUgZGlzY291bnQgaXMgdXN1YWxseSBVU0QgDQo+IDMwMC4pDQo+DQo+IElFRUUgODAyIGhvdGVs IHJlc2VydmF0aW9uIGlzIG5vdCB5ZXQgYXZhaWxhYmxlLCBidXQgaXQgd2lsbCBiZSBzb29uOiAN Cj4gaHR0cDovLzgwMndvcmxkLm9yZy9wbGVuYXJ5L2llZWUtODAyLWdyb3VwLWhvdGVsLw0KPg0K PiBCZXN0IHJlZ2FyZHMsDQo+IErDoW5vcw0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBKw6Fub3MgRmFya2FzIDxqYW5vcy5mYXJrYXNAZXJpY3Nzb24uY29tPg0KPiBT ZW50OiBUdWVzZGF5LCBKdWx5IDMxLCAyMDE4IDEwOjMyIEFNDQo+IFRvOiBkZXRuZXRAaWV0Zi5v cmc7IFNURFMtODAyLTEtTEBMSVNUU0VSVi5JRUVFLk9SRw0KPiBDYzogZGV0bmV0LWNoYWlyc0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBEZXROZXQg4oCTIFRTTiBqb2ludCBzZXNzaW9uIGluIEJhbmdr b2sNCj4NCj4gSGksDQo+DQo+IFdlIHdpbGwgaGF2ZSBhIERldE5ldCDigJMgVFNOIGpvaW50IHNl c3Npb24gaW4gQmFuZ2tvayBvbiBOb3ZlbWJlciAxMSANCj4gU3VuZGF5LCB3aGljaCBpcyBiZXR3 ZWVuIElFVEYgMTAzIGFuZCB0aGUgSUVFRSA4MDIgUGxlbmFyeS4gVGhlIHR3byANCj4gbWVldGlu Z3MgYXJlIGJhY2sgdG8gYmFjayBpbiB0aGUgc2FtZSBob3RlbDogTWFycmlvdHQgTWFycXVpcyBR dWVlbuKAmXMgDQo+IFBhcmssIEJhbmdrb2ssIFRoYWlsYW5kIChodHRwczovL3d3dy5pZXRmLm9y Zy9ob3cvbWVldGluZ3MvdXBjb21pbmcsDQo+IGh0dHA6Ly84MDJ3b3JsZC5vcmcvcGxlbmFyeS9m dXR1cmUtcGxlbmFyeS1zZXNzaW9ucykuDQo+IFRoZSBqb2ludCBzZXNzaW9uIHdpbGwgYmUgZnJv bSA5YW0gdG8gNXBtIHdpdGggYSBsdW5jaCBicmVhay4NCj4gTWVldGluZyByb29tIGlzIGJlaW5n IGFycmFuZ2VkIGJ5IElFRUUgODAyLg0KPiBUaGVyZSB3aWxsIGJlIGEgd2ViIHBhZ2UgZm9yIHJl Z2lzdHJhdGlvbi4gUmVnaXN0cmF0aW9uIHdpbGwgYmUgcmVxdWlyZWQ7IHdvcmsgaXMgb25nb2lu ZyB0byBtYWtlIGl0IGZyZWUuDQo+DQo+IFdlIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0b3BpY3Mg Zm9yIHRoZSBqb2ludCBzZXNzaW9uIGJvdGggZm9yIERldE5ldCBhbmQgVFNOOg0KPiAtIGN1cnJl bnQgc3RhdHVzDQo+IC0gb25nb2luZyB3b3JrDQo+IC0gZnV0dXJlIHBsYW5zDQo+IC0gcmVsYXRl ZCBhY3Rpdml0aWVzLCBlLmcuLCBURUFTLCBJb1QgZm9yIERldE5ldDsgSUVDLCBJRUVFIGZvciBU U04NCj4NCj4gUGxlYXNlIHNlbmQgYWdlbmRhIHJlcXVlc3RzIHRvIGRldG5ldC1jaGFpcnNAaWV0 Zi4NCj4NCj4gQWdlbmRhIHdpbGwgYmUgd29ya2VkIGFmdGVyIEF1Z3VzdCBob2xpZGF5cy4NCj4N Cj4gV2Ugd2lsbCBwcm92aWRlIHVwZGF0ZXMsIGUuZy4sIG9uIHJlZ2lzdHJhdGlvbiwgYWdlbmRh LCBldGMuLCBhcyB0aGV5IGJlY29tZSBhdmFpbGFibGUuDQo+DQo+IFRoZSBjby1sb2NhdGVkIG1l ZXRpbmdzIGdpdmUgdGhlIG9wcG9ydHVuaXR5IHRvIHBhcnRpY2lwYXRlIHRoZSBtZWV0aW5nIG9m IHRoZSBvdGhlciBncm91cCwgdGhlIGdyb3VwIG9uZSB1c3VhbGx5IG5vdCBhdHRlbmRzIG9yIGhh dmVu4oCZdCBhdHRlbmRlZCB5ZXQuIFdlIGhhdmUgY29sbGVjdGVkIHNvbWUgaW5mb3JtYXRpb24g dG8gaGVscCBuYXZpZ2F0aW9uLCBtYWtpbmcgZGVjaXNpb24sIGUuZy4sIGFnZW5kYXMgb2YgdGhl IGxhc3QgbWVldGluZ3MuDQo+DQo+IElFVEYgRGV0TmV0IFdHIGluZm86DQo+IFdlYiBwYWdlOiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2RldG5ldC9hYm91dC8NCj4gRG9jdW1lbnRz OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2RldG5ldC9kb2N1bWVudHMvDQo+IERl dE5ldCBXRyBhdCBJRVRGIDEwMjoNCj4gICAgICAtIEFnZW5kYTogaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy93Zy9kZXRuZXQvZG9jdW1lbnRzLw0KPiAgICAgIC0gUHJlc2VudGF0aW9uczoN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMi9zZXNzaW9uL2RldG5l dA0KPiAgICAgIC0gTWludXRlczogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWlu dXRlcy0xMDItZGV0bmV0Lw0KPiBJRVRGIDEwMiBvdmVyYWxsIGFnZW5kYToNCj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMi9hZ2VuZGEuaHRtbA0KPiBJRVRGIDEwMiBn ZW5lcmFsIGluZm9ybWF0aW9uOiBodHRwczovL3d3dy5pZXRmLm9yZy9ob3cvbWVldGluZ3MvMTAy Lw0KPiBJRVRGIDEwMyByZWdpc3RyYXRpb246IGh0dHBzOi8vd3d3LmlldGYub3JnL2hvdy9tZWV0 aW5ncy8xMDMvDQo+DQo+IElFRUUgODAyLjFUU04gVEcgaW5mbzoNCj4gV2ViIHBhZ2U6IGh0dHA6 Ly9pZWVlODAyLm9yZy8xL3Rzbg0KPiBEb2N1bWVudHMgYXJlIGF2YWlsYWJsZSB2aWEgdGhlIGxp bmtzIHByb3ZpZGVkIGF0IHRoZSBURyBwYWdlLCBlLmcuLCB2aWEgdGhlIHByb2plY3QgcGFnZXMu DQo+IFRTTiBURyBhdCB0aGUgSnVseSAyMDE4IElFRUUgODAyIFBsZW5hcnk6DQo+ICAgICAgLSBB Z2VuZGE6DQo+IGh0dHBzOi8vMS5pZWVlODAyLm9yZy9qdWx5LTIwMTgtcGxlbmFyeS1tZWV0aW5n LWluLXNhbi1kaWVnby1jYS11c2EtdHMNCj4gbi10Zy1hZ2VuZGEvDQo+DQo+ICAgICAgLSBQcmVz ZW50YXRpb25zIGFyZSBsaW5rZWQgZnJvbSB0aGUgYWdlbmRhDQo+ICAgICAgLSBNaW51dGVzOiAN Cj4gaHR0cHM6Ly8xLmllZWU4MDIub3JnL2NhdGVnb3J5L2N1cnJlbnQtYW5kLWZvcm1lci1tZWV0 aW5ncy8NCj4gSUVFRSA4MDIgUGxlbmFyeSBvdmVyYWxsIHNjaGVkdWxlOg0KPiBodHRwOi8vc2No ZWR1bGUuODAyd29ybGQuY29tL3NjaGVkdWxlL3NjaGVkdWxlL3Nob3cjLCBKdWx5IFBsZW5hcnkg aXMgc2F2ZWQgYXQ6DQo+IGh0dHA6Ly93d3cuaWVlZTgwMi5vcmcvMS9maWxlcy9wdWJsaWMvZG9j czIwMTgvYWRtaW4tODAyLXNjaGVkdWxlLTA3MTgNCj4gLnBkZi4pIElFRUUgODAyIFBsZW5hcnkg Z2VuZXJhbCBpbmZvcm1hdGlvbjogDQo+IGh0dHA6Ly84MDJ3b3JsZC5vcmcvcGxlbmFyeS8gSUVF RQ0KPiA4MDIgUGxlbmFyeSByZWdpc3RyYXRpb246DQo+IGh0dHA6Ly84MDJ3b3JsZC5vcmcvcGxl bmFyeS9yZWdpc3RyYXRpb24taW5mb3JtYXRpb24vDQo+IE5vdGUgdGhhdCB0aGUgUGxlbmFyeSBw YWdlcyBzaG93IHRoZSBKdWx5IFBsZW5hcnkgYXQgdGhlIG1vbWVudDsgdGhleSB3aWxsIGJlIHVw ZGF0ZWQgdG8gdGhlIE5vdmVtYmVyIFBsZW5hcnkgYXMgd2UgYXJlIGdldHRpbmcgY2xvc2VyLg0K Pg0KPiBJZiB5b3UgYXJlIG5ldyB0byBUU04sIHRoZW4gdGhlIElFQy9JRUVFIDYwODAyIEpvaW50 IFByb2plY3QgbWF5IGJlIG9mDQo+IGludGVyZXN0Og0KPiBodHRwOi8vaWVlZTgwMi5vcmcvMS90 c24vaWVjLWllZWUtNjA4MDItdHNuLXByb2ZpbGUtZm9yLWluZHVzdHJpYWwtYXV0b21hdGlvbi4N Cj4gVGhlIEpvaW50IFByb2plY3QgaGFzIGJlZW4gZm9ybWVkIHRvIHNwZWNpZnkgaG93IHRvIHVz ZSBUU04gZm9yIGluZHVzdHJpYWwgYXV0b21hdGlvbi4gVGhlIG1lZXRpbmdzIG9mIHRoZSBqb2lu dCBwcm9qZWN0IGFyZSBsaXN0ZWQgb24gdGhlIHdlYiBwYWdlLiBUaGUgam9pbnQgcHJvamVjdCB3 aWxsIG1lZXQgTm92ZW1iZXIgMTItMTQgaW4gQmFuZ2tvay4NCj4NCj4gSWYgeW91IGhhdmUgcXVl c3Rpb25zLCBkb27igJl0IGhlc2l0YXRlIHRvIGFzayB1cy4NCj4NCj4gQmVzdCByZWdhcmRzLA0K PiBKw6Fub3MgYW5kIExvdQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBkZXRuZXQgbWFpbGluZyBsaXN0DQo+IGRldG5ldEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldA0KDQo= From nobody Wed Aug 15 03:44:09 2018 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 68D5E130E62; Wed, 15 Aug 2018 03:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wzT-T83BeMfO; Wed, 15 Aug 2018 03:43:57 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 7DB47130E5A; Wed, 15 Aug 2018 03:43:57 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id c14-v6so982389wmb.4; Wed, 15 Aug 2018 03:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=tID5cQh87AV4EshWwucr7fU2nZux1TMBIoaJ8ZUmMCw=; b=NZ83TwIxbsS2gT3AfDGW0It3XGaFYGmDZppYu8PF+q7X0fnHb3XPCHC4PZOTXJTFn2 cBO1sNa4kvn+8S6ltChJbPlm9uFCSYf8+WcZqlk/ydCdlBcLZUzcuL4g97Hvhl+lZ7mM yXH07uGRdij4KLWwdrsiWplLb2/5FsEtARqNmcFog6HkJn1wW3Ck43z0OYUJnk/uMTLZ yFFMX0e3X/7Ai7fZNb5safuG551aN338Tr/MSzoCr+cjLn4k2YNgKmDtYj3H9OSqQ9yX wv0GwuyfoYuEIYWZm1+kqFeiOm+dNLq71EMX4KuQd3kBvlwUMUDr9mN1Dy5LHU6XbOUH dG9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=tID5cQh87AV4EshWwucr7fU2nZux1TMBIoaJ8ZUmMCw=; b=SVbxieDdiQYJShvCyx33n4s2R5eFSMTSRv41Bzwj2MUG/wEQwceQUdGxQ9ukFww0pa METOiE26pu+3J7iru7o6Tt7HjuyKY3CpLeCHdwcWmQdYkH9tZot6ki1rnfk7iL429K7+ D/Y2SFFWPjKiwrAmI1d6BPjyECG9jSAazX/Y8uHZKGBsQh567Y8Ndk3MASshkVPoEftK 4SH9d1C9Sw2QcqWEG9P2ktvKwYxRmYABtJHIQ9c5Xo6INzfegHroLp9wEhGmA9AYPpUv AO3pVbeBqA3+t1o8BazedTvi+3nX5OxHQ0jnoCG00qxYsx6kEJjQnHnXlzjz97Ttv96x PIeA== X-Gm-Message-State: AOUpUlGSOa/BWuqOFAq2orFaEHeEIaW1hVUkxXrvs2UI/X9BKjeOcBsL WFd+2vx05ICLEHJ7e81uf30pnULk X-Google-Smtp-Source: AA+uWPzp8y/2apRw7wejge0xWsafYpgzF+SH3IBnoJCi9tWdC1S8F4PXSKQN2bHtS/RMH9asPpkdmg== X-Received: by 2002:a1c:93d3:: with SMTP id v202-v6mr13477760wmd.57.1534329835685; Wed, 15 Aug 2018 03:43:55 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id m129-v6sm11350635wma.1.2018.08.15.03.43.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 03:43:55 -0700 (PDT) To: Janos Farkas Cc: "detnet@ietf.org" , "STDS-802-1-L@LISTSERV.IEEE.ORG" , "ieee-ietf-coord@ietf.org" , "detnet-chairs@ietf.org" References: From: Stewart Bryant Message-ID: Date: Wed, 15 Aug 2018 11:43:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [Detnet] =?utf-8?q?DetNet_=E2=80=93_TSN_joint_session_in_Bangkok?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Wed, 15 Aug 2018 10:44:00 -0000 Thank you Stewart On 14/08/2018 22:05, Janos Farkas wrote: > Hi Stewart, > > No update yet on any of the details. > We are working on making the joint session free. > As far as I understand, IEEE hotel booking is required to get the discount if one registers for the IEEE 802 Plenary; the Sunday joint session is a different story. > > Regards, > Janos > > -----Original Message----- > From: Stewart Bryant > Sent: Tuesday, August 14, 2018 9:55 PM > To: Janos Farkas ; detnet@ietf.org; STDS-802-1-L@LISTSERV.IEEE.ORG; ieee-ietf-coord@ietf.org > Cc: detnet-chairs@ietf.org > Subject: Re: [Detnet] DetNet – TSN joint session in Bangkok > > Hi > > Where are we with registering for the joint session, i.e. just registering for the Sunday. > > I have booked Sat/Sun on the IETF scheme to attend the meeting, I hope that IEEE are not going to require that we make split bookings to get a good rate (ideally free) at the joint session. > > Thanks > > Stewart. > > > On 06/08/2018 22:20, Janos Farkas wrote: >> Hi, >> >> Please note that hotel reservation for IETF 103 is possible: https://www.ietf.org/how/meetings/103/hotel/. >> >> My understanding of the cancellation policy for reservations at >> Bangkok Marriott Marquis Queen's Park is that cancellation is free up >> to 72 hours prior to arrival, however, it is not possible to change >> the reservation. I may be wrong. (This is what I saw after making a >> reservation.) >> >> Note that hotel room booking via IEEE 802 is needed in order to get a >> discount from the IEEE 802 Plenary registration fee. At least one >> night is needed. (As far as I recall, the discount is usually USD >> 300.) >> >> IEEE 802 hotel reservation is not yet available, but it will be soon: >> http://802world.org/plenary/ieee-802-group-hotel/ >> >> Best regards, >> János >> >> -----Original Message----- >> From: János Farkas >> Sent: Tuesday, July 31, 2018 10:32 AM >> To: detnet@ietf.org; STDS-802-1-L@LISTSERV.IEEE.ORG >> Cc: detnet-chairs@ietf.org >> Subject: DetNet – TSN joint session in Bangkok >> >> Hi, >> >> We will have a DetNet – TSN joint session in Bangkok on November 11 >> Sunday, which is between IETF 103 and the IEEE 802 Plenary. The two >> meetings are back to back in the same hotel: Marriott Marquis Queen’s >> Park, Bangkok, Thailand (https://www.ietf.org/how/meetings/upcoming, >> http://802world.org/plenary/future-plenary-sessions). >> The joint session will be from 9am to 5pm with a lunch break. >> Meeting room is being arranged by IEEE 802. >> There will be a web page for registration. Registration will be required; work is ongoing to make it free. >> >> We propose the following topics for the joint session both for DetNet and TSN: >> - current status >> - ongoing work >> - future plans >> - related activities, e.g., TEAS, IoT for DetNet; IEC, IEEE for TSN >> >> Please send agenda requests to detnet-chairs@ietf. >> >> Agenda will be worked after August holidays. >> >> We will provide updates, e.g., on registration, agenda, etc., as they become available. >> >> The co-located meetings give the opportunity to participate the meeting of the other group, the group one usually not attends or haven’t attended yet. We have collected some information to help navigation, making decision, e.g., agendas of the last meetings. >> >> IETF DetNet WG info: >> Web page: https://datatracker.ietf.org/wg/detnet/about/ >> Documents: https://datatracker.ietf.org/wg/detnet/documents/ >> DetNet WG at IETF 102: >> - Agenda: https://datatracker.ietf.org/wg/detnet/documents/ >> - Presentations: >> https://datatracker.ietf.org/meeting/102/session/detnet >> - Minutes: https://datatracker.ietf.org/doc/minutes-102-detnet/ >> IETF 102 overall agenda: >> https://datatracker.ietf.org/meeting/102/agenda.html >> IETF 102 general information: https://www.ietf.org/how/meetings/102/ >> IETF 103 registration: https://www.ietf.org/how/meetings/103/ >> >> IEEE 802.1TSN TG info: >> Web page: http://ieee802.org/1/tsn >> Documents are available via the links provided at the TG page, e.g., via the project pages. >> TSN TG at the July 2018 IEEE 802 Plenary: >> - Agenda: >> https://1.ieee802.org/july-2018-plenary-meeting-in-san-diego-ca-usa-ts >> n-tg-agenda/ >> >> - Presentations are linked from the agenda >> - Minutes: >> https://1.ieee802.org/category/current-and-former-meetings/ >> IEEE 802 Plenary overall schedule: >> http://schedule.802world.com/schedule/schedule/show#, July Plenary is saved at: >> http://www.ieee802.org/1/files/public/docs2018/admin-802-schedule-0718 >> .pdf.) IEEE 802 Plenary general information: >> http://802world.org/plenary/ IEEE >> 802 Plenary registration: >> http://802world.org/plenary/registration-information/ >> Note that the Plenary pages show the July Plenary at the moment; they will be updated to the November Plenary as we are getting closer. >> >> If you are new to TSN, then the IEC/IEEE 60802 Joint Project may be of >> interest: >> http://ieee802.org/1/tsn/iec-ieee-60802-tsn-profile-for-industrial-automation. >> The Joint Project has been formed to specify how to use TSN for industrial automation. The meetings of the joint project are listed on the web page. The joint project will meet November 12-14 in Bangkok. >> >> If you have questions, don’t hesitate to ask us. >> >> Best regards, >> János and Lou >> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet From nobody Thu Aug 23 11:42:53 2018 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 8564E130DBE for ; Thu, 23 Aug 2018 11:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.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 UkLHSlNQj59X for ; Thu, 23 Aug 2018 11:42:48 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0101.outbound.protection.outlook.com [104.47.40.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CE80130EDD for ; Thu, 23 Aug 2018 11:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gwaaBaWjZfJVOlkk7X4VFDZK30ZIQVhO6gWDFqkPqcQ=; b=lAdIJGgIzk3RSHmfTmhyq+ZCGH9xW4i4IJC4ViEDbWOUgE1OMTfayyj/PIeiehvZBM+e8aJMOXSCh+wp1IJanFRWx1V1tbgBFtv15hQQiUIa4PSSsvUiebkVn8ymF+B4F9WeZuAnAhZGKtn7u33dRFKpDXDRhwtawN6dt2dGz9s= Received: from BL0PR06MB4548.namprd06.prod.outlook.com (20.177.145.145) by BL0PR06MB4372.namprd06.prod.outlook.com (10.167.181.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.14; Thu, 23 Aug 2018 18:42:47 +0000 Received: from BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::4475:e51a:40ae:91c6]) by BL0PR06MB4548.namprd06.prod.outlook.com ([fe80::4475:e51a:40ae:91c6%2]) with mapi id 15.20.1080.015; Thu, 23 Aug 2018 18:42:47 +0000 From: "Grossman, Ethan A." To: DetNet WG Thread-Topic: DetNet Security Consideration: OAM Thread-Index: AdQ7EJIqCDZtz6qORa6B3QEb8Bt2Gg== Date: Thu, 23 Aug 2018 18:42:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4372; 6:0kvSGYFxjH4g/LHa7XGCikQIVBhS8P9vv8gkfNehfeEb7bKFFgwFX5I8CuarNTp1nhh0C1RbADFbvhfnQobiAFSIeINNM8lV9YAe99Lwpt9GByeBpB/Ul8Ryk9/b+TqMjTseESmoDP9ToJ2SbkKUtQCxBPICmzO1Hifb0A/Y+Gj3qpFIp56zTX94RR22LKJshTMWIJGlZE6Kg1As0PhKlfELFCSFTLxJkAzDmkN4jjSaea7sLYv8WYCXyeD4nm4y7TJtOX3lrK+gJxyAUXxiLPm/eInnJnuvq/FIR8Y91Mpl446FBnt+WU1vQ+LCMOXzi3F3g36YHIQkUn/I5/Hky7sjq6r/6ZtWDUJYWo8NdefOxbnAPl/fdqbCfKy4xLJtBfmcsdwZNV8gVVWLfba0ZTjoQMWSbwLnfLSY3zxY/gTX/6ispiTKid0RMVNTcNVL6O62bAiLmhYD9LJNVxpZRQ==; 5:GM+T47FI6LMYWD85GqN+wgFGvd7lyCHI2wWg4eEFjTFXhdLZ0Q2udAAWfLRZYQxGU0EjxDXNZkyfZoay5hthXHWvNG2LV+WBnFC+mvtlbWvXDQoiG95ykQVsG2dLz3uE3L/AB8f7e4e4AFEMukPk3zBgBLPjxx7buKmn1yX5+BU=; 7:vQd/mRk3puM5uE1q7yThl4XHabHkV7qd20c+CByHToN7YKi7Kpp0mCnsFW7Ds2FMkOpVbTsVdtR6VRUvWJztAYKicMP2nhKZCNLCyVF4A9PhaJnXKVNjJxSty14WJ4+iLf9JWLjqzlRG6PdU1Rg5wUpK36HzqC0IjoLkiAx93cGWQtUChJisot2h6sFBmIqtSSUQ61Oo1em/Q6U+UvG4Adt6QGwtaIkDb7Opjkvk2v0a2oihYWzzoIzHcn0ThF9N x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: d9a5eb83-84dd-46fa-adb1-08d6092838a5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4372; x-ms-traffictypediagnostic: BL0PR06MB4372: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699016); SRVR:BL0PR06MB4372; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4372; x-forefront-prvs: 0773BB46AC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(396003)(136003)(376002)(53754006)(199004)(189003)(86362001)(19609705001)(81166006)(105586002)(14454004)(15650500001)(2906002)(81156014)(106356001)(2420400007)(8676002)(7110500001)(5250100002)(6916009)(7736002)(33656002)(6436002)(74316002)(10710500007)(5660300001)(6116002)(53936002)(9686003)(6306002)(256004)(97736004)(9326002)(26005)(8936002)(55016002)(54896002)(186003)(14444005)(68736007)(2900100001)(6506007)(25786009)(316002)(99286004)(66066001)(102836004)(478600001)(486006)(7696005)(476003)(3846002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR06MB4372; H:BL0PR06MB4548.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: dbSZZzXOcDRIlvqF7BOo2AEYrn7lkygGMvcq9Rvsft2LtrJFemhlMiP/qqlQx80LaiAAXc/30iVFnZkBcyBgUeLKS79U58zwzSYrkFDWMeQP9s/RqjJ16cBnAvv0qgLAmgSPeVqpDmfB4voHSb2urcF1nW8cU4LYT/5+0vcxDhUppNDlD5ZOz3IrICMLgizLfgQh64mOOkqSQcazKvi0WrYA0zAbXAnPi8oXfCMvAooV+spVxJoTjv3890bnGUj7esd1RJMs1oOSt4oaOqANTAtLEi8J9MqYKVD07NB0cloR7sHmJzLx+is0D7QstaKqAey/dx8axVQGU3Q1sS/vTI6JP220hYP7TYh3+b5HcLs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR06MB454882CAE6F53D020298942EC4370BL0PR06MB4548namp_" MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: d9a5eb83-84dd-46fa-adb1-08d6092838a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2018 18:42:47.2602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4372 Archived-At: Subject: [Detnet] DetNet Security Consideration: OAM X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Thu, 23 Aug 2018 18:42:52 -0000 --_000_BL0PR06MB454882CAE6F53D020298942EC4370BL0PR06MB4548namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Recently it was pointed out that bandwidth occupied by OAM packets added to= a DetNet flow have to be accounted for in the bandwidth reservation for th= at flow. This made me wonder whether there were any DetNet-specific securit= y considerations associated with OAM traffic. As I understand it based on t= he input I have received so far, there is nothing there that we have to con= sider, except to say something like "We have considered the matter and foun= d that there are no DetNet-specific security considerations related to OAM = traffic". The rationale for this is that the OAM traffic is either: 1) Generated by the network itself, and is thus trusted, because if you can= 't trust the network you have much worse problems. The additional bandwidth= required for such packets is added by the network, presumably transparent= to the customer. Or 2) Generated by the customer, and is thus the customer's responsibility. Th= at is, it is our job to deliver the customer's packets with the given servi= ce level, and OAM packets are no different to us than any other data the cu= stomer is reserving bandwidth for and transmitting. I expect to put some text into the Security draft pretty much along those l= ines. Can anyone think of anything I might have not taken into account? Als= o any further statements of confirmation that this makes sense would be app= reciated. Thanks, Ethan. --_000_BL0PR06MB454882CAE6F53D020298942EC4370BL0PR06MB4548namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

Recently it was pointed out that bandwidth occupied = by OAM packets added to a DetNet flow have to be accounted for in the bandw= idth reservation for that flow. This made me wonder whether there were any = DetNet-specific security considerations associated with OAM traffic. As I understand it based on the input I have = received so far, there is nothing there that we have to consider, except to= say something like “We have considered the matter and found that the= re are no DetNet-specific security considerations related to OAM traffic”. The rationale for this is that the OAM traf= fic is either:

1) Generated by the network itself, and is thus trus= ted, because if you can’t trust the network you have much worse probl= ems. The additional bandwidth required for such packets is added by the net= work,  presumably transparent to the customer.

Or

2) Generated by the customer, and is thus the custom= er’s responsibility. That is, it is our job to deliver the customer&#= 8217;s packets with the given service level, and OAM packets are no differe= nt to us than any other data the customer is reserving bandwidth for and transmitting.

 

I expect to put some text into the Security draft pr= etty much along those lines. Can anyone think of anything I might have not = taken into account? Also any further statements of confirmation that this m= akes sense would be appreciated.

Thanks,

Ethan.

 

--_000_BL0PR06MB454882CAE6F53D020298942EC4370BL0PR06MB4548namp_-- From nobody Thu Aug 23 13:31:12 2018 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 8D7E4130EF9 for ; Thu, 23 Aug 2018 13:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 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, MIME_BOUND_DIGITS_15=0.798, RCVD_IN_DNSWL_NONE=-0.0001, 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 ufWLcC-Xa0Mo for ; Thu, 23 Aug 2018 13:31:08 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 DD1B3130EFE for ; Thu, 23 Aug 2018 13:31:07 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id m84-v6so5157896lje.10 for ; Thu, 23 Aug 2018 13:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M+uBwNfIFAvXAE3+itPD5qNgjLpcCfrIFVddZKMGHRc=; b=XkMD+TmRK3+LVbhCJJ7PmEJ0WvoWb3qZ5sKs5aYgWI1niBkDdM4dFL2nyJNrQlqGTf 6xWgy49knnLUdZb7nTQjLH5zApnxt2bAPiMu1BOIL6rr+hfcSn9gSw0gQ5gdUb88dht3 4MgumJEHAxNfw+tcn1nL51iaWyxax121y4ciOC60kpYI6uY6OsAEWrOQ3tN705a0MEri 5H2+bcHsesQgL2JP3Hu0+ebIY7/cMzSn6RI5P7paX51EzmHs6XRozAw9AHbiqskGSorh 2ETeL4GPJ2eTjv59eC6ukCP91mz6MDWwbSsTFRXAgVhy4x9Ov9+LQ05hH4HXYlX0kcTr mmGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M+uBwNfIFAvXAE3+itPD5qNgjLpcCfrIFVddZKMGHRc=; b=rMXZw7y52HjYYFpjIBW86vINkGCKdKNzmd7duTZV3+DHECA8EKks9DzeddHI1NNeST 13n8nQDRrA9NVBPJ98R8gwGGewUaO5RAi4pBVoLJPeaA2HiKbjb6Na3NTNqVAVUxQWAW rXOF/XO6QgF6yyyo31PUoED7TNr0P00DQljfRSo9fOrtNuCY7sphxhBAFSK7FTzaaFqC CJfaTB3T4w/NhZDc0gn4Xye9gFOQJ2ifiOtNpYMyZACpFp/BnE2gVLDUnnApGc0Zp3uV vCex85YGbKQBE7BWq/N0YtZClNqbtersrZXEOOvZyl2n1/3foEET+ZEPJ5zz525yFJ4s AO3A== X-Gm-Message-State: APzg51CrrTHPwwWaqBGU7d5VWDulbZCvLhIE/MRY2cW+s5npfh9SZbgT EkWTIPSX7A5+C8c0lu/nNbJxTRzC2XIKZbMYFcFx960Z X-Google-Smtp-Source: ANB0VdYlJ1OKVtZjLW2kfmRNEef0anwlGs/dDksp13sbzz9QRLWf4+H0jycj7NizIcYBRUmvG2BA0nyT98MiVIp5inA= X-Received: by 2002:a2e:9198:: with SMTP id f24-v6mr5448714ljg.64.1535056266095; Thu, 23 Aug 2018 13:31:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:709:0:0:0:0:0 with HTTP; Thu, 23 Aug 2018 13:31:05 -0700 (PDT) In-Reply-To: References: From: Greg Mirsky Date: Thu, 23 Aug 2018 13:31:05 -0700 Message-ID: To: "Grossman, Ethan A." Cc: DetNet WG Content-Type: multipart/alternative; boundary="0000000000007371570574202330" Archived-At: Subject: Re: [Detnet] DetNet Security Consideration: OAM X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.27 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: Thu, 23 Aug 2018 20:31:11 -0000 --0000000000007371570574202330 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ethan, thank you for the thorough analysis of the OAM in DetNet domain specifics. I think that the proposed text is very good. I have a few comments, questions that you can find in-line under tag GIM>>. Regards, Greg On Thu, Aug 23, 2018 at 11:42 AM, Grossman, Ethan A. wrote: > Hi All, > > Recently it was pointed out that bandwidth occupied by OAM packets added > to a DetNet flow have to be accounted for in the bandwidth reservation fo= r > that flow. This made me wonder whether there were any DetNet-specific > security considerations associated with OAM traffic. As I understand it > based on the input I have received so far, there is nothing there that we > have to consider, except to say something like =E2=80=9CWe have considere= d the > matter and found that there are no DetNet-specific security consideration= s > related to OAM traffic=E2=80=9D. The rationale for this is that the OAM t= raffic is > either: > > 1) Generated by the network itself, and is thus trusted, because if you > can=E2=80=99t trust the network you have much worse problems. The additio= nal > bandwidth required for such packets is added by the network, presumably > transparent to the customer. > GIM>> I think that assumtion that any network is a priori secure and thus is trusted domain is not the one we use. Unless, of course, this is the upfront requirement, i.e., the DetNet domain must be secure, protected. Though for industrial applications it may be hard to comply with such requirement because nodes may be easily accessible, perhaps taken over, used to launch an attack. > Or > > 2) Generated by the customer, and is thus the customer=E2=80=99s responsi= bility. > That is, it is our job to deliver the customer=E2=80=99s packets with the= given > service level, and OAM packets are no different to us than any other data > the customer is reserving bandwidth for and transmitting. > GIM>> We refer to DetNet Service OAM (to extend, do we differentiate DetNet Transport OAM and Service OAM functionality? Perhaps separate thread to discuss) or e2e Service OAM? In the former case, I believe, it is still the DetNet OAM. If the latter, then for DetNEt service OAM packet are indistinguishable from the data packets. > > > I expect to put some text into the Security draft pretty much along those > lines. Can anyone think of anything I might have not taken into account? > Also any further statements of confirmation that this makes sense would b= e > appreciated. > > Thanks, > > Ethan. > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > --0000000000007371570574202330 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ethan,
= thank you for the thorough analysis of the OAM in DetNet domain specifics. = I think that the proposed text is very good. I have a few comments, questio= ns that you can find in-line under tag GIM>>.

Regards,
Greg

On Thu, Aug 23, 2018 at 11:42 AM, Grossman, Ethan A. <eagr= os@dolby.com> wrote:

Hi All,

Recently it was pointed out that bandwidth occupied = by OAM packets added to a DetNet flow have to be accounted for in the bandw= idth reservation for that flow. This made me wonder whether there were any = DetNet-specific security considerations associated with OAM traffic. As I understand it based on the input I have = received so far, there is nothing there that we have to consider, except to= say something like =E2=80=9CWe have considered the matter and found that t= here are no DetNet-specific security considerations related to OAM traffic=E2=80=9D. The rationale for this is that the OAM tr= affic is either:

1) Generated by the network itself, and is thus trus= ted, because if you can=E2=80=99t trust the network you have much worse pro= blems. The additional bandwidth required for such packets is added by the n= etwork, =C2=A0presumably transparent to the customer.

Or

2) Generated by the customer, and is thus the custom= er=E2=80=99s responsibility. That is, it is our job to deliver the customer= =E2=80=99s packets with the given service level, and OAM packets are no dif= ferent to us than any other data the customer is reserving bandwidth for and transmitting.

=C2=A0

I expect to put some text into the Security draft pr= etty much along those lines. Can anyone think of anything I might have not = taken into account? Also any further statements of confirmation that this m= akes sense would be appreciated.

Thanks,

Ethan.

=C2=A0


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

--0000000000007371570574202330--