Re: [Detnet-dp-dt] New update of the draft available

Jouni Korhonen <jouni.korhonen@broadcom.com> Wed, 15 March 2017 15:59 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 4F3E61316E0 for <detnet-dp-dt@ietfa.amsl.com>; Wed, 15 Mar 2017 08:59:30 -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, 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 AW1snrqUhEpf for <detnet-dp-dt@ietfa.amsl.com>; Wed, 15 Mar 2017 08:59:27 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 990331316A6 for <detnet-dp-dt@ietf.org>; Wed, 15 Mar 2017 08:59:26 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id g10so14055169wrg.2 for <detnet-dp-dt@ietf.org>; Wed, 15 Mar 2017 08:59:26 -0700 (PDT)
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=FV/oGytMmdveexdImMYHHoZNdrkgwr1OyD8ReB2U2J8=; b=fhsd8MEgXXQLqrWwW3mx2FutK72rDKXbnhJ9SUZMZgT7AnGjIuUVHYY780kTgGHZhl egDaNHNCrD3mtEjtbbvu52cDyCIplOIVbKu1ZwogbYrdtgMi+nRc7iBv0iFXgoCSaSnP GIcZie6DA2ZpgRA75yEugumCK/8OVEs3fWyag=
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=FV/oGytMmdveexdImMYHHoZNdrkgwr1OyD8ReB2U2J8=; b=A050J3afbebPZtg1L3XStNAa/JfyT0FUnW0N24oSta4xK9SF46g5TOm9l2DczBRVB/ phhq3YHUBSAJ2YqgN+eNWFJQuP17Da/0MbP29QSx1MYhQWMdInxfhyhtL7xisQu3RjVj zA0pwqAkoxtFbbgoli9qXhC5LSDyBDoCqfxesXJn20Hq4bZq187rZVGUzZGrxXKntnEI RKRrnwWrmkpJoJV5/1tsrDWKEZi+5OhQzp474fCcN2SHWRVTwov5r9Leoex0t1WylMi/ wCn7IXavLQH3ptjjs1EVH2rICnqfBpPLECFnVkcHb0L/b9KibELFmOe3yLK+/6RJFSYR U5Zg==
X-Gm-Message-State: AFeK/H36UjRqU+FEP0D1rOlDptonWWx1E/uLRUGLvZFOTYNtCD6bRe+3gU+VSBhM5J5c1t3l
X-Received: by 10.223.168.80 with SMTP id l74mr3814437wrc.184.1489593564819; Wed, 15 Mar 2017 08:59:24 -0700 (PDT)
Received: from [192.168.90.98] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id t30sm2835734wra.55.2017.03.15.08.59.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 08:59:24 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Jouni Korhonen <jouni.korhonen@broadcom.com>
In-Reply-To: <96ef5de6-52da-87e0-25d1-96f1d88d68e5@pi.nu>
Date: Wed, 15 Mar 2017 08:59:19 -0700
Cc: =?utf-8?Q?Bal=C3=A1zs_Varga_A?= <balazs.a.varga@ericsson.com>, "detnet-dp-dt@ietf.org" <detnet-dp-dt@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <697FF96C-7364-45F5-8EFC-59E2C1AF475C@broadcom.com>
References: <C0EC6F12-4028-4360-A6BB-BFEE3C253EA3@broadcom.com> <45bccdbf-2457-2c08-34fe-c559a80e9c7d@pi.nu> <AMXPR07MB117CFC8AF83D9294E402897AC230@AMXPR07MB117.eurprd07.prod.outlook.com> <DBXPR07MB12874D8FD0DEF578E72882BAC250@DBXPR07MB128.eurprd07.prod.outlook.com> <fe645f19-475c-b49e-8e1d-21ec06c6585b@pi.nu> <DBXPR07MB1280A02737AB1CF6061F8AAAC240@DBXPR07MB128.eurprd07.prod.outlook.com> <96ef5de6-52da-87e0-25d1-96f1d88d68e5@pi.nu>
To: Loa Andersson <loa@pi.nu>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/AdQrE9IocyrbTgH4iBnF7osuQiw>
Subject: Re: [Detnet-dp-dt] New update of the draft available
X-BeenThere: detnet-dp-dt@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 15 Mar 2017 15:59:30 -0000

Inline..

