Subject: RE: could we agree on this ? Fwd: RE: TE Requirements Draft - ELS P

From: "Roberto Mameli (ERI)" <[email-masked]>
Date: Mon, 3 Dec 2001 15:00:45 +0100

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 03 Dec 2001 15:58:48 +0100

Roberto,
Thanks a lot for your response.
I will differ the discussion on 2b) for now as I'd like to see if others 
can also agree on 1) , 3) and 2a).
Cheers
Francois

At 15:00 03/12/2001 +0100, Roberto Mameli (ERI) wrote:
>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.
>
>
>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.
>
>
>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):
>
>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

---

From: Shahram Davari <[email-masked]>
Date: Mon, 3 Dec 2001 08:37:38 -0800

Francois,

I think i,ii, iii(a), iv should be supported. No need to support iii(b), unless there is real demand.

Yours,
_Shahram 

> -----Original Message-----
> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Monday, December 03, 2001 9:14 AM
> To: Nabil Seddigh
> Cc: Francois Le Faucheur; Shahram Davari; [email-masked]
> Subject: Re: could we agree on this ? Fwd: RE: TE Requirements Draft -
> ELSP
> 
> 
> Nabil and all,
> 
> >In this regard, I would suggest that your options are actually:
> >
> >   i) Using E-LSPs with traffic from a single OA
> >  ii) Using E-LSPs with traffic from multiple OAs with single BW
> >  iii) Using E-LSPs with traffic from multiple OAs with multiple BW
> >   iv) Using L-LSP
> >
> >There seems to be prior agreement that options (i) and (iv) are
> >required.
> 
> So let's record that we can agree on the proposal to update 
> REQTS draft to 
> allow support for (i), unless we hear other views.
> (iv) is already there.
> 
> >The open questions seem to be whether or not (ii)
> 
> We need to be more specific on (ii). I believe we have 
> established that:
>          - (ii) can be supported without any protocol 
> extensions. Whether 
> we put it in the REQTS document or not, it will not affect the DSTE 
> protocol extensions and it can be implemented in a head-end 
> LSR. As I said 
> earlier, it comes for free from a "protocol" viewpoint
>          - a valid scenario has been described that would 
> make use of (ii).
> Excluding it would be a useless restrictions. Would it not?
> Can you agree to the proposal of updating REQTS to allow 
> support of (ii).
> 
> 
> >and (iii) are required.
> 
> Your breakdown misses part of the discussion we've had which 
> is precisely 
> while I splitted that case earlier. Bandwidth is just one of 
> the Traffic 
> Trunk attributes. Based on the thread I think it is useful to 
> split (iii) into:
>          (iiia) Using E-LSPs with traffic from multiple OAs 
> with multiple 
> BW and single value for all other attributes (preemption, CT, 
> affinity...)
>          (iiib) Using E-LSPs with traffic from multiple OAs 
> with multiple 
> BW and multiple values for all other attributes (preemption, CT,...)
> 
> Those two cases do require different protocol extensions (eg signal 
> multiple preemtion/CT/affinity).
> 
> I thought we may be able to agree on (iiib). For example , I 
> understand 
> that while Sharham felt (iiia) should be added he agreed 
> (iiib) should not.
> So again, leaving aside (iiia) for now, can you agree that 
> (iiib) shoudl 
> not specifically be added to REQTS draft for now until SPs 
> have expressed 
> the requirement for it?
> 
> Cheers
> 
> Francois
> 
> >Kind Regards
> >Nabil
> 
>