>> 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