Re: A proposal for moving ahead on BC models

[Dave Cooper <dcooper@GBLX.net>]

I think we should drop the mandate on a default
BC model and just move on.

-dave

On Fri, Jan 17, 2003 at 05:28:18PM -0700, Dave Cooper wrote:
> > Hi all,
> > 
> > >> 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.
> > 
> 
> ----- End forwarded message -----