Re: [Detnet-dp-dt] Providing unique Flow-ID

Jiangyuanlong <jiangyuanlong@huawei.com> Mon, 27 February 2017 09:00 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 21915129736 for <detnet-dp-dt@ietfa.amsl.com>; Mon, 27 Feb 2017 01:00:58 -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 AVSlDm4TwYdR for <detnet-dp-dt@ietfa.amsl.com>; Mon, 27 Feb 2017 01:00:56 -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 1BBB4128824 for <detnet-dp-dt@ietf.org>; Mon, 27 Feb 2017 01:00:54 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBT85801; Mon, 27 Feb 2017 09:00:53 +0000 (GMT)
Received: from SZXEMA417-HUB.china.huawei.com (10.82.72.34) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 27 Feb 2017 09:00:51 +0000
Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.67]) by SZXEMA417-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0235.001; Mon, 27 Feb 2017 17:00:42 +0800
From: Jiangyuanlong <jiangyuanlong@huawei.com>
To: Loa Andersson <loa@pi.nu>, "detnet-dp-dt@ietf.org" <detnet-dp-dt@ietf.org>
Thread-Topic: [Detnet-dp-dt] Providing unique Flow-ID
Thread-Index: AdKMZFXKT27zr+XoRKu9EVWhNIEjHP//xbqA//8ak4CAAUjcgP//dMxwgACzRYCAALjGgIAHRp6A//9rEWA=
Date: Mon, 27 Feb 2017 09:00:42 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBAB1552F@szxema506-mbs.china.huawei.com>
References: <DBXPR07MB12832861ED58D86FD3D0A09AC510@DBXPR07MB128.eurprd07.prod.outlook.com> <F278A381-1E43-4607-8015-5CFDE871D382@broadcom.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBAB14184@szxema506-mbs.china.huawei.com> <1545D020-5B94-486A-A381-413E7605AB08@broadcom.com> <3B0A1BED22CAD649A1B3E97BE5DDD68BBAB141A8@szxema506-mbs.china.huawei.com> <27a14039-28b2-dd2a-cbe2-226ac82a3698@pi.nu> <D62EF794-53F1-4591-952E-98C4095B51C8@broadcom.com> <828da811-a6cf-4a5c-f644-0dfd3990cf61@pi.nu>
In-Reply-To: <828da811-a6cf-4a5c-f644-0dfd3990cf61@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.0A020202.58B3EAC5.015A, 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: 42557231cf04cf307a6de664a85e879e
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/woNK7mmciqjyiI2Mch9Be9gnSS8>
Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID
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: Mon, 27 Feb 2017 09:00:58 -0000

Hi Loa,
How about just using a single T-Label? We can use it to stand for an LSP or whatever LSP hierarchy.
It can be bandwidth reserved, or PHP enabled.
B.R.,
Yuanlong

-----Original Message-----
From: Detnet-dp-dt [mailto:detnet-dp-dt-bounces@ietf.org] On Behalf Of Loa Andersson
Sent: Monday, February 27, 2017 4:01 PM
To: detnet-dp-dt@ietf.org
Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID

Jouni,

Sorry for late response.

The terminology around T-Labels and L-labels are a bit ambivalent.

Basically T-Labels and L-Labels are labels in the same label stack, only that the T-label is on the top of the stack. Normally T-labels are just for transportation, i.e. no BW allocated.

/Loa

