Tom:
In essence, your idea of one solution is an application specific variation of a particular style of tool where you've already operationalized the general style, and plan on managing everything on that basis.
OK, I obviously do not agree on all points, and on more than simply PW specifics, so its time for other folks to chime in as to whether your approach meets their needs.
cheers
Dave
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Tuesday, June 03, 2003 3:34 PM
> To: Allan, David [CAR:NS00:EXCH]; 'Mark Seery'
> Cc: pwe3@ietf.org
> Subject: 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
> > >
> >
> >
>
>
>