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

RE: Progressing BC Models was RE: Progressing MAR

Hi Jerry,

I'll just comment on the last aspect for now. See in line,

At 15:56 14/03/2003 -0600, Ash, Gerald R (Jerry), ALABS wrote:
Francois,

Francois>>>
>>> I believe the conclusion of our long discussion on BC Model was that we
>>> agreed to specify RDM and MAM and to investigate further other models
>>> including MAR.

Jerry>>
>> I don't see that conclusion written down anywhere. In
>> Atlanta, the WG debated 1 default versus 2 default models,
>> and no conclusion was reached. As to what to specify in the
>> way of BC models, that's the discussion we're having now on
>> all 3 models, so no conclusion is yet reached.

Francois>
> Looking at the Atlanta minutes:
>
> "[Francois] Propose to document not only one model but rather to document
> two models. Propose that these two documented models be RDM and MAM.
> ...
> Jerry recommended that the MA model be the default BC model and
> that the RD model be an optional BC model (should be used only
> when preemption is also used).
> Jerry also recommended that we
> continue to study possible extensions to MA, such as MAR, to
> improve performance.
> ...
> [Waisum]: Draft is a comparison of MAM and RDM... Proposes to have MAM
> as default model."
>
> So my reading of this is that at least back then, while we disagreed on
> which should be default vs optional, we actually all agreed on (i)
> specifying both MAM and RDM and (ii) further investigating MAR. My
> impression was that the group also agreed with this (or at the very
> least no one raised any issue with this).

These were the statements of 3 people in the Atlanta TEWG meeting, not a 'conclusion' of the WG. As you very well know, the 3 of us agreed before the meeting to recommend that *both* MAM and RDM be default models. The reason we agreed to that was that we could not accept RDM as the *single* default BC model. This is because it performed poorly unless preemption is used, and many SPs don't use preemption (including AT&T). If both MAM and RDM were required, we thought could be a compromise, then a SP could opt to use MAM, since it would be required to implement with DSTE.

However, the TEWG didn't agree to that recommendation (this is clear in the minutes). Instead the issue went back to the list for discussion, and we've now agreed to your suggestion to have *no* default BC models.

Furthermore, given the agreement to have *no* required models, it makes it essential that all BC models meet all the BC model requirements. SPs would not want to be put in the position where their vendors only implement RDM (and not MAM), which has unacceptable performance unless preemption is used. Recall that under the present agreement, no BC models are required, it is a vendor's choice which to implement.

Therefore RDM and all other BC models must meet the requirement to 'perform well with or without preemption', as well as all the other BC model requirements.

> It sounds like one good objective for our SFO meeting would be to
> establish/document such agreement on :
> - which BC Model we should specify right away, and
> - (coming back to Dimitry's question) which goes as
> Standards/Experimental/Informational

Agreed.

> My proposal will be:
> - progress RDM right away in Standard Track

Disagree with that, until further extensions/protections are proposed for RDM to protect against poor performance when preemption is not used.

> - progress MAM right away in Standards Track

Agreed.

> - keep investigating MAM extensions like MAR, and based on
> upcoming conclusions decide then how to proceed
> (Standards/Experimental/Informational/no-specification).

We'll see where we're at in this discussion at the SF meeting.

>> There are service providers who do not use preemption, and
>> have major concerns with RDM and its dependence on
>> preemption to work well, that it can perform poorly when
>> preemption is not enabled. Our preference would be to use
>> models not dependent on preemption (MAM or MAR). There was
>> much support on the list that a BC model should not require
>> preemption to work well. I think you should take that into
>> account in RDM, and provide extensions to protect against same.

> We have discussed the relative properties of RDM and MAM at length. This
> is precisely why we evolved towards specifying both RDM and MAM (rather
> than keep trying to come up with a single super model that works
> perfectly in all cases).

As above, I don't think we should specify/progress RDM in its current form.

> I am not suggesting everyone should use RDM; this is why MAM is also
> progressed.

The problem is that MAM is not *required*, so SPs cannot count on it being available from every vendor.

> Incidentally, perhaps mechanisms like
> draft-meyer-mpls-soft-preemption-00.txt may also alleviate some of the
> concerns associated with preemption.

If you mean that SPs who don't use preemption will suddenly opt to use soft preemption, certainly not. Also, if one does too much soft preemption, and forces a lot of flows off of short routes onto much longer, inefficient routes, this would (perhaps severely) degrade network performance. There are studies which show that effect. One of the applications of bandwidth reservation mechanisms (as in MAR), used in large-scale networks today, is to protect against such an effect.
As I'm co-authoring the soft preemption draft, I'd like to make a comment here. The point Francois wanted to stress which I think is perfectly valid is that one of the very well known limitation of the current preemption scheme is its disruptive nature for preempted TE LSP: indeed, a preempted TE LSP is just torn down which results in traffic disruption, something undesirable. Hence we came up with a proposal to signal a pending preemption to the HE of a soft preempted TE LSP so that the HE could perform a TE reroute (with make before break); this results in a very temporary overbooking but allows to avoid traffic disruption. I think this scheme can definitely help alleviating some issues with preemption schemes used with RDM.

Thanks.

JP.

Thanks,
Jerry