Subject: [mpls] I-D Action:draft-ietf-mpls-te-scaling-analysis-04.txt

From: [email-masked]
Date: Tue, 2 Dec 2008 08:30:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title           : An Analysis of Scaling Issues in MPLS-TE Core Networks
	Author(s)       : S. Yasukawa, et al.
	Filename        : draft-ietf-mpls-te-scaling-analysis-04.txt
	Pages           : 41
	Date            : 2008-12-02

Traffic engineered Multiprotocol Label Switching (MPLS-TE) is
deployed in providers' core networks. As providers plan to grow these
networks, they need to understand whether existing protocols and
implementations can support the network sizes that they are planning.

This document presents an analysis of some of the scaling concerns
for the number of Label Switching Paths (LSPs) in MPLS-TE core
networks, and examines the value of two techniques (LSP hierarchies,
and multipoint-to-point LSPs) for improving scaling. The intention is
to motivate the development of appropriate deployment techniques and
protocol extensions to enable the application of MPLS-TE in large
networks.

This document only considers the question of achieving scalability
for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint
MPLS-TE LSPs are for future study.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-scaling-analysis-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Dec 2008 16:32:53 -0000

Hi,

New revision is a few minor editorial things resulting from GenArt review in 
IETF last call.

RFC-diff will show them to you.

Thanks,
Adrian

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Mon, 15 Dec 2008 17:11:46 +0100

Hi,

Question to authors of the draft: the document basically considers only
number of LSP as gauge of growth, but is it not important to take into
account actual data structures used to store LSP-related info
internally? E.g. if LSP's are stored in one-dimentional array/list then
document describes scenario accurately, but if on the other hand some
tree-like structure is used, then memory requirements may grow faster
than number of LSP's and could be not just O(M^K) but something like
O(L*M^K). This may be not an issue with control plane on the routing
processor, but could face additional restriction when resulting data
structures need to be uploaded to line cards. 

Above said is not to diminish value of your document, it's important
reference already, just a thought for future updates.

Cheers,
iLya

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Adrian Farrel
> Sent: Tuesday, December 02, 2008 5:33 PM
> To: [email-masked]
> Subject: Re: [mpls] I-D 
> Action:draft-ietf-mpls-te-scaling-analysis-04.txt
> 
> Hi,
> 
> New revision is a few minor editorial things resulting from 
> GenArt review in IETF last call.
> 
> > This draft is a work item of the Multiprotocol Label 
> Switching Working 
> > Group of the IETF.
> 
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Dec 2008 16:49:09 -0000

Hi Ilya,

> Question to authors of the draft: the document basically considers
> only number of LSP as gauge of growth, but is it not important to
> take into account actual data structures used to store LSP-related
> info internally?

Well, in fact the I-D concentrates on the number of LSP segment states (this 
is represented as X(n) in the draft). We recognise that scalability is a 
function of the number of LSP segment states.

> E.g. if LSP's are stored in one-dimentional array/list then

This is true, but I would say that the wrinkles of individual 
implementations are also not in scope. I suppose it would be possible to 
invent an implementation where the memory requirements scale as O(n**2) for 
the number of LSP segments. But that would be a silly implementation!

We have tried to focus on the basic factors that cause scaling changes. I 
guess that an implementaiton that does not scale linearly with the number of 
LSP segments can still use this work to determine how it will scale by apply 
its own function on top of the X(n) function.

Thanks,
Adrian