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

[Jouni Korhonen <[e-mail]>]

Carlos,


Many pops here..

>>>  
>>> 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..
> 
> I share Jouni's view on this. One clarifying question (for Jouni): you
> mean here the action decision would still be per __d-pw__ label, right?

Yes.. if I understood you question correctly.

- JOuni


> 
>> 
>>> 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.
> 
> Wouldn't this (Option-B) make P nodes "DetNet service aware"?
> 
>>>  
>>> 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.
> 
> I agree.
> 
> Carlos
> 
>> 
>>>  
>>> 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