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

Jiangyuanlong <jiangyuanlong@huawei.com> Thu, 23 February 2017 10:51 UTC

Return-Path: <jiangyuanlong@huawei.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 D161B129541 for <detnet-dp-dt@ietfa.amsl.com>; Thu, 23 Feb 2017 02:51:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 kb2m5-hTGrYc for <detnet-dp-dt@ietfa.amsl.com>; Thu, 23 Feb 2017 02:51:37 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28161294B2 for <detnet-dp-dt@ietf.org>; Thu, 23 Feb 2017 02:51:35 -0800 (PST)
Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHP84674; Thu, 23 Feb 2017 10:51:33 +0000 (GMT)
Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 23 Feb 2017 10:51:31 +0000
Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.67]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Thu, 23 Feb 2017 18:51:20 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Loa Andersson <loa@pi.nu>, Jouni Korhonen <jouni.korhonen@broadcom.com>
Thread-Topic: [Detnet-dp-dt] FRER example.. maybe a way forward? was Re: quick notes from call 2/14/15
Thread-Index: AQHSiU7K/u+vUs2FQ0qQNWO2NCqKMqFvS8+AgAAcC4CAAAEegIAGc33QgAAImICAAIt6EA==
Date: Thu, 23 Feb 2017 10:51:19 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBAB146E4@szxema506-mbs.china.huawei.com>
References: <BDABA4E9-F3F5-4EA3-BB16-BE877A70F0B6@broadcom.com> <FBC4D57C-51D4-41A8-95D7-56AF22084852@broadcom.com> <eb45b8a8-934e-1353-29fe-0100f1fbf9db@pi.nu> <95FC3243-3FA4-4BB3-B86A-490757E78DAA@broadcom.com> <5894aa82-1b46-c37b-f71c-ef8afb00b9f4@pi.nu> <3B0A1BED22CAD649A1B3E97BE5DDD68BBAB1462A@szxema506-mbs.china.huawei.com> <b0cd4c8f-cfb5-b824-04f5-30219f40ee23@pi.nu>
In-Reply-To: <b0cd4c8f-cfb5-b824-04f5-30219f40ee23@pi.nu>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.74.203.119]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.58AEBEB5.00A7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.67, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9bf9a3f0a96d987b877523b08d391d74
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/LUBeZT9xGpgHy-Dqg-WfyEBz7sQ>
Cc: "detnet-dp-dt@ietf.org" <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: Thu, 23 Feb 2017 10:51:39 -0000

Hi Loa,

This discussion is not meant to include switch fabric in any IETF standard, but to show how it influences the choice of "Eliminate & replicate" scheme.
My opinion is Detnet DT can follow the PWE3 architecture, while some texts may be needed to explain how the "Eliminate & replicate" scheme works.

Cheers,
Yuanlong

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu] 
Sent: Thursday, February 23, 2017 6:24 PM
To: Jiangyuanlong; Jouni Korhonen
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

Yuanlong,

I still not sure about this, it looks very much like the element functional blocks that ITU-T SG15 used to do, but that IETF never done. IETF leave this mostly up the different implementations.

Having said that, I realize that for an implementor this is important, but just now I don't see how to fold it on to an IETF standard.

/Loa

On 2017-02-23 15:58, Jiangyuanlong wrote:
> Hi loa,
>
> Your slides provide a good start point, it also made me think about the "Eliminate first and then replicate" scheme.
> In slide 4 & 5, you said:
> "Eliminate duplicates in PW instance (indexed by d-pw).
> Replicate d-pw after duplicate elimination towards C and D using L5 and L2."
>
> Assume that we have an S-PE router with a switch fabric inside (given the high throughput in the typical aggregation and metro network, switch fabric is a reasonable piece imbedded in a router).
> Assume that Eliminate module and Replicate module are separate modules.
> For a DetNet flow with a 10M bps, let us calculate what is the requirement on the switch fabric.
> We have several options to implement Eliminate & Replicate in the S-PE1 (please see the attached slides):
> 1. "Eliminate first and then replicate", if we put both Eliminate module and Replicate module in some central processing unit near the switch fabric, then 4 times of the DetNet flow (i.e., 40Mbps) need to pass through the switch fabric. When d-pw1 is broken, the traffic from d-pw3 is looped back to S-PE2.
> 2. "Eliminate first and then replicate", if we put both Eliminate module and Replicate module in the port connecting to the other S-PE, then optimally only 2 times of the DetNet flow (i.e., 20Mbps) need to pass through the switch fabric. When d-pw1 is broken, the traffic from d-pw3 is also looped back to S-PE2.
> 3. "Replicate first and then Eliminate", we can put Replicate module in the ingress of pw1 and put Eliminate module in the egress to PW2, then 3 times of the DetNet flow (i.e., 30Mbps) need to pass through the switch fabric.
> When d-pw1 is broken, no traffic from d-pw3 is looped back to S-PE2.
>
> In summary, "Eliminate & replicate" scheme will influence the bandwidth consumed in the switch fabric and on d-pw3.
>
> Thanks,
> Yuanlong
>
> -----Original Message-----
> From: Detnet-dp-dt [mailto:detnet-dp-dt-bounces@ietf.org] On Behalf Of 
> Loa Andersson
> Sent: Sunday, February 19, 2017 3:22 PM
> To: Jouni Korhonen
> 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
>
> slides
>
> /Loa
>
> On 2017-02-19 15:17, Jouni Korhonen wrote:
>> Loa,
>>
>>> On 18 Feb 2017, at 21:37, Loa Andersson <loa@pi.nu> wrote:
>>>
>>> Jouni,
>>>
>>> You st me off thinking in another direction. I have a concern that I tried to describe in two slides I've added in front of your. The solution involves adding  DetNet Id label to the stack.
>>
>> No slides?
>>
>>> The issues arises when two pair of nodes agree on the same d-pw 
>>> label value.
>>
>> Is this an issue with an _existing_ control plane?
>>
>>
>>>
>>> Though I need to re-read draft-ietf-mpls-flow-ident to see if there 
>>> is a more efficient way of doing it.
>>>
>>> I also have a question on what now is slide 5. WHy do we send a packet out over the same interface it came in over?
>>
>> That was an automatic byproduct of the replication rule as it does not care which interface the packet came in. Also I think the ladder redundancy case needed to have packets going two directions and this type of “echoing” would do that. The content of a packet on A->B->C would be the same as coming from C->B->C.
>>
>> - Jouni
>>
>>
>>>
>>> /Loa
>>>
>>>
>>> On 2017-02-18 02:50, Jouni Korhonen 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>> Thoughts? Comments? Flames?
>>>>
>>>> - Jouni
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>> _______________________________________________
>> 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