Re: [Detnet-dp-dt] FRER example.. maybe a way forward? was Re: quick notes from call 2/14/15

Jouni Korhonen <jouni.korhonen@broadcom.com> Sun, 19 February 2017 06:49 UTC

Return-Path: <jouni.korhonen@broadcom.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 47257129432 for <detnet-dp-dt@ietfa.amsl.com>; Sat, 18 Feb 2017 22:49:26 -0800 (PST)
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, 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 (1024-bit key) header.d=broadcom.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 xcnCWPdowa3z for <detnet-dp-dt@ietfa.amsl.com>; Sat, 18 Feb 2017 22:49:25 -0800 (PST)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 07EE61293F4 for <detnet-dp-dt@ietf.org>; Sat, 18 Feb 2017 22:49:24 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id b129so5756314pgc.2 for <detnet-dp-dt@ietf.org>; Sat, 18 Feb 2017 22:49:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=pVobBpFgCCMr52TunNJC0mk6xfHqXMJxJp3paoutmuw=; b=OuFF9WTh3Qc2LEehW7F4tJQTJQOmeP5YqVuDPxHSDJM89aMLZO4R1qlN429AbuOrsB o/2Qq4+ePoTx3eG//Yil6Z0G3abNIqXKUHW2PTYqdLN37TsdTsn8nkaH/eW3hg+Xqh9G HbYJX3ZxIA69T5B6tYsDLMVeAmq/i6j+K7GOI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=pVobBpFgCCMr52TunNJC0mk6xfHqXMJxJp3paoutmuw=; b=VVsXPKd3w3cDzYFnr7tskPcxzGG9swjcEmefdsWklG8DhuILTt3WiTJoykQPPsmyDG lIfD0BEE4pmABdkeIusSHr/MDZv8IpFzpCLaZbvh/RkQSLVjNRx7RjPNAomidmJhIqnB ouYuq8Zzlby4EkbpssJbCFkMKgbT59xOUndnQbW6DhbD3F5f9MtR7H1vHdrQrTMQoiIs ozGJ21r4d6SixKTW6c4XQbSx8V2M7S5XxG2+hU8iqc2SgXvXboT+goabgvLek5HqEwyh pPW9Ml0aTjXKWQhcNZpk4/uweqruzAJLibLR/4P20SlFoz92nQJTwls2UyYB3ZZ1wdD1 ZSUg==
X-Gm-Message-State: AMke39mok27uKsYxXi7FHWHFL4sYlihCSpDkRGNCpYwQyXBMsaNq6WWteyj2Hltizx42MmjY
X-Received: by 10.84.231.205 with SMTP id g13mr23131894pln.30.1487486963947; Sat, 18 Feb 2017 22:49:23 -0800 (PST)
Received: from [10.0.0.5] (c-24-5-144-221.hsd1.ca.comcast.net. [24.5.144.221]) by smtp.gmail.com with ESMTPSA id q7sm28011298pfb.98.2017.02.18.22.49.22 for <detnet-dp-dt@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 18 Feb 2017 22:49:23 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Jouni Korhonen <jouni.korhonen@broadcom.com>
In-Reply-To: <FBC4D57C-51D4-41A8-95D7-56AF22084852@broadcom.com>
Date: Sat, 18 Feb 2017 22:49:21 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E4E59F6-0E62-476B-897F-D2D59E94C6EB@broadcom.com>
References: <BDABA4E9-F3F5-4EA3-BB16-BE877A70F0B6@broadcom.com> <FBC4D57C-51D4-41A8-95D7-56AF22084852@broadcom.com>
To: detnet-dp-dt@ietf.org
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/bMxcY2srTcpiJaqh9zyRnFkruhk>
Subject: Re: [Detnet-dp-dt] FRER example.. maybe a way forward? was Re: quick notes from call 2/14/15
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: Sun, 19 Feb 2017 06:49:26 -0000

Additional thoughts from my side.

