The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: MPLSOAM BOF meeting draft minutes

Curtis:

You make some reasonable points, but your compare and contrast of the different proposals blurs several things together and avoids what I think is the real issues in the debate.

The original fault management work brought to ITU-T Y.1711 and to the IETF back in Pittsburgh involved a one way continuity check and fault notification transactions (collectively CV, FDI, and BDI).

Some of us have proposed some extensions to this in our messaging draft in the form of a loopback (for explicit or implicit bi-directional LSPs, either for ad-hoc verification and/or RTT measurement) and an initial stab at performance measurement and an extensibility framework. IMHO these are reasonable extensions.

At the present time I don't think consensus can be said to exist for any technical proposal. That we don't agree on an explicit solution right off is OK. If we cannot agree on the general attributes of a solution we have a problem.  I think it would be useful to understand if that's the real situation (rather than arguing the minutae of ICMP octet 3 vs. CV octet 7).

It should be noted that lot of folks have already given the topic a lot of thought. It is not their fault that this group has not been willing in the past to entertain this discussion and as a consequence you've not been privy to all the details. With that in mind I think there's lots of room for constructive dialog.

rgds
Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Monday, December 17, 2001 12:51 PM
> To: Cuevas, Enrique G, ALCTA
> Cc: curtis@fictitious.org; dave.mcdysan@wcom.com;
> giles@packetexchange.net; Shahram_Davari@pmc-sierra.com; Fedyk, Don
> [BL60:1A00:EXCH]; Ben.Mack-Crane@tellabs.com; mpls@UU.NET;
> neil.2.harrison@bt.com
> Subject: Re: MPLSOAM BOF meeting draft minutes
>
>
>
> 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
>
>