Subject: Re: A proposal for moving ahead on BC models

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 17 Dec 2002 10:43:49 -0500

This sounds like a pragmatic way to move the DS-TE work
forward.

         --Tom

> >> However, we have
> >> multiple BC
> >>    models on the table here, and the requirements document says there
> >>    must be a default BC model for implementation.  So the question
> >>    becomes: Is "one" of these the default?  Or both? Or maybe should
> >>    neither really be required, they proceed non-standard until
> >>    operational experience shows what people really use (and thus
> >>    should be required for implementation).
>
>It's occurred to me that there is an interesting analogy between the
>situation we are in with respect to BC Models, and the situation the
>Diff-Serv WG was a little while back with respect to PHBs:
>         - the architecture + basic on-the-wire "protocol" extensions
>were defined (e.g. DSCP for Diff-Serv; IGP/RSVP for DSTE)
>         - PHB is local to a box, but to achieve something end-to-end you
>generally want to run the same PHB on all boxes (as externally visible).
>Similarly, BC Model is a local behaviour but to achieve something
>end-to-end you want the same BC Model on all boxes.
>         - it was clear that more than one PHB would be needed for
>different applications. A number of specific PHBs (EF, AFxy,..) were
>recognised as clearly useful for respective applications. It was
>recognised that additional PHBs may be required in the future. It was
>unclear which exact set of PHBs were going to be eventually deployed in
>the long run, it was unclear that all networks would require the same
>set of PHBs anyway, and more operational experience was required. All of
>this applies to the BC models.
>
>The Diff-Serv WG approach has been to:
>         - document each PHB (or group of PHBs) which were clearly
>recognised as useful in a separate standards track RFC (eg EF, AFxy  ).
>Tis basically says : "if you're going to support this PHB, here is what
>you MUST do".
>         - allow additional PHBs to be specified in the future as deemed
>necessary from experience
>         - NOT mandate which PHB to support (*) and let user/vendor
>determine the right set of PHBs to deploy/support as experience grows.
>
>So my proposal would be to handle BC models in the same way, i.e. :
>         - document Russian Dolls model in a standards track RFC. This
>would basically say, "if you're going to support RDM, here is what you
>MUST do".
>         - document MAM in a standards track RFC. This would basically
>say, "if you're going to support MAM, here is what you MUST do".
>         - in the future, allow additional models (eg something
>incorporating some MAR concepts) to be defined as required from
>operational experience
>         - do NOT mandate in the "diff-te-proto" draft which BC model is
>to be used
>         - update "diff-te-reqts" to reflect this (get rid of concept of
>"Default BC model"). This draft is with IESG so it should still be
>possible to update it.
>
>I think this approach would allow us to achieve standardised
>interoperable DSTE deployment in short timeframes, yet at the same time
>would prepare us well for adjusting in the future as we gather more
>operational expertise.
>
>Thoughts/comments on this approach?
>
>Francois
>
>
>
>
>(*) the Diff-Serv spec actually mandates support of the
>Default/Best-Effort PHB (and some Class Selector PHBs). But note that
>this is not analogous to supporting a Default BC model. It is in effect
>the minimum required to maintain operation as BEFORE Diff-Serv service.
>So in the DS-TE context, it is analogous to the minimum required to
>operate without DS-TE (ie to support regular TE) and that would be
>support of the existing TE trivial BC Model with a single CT.

"The difficult, we do immediately.  The impossible takes a little longer." 
-- Air Force Motto

http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Tue, 17 Dec 2002 11:34:55 -0500

> end-to-end you want the same BC Model on all boxes.

Typically several PHBs are used in a domain, whereas a single BC model MUST  be used.  DiffServ has the DSCP to decide which PHB to apply.  What tells an LSR which BC model to apply (configured)?

For DSTE to work, at least one, common BC model MUST be supported by all LSRs.  How do we ensure that?

Jerry

---

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Tue, 17 Dec 2002 19:00:26 +0100

Hi all,

This is IMHO the best approach, 

Indeed, using distinct BC models on different boxes ,or even distinct BC
models
on distinct links of the same box, does not raise any interoperability
issue, 

Thus,  diff-te-proto document should not mandate which BC model MUST be
used, but just give pointers to several Standard Track BC model
documents .

Of course the best solution for ISPs is to have a flexible box that
allows selecting between various implemented BC models...

Regards, 

JL

-----Message d'origine-----
De : Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Envoye : mardi 17 decembre 2002 15:51
A : [email-masked]
Cc : Francois Le Faucheur (flefauch); Wijnen, Bert (Bert)
Objet : A proposal for moving ahead on BC models

