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 07:11 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 566AB12706D for <detnet-dp-dt@ietfa.amsl.com>; Sat, 18 Feb 2017 23:11:39 -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 p_1DTwzXrvwW for <detnet-dp-dt@ietfa.amsl.com>; Sat, 18 Feb 2017 23:11:37 -0800 (PST)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 A5A33120727 for <detnet-dp-dt@ietf.org>; Sat, 18 Feb 2017 23:11:37 -0800 (PST)
Received: by mail-pg0-x22b.google.com with SMTP id b129so5873230pgc.2 for <detnet-dp-dt@ietf.org>; Sat, 18 Feb 2017 23:11:37 -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:cc :content-transfer-encoding:message-id:references:to; bh=VQ9SrXRVzCsTDApBE3sL2BsYQ7GT64UZEuy4kFm40Ds=; b=Vz/pILZQQg6IReZ0D3bPvnHEqR3LfD42nfytRkLZIsMlgsIcIBRW/mVvyy0VCZ9lGn xkHKwm3HYDnMjmeHJ3LgKvAzLQ1Lf/jFwdO0xfs0Q5qDAyRhp9a/FTcthwrk1LdLMMRI dKryQHzjg0ZnfYKYII/BJsmSzktbVVzL/AEz0=
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:cc :content-transfer-encoding:message-id:references:to; bh=VQ9SrXRVzCsTDApBE3sL2BsYQ7GT64UZEuy4kFm40Ds=; b=A9I51P+JFfIkUmT8bCVdIIKhj3jwoOlssJO5gZcfvqFiG6V5mB0kYbK5GbeGMO5zS/ m9+g7nn0ujhf+hvw7IeCRz8/EoZ7UoyXkmpgpVWqzZBY6qmi6qASobWNzfYHMBo5YH4M iq6Bl2y6bW5xQYKswl1SpTds6KNrCJ2hxwqW0itGTh7QuLVGj8O06eyWRIeHTKJ0WHzH O/3Pw6TCIJpxtU6SzpRC7XhIBBSgTOJp1kxU3SrzzavrUU1qsYbeOmel4c+4o5Scyng6 NEEVrbCHv25oNhxjJbAietoOFiIJSVRorioswnhm5Hxr/5TfV+3S4bB9VNuddm3frzGR 0Fgg==
X-Gm-Message-State: AMke39kyIM4DbkxYjQDiBYStqh3FKq+AkyTm+G8noP1RObPQInj6StgPlm4eI/CWnFVP3hop
X-Received: by 10.84.224.65 with SMTP id a1mr23265344plt.28.1487488296818; Sat, 18 Feb 2017 23:11:36 -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 p6sm28235988pfg.6.2017.02.18.23.11.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 18 Feb 2017 23:11:36 -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: <f3bbb70a-0f5d-b515-6c5a-1d31ba5ae5a2@pi.nu>
Date: Sat, 18 Feb 2017 23:11:34 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F2B8081-ADB8-4B4F-BACD-78DFB63B8FBE@broadcom.com>
References: <BDABA4E9-F3F5-4EA3-BB16-BE877A70F0B6@broadcom.com> <FBC4D57C-51D4-41A8-95D7-56AF22084852@broadcom.com> <9E4E59F6-0E62-476B-897F-D2D59E94C6EB@broadcom.com> <f3bbb70a-0f5d-b515-6c5a-1d31ba5ae5a2@pi.nu>
To: Loa Andersson <loa@pi.nu>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/LkOcp3MDNrCPk6MbIBrWp_0060k>
Cc: detnet-dp-dt@ietf.org
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 07:11:39 -0000

Loa,

> On 18 Feb 2017, at 23:04, Loa Andersson <loa@pi.nu> wrote:
> 
> Jouni,
> 
> 
> 
> On 2017-02-19 14:49, Jouni Korhonen wrote:
>> 
>> 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.
>> 
> What is the scope of "single" here? Do you mean that packet being replicated will have the same d-pw label? I thought that was necessary

As in the slidesset the detnet/administrative domain. All x-PE devices would use the same d-pw. What I am saying above is that if we were using different d-pw labels stuff gets complicated even when replicating.

- JOuni

> otherwise we can identify duplicates.
> 
> If you mean that each node only uses one d-pw, I don't think that can
> work.
> 
> /Loa
>>> 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>
>>> 
>> 
>> _______________________________________________
>> Detnet-dp-dt mailing list
>> Detnet-dp-dt@ietf.org
>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>> 
> 
> -- 
> 
> 
> Loa Andersson                        email: loa@mail01.huawei.com
> Senior MPLS Expert                          loa@pi.nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64