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

Lou Berger <lberger@labn.net> Wed, 08 March 2017 20:20 UTC

Return-Path: <lberger@labn.net>
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 EC3251295BE for <detnet-dp-dt@ietfa.amsl.com>; Wed, 8 Mar 2017 12:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 60vL3-bQg4vH for <detnet-dp-dt@ietfa.amsl.com>; Wed, 8 Mar 2017 12:20:47 -0800 (PST)
Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AEE1294B4 for <detnet-dp-dt@ietf.org>; Wed, 8 Mar 2017 12:20:47 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 0B31E1E0F16 for <detnet-dp-dt@ietf.org>; Wed, 8 Mar 2017 13:20:46 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id tYLY1u00i2SSUrH01YLboe; Wed, 08 Mar 2017 13:20:36 -0700
X-Authority-Analysis: v=2.1 cv=Ath9goNP c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=Q-fNiiVtAAAA:8 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=nEGFVyNSgiA9DZulqJEA:9 a=bmYVnTvKLHA0IE6C:21 a=xB5Q94IgFaktReWS:21 a=pILNOxqGKmIA:10 a=Fp8MccfUoT0GBdDC_Lng:22 a=l1rpMCqCXRGZwUSuRcM3:22 a=w1C3t2QeGrPiZgrLijVG:22 a=02toJ7V-nxh73JlV0Smw:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jrcC1IVbwCubtF5Eyu7d0Zhm5lSOzxZWGunZ/gPK/hI=; b=hMXa/9oL+qqisk9zrzOGCI1j+3 yajbpkwWo1VcE0hksmdns4ISbe7LKFd5u8fw+MfdnXfAk/Xqbm5o7OPM1qlGGwyrQN4jwDe11JSFO hg+AuC0KZPrFX+5pEwVJHEJEZ;
Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:58558 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1cli4W-0004tg-Fm; Wed, 08 Mar 2017 13:20:32 -0700
To: jouni.korhonen@broadcom.com, Loa Andersson <loa@pi.nu>, detnet-dp-dt@ietf.org
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>
From: Lou Berger <lberger@labn.net>
Message-ID: <16f5a4ad-2b31-5f4c-a5f3-44fe8bf59a02@labn.net>
Date: Wed, 8 Mar 2017 15:20:30 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <c80c66b2-e41a-7d73-25a6-f5a113793ee4@broadcom.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.85.191
X-Exim-ID: 1cli4W-0004tg-Fm
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:58558
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/eRV-xOepFOE3N7ClPmcNDiWqfMA>
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
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:20:50 -0000

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
>>