On 2017-02-23 00:54, Jouni Korhonen wrote:
> Thanks Loa for listing these and specifically pointing out that L-label level can be a stack itself. I was myself assuming that the T-label-level could be a label stack as well.
>
> I would exclude d-id for now because we really have not had any discussion around it yet. I, for example, am not sure whether it is actually present on wire or not.
>
> - Jouni
>
> --
> Jouni Korhonen, Broadcom Ltd.
> M: +1-408-391-7160
>
>> On Feb 21, 2017, at 9:53 PM, Loa Andersson <loa@pi.nu> wrote:
>>
>> Yuanlong,
>>
>> Since this is on the table I think we should review the naming.
>>
>> For labels we currently have
>>
>> T-lable (Tunnel Label), i.e. the outermost label that is PHP'ed by 
>> the pen-ultimate node before reaching one of the x-PEs.
>>
>> L-label (or L-level-label, since it can be a stack in its own right, 
>> the lavle that takes you between the x-PE's and conserving what node 
>> the packet came from.
>>
>> d-pw label, the label that is preserved end to end
>>
>> d-id (DetNet node ID), label that is used to disambiguate between 
>> flows when the control plane has allocated the same d-pw label beween 
>> two different pair of ingress and egress T-detnet-PE
>>
>> Apart from that we have  some other terms (which I btw think should 
>> be changed)
>>
>> T-detnet-PE, the ingress and egress nodes for a detnet flow.
>> - A node that is ingress relative to a flow does replication.
>> - A node that is egress relative to a flow does elimination.
>>
>> S-detnet-PE, the node on the wire that does both replication and 
>> elimnination.
>>
>> /Loa
>>
>> On 2017-02-22 11:50, Jiangyuanlong wrote:
>>> Is I-label just the DetNet Id label named by Loa?
>>>
>>> -----Original Message-----
>>> From: Jouni Korhonen [mailto:jouni.korhonen@broadcom.com]
>>> Sent: Wednesday, February 22, 2017 11:30 AM
>>> To: Jiangyuanlong
>>> Cc: Balázs Varga A; detnet-dp-dt@ietf.org
>>> Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID
>>>
>>> Hi,
>>>
>>> We refer to the naming found in slides we used & shared in past two or so calls.
>>>
>>> - Jouni
>>>
>>> --
>>> Jouni Korhonen, Broadcom Ltd.
>>> M: +1-408-391-7160
>>>
>>>> On Feb 21, 2017, at 7:27 PM, Jiangyuanlong <jiangyuanlong@huawei.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> What is I-label and what is L-label? Are they in the same label 
>>>> stack as the d-pw label? It will help us to be aligned to the same picture;) In the past, we have PW label and LSP label (maybe multiple LSP labels in hierarchy) for a service.
>>>>
>>>> Thanks,
>>>> Yuanlong
>>>> -----Original Message-----
>>>> From: Detnet-dp-dt [mailto:detnet-dp-dt-bounces@ietf.org] On Behalf 
>>>> Of Jouni Korhonen
>>>> Sent: Wednesday, February 22, 2017 5:34 AM
>>>> To: Balázs Varga A
>>>> Cc: detnet-dp-dt@ietf.org
>>>> Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID
>>>>
>>>> Hi,
>>>>
>>>> I have few comments inline.
>>>>
>>>>
>>>> --
>>>> Jouni Korhonen, Broadcom Ltd.
>>>> M: +1-408-391-7160
>>>>
>>>>> On Feb 21, 2017, at 9:05 AM, Balázs Varga A <balazs.a.varga@ericsson.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> question to be answered:
>>>>> - how to ensure that detnet flows can be unique recognized during transport?
>>>>>
>>>>> Labels used by DetNet flows so far in our discussions:
>>>>> - d-pw: DetNet flow specific
>>>>> - l-label: FRER specific label to identify replica (member) flows
>>>>> - t-label: transport label (FEC of T-PE or S-PE nodes)
>>>>> Note: Text below assumes an l-label present, what may not be always the case.
>>>>
>>>> To my understanding the l-labels “connect” x-PE nodes i.e. create the desired overlay topology over all LSRs/PEs. L-labels also identify which packets will receive FRER processing and which not i.e., whether a specific PW gets terminated in an x-PE or whether x-PE just acts as a transit.
>>>>
>>>>
>>>>> Before discussing uniqueness/allocation/usage of these labels 
>>>>> let's list the scenarios requiring flow identification during transport. They can be separated in two groups:
>>>>> 1, DetNet function related scenarios:
>>>>> - congestion protection: usage of allocated resources (queuing, policing, shaping).
>>>>> - explicit routes: select/apply the flow specific path.
>>>>> - service protection: recognize compound / member flows for 
>>>>> replication an elimination.
>>>>>
>>>>> 2, OAM function related scenarios:
>>>>> - troubleshooting (e.g., identify misbehaving flows, etc.)
>>>>> - recognize flow(s) for analytics (e.g, increase counters, etc.)
>>>>> - correlate events with flows (e.g., volume above threshold, etc.)
>>>>> - others ...
>>>>>
>>>>> We can distinguish 3 node types:
>>>>> - T-PE: d-pw starts/terminates here
>>>>> - S-PE: place of detnet specific function (e.g., FRER)
>>>>> - P: intermediate node (transport only functions)
>>>>>
>>>>> T-PE and S-PE nodes are fully aware of both the DetNet service and transport layers.
>>>>> In case of PHP, they receive only "d-pw + l-label", so the x-PE 
>>>>> node should recognize the DetNet flow based on these labels. 
>>>>> DetNet specific functions are driven by the "d-pw label" and "l-label" pair.
>>>>> The "d-pw"+"l-label" pairs have to be locally unique on the x-PE.
>>>>
>>>> I have an issue what “pair” means here. L-labels should only have simple rules and actions like pop, label swap, etc:
>>>>
>>>> In the context of DetNet and L-labels, popping it would expose the d-pw label to the system, which would then do PW (+FRER) thing based on the top d-pw label. Label swap for L-label would allow making desired x-PW nodes to behave as transit nodes in the DetNet context.
>>>>
>>>> Combining L-label into DetNet specific processing is IMHO a bad decision. Even if the hardware could be able to look up multiple labels in parallel, the next hop and action decisions would still be per label, not as a single result. Keeping this in mind, the system would also work as such when L-labels are not present i.e., the x-PE just receives a packet with d-pw label or T-label+d-pw label.. the assumption here is that the configuration at this point is such there is no ambiguity..
>>>>
>>>>> The problematic points are the intermediate "P" nodes. Their 
>>>>> detnet role is limited to ensure congestion protection from the 
>>>>> above listed DetNet functions. Additionally OAM functions are also nice to have at each hop (as usual).
>>>>>
>>>>> We have two options for P nodes:
>>>>> - Option-A, P node can recognize only "t-label" and cannot 
>>>>> consider the whole label stack for flow recognition. This is the 
>>>>> scenario, where we have pre-established tunnels over the network, 
>>>>> where the DetNet flows are mapped to appropriate tunnels to be 
>>>>> transported over the network. This can be treated as a form of 
>>>>> aggregation as many DetNet flows may use the same tunnel. Of course with this aggregation we lost per flow identification, that is the price for scalability.
>>>>> - Option-B, P-nodes can consider the whole label stack and they 
>>>>> can identify each individual flow. That represents additional 
>>>>> requirement on P nodes, which may not be acceptable in some network scenarios.
>>>>>
>>>>> So, what labels should be unique and how should we allocate labels?
>>>>> - d-pw: allocated by egress PE node. Label value is unique on that particular PE node.
>>>>> Other PE nodes may allocate the same label value for a different detnet flow.
>>>>> - l-label: allocated by the S-PE node. Label value is unique on 
>>>>> that particular S-PE node.
>>>>
>>>> How would the L-label assignment work in our A,B,C,D x-PE example? B would do downstream assignment to A and upstream assignment to D?
>>>>
>>>>> - t-label: allocated by P node. Refer to the tunnel endpoint node
>>>>> (FEC) and the tunnel-ID. Value locally unique on the P node.
>>>>>
>>>>> Such an allocation scheme ensure that all nodes in the network are 
>>>>> able to identify uniquely the DetNet flows (or aggregate flows) 
>>>>> and support the above listed
>>>>> functions:
>>>>> - T-PE (egress): DetNet flow(s) identified based on the "d-pw" value.
>>>>> - S-PE: DetNet flow(s) identified based on the “l-label" value
>>>>
>>>> How do you do the flow to seqnum pairing? It does not make sense to map multiple L-labels to a single seqnum counter & duplicate elimination function. A solution like this would need us to introduce kind of master and slave label relationships, or virtual labels that L-labels point at.
>>>>
>>>>> - P-node (option-A): aggregated DetNet flow(s) identified based on the "t-label"
>>>>> - P-node (option-B): DetNet flow(s) identified based on the 
>>>>> "l-label
>>>>> + t-label" (no need to look for the “d-pw" label, unless “l-label” 
>>>>> + is
>>>>> not present)
>>>>>
>>>>> Note, that as shown above globally unique “d-pw" labels are optional!
>>>>
>>>> I realize that detnet domain wide global d-pw labels are a pain in a neck. It would, for example, required each ingress T-detnet-PE to have their own d-pw label ranges they assign labels to detnet flows (assuming upstream label assignment). However, I still think global d-pw labels are cleaner from the forwarding point of view.
>>>>
>>>>>
>>>>> Good night and see You tomorrow early morning Bala'zs
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>> _______________________________________________
>>>> 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
>>>
>>
>> --
>>
>>
>> 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
>
> _______________________________________________
> 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