> On Mar 15, 2017, at 12:21 AM, Loa Andersson <loa@pi.nu> wrote:
> 
> Bala'zs,
> 
> OK - I think we are close to consensus here.
> 
> In line please.
> 
> On 2017-03-14 17:11, Balázs Varga A wrote:
>> Hi Loa,
>> 
>> Yes, I am fine with the tunneling, no issues on that. Now I see
>> your point better.
>> 
>> Your concern is regarding the control plane and not the data plane.
> 
> Well, almost - I'm concerned that for some control planes it is not
> possible to distinguish between a node that act as P or PE when setting
> up a PW. I it is my gut feeling that if we want to change the control
> plane to do this it would be a major change.
> 
>> In my view request for PRER
> Jouni calls the "Packet Replication and Elimination function (PREF)"
> in the draft - should we stay with that terminology??

Yes ;)

> 
> should be (i) PW and (ii) node specific:
> 
> This a a big bite to bite of for example for LDP if we are talking
> about an un-tunneled PW, if we are talking about a MS-PW with a
> L-label (PSN tunnel) it is state of the art.
> 
> It might be that I misunderstood your earlier comment:
> 
> "I think the addition of the DetNet Flow-ID to the "PW Encapsulation
> header" changed our former discussions. If the DetNet Flow-ID is
> present, we can change the d-pw label during the transport like in
> case of a legacy MS-PW."
> 
> I took that to mean that we could change he PW label "during transport"
> and thought you meant at P nodes also. Reading it more careful and
> seeing "like in case of a legacy MS-PW" I think you meant that the
> PW-label can be changed at every DA-S-PE node. And pushed/popped at the
> DA-T-PE nodes.
> 
> If this is the case we are in agreement!

This is my understanding of “changing PW label during transport”. Only DA-*-PE nodes may swap/push/pop PW label. The text in the draft should already be written this as the design.

>> - PRER points need proper planning before the setup of the DetNet-PW
>> (which nodes should be selected for x-PE roles, already established
>> overlay tunnel might be considered during the design also, etc.)
> 
> hmmm  - yes, but setting up an un-tunneled PW through PA-1/PE-B2, will
> be non-deterministic, the control plane for one overlay network will
> view PA-1/PE-B2 as a P node (un-capable of DetNet NSP and PREF), and
> send the TLV/object that request DetNet NSP and PREF that is intended
> for PE-A2. Since PA-1/PE-B2 are capable of DetNet NSP and PREF, since
> it is a DA-A-PE in the other overlay network, it will try to act on
> the  DetNet NSP and PREF (and very likely fail).

I think you will always have at least one label in a stack above the PW label (until you reach the DA-*-PE node) during transit.

> 
>> - signaling for PW setup should contain the planning results
> 
> yes it does, only that this planning should include the L-label overlay.
> 
>> 
>> So in your example, when PE-A1 signals for the PW to PE-A2, the role
>> of P-A1 should be clear (i.e. no PRER for PW between A1 and A2) and
>> included in signaling.
> 
> Sure - but since PA-1/PE-B2 is capable of DetNet NSP and PREF, it can't
> be allowed to see the signalling for PE-A2 or packets that are intended
> for PE-A2. One reason we need the L-label.
> 
>> Simultaneously PE-B1 should signal explicitly that PE-B2 is a PRER
>> point for the PW between PE-B1 and PE-B3.
> Yes - in this case the MS-PW label is exposed, it is understood that
> NSP and PREF is required, since the signaling is specifically to
> PA-1/PE-B2 (e.g. tLDP) and when forwarding the L-label is php'ed or
> popped.

Ack.


- JOuni

