RE: Comments on Applicability Statement

[Jim Boyle <jboyle@Level3.net>]

yes, CAC is good, and tested well in IP/MPLS networks w/ one service
class, not sure it is widely held that many hav tested it well with
many classes as you infer.  I'd be happy to hear from others if I'm not
in sync with general sentiment in IP network engineering. However that's
besides the point.

The point of section 5 is to point out Limitations, e.g. forwarding
issues, debugging complexity, instability, positron stimulated reboots,
etc...  This is the surgeon general's warning section.  I don't think it'd
be the right place to put in a ("and w/ connection orientied forwarding
and CAC - bing! - multi-class QoS can be assured") 

regards,

Jim


On Fri, 6 Apr2001, Lai, Wai S (Waisum),
ALSVC wrote:
> Jim,
>    Thanks for clarifying the intent of the Applicability Statement.
> I think the e-mail exchange in the last couple of days following
> your e-mail below further amplifies the fact the Applicability 
> Statement should include also those capabilities needed to ensure
> proper operation, though may not currently be implemented in the
> manner desired/required.
>    In this regard, I'd like to follow up on the issue of admission
> control that triggered the discussion.  As pointed out below, it's
> done by administrative means today in static provisioning.  Even in
> a primitive form like this, its use is essential to ensure network
> performance.  Recommended by the Framework
> (<draft-ietf-tewg-framework-03.txt>, p.53), admission control is
> neither something untested in IP networks nor of tangential
> relevance.  A discussion of its applicability is well within the
> scope of the Applicability Statement.
> Thanks, Wai Sum.
> 

<snip><snip>

> > > 
> > > (D) In Section 5, add the following paragraph to end of the 4th
> paragaph:
> > > 
> > > Connection-oriented mode of operation allows the use of admission
> control
> > at
> > > the connection or flow level to avoid QoS degradation at the packet
> level.
> > > This is a form of preventive control to ensure that the QoS requirements
> > of
> > > different service classes can be met simultaneously, while maintaining
> > > network efficiency at a high level.  However, it requires proper network
> > > dimensioning to keep the probability for the refusal of connection/flow
> > > requests sufficiently low.    
> > > 
> > 
> > Is this from MPLS TE in a service provider network?  Or from experience in
> > ATM/FR networks or in simulations.  I'd like to keep the focus of the
> > applicability statement to real experience with MPLS TE in SP
> > environments.  I feel nervous about saying something is applicable, where
> > there are no war-scars to show either way that it is or not.
> > 
> > 
>