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

[Jouni Korhonen <[e-mail]>]

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: [phone]

> On Feb 21, 2017, at 9:53 PM, Loa Andersson <[e-mail]> 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:[e-mail]]
>> Sent: Wednesday, February 22, 2017 11:30 AM
>> To: Jiangyuanlong
>> Cc: Balázs Varga A; [e-mail]
>> 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: [phone]
>> 
>>> On Feb 21, 2017, at 7:27 PM, Jiangyuanlong <[e-mail]> 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:[e-mail]] On Behalf Of
>>> Jouni Korhonen
>>> Sent: Wednesday, February 22, 2017 5:34 AM
>>> To: Balázs Varga A
>>> Cc: [e-mail]
>>> Subject: Re: [Detnet-dp-dt] Providing unique Flow-ID
>>> 
>>> Hi,
>>> 
>>> I have few comments inline.
>>> 
>>> 
>>> --
>>> Jouni Korhonen, Broadcom Ltd.
>>> M: [phone]
>>> 
>>>> On Feb 21, 2017, at 9:05 AM, Balázs Varga A <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>> 
>>> _______________________________________________
>>> Detnet-dp-dt mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>>> _______________________________________________
>>> Detnet-dp-dt mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>> 
>> _______________________________________________
>> Detnet-dp-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>> 
> 
> -- 
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt