Re: [Detnet-dp-dt] Section 4.1 added (DP solution requirements)

Jouni Korhonen <jouni.korhonen@broadcom.com> Wed, 08 March 2017 20:42 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 4B52A1294CC for <detnet-dp-dt@ietfa.amsl.com>; Wed, 8 Mar 2017 12:42:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-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 Xon0qCJVND-l for <detnet-dp-dt@ietfa.amsl.com>; Wed, 8 Mar 2017 12:42:30 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 22FB51295BA for <detnet-dp-dt@ietf.org>; Wed, 8 Mar 2017 12:42:30 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id t189so40728783wmt.1 for <detnet-dp-dt@ietf.org>; Wed, 08 Mar 2017 12:42:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=KCh2g5WbJJDUo1Uxq/6rzr8tRVHaacN6KuzdttDZOLk=; b=G/aCit0BOqryhXlTGHLKxhAzfNiylJFCsWMlBJFw1gaFwU4SCr0CXumQCxa3jQR6PY iXbRTtK/S3v25iU/EFgmMPITX3w2j0U2TmdHF+pz70X6OTWiDEuXiYWGFncm9Y6cQxJh gAKVceu8fKw22FmQbOYLq26B6CgDnzhjIzEIw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KCh2g5WbJJDUo1Uxq/6rzr8tRVHaacN6KuzdttDZOLk=; b=roSjo7brLiGtCRs+X0lp0GewIlN6qD4U+//QR/MIIwUYNOEkweqrgqyX4PRQCz7DYL 1UnsQvLbZfutgaj5LlPpbT6qt5hlSfaHpnCmiMtlaBMLuNZrWMDnERCyDZROEtaXHJ1F Bhsknpyyp/ETpj4K8E6Z3jfVefuTNADzw/t8h3p2RxOVIGIBlshPBAQthq2eqxB9MpiK A3wqll5TazD646CuIsEn61NwX57yYpXpA1cBo0JaLE4OilB72ADYt0pVta2nWgjtM5O3 xPX0PbjYMb89bhwQPD733LK9wJUBM7xRYVJ68f3qTW840Q1zMNPglv/oVldMcMPYR3XT z91A==
X-Gm-Message-State: AMke39lT04ut6JZeGtIPgFbgRvzfexWLzBli3p0AyQubV05+NDZ/oXRSor+ixg4mQoCKdZHq
X-Received: by 10.28.29.88 with SMTP id d85mr7111849wmd.56.1489005748029; Wed, 08 Mar 2017 12:42:28 -0800 (PST)
Received: from [192.168.88.100] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id 10sm5577591wrw.13.2017.03.08.12.42.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Mar 2017 12:42:27 -0800 (PST)
References: <DBXPR07MB12896F1424C82CF718C93FEAC2F0@DBXPR07MB128.eurprd07.prod.outlook.com> <8f3dd80e-794b-77a9-44dd-09e98d9eb64c@broadcom.com> <DBXPR07MB128916BC4D61D0C1A12BF08AC2E0@DBXPR07MB128.eurprd07.prod.outlook.com> <1ce7d64d-66b2-3888-e80d-b030304ab7c1@pi.nu> <722c6db1-f9bd-1982-0c53-093a8c332884@labn.net> <c80c66b2-e41a-7d73-25a6-f5a113793ee4@broadcom.com> <16f5a4ad-2b31-5f4c-a5f3-44fe8bf59a02@labn.net>
To: Lou Berger <lberger@labn.net>, Loa Andersson <loa@pi.nu>, detnet-dp-dt@ietf.org
From: Jouni Korhonen <jouni.korhonen@broadcom.com>
Message-ID: <a6916010-206f-7770-ce1d-f3a83d5243df@broadcom.com>
Date: Wed, 8 Mar 2017 12:42:24 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <16f5a4ad-2b31-5f4c-a5f3-44fe8bf59a02@labn.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/ltd4KOW8_wOBGoCO_9AEWBIMmP0>
Subject: Re: [Detnet-dp-dt] Section 4.1 added (DP solution requirements)
X-BeenThere: detnet-dp-dt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jouni.korhonen@broadcom.com
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, 08 Mar 2017 20:42:33 -0000