Hi all,

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 18 Dec 2002 10:00:20 -0000

Jerry,

>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALASO [mailto:[email-masked]] 
>> Sent: 17 December 2002 17:35
>> To: Francois Le Faucheur (flefauch); [email-masked]
>> Cc: Ash, Gerald R (Jerry), ALASO; Wijnen, Bert (Bert)
>> Subject: RE: A proposal for moving ahead on BC models
>> 
>> 
>> Typically several PHBs are used in a domain, whereas a 
>> single BC model MUST  be used.  

True, but nonetheless, if:
	- box A support Best Effort PHB and EF PHB only 
	- box B supports Best Effort PHB and AFxy PHBs only
it is kind of messy to support Diff-Serv end-to-end. Yet, Diff-Serv WG
did not mandate support for AF and EF. It relies on
Administrators/Vendors to select the right set of PHBs to
deploy/implement. Again, the rationale was that operational experience
was required before knowing what would be the right set of PHBs to
mandate- or even that differnet environments may simply just need
different sets of PHBs. So the approach is to leave it open, rather than
mandate something which can be proven wrong later on.

My perception is that we are in a similar situation with DS-TE. Right
now some of us believe that Model 1 is a better default model, some
believe Model 2 is a better default model. Some argued Model 3 might
even be better. It may be that after a few years of operational
experience, we realise that whichever model we mandated as Default is
not that good, and maybe that the other one is better or maybe that some
"model 4" is really much better than any of those. My proposal is to
leave it open so we can adjust as we gather more operational experience.

>> For DSTE to work, at least one, common BC model MUST be 
>> supported by all LSRs.  How do we ensure that?
>> 

From a practical perspective, not mandating an exact set of PHBs in
Diff-Serv has not affected Diff-Serv interoperability because the
Diff-Serv WG was careful in specifying a reasonable number of PHBs so
that vendors could easily support a largely overlapping set.
Requirements from Network Administrators dictated what was the right
overlapping set to support for various environments.

For DS-TE, practically speaking, you would ensure that you have at least
one (or most probably two) BC models supported on all DSTE boxes by:
	- TEWG being careful and specifying only a reasonable number of
BC models (eg RDM + MAM for now, maybe one or two more in the future if
needed) 
	- Network Administrators dictating which BC Model they need for
their own deployment (eg some requesting RDM, some requesting MAM, and
maybe in a few years some requesting Model 4...).
then in practise there would not be any DS-TE interoperability issues
because vendors will support the required set of BC Models.

Could that work for you?

Cheers

Francois

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Thu, 19 Dec 2002 08:06:18 -0500

Francois,

