RE: A proposal for moving ahead on BC models

["Francois Le Faucheur (flefauch)" <flefauch@cisco.com>]

Jerry,

>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALASO [mailto:gash@att.com] 
>> Sent: 17 December 2002 17:35
>> To: Francois Le Faucheur (flefauch); te-wg@ops.ietf.org
>> Cc: Ash, Gerald R (Jerry), ALASO; Wijnen, Bert (Bert)
>> Subject: RE: A proposal for moving ahead on BC models
>> 
>> 
>> > 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.
>> 
>> 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

>> Jerry
>>