Hi,

DA-S-PE (like.. das PE ;)

- Jouni

3/8/2017, 12:20 PM, Lou Berger kirjoitti:
> Which option do you prefer?
>
>
> On 3/8/2017 3:18 PM, Jouni Korhonen wrote:
>> WFM.
>>
>> 3/8/2017, 5:56 AM, Lou Berger kirjoitti:
>>> On 3/8/2017 7:35 AM, Loa Andersson wrote:
>>>> Folks,
>>>>
>>>> One terminology question, I don't really have any opinion on what we
>>>> call things, but I'm definitely for that we only have one name for one
>>>> thing.
>>>>
>>>> Today we use T-PE and S-PE, but also T-DetNet-PE and S-DetNet-PE, can we
>>>> converge. My slight preference would be  T-DetNet-PE and S-DetNet-PE,
>>>> to differentiate it from "normal" S-PE and T-PE.
>>> The architecture defines this as:
>>>
>>>    DetNet intermediate node
>>>            A DetNet relay node or transit node.
>>>
>>> And some good examples are in the DP Alternatives draft
>>>
>>>   TSN              Edge          Transit        Relay        DetNet
>>>   End System       Node            Node         Node         End System
>>>
>>>   +---------+    +.........+                                 +---------+
>>>   |  Appl.  |<---:Svc Proxy:-- End to End Service ---------->|  Appl.  |
>>>   +---------+    +---------+                   +---------+   +---------+
>>>   |   TSN   |    |TSN| |Svc|<-- DetNet flow ---: Service :-->| Service |
>>>   +---------+    +---+ +---+    +---------+    +---------+   +---------+
>>>   |Transport|    |Trp| |Trp|    |Transport|    |Trp| |Trp|   |Transport|
>>>   +-------.-+    +-.-+ +-.-+    +--.----.-+    +-.-+ +-.-+   +---.-----+
>>>           :  Link  :    /  ,-----.  \   :  Link  :    /  ,-----.  \
>>>           +........+    +-[  Sub  ]-+   +........+    +-[  Sub  ]-+
>>>                           [Network]                     [Network]
>>>                            `-----'                       `-----'
>>>
>>>                  Figure 1: A Simple DetNet Enabled Network
>>>
>>>
>>>           DetNet                                           DetNet
>>>           Service         Transit          Transit        Service
>>>    DetNet   |          |<-Tunnel->|     |<-Tunnel->|         |    DetNet
>>>    End      |          V     1    V     V     2    V         |    End
>>>    System   |    +-----+          +-----+          +-----+   |    System
>>>    +---+    |    |S-PE1|==========|S-PE2|==========|S-PE3|   |    +---+
>>>    |  X....DFa.....X_.......DF1.......X_....DF3........X.....DFa...X  |
>>>    |CE1|=========|  \  |          |  /  |          |  /  |========|CE2|
>>>    |   |    |    |   \......DF2.....X_......DF4....../   |   |    |   |
>>>    +---+         |     |==========|     |==========|     |        +---+
>>>        ^         +-----+          +-----+          +-----+        ^
>>>        |        Relay Node       Relay Node       Relay Node      |
>>>        |                                                          |
>>>        |<------------- End to End DetNet Service ---------------->|
>>>
>>>                           Figure 5: Native DetNet
>>>
>>>
>>> So I think what you are asking for is a shorthand for a 'S-PE that is a
>>> DetNet (aware) Relay Node' , right?
>>> How about one or more of the following:
>>>     - DetNet S-PE
>>>     - DA-S-PE (DA=DetNet Aware)
>>>     - DC-S-PE (DA=DetNet Capable)
>>>     - DR-S-PE (DR=DetNet Relay)
>>>     - DRN-S-PE (DRN=DetNet Relay Node)
>>>
>>> Lou
>>>
>>>> /Loa
>>>>
>>>> On 2017-03-08 13:46, Balázs Varga A wrote:
>>>>> Hi Jouni,
>>>>>
>>>>> OK, I think my text may not be clear enough. Local-ID is not meant as a router id.
>>>>> " Each node (T-PE, S-PE and P) use a local-ID of the detnet-(compound)-flow in order to accomplish its role during transport."
>>>>> Local-ID refers to an ID used by a node to identify internally a DetNet-flow. Maybe "local-Flow-ID" would express it better.
>>>>> Such a "local-Flow-ID" value may or may not differ from the "Flow-ID" value encoded in the DetNet packet. If it is different
>>>>> we fallback to what You have called "virtual-label".
>>>>>
>>>>> I hope that clarifies your concerns.
>>>>>
>>>>> Cheers
>>>>> Bala'zs
>>>>>
>>>>> -----Original Message-----
>>>>> From: Jouni Korhonen [mailto:jouni.korhonen@broadcom.com]
>>>>> Sent: Tuesday, March 07, 2017 8:21 PM
>>>>> To: Balázs Varga A <balazs.a.varga@ericsson.com>
>>>>> Cc: detnet-dp-dt@ietf.org
>>>>> Subject: Re: [Detnet-dp-dt] Section 4.1 added (DP solution requirements)
>>>>>
>>>>> Thanks Balazs,
>>>>>
>>>>> I am not quite sure about the local-id text:
>>>>> "Local-ID MUST be unambiguously bounded to the Flow-ID encoded in the DetNet packet."
>>>>>
>>>>> By default each router has their unique router id with the autonomous system that you need e.g., with routing protocols.
>>>>>
>>>>> If the flow-id is unique within the detnet domain I am not sure what mapping the above is talking about. Do you mean that a set of flow-ids would belong to a router (identified by a local-id)?
>>>>>
>>>>> - Jouni
>>>>>
>>>>>
>>>>> 3/7/2017, 10:23 AM, Balázs Varga A kirjoitti:
>>>>>> Hi,
>>>>>> Section 4.1 added on the GitHub.
>>>>>> Cheers
>>>>>> Bala'zs
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jouni Korhonen [mailto:jouni.korhonen@broadcom.com]
>>>>>> Sent: Monday, March 06, 2017 7:23 PM
>>>>>> To: Balázs Varga A <balazs.a.varga@ericsson.com>om>; Loa Andersson
>>>>>> <loa@pi.nu>
>>>>>> Cc: cjbc@it.uc3m.es; detnet-dp-dt@ietf.org
>>>>>> Subject: Re: [Detnet-dp-dt] about identity labels.. was Re: new
>>>>>> versions of my slides
>>>>>>
>>>>>> Balazs,
>>>>>>
>>>>>> Your proposed Section 4.x would definitely be good to have. I am not too much for Section 4.y since I do not see it would not be needed in the final document, except for the definitions that should go to Section 2.
>>>>>>
>>>>>> Regarding the two choices we have now I just add prologue text and describe (graphically both). The logic of the "identity label/tag" is mostly the same independent of the location in the stack. The processing is of course different.
>>>>>>
>>>>>> - Jouni
>>>>>>
>>>>>> 3/6/2017, 9:49 AM, Balázs Varga A kirjoitti:
>>>>>>> Hi Jouni,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> just for clarification: Do we intend to list all options in the draft ???
>>>>>>>
>>>>>>> They all have pros and cons ...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Anyway I think we need a structure like below in the draft for
>>>>>>> example
>>>>>>>
>>>>>>> in section 4. Is it inline with your intention? Shall I prepare some
>>>>>>> text
>>>>>>>
>>>>>>> around this items for the call on Wednesday?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *4.x DP solution requirements*
>>>>>>>
>>>>>>> List of prerequisites for a proper solution on an x-PE:
>>>>>>>
>>>>>>> 1, to distinguish PWs going through (operation label-swap) and PWs
>>>>>>> need DetNet serving (e.g., FRER)
>>>>>>>
>>>>>>> 2, to handle PW-label collisions (without major implementation
>>>>>>> difficulties)
>>>>>>>
>>>>>>> 3, to work with both centralized control and distributed control
>>>>>>> (signaling)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *4.y DP solution toolset*
>>>>>>>
>>>>>>> Description of the toolset discussed so far:
>>>>>>>
>>>>>>> A, L-label: additional label between t-label and PW-label
>>>>>>>
>>>>>>> B, different PW-labels per segment: similar to the MS-PW label
>>>>>>> allocation mechanism
>>>>>>>
>>>>>>> C, e2e PW label: no change of the PW-label (same PW-label value
>>>>>>> between T-PE nodes)
>>>>>>>
>>>>>>> D, d-id label: additional label used as T-PE identification
>>>>>>>
>>>>>>> E, Flow-ID outside of the label stack
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Bala'zs
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Detnet-dp-dt [mailto:detnet-dp-dt-bounces@ietf.org] On Behalf
>>>>>>> Of Loa Andersson
>>>>>>> Sent: Monday, March 06, 2017 3:07 AM
>>>>>>> To: Jouni Korhonen <jouni.korhonen@broadcom.com>
>>>>>>> Cc: cjbc@it.uc3m.es; detnet-dp-dt@ietf.org
>>>>>>> Subject: Re: [Detnet-dp-dt] about identity labels.. was Re: new
>>>>>>> versions of my slides
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jouni,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2017-03-06 07:36, Jouni Korhonen wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>>> - global as the special purpose labels, seems unlikely
>>>>>>>>> - global as unique with in the domain, though we know there is a
>>>>>>>>> scaling  problem
>>>>>>>>> - global for one sender, not that different from d-id, other that
>>>>>>>>> the
>>>>>>>>> placment in the stack
>>>>>>>>> ???
>>>>>>>> In my small mind I reasoned it to be unique within one domain. Since
>>>>>>> the identity would now be 32 bits (there is no need to restrict it to
>>>>>>> 20 bits since it is part of the _encapsulation_header_ not the label
>>>>>>> stack), the scaling concern is more relaxed. Assuming each node in
>>>>>>> the domain would like to be able to name 4k unique detnet flows of
>>>>>>> their own then the domain could host 1M such detnet nodes.. not too
>>>>>>> bad for one domain.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My earlier calculations estimated that we would have about the number
>>>>>>> of PWs between any pair of T-DetNet-PEs would be about 400 and the
>>>>>>> number T-DetNet-PEs about 1000.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 32 bits is  4 000 millions, so there is ample number of flow id's
>>>>>>> even if we would have to configure a range on each T-DetNet-PE.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> So you look at the flow-id and then compare the CW/Seq #, right?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Now, range configuration is a kludge, can we find a way to avoid it,
>>>>>>> maybe d-pw + node-id would work, all this would have to happen in the
>>>>>>> context of the (outgoing) d-pw anyway, right?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> /Loa
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> - Jouni
>>>>>>>>> /Loa
>>>>>>>>>> Carlos
>>>>>>>>>>> - Jouni
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>> --
>>>>>>>>> Loa Andersson                        email: loa@mail01.huawei.com
>>>>>>> <mailto:loa@mail01.huawei.com>
>>>>>>>
>>>>>>>>> Senior MPLS Expert                          loa@pi.nu <mailto:loa@pi.nu>
>>>>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Loa Andersson                        email: loa@mail01.huawei.com
>>>>>>> <mailto:loa@mail01.huawei.com>
>>>>>>>
>>>>>>> Senior MPLS Expert                          loa@pi.nu <mailto:loa@pi.nu>
>>>>>>>
>>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>> 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
>>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>>>>
>>> _______________________________________________
>>> Detnet-dp-dt mailing list
>>> Detnet-dp-dt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>>
>