> BC models (e.g. RDM + MAM for now, maybe one or two more in the 
> future if needed) 
> their own deployment (e.g. some requesting RDM, some requesting MAM, and
> then in practice there would not be any DS-TE interoperability issues

Your proposal is assuming that vendors will support all of the 'reasonable number' (= 2) of BC models (RDM & MAM).  That being the case, I don't see why we just don't mandate support of the 2 BC models.  Many participants in the TEWG meeting already supported that proposal (including the authors of the BC drafts, you, Wai Sum, and me).  I suggest we try to get consensus on that since it will ensure interoperability.  We will not get interoperability if some vendors support one BC model and other vendors another BC model.

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 20 Dec 2002 09:52:07 -0000

Hello Jerry,

>> Sent: 19 December 2002 14:06
>> Your proposal is assuming that vendors will support all of 
>> the 'reasonable number' (= 2) of BC models (RDM & MAM).  

Yes. That is what I would expect.

>> That being the case, I don't see why we just don't mandate 
>> support of the 2 BC models.  

In the short term, I think the practical result would effectively be the
same wether we mandate them or not. The difference is that, if in the
long run we realise that other models are better/more commonly used, we
are not stuck with DSTE specs which mandate "older" BC models.

I can live with other approaches mandating one or two models, but my
preference is for not mandating the models at this stage and for relying
on market/experience to drive BC model selection. 

Let's see if we hear more on this on the list and then we'll try
converge soon onto one approach. 

Cheers

Francois

>> Many participants in the TEWG 
>> meeting already supported that proposal (including the 
>> authors of the BC drafts, you, Wai Sum, and me).  I suggest 
>> we try to get consensus on that since it will ensure 
>> interoperability.  We will not get interoperability if some 
>> vendors support one BC model and other vendors another BC model.
>> 
>> Thanks,
>> Jerry
>>

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Fri, 20 Dec 2002 09:09:43 -0500

Francois,

>> So the suggestion is to specify 2 default BC models (RDM & MAM) in
>> the proto draft and allow for additional BC models to be introduced in
>> the future (e.g., MAR, or something else).  I suggest we try to get
>> consensus on that since it will ensure interoperability in the near term
>> and allow for improvements/extensions in the future. 

> This is clear.
> Yes, what we had specified in the Requirements document allows for
> extension. And as I said, I could live with that.

Good.  So I'm suggesting we go with the above proposal.
 
> The point I have been trying to convey, though, is that if in 2 years
> time it turns out that we all realise that no one actually uses RDM and
> MAM because everybody realised that Model_xyz is much better, then we
> are left with specifications that mandate support for something useless.
> I am not saying this will happen for sure, I just don't know. 
> Do you get my point?

Yes I get your point.  I agree that better BC models may come along in the future (e.g., MAR or something else).  Both proposals allow for that, however, specifying 2 default BC models guarantees interoperability in the near term.

> Do you feel confident that RDM and MAM will always be required anyway?
> Or are you saying it is no big deal if we mandate two models that are
> not the ones eventually used in the long run.

Actually both.  I'm saying that in the beginning DSTE should at least allow (require) either RDM or MAM to be used, so that operators can use DSTE (with either RDM or MAM) as soon as vendors implement.  This will ensure interoperability from the get-go of DSTE.  Better models can come along in the long term, be standardized, and (hopefully) be implemented by all vendors used by an operator.

I hope that others on the list will express their opinions.

Thanks,
Jerry

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 20 Dec 2002 10:43:04 -0500

I agree with Francois that not mandating any specific BC models would be the
most practical approach at this point. I'm not even convinced that multiple
BC models can not interoperate in a single TE domain.

Dimitry

> Sent: Friday, December 20, 2002 9:10 AM
> Yes I get your point.  I agree that better BC models may come 
> along in the future (e.g., MAR or something else).  Both 
> proposals allow for that, however, specifying 2 default BC 
> models guarantees interoperability in the near term.
> 
> Actually both.  I'm saying that in the beginning DSTE should 
> at least allow (require) either RDM or MAM to be used, so 
> that operators can use DSTE (with either RDM or MAM) as soon 
> as vendors implement.  This will ensure interoperability from 
> the get-go of DSTE.  Better models can come along in the long 
> term, be standardized, and (hopefully) be implemented by all 
> vendors used by an operator.
>

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Fri, 20 Dec 2002 11:26:28 -0500

Hi! Few comments:

1. Personally, I think it is not a good idea to define 
   2 "default" models, just because we can't agree on 
   one. If somebody submits a third one tomorrow, are
   we going to specify 3 "default" models!!!  

2. The requirement draft calls for the specification 
   of a default model to ensure that a multi-vendor 
   DSTE LSR network operates without significant 
   interoperability problems. 

   Since the default model is not expected to be the
   "best model" (most efficient in all circumstances), 
   we can consider specifying a trivial model like MAM 
   as the default BC Model.

   When the specification of other BC Models mature, 
   providers can always demand the BC models they need 
   from the prospective vendors.

   [A possibly controversial alternative is to use the
   BC Model that has been out the longest -Not because it
   is optimal in all situations, but more vendors might
   have an implementation for them.]

Thanks,
sanjay

	

> From: Jim Boyle [mailto:[email-masked]]
> Sent: Friday, December 20, 2002 9:21 AM
> To: Francois Le Faucheur (flefauch)
> Cc: Ash, Gerald R (Jerry), ALASO; [email-masked]
> I don't think a lack of accurate forsight should weaken protocol 
> requirements. If in two years we realize that one (or both) are in 
> practice never used, we can update the RFC.
> 
> The real question is whether folks think there is a *need* (for 
> consistent/interoperable implementations) to require one (or two)
> BC model(s)?  Or not.
> 
> regards,
> 
> Jim
> 
> On Fri, 20 Dec 2002, Francois Le Faucheur (flefauch) wrote:
> 
> > Jerry,
> > 
> > >> Just to be clear:
> > >> 
> > >> The suggestion is to specify 2 *default* BC models in the 
> > >> proto draft 
> > >> http://ietf.org/internet-drafts/draft-ietf-tewg-diff-te-proto
> > -02.txt.  Recall that the requirements draft
> > http://ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-06.txt
> > calls for at least one BC model and allows for additional 
> BC models to
> > be specified later:
> > 
> > time it turns out that we all realise that noone actually 
> uses RDM and
> > Thanks