The MPLS WG Archive

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

I support making this capability optional (as it was/is for ATM). If this
types of OAM functions are intended to support pseudo-wires and PPVPNs, I
would also like to suggest that this support be provided for the
infrastructure of these services as well.

Dave

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> neil.2.harrison@bt.com
> Sent: Thursday, December 13, 2001 7:38 PM
> To: Scott_Reynolds@pmc-sierra.com; John.Rutemiller@marconi.com;
> mpls@UU.NET
> Subject: RE: MPLSOAM BOF meeting draft minutes
>
>
> Thanks Scott,
>
> That is exactly what I have been advocating.  You don't *have* to
> run the CV
> flow on every LSP....though that would be the best option to detect LSP
> leakage problems.  Further, you can decouple source generation from sink
> processing......this stuff is trivial to generate IMO since its fixed, at
> least for CV (though I'd bow to the experts like Scott/Shahram from
> companies like PMC-Sierra to confirm this).  It also has no impact on
> intermediate LSRs....its just goes source to sink.  You can also do some
> pretty neat things with tapping off parallel flows (CV of P) at
> intermediate
> nodes along an LSP and sending them to a centralised NMS centre for
> segmentation diagnostics.
>
> Personally I am surprised at the heat of discussion here.  People
> seem very
> happy to load-up control-plane protocols with loads of
> functions/complexities (and even CV...its called 'Hello' here),
> but when it
> comes to looking after the service/traffic they deliver to customers seems
> some people don't care.
>
> regards, Neil
>
> > -----Original Message-----
> > From: Scott Reynolds [mailto:Scott_Reynolds@pmc-sierra.com]
> > Sent: 13 December 2001 18:42
> > To: 'neil.2.harrison@bt.com'; John.Rutemiller@marconi.com; mpls@UU.NET
> > Subject: RE: MPLSOAM BOF meeting draft minutes
> >
> >
> > All:
> >
> > From Neil's comments below, it appears that either operators
> > view MPLS as a way to deliver superior IP-based services, or
> > as a converged backbone, supporting ATM, FR and IP based
> > services. This second group of operators appear to want a set
> > of operational tools "similar" to those offered by other
> > layered networking technologies, because they believe they
> > will be facing the same problems with MPLS as technology X.
> >
> > neil> George, you should take careful note that operators
> > also have lots of major
> > neil> revenue earning FR and ATM services out there, and
> > maybe new services.  It
> > neil> would be really nice for operators to have/see MPLS as
> > that convergence
> > neil> technology......not as a set of disparate 'vendor
> > fixes' for specific
> > neil> problems.  For example, I could very easily see
> > operators running FR/ATM,
> > neil> BE/Internet and MPLS/VPN platforms all disjoint and
> > with no obvious
> > neil> convergence strategy...and that is exactly what I can see today.
> >
> > Providing a form of MPLS OAM will result in a cost burden,
> > which the operators justify based on the belief that end
> > customers now do and will continue to pay a premium for ATM
> > and FR based services because of the guarantees the operators
> > can offer because of these tools.
> >
> > I don't believe anyone supporting the MPLS OAM activities has
> > demanded that supporting MPLS OAM be mandatory. If you don't
> > want it, can't afford it or just don't like it then leave it off.
> >
> > If we have a group of users who have determined a need for
> > the tools, the appearance of unsatisfied requirements with
> > the current set of tools and a group of people willing to
> > develop new tools, why is there so much resistance ?
> >
> > Regards,
> > Scott
> >
> > --
> > Scott Reynolds,
> > Senior Architect,
> > PMC-Sierra, Inc.
> > 8555 Baxter Place,
> > Burnaby, B.C, Canada V5A 4V7
> > ph:  		(604) 415-6000 x 2593
> > fax: 		(604) 415-6659
> > e-mail: 	mailto:scott_reynolds@pmc-sierra.com
> > web:		http://www.pmc-sierra.com
> >
> >
> >