[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] RE: Is PWE a layer?
> -----Original Message-----
> From: David Allan [mailto:dallan@nortelnetworks.com]
> Sent: Tuesday, June 03, 2003 2:25 PM
> To: 'tnadeau@cisco.com'; 'Mark Seery'
> Cc: pwe3@ietf.org
> Subject: RE: [PWE3] RE: Is PWE a layer?
>
>
> Tom:
>
> I agree we need to get to a consensus decision, I also think
> it should be an informed one.
>
> 1) Use of LSP-PING in one way mode is an option, however what
> the far end should do is not specified (which is absolutely
> mandatory for interoperability). VCCV/LSP-PING specification
> would need to be extended to either define the exact far end
> message handling, permit the handling to be negotiated, or
> configured as part of LDP exchange. If this is configured via
> control plane exchange, then there is a few other details to
> sort out (Shah draft & graceful restart come to mind). Merely
> claiming a one way mode exists is insufficient.
I think that we are in agreement that perhaps more
details about what to do need to be specified. George and
I have already agreed for example, to add this to the next
VCCV draft.
> 2) I have trouble with the characterization of LSP-PING as a
> single mechanism. We're already into numerous encapsulations
> of it to overcome ECMP issues and carry variations of FEC
> information, so there is no possibility of a single simple
> implementation for on the wire handling, something we've
> worked to overcome with CV/FEC-CV.
I never claimed it was a single mechanism; it should be
used in concert with things like VRF-aware ping, ICMP ping, VCCV,
etc... The key observation is that these tools all are formulated
together for the specific application in question while being
available for re-use for other applications. For instance,
in the case of L3 VPN, you can use the existing VRF-aware ping
that many vendors offer plus LSP ping/trace. If you want to use
EoMPLS, you use Ethernet ping, VCCV and possibly Lsp ping. Guess
what? Doing this, you can leverage most of that solution
based on the existing LSP ping code and OSS investment.
> The information model to
> control one way periodic mode vs. ping mode will again be
> significantly different. Don't think there is a lot of
> benefit to be had on the northbound interface or a CLI unless
> for some perverse reason we're required to name the protocol
> used rather than the desired function. I wouldn't particularly care.
There is nothing perverse about it. A consistent interface
makes for consistent management of the device. I don't see
what impact this has on the north-bound interface.
> My point is that we're already into numerous variations of
> behavior for a tool that I do not believe is suited for all
> applications. This is on the claimed basis that operators
> want one tool.
Not one tool, one solution.
> I'd like to test that assumption as I presume
> they want a consistent operator interface and really do not
> care what is on the wire so long as it meets useful criteria
> and the overall system behavior is useful.
Yes, but given that we have already adopted
LSP ping for MPLS networks, why not leverage this
for PW/MPLS networks and re-use the implementations
and OSS investments in that approach? Surely
many devices and networks are going to be deployed
with not only PWs but also LDP, TE and L3 VPN all
of which can utilize LSP ping, VRF-aware ping and
ICMP ping. It seems that you are advocating an
approach that requires lots of investment and churn
this time for PWs, whereby you want the operator to
do something completely different just because it
is a new application and you claim it is a superior
solution. I assert that it is better in terms of cost,
effort and time to market to incorporate the tools and
techniques that exist today as part of the approach for
the new application. This is precisely what we have done
in defining VCCV to re-use LSP ping when used for PW/MPLS.
> 3) As for re-application of tools already in use, on MPLS-OPS
> I got the impression that LSP-PING will be in an IOS release
> Q4 this year (?). And if implementations of it does already
> exist, given the shortcomings discussed in '1' above, are you
> planning on "fixing/patching" it?
We do code fixes based on customer requirements.
--Tom
> cheers
> Dave
>
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> > Sent: Tuesday, June 03, 2003 8:23 AM
> > To: 'Mark Seery'
> > Cc: pwe3@ietf.org
> > Subject: RE: [PWE3] RE: Is PWE a layer?
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Mark Seery [mailto:mark@mseery.com]
> > > Sent: Saturday, May 31, 2003 12:10 AM
> > > To: tnadeau@cisco.com
> > > Cc: pwe3@ietf.org
> > > Subject: RE: [PWE3] RE: Is PWE a layer?
> > >
> > >
> > >
> > > --- "Thomas D. Nadeau" <tnadeau@cisco.com> wrote:
> > > [SNIP]
> > >
> > > >> I am totally in favor of this approach. In fact,
> > > I have been advocating an evolutionary approach for
> > > over
> > > a year now that includes lots of tools and techniques,
> > > not any single one. <<
> > >
> > > Tom, that seems like a constructive position to take,
> > > thanks for offering that.
> > >
> > > That being the case, how do you feel about Dave's
> > > suggestion of the following:
> > >
> > > "1) We require a mechanism to distinguish OAM flows in
> > > PWs. The discussion is moving in a direction whereby
> > > there is a requirement to support multiple flows or
> > > combinations of the same (LSP-PING, Y.1711, other) depending
> > > on operator sensibilities.
> >
> > I don't think that we need to define
> > more than one mechanism for the reasons I have
> > explained my my prior posting. My customers certainly
> > don't want more than one mechanism. Also, before any
> > conclusion is drawn, I suggest asking the WG for consensus on
> > such a decision.
> >
> > --Tom
> >
> >
> > > 2) The mechanism needs to work and have useful OAM
> > > characteristics (aka fate sharing) in the presence of all
> > > known (or alluded to) ECMP mechanisms (which I believe
> > > uniquely impact PWs over MPLS unless folks have bizzare plans
> > > for L2TPv3 ;-). This means no reserved labels or appearance
> > > as an IP packet directly as MPLS/PW payload for any OAM
> > > tools, or aliasing as an IP packet.
> > >
> > > IMHO this pushes us directly into the MPLS PID space
> > > as the only tractable compromise solution that meets
> > > the criteria above (we needed more header bits
> > > somewhere and it has to be somthing new :-( ). It
> > > complicates life as PW control words now pretty much
> > > become mandatory.
> > >
> > > This has a number of benefits as it can also apply to
> > > MPLS as a layer independent of the PW application, so
> > > it would appear that both MPLS and PWs in general have
> > > a mechanism for muxing OAM (and possibly control)
> > > flows with payload.
> > >
> > > So the above being said, some practical steps that
> > > facilitate getting to your proposal are:
> > >
> > > 1) Agree on the above requirements
> > > 2) Devise a converged MPLS/PW PID approach that
> > > permits multiple OAM tools to be employed over PWs and
> > > LSPs
> > > 3) Get the requisite missing PIDs from IANA for tools
> > > we wish to have as candidiates "
> > >
> > > -Mark
> > >
> > >
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
>
>
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3