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

Jiangyuanlong <jiangyuanlong@huawei.com> Mon, 27 February 2017 12:05 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 BFE77129C49 for <detnet-dp-dt@ietfa.amsl.com>; Mon, 27 Feb 2017 04:05:22 -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 3uKdErpR8J4P for <detnet-dp-dt@ietfa.amsl.com>; Mon, 27 Feb 2017 04:05:19 -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 E5AB61294C0 for <detnet-dp-dt@ietf.org>; Mon, 27 Feb 2017 04:05:18 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBU16742; Mon, 27 Feb 2017 12:05:15 +0000 (GMT)
Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 27 Feb 2017 12:05:07 +0000
Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.67]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Mon, 27 Feb 2017 20:04:51 +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//9rEWAAGSUDgP//cS5A
Date: Mon, 27 Feb 2017 12:04:50 +0000
Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68BBAB155D8@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> <3B0A1BED22CAD649A1B3E97BE5DDD68BBAB1552F@szxema506-mbs.china.huawei.com> <bb87c595-ae66-9b67-0f9e-4c98ad9ba983@pi.nu>
In-Reply-To: <bb87c595-ae66-9b67-0f9e-4c98ad9ba983@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.0A090201.58B415FC.00E8, 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/ZOweQ-KXU0Y6tr445S7B_Vgo5-Q>
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 12:05:22 -0000

Loa, 

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

Yuanlong,

On 2017-02-27 17:00, Jiangyuanlong wrote:
> 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.

Exactly what do you gain by first saying 1 single label, and then saying that it can stands for hierarchy?
[YJ] Sorry that I was totally influenced by the PW and MS-PW architecture (RFC 3985 and RFC 5659), where the LSP is called PSN tunnel.
[YJ] But my point is, all the approaches in discussion will have a PSN tunnel between T-PE and S-PE, there is no difference in this respect.


What I think we need to show is that each node has the information needed to take the right decision in all cases.

One case is intresting to look at, and where I hav not made up my mind.
With a label stack T/d-pw/d-id might work. You need to use the T-label as the BW container. And the d-pw label need to carry information whether it is "swapped only" or "eliminated/replicated", but the gain is very small and if routing is changing there is no guarantee that all PWs actually pass throug the correct nodes if there is more links in the mesh than we show in the pictures.
[YJ] Dynamic paths will have great impact on the sequence number, static paths make more sense if any FRER operation is needed. 
Cheers,
Yuanlong

/Loa

> 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