The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Dec> msg00198



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

MPLSOAM BOF meeting draft minutes

  • From: Curtis Villamizar <curtis@workhorse.fictitious.org>
  • Date: Mon, 17 Dec 2001 12:51:13 -0500
  • cc: curtis@fictitious.org, dave.mcdysan@wcom.com, giles@packetexchange.net, Shahram_Davari@pmc-sierra.com, dwfedyk@nortelnetworks.com, Ben.Mack-Crane@tellabs.com, mpls@UU.NET, neil.2.harrison@bt.com


In message <28F05913385EAC43AF019413F674A017A8AEB5@OCCLUST04EVS1.ugd.att.com>, 
"Cuevas, Enrique G, ALCTA" writes:
> Curtis,
> >I hate to add to this agonizingly long thread, I counted 107 messages
> >already and going nowhere. 
> 
> I disagree with you. The fact that this may be the 108th message on this thre
> ad is because this IS an important topic that has raised a lot of interest th
> at it needs WORK. The requirements are supported by many operators and vendor
> s (AT&T, British Telecom, Deutsche Telekom, Sprint, SBC, NTT, Nortel, Lucent,
>  Tellabs, NEC, Caspian Network, Maple, PMC-Sierra) and I am sure many more wh
> o have  attended the BoF or/and have read and understood the drafts. 
> You cannot ignore customer requirements, specially if these call for RELIABLE
> , STANDARDIZED and INTEROPERABLE solutions.
> 
> Enrique
> AT&T Labs


My personal experience, having been on both sides of the network
provider / equipment provider interaction, has been that the network
provider needs to be very clear about the capabilities that are needed
to run their network.  The vendor side needs to listen carefully.
Both sides may propose the protocol specifics.  Again, my personal
experience has been that the network provider needs also to listen to
the equipment provider about implementation concerns and be open to
alternatives that provide the capabilities that the network provider
needs.

MPLS-OAM provides connectivity check, a loopback (no one has been
clear why a one way check in each direction would not be sufficient),
and an poorly defined performance check.  BT (Neil) has led the push
to get the requirements heard but has also insisted on a specific
implementation for which objections have been raised and consensus has
not been acheived.

LSP ping provides connectivity check for an LSP regardless of payload
type.  GTTP provides a means to check the control plane.  LSP ping
identifies the case where the control plane and forwarding plane do
not match.  There is currently no loopback or performance statistic.

The equipment provider who has experienced the problems is among those
that is proposing a means to accommodate the requirement for a
connectivity check.

Constructive dialog might resolve the issues of LSP Ping being too
RSVP-TE specific and provide the capability the network providers need
in a format that the network providers can live with and the equipment
providers can easily implement.

Curtis