[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: could we agree on this ? Fwd: RE: TE Requirements Draft - ELSP



Hi Francois,

thank you for your analysis of the thread. I agree with you about the need to break option 2 in two cases, since the two sub-options are actually a bit different. Please see my comments inline.


> 1) using E-LSPs with traffic from a single OA:
> ==============================================
> So I consider this one closed. Agreed?

I perfectly agree.


> 3) using E-LSPs with traffic from multiple OAs each with their own SPF
> ======================================================================
> Can we agree 
> to keep this out of REQTS draft?

Again, I perfectly agree. This option is actually very complicated and raises a lot of non trivial issues. Moreover we are not able to envision scenarios in which a SP could benefit of it, so it is better avoiding unnecessary complexity.


> 2a) using E-LSPs with traffic from multiple OAs but using 
> single CSPF and 
> SINGLE bandwidth
> ==============================================================
> I proposed to allow support for this in the REQTS draft.

Again, I agree. This can be supported by DSTE without any change to the current model.


> 2b) using E-LSPs with traffic from multiple OAs but using 
> single CSPF and 
> MULTIPLE bandwidth
> ==============================================================

This is the only scenario that is currently missing. In my opinion this is a form of aggregate TE, rather than fine per-class TE. In fact, quoting the MPLS-DIFF draft (appendix A.3):

   A Service Provider running 8 (or fewer) BAs over MPLS, performing
   aggregate Traffic Engineering (i.e. performing a single common path
   selection for all BAs), using aggregate MPLS protection   (i.e.
   restoring service to all PSCs jointly)........

Based on the previous lines, one could guess that aggregate TE simply
means common path selection (independently from any other factor, e.g. the relative proportion of traffic across classes). I think that scenario 2b) should be considered. In fact there are some, let's say, "border situations", in which a SP could be interested in some form of TE capabilities, without the need of per-class TE. An example is given by VPN (see Neil's scenario). Moreover I think that it requires some minor protocol extensions (i.e. the possibility to signal per-OA bw requirements).

Best regards
Roberto