[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TE Requirements Draft - ELSP
Roberto,
At 10:49 22/11/2001 +0100, Roberto Mameli (ERI) wrote:
>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.
super.
> > 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.
super.
> > 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.
I agree they do have to know the "ratio".
But they don't have to be told via signaling. They are effectively told
through the Diff-Serv config anyway. In Jim's example, the SP just has to
configure the voice-sig queue 4 times smaller than the voice-payload queue.
>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.
Super.
>Hope it helps
Certainly does. My perception is that we now have the same view on what we
should handle each of the 3 cases above (ie keep -1- in Reqts draft; add
-2- to Reqts draft; don't include -3- in Reqts draft until we have explicit
requirements from SPs). Is that right?
Thanks
Francois
>Best regards
>Roberto
_________________________________________________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone: +33 4 97 23 26 19
Mobile : +33 6 89 108 159
Fax: +33 4 97 23 26 26
Email: flefauch@cisco.com
_________________________________________________________
Cisco Systems
Domaine Green Side
400, Avenue de Roumanille
06 410 Biot - Sophia Antipolis
FRANCE
_________________________________________________________