The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Nov> msg00182



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

About the P2MP scalability

  • From: Seisho Yasukawa <seisho-yasukawa@apricot.ocn.ne.jp>
  • Date: Thu, 20 Nov 2003 23:12:52 +0900
  • Cc: "'mpls@uu.net'" <mpls@UU.NET>, yasukawa.seisho@lab.ntt.co.jp

Hi Melvin and Adrian,

Yes, I agree with Adrian.
Scalability is an important requirement for p2mp becuase
some p2mp typical service scenario require a lot of p2mp lsp
setup in the core with large number of leaf nodes.
And we hope this is clearly expressed in the requirements draft.

There are at least four aspects of scaling that we must cover

  1. The number of protocol messages needed to set up the full p2mp
     tree, or to recover the tree after failure.
  2. The size of the protocol messages
  3. Sharing of resources between flows for the same p2mp tree
  4. The amount of Path and Resv state required to support the p2mp
     tree when it passes through one LSR.

The solutions will need to resolve these issues.

Cheers,

Seisho

> Hi Melvin,
> 
> Thanks for both of your emails on this subject.
> 
> > Sir, I have several questions to ask:
> > 1) how can we implement the P2MP in the non-packet network?
> > 2) can we have some method to solve the scalability problem in P2MP
> >     implementation?
> > 3) Can we not to put the PE1 from the sender node in the edge-node,
> >      but in the inner node in the mpls domain? I think it could enhance
> >      the scalability. Although I know we always put these functions on
> >      the edge node.
> >
> >  Hope your reply.
> 
> It is the intention of draft-yasukawa-mpls-p2mp-requirement-01.txt to make sure that any
> p2mp solution developed in the MPLS WG should be applicable to other switching types (i.e.
> non-packet).
> 
> Scalability is, of course, a significant concern.
> draft-yasukawa-mpls-p2mp-requirement-01.txt describes networks where the branch points are
> within the network and not at the edges. Scaling issues are mentioned at many points in
> the draft.
> 
> There are currently two proposed solutions drafts (it is to be hoped that these may
> converge on a single solution over time). Both proposed solutions take some pains to
> ensure optimal use of network resources. Both solutions currently have some scaling issues
> within the control plane, but I'm sure the authors are working to resolve these issues.
> 
> Cheers,
> Adrian

-- 
seisho yasukawa <seisho-yasukawa@apricot.ocn.ne.jp>