Re: [Detnet-dp-dt] New architecture draft
"Norman Finn (nfinn)" <nfinn@cisco.com> Fri, 08 July 2016 21:09 UTC
Return-Path: <nfinn@cisco.com>
X-Original-To: detnet-dp-dt@ietfa.amsl.com
Delivered-To: detnet-dp-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7F112D76B for <detnet-dp-dt@ietfa.amsl.com>; Fri, 8 Jul 2016 14:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 94ZPHtVxcrPU for <detnet-dp-dt@ietfa.amsl.com>; Fri, 8 Jul 2016 14:09:48 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A230712D86E for <Detnet-dp-dt@ietf.org>; Fri, 8 Jul 2016 14:09:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40668; q=dns/txt; s=iport; t=1468012188; x=1469221788; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=lVfATz6+4qHxa14fNuRKvFVJKdMfHnsBr8G7N4DlGuE=; b=CtHhfcC6qEaLM5YO/nefrMHC7Hwx4CJbT/1qQXG4Hi9TB8DoOYrTAbbL RSWZhoM1bfXaJUBfNzlRz9KYvRzcNxVOG43E9akn/vLtX5mku0LiCmcaS f1R4FfUU4ZZPipJq2mGvzj/iyW1580rjl986BhpyLZ/fPT5LqE4TYu+Ex o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BFAgDPFYBX/5JdJa1cgnBOVm4OBrkQgXokhSpKAhyBDDgUAQEBAQEBAWUnhEwBAQUBASFLBBcCAQgRAQIBAiEHAwICAiULFAMGCAIEARIJiCcOrnuFNYlkAQEBAQEBAQECAQEBAQEBAQEfhieDSoEDhBECEQE8FoJLgloFjgSFQYVPAY5OgWqEWIQphEGGWokzAR42ggkcgUxuh24PFx9/AQEB
X-IronPort-AV: E=Sophos;i="5.28,332,1464652800"; d="scan'208,217";a="122073141"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2016 21:09:47 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u68L9lws003753 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jul 2016 21:09:47 GMT
Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 16:09:46 -0500
Received: from xch-rcd-018.cisco.com ([173.37.102.28]) by XCH-RCD-018.cisco.com ([173.37.102.28]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 16:09:46 -0500
From: "Norman Finn (nfinn)" <nfinn@cisco.com>
To: "Norman Finn (nfinn)" <nfinn@cisco.com>, János Farkas <janos.farkas@ericsson.com>, "detnet-dp-dt@ietf.org" <Detnet-dp-dt@ietf.org>
Thread-Topic: [Detnet-dp-dt] New architecture draft
Thread-Index: AQHR17cVYgVQT6iIp0GPjxGs/DHhHKAMGNeAgAFtQoCAAU/2AIAAAX8AgAABIoCAABB0AA==
Date: Fri, 08 Jul 2016 21:09:46 +0000
Message-ID: <D3A560FD.4F5BC%nfinn@cisco.com>
References: <D3A2A0B5.4F431%nfinn@cisco.com> <453432c6-6ff8-c1ad-2f29-9e3679abab05@labn.net> <577E8A53.5070106@ericsson.com> <D3A55120.4F585%nfinn@cisco.com> <D3A554FC.4F5A7%nfinn@cisco.com> <D3A5564B.4F5B2%nfinn@cisco.com>
In-Reply-To: <D3A5564B.4F5B2%nfinn@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.94.161]
Content-Type: multipart/alternative; boundary="_000_D3A560FD4F5BCnfinnciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/XCIXONDOBCOOnbafGHhgFOWOYGk>
Subject: Re: [Detnet-dp-dt] New architecture draft
X-BeenThere: detnet-dp-dt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DetNet WG Data Plane Design Team <detnet-dp-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet-dp-dt>, <mailto:detnet-dp-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet-dp-dt/>
List-Post: <mailto:detnet-dp-dt@ietf.org>
List-Help: <mailto:detnet-dp-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet-dp-dt>, <mailto:detnet-dp-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2016 21:09:52 -0000
Made some small changes, as indicated in email threads. Left out transit edge node; it can come back if needed. Did change “DetNet reliability” to “DetNet loss prevention”. Made more of a deal about replication/elimination is just the best-explored form of loss prevention, but more will be needed there, both to make that more clear, and to examine viable alternatives. In bitbucket as -06, uploaded to datatracker, clicked on the email, and verified it’s there on the DetNet WG page. — Norm From: Norman Finn <nfinn@cisco.com<mailto:nfinn@cisco.com>> Date: Friday, July 8, 2016 at 13:10 PM To: Norman Finn <nfinn@cisco.com<mailto:nfinn@cisco.com>>, János Farkas <janos.farkas@ericsson.com<mailto:janos.farkas@ericsson.com>>, "detnet-dp-dt@ietf.org<mailto:detnet-dp-dt@ietf.org>" <Detnet-dp-dt@ietf.org<mailto:Detnet-dp-dt@ietf.org>> Subject: Re: [Detnet-dp-dt] New architecture draft Ahhhh yes. There was one other possible use for a “transit edge node": Without any sequencing or elimination, there was the function of protecting reservations from mislabeled traffic and shaping and/or policing incoming critical streams to make sure they can’t mess up other streams. Still, more people have put more thought into the dp-alt doc, so I’ll go with that usage, for this rev, and cut out transit edge node. — Norm From: Norman Finn <nfinn@cisco.com<mailto:nfinn@cisco.com>> Date: Friday, July 8, 2016 at 13:06 PM To: Norman Finn <nfinn@cisco.com<mailto:nfinn@cisco.com>>, János Farkas <janos.farkas@ericsson.com<mailto:janos.farkas@ericsson.com>>, "detnet-dp-dt@ietf.org<mailto:detnet-dp-dt@ietf.org>" <Detnet-dp-dt@ietf.org<mailto:Detnet-dp-dt@ietf.org>> Subject: Re: [Detnet-dp-dt] New architecture draft Forgot, DetNet transport edge node (should have been DetNet transit edge node): If the end system provides the sequencing with an 802.1CB tag, and the transit node converts that to a pseudowire, that was my idea of a DetNet transit edge node. Obviously, that wasn’t clear. As I think about it, that would probably be better described as a relay edge node, because even though it doesn’t alter any sequence numbers, it certainly changes their form and messes around at the sequence numbering layer. I’l remove it. — Norm From: Detnet-dp-dt <detnet-dp-dt-bounces@ietf.org<mailto:detnet-dp-dt-bounces@ietf.org>> on behalf of Norman Finn <nfinn@cisco.com<mailto:nfinn@cisco.com>> Date: Friday, July 8, 2016 at 13:01 PM To: János Farkas <janos.farkas@ericsson.com<mailto:janos.farkas@ericsson.com>>, "detnet-dp-dt@ietf.org<mailto:detnet-dp-dt@ietf.org>" <Detnet-dp-dt@ietf.org<mailto:Detnet-dp-dt@ietf.org>> Subject: Re: [Detnet-dp-dt] New architecture draft János, I’d like to get these things aligned. See in-line From: Detnet-dp-dt <detnet-dp-dt-bounces@ietf.org<mailto:detnet-dp-dt-bounces@ietf.org>> on behalf of János Farkas <janos.farkas@ericsson.com<mailto:janos.farkas@ericsson.com>> Date: Thursday, July 7, 2016 at 09:58 AM To: "detnet-dp-dt@ietf.org<mailto:detnet-dp-dt@ietf.org>" <Detnet-dp-dt@ietf.org<mailto:Detnet-dp-dt@ietf.org>> Subject: Re: [Detnet-dp-dt] New architecture draft Hi, I've also found some differences that may be confusing. The architecture draft defines: DetNet intermediate node A DetNet relay node or transport node. DetNet transport 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. An MPLS LSR is an example of a DetNet transport node. Whereas "transport node" is not used in the data plane draft. Instead, the data plane draft defines: Transit Node A node that provides link layer and network layer switching across multiple links and/or sub-networks. An MPLS LSR is an example of a transit node. I’m good with that. The transit node operates in the transport layer. I gave them the same name. I’ll make it right, if Pascal has not, already. The architecture draft defines: DetNet relay edge node An instance of a DetNet relay node that includes a service layer (packet sequencing and/or elimination) proxy function for one or more end systems, analogous to a Label Edge Router (LER). DetNet transport edge node An instance of a DetNet transport node that includes a transport layer (DetNet flow encapsulation, splitting and/or merging) proxy function for one or more end systems, for example, a Label Edge Router (LER). Do we have DetNet transport edge node? Isn't each DetNet edge node is a DetNet relay edge node? The data plane draft says at the moment: Edge Node A relay node with application level knowledge (i.e., basically a "proxy" node). Egde nodes are needed when interfacing with nodes or end systems that are not DetNet-enabled. The data plane draft says: Transit Node A node that provides link layer and network layer switching across multiple links and/or sub-networks. An MPLS LSR is an example of a transit node. The architecture draft says: relay node A DetNet service layer function that interconnects different DetNet transport layer protocols or networks (instances) to perform packet replication and elimination (Section 3.4. May be a router, transit node, bridge, Label Switch Router (LSR), firewall, or any other system that participates in the DetNet service layer. A DetNet relay node typically incorporates DetNet transport layer functions, as well. Should be "transit node" and LSR removed from the definition of relay node in the architecture draft? (My understanding from the call yesterday and from the data plane draft is that a relay node is rather a LER than an LSR.) Kept some old text, there. A relay node can’t be those things; it just resides in the same box. Will trim down to match dp-alt more closely. In the data plane draft, the criteria relevant for the Service and dor the Transport layer are collected in Section 4. IT has been discussed a lot and what we have at the moment is: for the Service layer: #5 Packet replication and elimination (note: only the packet deletion for seamless redundancy) for the Transport layer #5 Packet replication and elimination (note: only the packet replication and/or flow merging for seamless redundancy) The architecture draft says: DetNet service layer The layer at which packet replication and elimination (Section 3.4) is performed. DetNet transport layer The layer that splits and merges Detnet flows for packet replication and elimination (Section 3.4). 1. Please get rid of the term “seamless redundancy” (: not necessarily right now :) I took it out of the architecture document because ISO/IEC 62439-3 kind of owns that term. 2. The DetNet service layer definition in the architecture should NOT say packet replication, but can say packet sequencing and elimination. I think that fixes the gross difference. I guess the two drafts could be better synchronized. One key difference is that packet replication is considered as part of the Service layer in the Architecture draft whereas it is part of the Transport layer in the data plane draft. At the moment, maybe the easiest way to delete these from the architecture draft? (Actually the Service and Transport layers are distinguished for other purposes too.) The data plane draft said yesterday: [I-D.finn-detnet-architecture] does not specify the relationship between layers. which I've just suggested to update to [I-D.finn-detnet-architecture] does not specify the relationship between the DetNet Service and Transport layers used in this document to investigate data plane options as explained in the following. In any case, I guess we should get rid of "seamless redundancy" from the data plane draft as the architecture uses "packet replication and elimination" instead. I guess we should update the data plane draft to The two referred bullets of Section 4 could be updated to: for the Service layer: #5 Packet elimination for packet replication and elimination (see Section 3.4 in Architecture) for the Transport layer #5 Packet replication and splits and merges of DetNet flows for packet replication and elimination (see Section 3.4 in Architecture) If you have time, I’d say #5 packet sequencing (if needed) and packet elimination ... nits on the architecture draft all kinds of nodes are defined as "DetNet xy node" except for "relay node" which has no DetNet in its name but the definition itself begins with DetNet. Maybe it could be renamed to "DetNet relay node" and the definition could be moved next to "DetNet relay edge node" to show the specialty of edge. DetNet node A DetNet aware end system, transport node, or relay node. "DetNet" may be omitted in some text. It may be confusing to have "end system here. However,, I understand that an end system is a DetNet relay node e.g., the right hand side end system in Fig 1 of data plane. Unfortunately, I have no resolution at hand. Regards, Janos On 7/6/2016 9:11 PM, Lou Berger wrote: Norm, I think there are still some mismatches between what Jouni is working on and this document. Do you have time to discuss today? or tomorrow am? What's the best way to get you comments on other sections? Lou On 7/6/2016 2:49 PM, Norman Finn (nfinn) wrote: Uploaded it to bitbucket. Here’s a link to the text in dropbox. https://www.dropbox.com/s/9kc1ingqtnwgb49/draft-finn-detnet-architecture-05 .txt?dl=0 Big differences are the simplified stack diagram and terminology revised to better match dp-alt, in accordance with last two dial-in meetings. — Norm _______________________________________________ Detnet-dp-dt mailing list Detnet-dp-dt@ietf.org<mailto:Detnet-dp-dt@ietf.org>https://www.ietf.org/mailman/listinfo/detnet-dp-dt _______________________________________________ Detnet-dp-dt mailing list Detnet-dp-dt@ietf.org<mailto:Detnet-dp-dt@ietf.org>https://www.ietf.org/mailman/listinfo/detnet-dp-dt
- Re: [Detnet-dp-dt] New architecture draft Pascal Thubert (pthubert)
- Re: [Detnet-dp-dt] New architecture draft Lou Berger
- Re: [Detnet-dp-dt] New architecture draft Norman Finn (nfinn)
- Re: [Detnet-dp-dt] New architecture draft Norman Finn (nfinn)
- Re: [Detnet-dp-dt] New architecture draft Norman Finn (nfinn)
- Re: [Detnet-dp-dt] New architecture draft Lou Berger
- Re: [Detnet-dp-dt] New architecture draft Lou Berger
- Re: [Detnet-dp-dt] New architecture draft Lou Berger
- Re: [Detnet-dp-dt] New architecture draft Pascal Thubert (pthubert)
- Re: [Detnet-dp-dt] New architecture draft Pascal Thubert (pthubert)
- Re: [Detnet-dp-dt] New architecture draft Lou Berger
- Re: [Detnet-dp-dt] New architecture draft Lou Berger
- Re: [Detnet-dp-dt] New architecture draft Jouni Korhonen
- Re: [Detnet-dp-dt] New architecture draft János Farkas
- Re: [Detnet-dp-dt] New architecture draft Lou Berger
- Re: [Detnet-dp-dt] New architecture draft Jouni Korhonen
- [Detnet-dp-dt] New architecture draft Norman Finn (nfinn)
- Re: [Detnet-dp-dt] New architecture draft Norman Finn (nfinn)
- Re: [Detnet-dp-dt] New architecture draft Norman Finn (nfinn)