RE: TE Requirements Draft - ELSP

["Giovanna Piantanida (ERI)" <Giovanna.Piantanida@eri.ericsson.se>]

Hi Francois,


>Great. So I guess you would then agree we should first get SPs to express 
>the need for something before including it in the requirements document and 
>specifying the correponding extensions.

not only I agree, but also I notice that you come exactly to the point ( to my point at
least) originating this discussion. 
What I think I was misled about , and beg for clarification, is , in fact, not purpose and motivation for E-LSP
themselves , but for extension of a 
DIFFSERV object for an E-LSP (Ref. section 5.2.1 of draft-ietf-mpls-diff-ext-09), even if
only optional, in the framework we all agree about. 


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

A SP using DIFFSERV object would need LSRs to pick up queues based on (EXP , label)
couples, and this cancels, in my opinion, advantages of this first point.

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

At first sight, and here is probably where I am missing something, I would
have said that having a dynamic establishment of EXP <-> PHB mapping could
complicate things in this case also.

this is why i was induced to think that reason for having DIFFSERV object 
in current extensions was that somebody exists who really wants to follow point #3

>3) using E-LSPs with traffic from multiple OAs each with their own SPF
>======================================================================
>In that case, EF and AF1 may be transported on a single E-LSP and would 
>each have their own CSPF (ie own bandwidth, and being constrained by 
>different bandwidth constraints, and then presumably with different 
>restoration requirements, most probably different preemption priorities,...).

and assuming  therefore as hypothesis, not as consequence, that such SPs exists,
per-OA signaling of bandwidth in E-LSP could be aimed to them, and this is why
it could be worth considering solutions for that,

regards,
giovanna