> 
> /Loa
>> 
>> Cheers
>> Bala'zs
>> 
>> -----Original Message-----
>> From: Detnet-dp-dt [mailto:detnet-dp-dt-bounces@ietf.org] On Behalf Of Loa Andersson
>> Sent: Monday, March 13, 2017 4:05 PM
>> To: Balázs Varga A <balazs.a.varga@ericsson.com>om>; detnet-dp-dt@ietf.org
>> Subject: Re: [Detnet-dp-dt] FW: New update of the draft available
>> 
>> Balázs,
>> 
>> I'd not seen this before. I thought that we'd reached consensus on the need to tunneling across the P routers after the comments from Jouni and Yuanlong. Please see inline.
>> 
>> On 2017-03-13 18:09, Balázs Varga A wrote:
>>> Hi, mail below seems to be lost in hyperspace. I send it again, sorry
>>> for possible duplicates ... Cheers Bala'zs
>>> 
>>> -----Original Message-----
>>> From: Balázs Varga A
>>> Sent: Saturday, March 11, 2017 7:54 PM
>>> To: 'Loa Andersson' <loa@pi.nu>nu>; detnet-dp-dt@ietf.org
>>> Subject: RE: [Detnet-dp-dt] New update of the draft available
>>> 
>>> Hi Loa,
>>> 
>> <snip>
>> 
>>>> d-pw label with signaling that exposes the "request for DetNet
>>>> NSP/FRER" to P nodes
>>> Could You explain it more, I do not see your point. Do You propose that the L-label value would control whether a PW is a DetNet PW with PRER or not?
>>> 
>> 
>> We discuss the "overlay network" in terms of P and PE nodes. The P node does not not do PRER, while the PE may do so if we tell them.
>> 
>> However one node by serve as P in one overlay network, and as PE in another.
>> 
>> Consider:
>> 
>>                 +------+
>>                 | PE-B1|
>>                 +------+
>>                    |
>>                    v
>>                 +------+
>>                 | P-B1 |
>>                 +------+
>>                    |
>>                    v
>>                 +------+
>>  +------+       | P-A1 |       +------+       +------+       +------+
>>  | PE-A1|------>| PE-B2|------>| P-A2 |------>| P-A3 |------>| PE-A2|
>>  +------+       +------+       +------+       +------+       +------+
>>                    |
>>                    v
>>                 +------+
>>                 | P-B2 |
>>                 +------+
>>                    |
>>                    v
>>                 +------+
>>                 | PE-B3|
>>                 +------+
>> 
>> 
>> Ledgend: PE-A = DA-*-PE, PE node in network A
>>          P-A  = P node network A
>>          PE-B = DA-*-PE, PE node in network B
>>          P-B  = P node network B
>> 
>> Problem is signalling!
>> 
>> If have the PW-Label un-tunneled PE-B will establish the unprotected PW to PE-B3, requesting PERF of the PERF capable nodes.
>> 
>> Node PE-B2 will do PREF, which is fine, that is what it is supposed to do. PE-B3 will eliminate duplicates as it is supposed to do.
>> 
>> PE-A1 will also try to set up an un-tunneled PW to PE-A2, PA-2, PA-3 and
>> PE-A2 will do what they are supposed to do. The problem is that the node "P-A1" is also "PE-B2" and will understand the request for PERF, which it is not supposed to do.
>> 
>> Our solution is to use the L-label to tunnel between DA-*-PE.
>> 
>> /Loa
>> 
>> 
>> 
>>> Thx & Cheers
>>> Bala'zs
>>> 
>>> -----Original Message-----
>>> From: Detnet-dp-dt [mailto:detnet-dp-dt-bounces@ietf.org] On Behalf Of
>>> Loa Andersson
>>> Sent: Saturday, March 11, 2017 3:38 AM
>>> To: detnet-dp-dt@ietf.org
>>> Subject: Re: [Detnet-dp-dt] New update of the draft available
>>> 
>>> Jouni,
>>> 
>>> Mostly looks very good, the thing I don't understand is why you still say that the L-label is optional, it really isn't.
>>> 
>>> - we need it to deliver the d-pw label unchanged
>>> - since we can't guarantee that the "P" nodes are not able to do
>>>   DetNet NSP, we can't set up the d-pw label with signaling that
>>>   exposes the "request for DetNet NSP/FRER" to P nodes.
>>> - needed for protection
>>> - the end-to-end tunnel must be the innermost tunnel, carrying
>>>   pw label
>>> 
>>> There is one case, if two DA-*-PEs are immediately adjacent, there the L-lable will be an implicit NULL label and not appear in the stack, but for the control plane it is there.
>>> 
>>> /Loa
>>> 
>>> On 2017-03-11 07:25, Jouni Korhonen wrote:
>>>> * Added Loa’s comments on the L-label.
>>>> * Added Janos’ comments.
>>>> * Added extended forwarder text.
>>>> * Added (speculative text.. can be removed) D bit to flow-id word so
>>>> that we can check in a ring case the direction of the flow (note this
>>>> does not double history buffer space as claimed.. did not bother to
>>>> fix that)
>>>> * reworked the PW encapsulation pictures.
>>>> * Added more content to DA-*-PE descriptions.
>>>> 
>>>> - Jouni
>>>> 
>>>> 
>>> 
>> 
> 
> -- 
> 
> 
> 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