RE: Comments on Applicability Statement

[Jim Boyle <jboyle@Level3.net>]

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