> On 17 Feb 2017, at 10:50, Jouni Korhonen <jouni.korhonen@broadcom.com> wrote:
> 
> Folks,
> 
> See the attached slideset for some thoughts on implementing FRER in S-DetNet-PEs and Norm’s ladder redundancy case. Note, S-DetNet-PEs and T-DetNet-PEs are not off the shelf x-PEs, since they do understand DetNet quirks in addition to existing x-PE functionality.
> 
> The solution still assumes global d-pw space witin an administrative domain due the easier handling of SN counters and bit vectors for elimination on each x-PE. I have rightfully been pointed out that having a common reserved label space among all x-PEs for d-pw (detnet) purposes can be hard to achieve, especially in a multivendor environment (there are similar issues on segment routing as well). This is mostly a management/implementation issue, not a technical hardship IMHO.

Assuming that after replication each outgoing PWs would have also different d-pw label makes the solution less hardware friendly. That would mean yet another mapping table and effectively doubling the label space needed for each PW.

With a single outgoing d-pw one could be effectively reusing (to most part) 1+1 redundancy if the existing implementation already has one.

> If we were to agree to go towards a solution where each x-PE knows the d-pw space of their peers (at L-label level) the d-pw could be different on each PW for the same e2e detnet flow. The d-pw label would in this case be an x-PE DetNet-label-base + index. The index here would actually identify the e2e detnet flow.


- Jouni

> 
> 
> Thoughts? Comments? Flames?
> 
> - Jouni
> 
> 
> <detnet-frer-jik_v3.pptx>
> --
> Jouni Korhonen, Broadcom Ltd.
> M: +1-408-391-7160
> 
>> On Feb 15, 2017, at 11:37 AM, Jouni Korhonen <jouni.korhonen@broadcom.com> wrote:
>> 
>> Present: Jouni, Norm, Loa, Balazs, Janos, Carlos, Yuanlong.
>> 
>> Agenda:
>> - Was meant to be about CoS and QoS. However, we ended up discussion all time about proper layering and encapsulation of PW stack.
>> 
>> Discussion:
>> - Sequence number. We made a >>decision<< to settle down to 16 bits. This is the most “compatible” approach. At high speeds it has been argued 16 bits is not enough. In practical implementations even 16 bits of sequence number won’t be maintained. It is typically a much smaller window of the entire sequence number space (think about numbers.. 1M PWs times the seqnum bit vector etc..)
>> - PWs and the label stack. See the latest slides from Loa and specifically the slide 9 (attached). I did add one slide to this deck, the slide 14.
>> - T-labels are typically per hop. L-labels are between DetNet aware S/P-PEs and essentially form an overlay over the underlying network. d-pw labels are end to end (at the moment.. to be discussed) between the T-PEs or in general between the DetNet aware end point that understand the detnet data plane.
>> - currently all d-pw (detnet PW labels) experience FRER if that functionality is enabled. d-pw labels are tied to sequence numbers (the detnet CW).
>> - L-labels seen beneficial allowing the autoconfiguration of FRER i.e., build the overlay over the network and do not care configuring the PWs. This mimics one 802.1CB feature (see .1CB sub-clause 7.11).
>> - L-labels also allow simple label swap in a detnet S-PE i.e., no FRER would be applied. 
>> - This setup seems plausible. There was concerns overloading L-labels with some of the PW decision making in the fast path and thus possibly causing a lookup that needs to be done over two labels (L & d-pw). Essentially it is the L-label that signals whether the FRER gets applied.
>> - General consensus towards the PW instance “facing egress ports” in a detnet S-PE would do the elimination.  This discussion needs to be completed. An interesting use case was described by Norm (see slide 14). An example: packet arrives from A towards B (flow X), it always gets replicated towards C, but towards D only if the same packet (from flow Y) has not earlier arrived from C. Whether this works ok with the current S-PE and PW instance doing elimination concepts needs to be verified.
>> - Discussion to be completed whether there are cases where L-labels can be left out i.e., only use T-labels and d-pw labels. 
>> - Balazs said to provide a matrix/table of different permutations for labels & replications & eliminations.
>> 
>> We’ll have a call next Tuesday 2/21/17.
>> 
>> 
>> --
>> Jouni Korhonen, Broadcom Ltd.
>> M: +1-408-391-7160
>> 
>> <detnet-replication-jik.pptx>
>