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

[Jouni Korhonen <[e-mail]>]

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