The MPLS WG Archive

[Dave McDysan <dave.mcdysan@wcom.com>]

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram
> Davari
> Sent: Wednesday, December 12, 2001 11:50 AM
> To: 'Ping Pan'; dirk.ooms@alcatel.be
> Cc: mpls@UU.NET
> Subject: RE: MPLSOAM BOF meeting draft minutes
>
>
> Ping,
>
> > -----Original Message-----
> > From: Ping Pan [mailto:pingpan@juniper.net]
> > Sent: Wednesday, December 12, 2001 2:46 AM
> > To: dirk.ooms@alcatel.be
> > Cc: Shahram Davari; mpls@uu.net
> > Subject: Re: MPLSOAM BOF meeting draft minutes
> >

Stuff Deleted.

> >
> > The question you should ask yourself is:" LSP traffic black-hole has
> > been seen in several backbones. Do you think the operators
> > want to wait
> > for a fancy solution that will come out sometime in the future, or a
> > solution that can solve most of the problems with a couple of simple
> > tools and will be available soon?"
>
>
> May be other questions you should ask are:
>
> 1) Should a rush non-complete solution be standardized by IETF?
> 2) Do you prefer a different solution for each MPLS application,
> or you think a unique solution is more desirable for a standard.
>

It is not clear to me that an MPLS layer only solution will support the
requirements for IP over MPLS in traffic engineering and network-based VPN
applications. I think that there will be a strong dependence on the
implementation for the LSP ingress. For example, in an Internet backbone,
injecting say a 50 byte MPLS continuity packet once a second for 100,000
FECs is 40 Mbps of traffic from each edge router. At places in the core
where say 100 LSPs traverse, this would be 4 Gbps of traffic! If only the
"trunk parts of the LSP are monitored, then for a 1000 LSPs the traffic is a
much more modest 400 kbps, but then it does not monitor all of the potential
forwarding table corruption defects for MPLS in support of IP.