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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi,

A couple of small comments/questions inline below.

On Tue, 2017-02-21 at 13:34 -0800, Jouni Korhonen wrote:
> Hi,
> 
> I have few comments inline.
> 
> 
> --
> Jouni Korhonen, Broadcom Ltd.
> M: [phone]
> 
> > On Feb 21, 2017, at 9:05 AM, Balázs Varga A <balazs.a.varga@ericsso
> > n.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..

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?

> 
> > 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