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

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



Francois,

I am not sure where the requirement for (iii b) came from.
It is been always (iii a). Definitely (iii b) should be out.

-Sudhakar

> -----Original Message-----
> From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
> Behalf Of Francois Le Faucheur
> Sent: Monday, December 03, 2001 9:14 AM
> To: Nabil Seddigh
> Cc: Francois Le Faucheur; Shahram_Davari@pmc-sierra.com;
> te-wg@ops.ietf.org
> 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
>
>
>