FW: Comments on Applicability Statement

["Lai, Wai S (Waisum), ALSVC" <wlai@att.com>]

Jim,
   Thanks for your agreement on:
(1) The Applicability Statement is more than a TEIMP (TE document
decribing implementation experience) and hence should include also
those capabilities needed to ensure proper operation, though may
not currently be implemented in the manner desired/required.
(2) CAC is good, it's also recommended by the Framework for
Internet Traffic Engineering.
   My inference is that a discussion of the applicability of CAC
would be appropriate.
   I think there is room for improvement of the proposed text
(which can be found towards the end of this email), and I welcome
any suggestion for improvement.  The intent is to highlight how
CAC is applicable -- a pre-condition for effective CAC is the need
for proper dimensioning.  In addition, if what you described below
for CAC holds, one would think that's something a surgeon general
would like to issue a warning.
   In any case, if you think the proposed text doesn't belong in
Section 5, I would not insist on it.  But I am sure that there will
be some place in the Applicability Statement for the discussion,
if the intention is to make good the agreements in this email thread.
Thanks, Wai Sum.

-----Original Message-----
From: Jim Boyle [mailto:jboyle@Level3.net]
Sent: Friday, April 06, 2001 11:20 PM
To: Lai, Wai S (Waisum), ALSVC
Cc: te-wg@ops.ietf.org
Subject: RE: Comments on Applicability Statement



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

-----Original Message-----
From: Lai, Wai S (Waisum), ALSVC 
Sent: Friday, April 06, 2001 8:52 PM
To: te-wg@ops.ietf.org
Subject: RE: Comments on Applicability Statement


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.

-----Original Message-----
From: Jim Boyle [mailto:jboyle@Level3.net]
Sent: Wednesday, April 04, 2001 9:50 AM
To: Lai, Wai S (Waisum), ALSVC
Cc: te-wg@ops.ietf.org
Subject: RE: Comments on Applicability Statement




Wai Sum, yes.  It should include what is needed for proper
operation.  More precisely, it should be a statement of applicability of
mpls and traffic engineering in service provider networks.  Where is it
applicable, and how.  And what are some of the gotchas and complexities
that come along as baggage.

It shouldn't, in my estimation, make comments as to how something untested
might be applicable, or highlight something tangential (such as intserv,
or operation of phone or atm networks, or even simulation results) that
might have some relevance. There is enough experience deploying traffic
engineering techniques in operational IP networks that the applicability
statement should be based on that.

What do others think?

Jim




On Wed, 4 Apr 2001, Lai, Wai S (Waisum), ALSVC wrote:

> Jim,
>    Please clarify the intent of the MPLS-TE Applicability Statement.
> Is it to document implementation experience only (in which case, the
> Statement would be no more than a TEIMP), or to include also what is
> needed for proper operation?
>    Regarding your comment on point (A), what you rephrased reflects
> today's environment.  Given that RSVP-TE and CR-LDP are intended to be
> functionally similar, as described in their respective Applicability
> Statements, please explain the significance or the relevance.
>    Regarding your comment on point (D), admission control takes many
> forms.  For example, it is performed today by administrative means in
> static provisioning in SP environments.  Moreover, work done on RSVP
> in Intserv has demonstrated the need for such a mechanism.  So, again,
> the Applicability Statement should include what is needed for proper
> operation of TE.
> Thanks, Wai Sum.
> 
> -----Original Message-----
> From: Jim Boyle [mailto:jboyle@Level3.net]
> Sent: Tuesday, April 03, 2001 10:28 AM
> To: Lai, Wai S (Waisum), ALSVC
> Cc: te-wg@ops.ietf.org
> Subject: Re: Comments on Applicability Statement
> 
> 
> On Mon, 2 Apr 2001, Lai, Wai S (Waisum), ALSVC wrote:
> 
> > The "Applicability Statement for Traffic Engineering with MPLS" draft is
> an
> > excellent summary of MPLS TE issues.  To broaden its coverage, I propose
> > below some further points (A, B, C, D) for consideration.  Your feedback
> > would be appreciated.
> > Thanks, Wai Sum.
> > 
> > -----------------------------------------------------------------------
> > 
> > (A) In Section 1, 2nd paragraph, add the following after the 2nd
sentence:
> > 
> > Another signaling protocol that performs similar functions is CR-LDP,
the
> > applicability of which is described in
> > G. Ash, M.K. Girish, E. Gray, B. Jamoussi, and G. Wright,
> >    "Applicability Statement for CR-LDP", work in progress, July 2000.
> 
> 
> In similar, do you mean that CR-LDP has been "developed and deployed in
> scale, and in a multi-vendor environment", or do you mean "Another
> signalling protocol that intends to perform similar functions is CR-LDP
> [CR-LDP-REF], though it hasn't been deployed in scale".
> 
> 
> > 
> > -----------------------------------------------------------------------
> > 
> > (B) After Sub-section 3.3, add a new Sub-section:
> > 
> > 3.4 Re-optimization after restoration
> >  
> > After a network failure, a new set of LSPs can be calculated that
optimize
> > the performance of the new topology. This re-optimization is
complementary
> > to the fast-reroute operation used to reduce packet losses during
routing
> > transients under network restoration.  Traffic protection can also be
> > accomplished by associating a primary LSP with a set of secondary LSPs,
> > hot-standby LSPs, or a combination thereof.
> 
> probably wouldn't hurt to highlight the increased role after failures.
> 
> > 
> > -----------------------------------------------------------------------
> > 
> > (C) After Sub-section 4.2, add two new Sub-sections:
>  > 
> 
> We have no section 4.2.  These are important aspects, the value of the
> measurements one can get off an MPLS TE network.  But again, in order to
> try to hold the line on conciseness, we need to figure out a way to touch
> on that in less words.
> 
> > 4.3 Capacity
> Engineering Aspects
> > 
> > Traffic engineering has a goal of ensuring traffic performance
objectives
> > for different services.  This requires that the different network
elements
> > be dimensioned properly to handle the expected load.  More specifically,
> in
> > mapping given user demands onto network resources, network dimensioning
> > involves the sizing of the network elements, such as links, processors,
> and
> > buffers, so that performance objectives can be met at minimum cost.
Major
> > inputs to the dimensioning process are cost models, characterization of
> user
> > demands and specification of performance objectives.
> > 
> > In using MPLS, dimensioning involves the assignment of resources such as
> > bandwidth to a set of pre-selected LSPs for carrying traffic, and
mapping
> > the logical network of LSPs onto a physical network of links with
capacity
> > constraints.  The dimensioning process also determines the link capacity
> > parameters or thresholds associated with the use of some bandwidth
> > reservation scheme for service protection.  Service protection controls
> the
> > QoS for certain service types by restricting access to bandwidth, or by
> > giving priority access to one type of traffic over another.  Such
methods
> > are essential, e.g., to guarantee a minimum amount of resources for
flows
> > with expected short duration, to improve the acceptance probability for
> > flows with high bandwidth requirements, or to maintain network stability
> by
> > preventing performance degradation in case of a local overload.
> > 
> > 4.4 Network Measurement Aspects
> > 
> > To ensure that the QoS objectives have been met, performance
measurements
> > and performance monitoring are required so that real-time traffic
control
> > actions, or policy-based actions, can be taken.  To characterize the
> traffic
> > demands, traffic measurements are used to estimate the offered loads
from
> > different service classes and to provide forecasting of future demands
for
> > capacity planning purposes.  Forecasting and planning may result in
> capacity
> > augmentation or may lead to the introduction of new technology and
> > architecture.
> > 
> > -----------------------------------------------------------------------
> > 
> > (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.
> 
>