RE: TE Requirements Draft - ELSP

["Roberto Mameli (ERI)" <Roberto.Mameli@eri.ericsson.se>]

Hi Francois,

your analysis helps me in explaining my concerns. I try to summarize, please see my comments in line.

> 1) using E-LSPs with traffic from a single OA:
> ==============================================
> This is already explicitely allowed in the recently posted 
> REQTS draft.
> As pointed out already, one application for this to allow 
> LSRs to pick 
> queues based on EXP rather than Label.
> I think everyone agrees this is all fine.


I completely agree.


> 2) using E-LSPs with traffic from multiple OAs but using single CSPF
> =====================================================================
> Jim Boyle provided a convincing example of how this could be 
> used in his 19 
> Sept message (ie in the case where ratio between voice-sig and 
> voice-payload is known and stable so both traffic can be 
> treated together 
> as a whole from CSPF viewpoint).
> The important point is that although we have traffic from 
> multiple OAs, 
> those are really treated as a single "traffic trunk" from the 
> DSTE perspective.
> However, this is currently not allowed in the recently posted 
> REQTS draft.
> I agree that REQTS draft should be modified to allow this 
> case. 


I agree up to this point.


> This does 
> not create any significant changes to the current DS-TE model 
> and does not 
> entail any protocol extensions (ie it comes for free), so it 
> would indeed 
> be an artificial unnecessary restriction to rule it out.
> 

I do not agree on the last observation, but maybe there is something that I'm missing.
Referring to Jim's example (where ratio between voice-sig and voice-payload is known and stable so both traffic can be treated together as a whole from CSPF viewpoint) my concern is the following. I understand that the ratio voice-sig/voice-payload is known, but I guess that it is known only to the user originating these flows. Since there is no way to signal this ratio to network elements I guess that those elements don't know the exact proportion of the two types of traffic carried within the E-LSP.

Here comes up my question: do network elements along the path need to know this ratio of traffic? I think they do, and this is what the protocol doesn't allow at the moment. But maybe this is not an issue and I have just misunderstood the problem. In that case, I guess that all the issues related to the allocation of intra-LSP resources are up to the LSP ingress. So again, I don't see a great difference with the standard DiffServ model, and this is the reason that leads me to the conclusion that probably this is not what is commonly known as "aggregate TE".


> 3) using E-LSPs with traffic from multiple OAs each with their own SPF
> ======================================================================

I completely agree with you that this is a departure from the current model. In fact I haven't ever considered a scenario like this. This is not what I am proposing. If you need different CSPF, different bandwidth constraints, different restoration requirements, different preemption priorities, etc. you're not really doing aggregate TE. Just set up different LSP and the whole thing will become simple. We don't need complex extension to include this scenario, I perfectly agree. The real point was the one stated above.

Hope it helps

Best regards
Roberto