Subject: RE: RE: Is PWE a layer?

From: "David Allan" <[email-masked]>
Date: Mon, 2 Jun 2003 09:46:24 -0400

Tom:

You're correct. IMHO PPP DLL is fine as a protocol authority. 

For reference, the key deltas between the proposals were:

- presence of an authority ID, such that PIDs other than PPP DLL could be
used. The intent was not to produce an overlapping nightmare, but to provide
the option of using the IP protocol identifier, and collapse out the IP
header (similar to VCCV).

- presence of the "router alert" bit (as a replacement for the MPLS RA
label, and new functionality unique to multi-hop non-MPLS PWs), which is
orthogonal to the specific problem being solved but falls into the same
general category of addressing ECMP issues.

I'd be happy to discuss these as separate topics.

cheers
Dave 

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Saturday, May 31, 2003 9:31 AM
> To: 'Mark Seery'
> Cc: [email-masked]
> Subject: RE: [PWE3] RE: Is PWE a layer?
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Mark Seery
> > Sent: Saturday, May 31, 2003 12:10 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [PWE3] RE: Is PWE a layer?
> > 
> > 
> > 
> > --- "Thomas D. Nadeau" <[email-masked]> 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 am in favor of George Swallow's original PID 
> proposal that took this into account. I believe that 
> Dave's proposal was along those lines with the exception 
> of a few bits.
> 
> 	--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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 3 Jun 2003 08:14:56 -0400

Hi,

	Just catching up on some old emails...

> Behalf Of Busschbach, Peter B (Peter)
> Sent: Thursday, May 29, 2003 6:02 PM
> To: 'Mark Seery'; David Allan
> Cc: [email-masked]
> Mark,
> I agree with many of the points that you raise. However, 
> there is one issue that keeps bothering me whenever we 
> discuss Y.1711 and LSP Ping, which you bring up in your email 
> as well. It is the notion that Y.1711 requires to a lot of 
> processing whereas LSP Ping does not.
> 
> According to Y.1711, Connection Verification messages are 
> sent at a rate of one packet per second, but "other 
> configurable CV generation rates are for further study".
> 
> Let's assume that the CV generation rate is configurable. The 
> rate required by a Service Provider depends on the client 
> service (e.g. VPLS probably doesn't require frequent CV), the 
> architecture of the MLS network (e.g. can fault detection be 
> done at a lower layer of MPLS pipes, thus reducing the number 
> of connections that need to be monitored), etc.
> 
> For the purposes of specifying OAM for PWE3, I don't think 
> there is any reason to require that the generation rate of 
> Y.1711 CV messages is necessarily higher than the generation 
> rate of LSP Ping messages.
> 
> Comparing Y.1711 and LSP Ping, I see one big difference: With 
> LSP Ping, if a PE doesn't receive a reply, it doesn't know 
> what the problem is. It is possible that the PW is down, but 
> it is also possible that the return path is unavailable. In 
> Y.1711, upstream and downstream PEs work in tandem and it is 
> the downstream PE that determines that the link is down.

	You can run LSP ping in a one-way
mode (no reply), just as you can run Y.1711, and have the
downstream LSR determine that that direction is not working.
You can also run it in normal mode from both sides
of the PW.
 
> To me it seems evident that the fault detection mechanism 
> defined in Y.1711 is superior to that of LSP Ping, no matter 
> what Tom's 25 happy customers say.

	It seems evident to me that the way to go is to 
listen to what the market and customers say are the tools
and techniques they want.

> So what exactly is the problem with adopting Y.1711 for PW 
> OAM, as long as we speciify that the CV generation rate is 
> configurable? 
	
	A few reasons. First, Y.1711 is NOT currently specified
this way, thus adopting it still requires the interval regardless
of what patches/fixes are in the works. Second, as I just 
pointed out, you can do the same things based on mechanisms 
defined here at the IETF.  Third, the mechanisms defined by the 
IETF that are already in use for other MPLS applications, 
can be re-used for PWs, thus obviating the need to implement/manage 
another mechanism for just PWE implementations.

	--Tom

> This would not require any vendor to implement 
> the function in ASICs or provide some other form of HW acceleration.
> 
> Peter
> 
> 
> > From: Mark Seery [mailto:[email-masked]]
> > Sent: Tuesday, May 27, 2003 10:00 PM
> > To: David Allan
> > Cc: [email-masked]
> > Dave,
> > The first batch of questions in my previous response
> > was to try and flush out the fact that this effort is
> > trying to meet the needs of a wide range of service
> > providers with different mindsets and business models; including 
> > stand-alone ISPs, ISPs within a carrier, carriers upgrading ATM 
> > networks to MPLS, carriers building new MPLS networks for Ethernet, 
> > etc.
> > 
> > From this flows two distinct categories of conflict:
> > 
> > 1) What can be implemented in existing equipment
> > 2) The operations culture variance among different SPs
> > 
> > Quoting from draft-allan-y1711-and-lsp-ping:
> > 
> > "LSP-PING is designed to be retrofitted to existing
> > deployed networks....."
> > "Y.1711 depends on some degree of ubiquitous
> > deployment at the edge to maximize coverage of fault detection"
> > 
> > These two comments alone lead to various substantial
> > inferences: 1) That LSP-PING can be used with existing installed 
> > equipment and that other approaches may not be optimized for that 
> > purpose and b) substantial benefits may only accrue via Y.1711 if 
> > there is ubiquity of deployment. So perhaps my previous
> > comments were badly worded if they implied that the
> > entire network needs to be replaced, but clearly there
> > is an existing assets issue here. The accomodation of
> > existing equipment and network evolution is not
> > without precedent, as an example I would cite the DSL
> > Forum's working text 81 (WT81) which proposes
> > significant capability increase to the network, but
> > clearly accomodates the presence of existing DSLAMs by
> > the creation of a new gateway function.
> > 
> > With respect to your comment that this functionality
> > is easily assumed into silicon, I'd like to first make
> > the flipant remark that a few gates here, and a few
> > gates there, and all of a sudden we are talking
> > serious silicon; or rather if you take one approach as
> > a whole and compare it to another approach as a whole,
> > on aggregate there may be significant differences. I
> > would also observe that packet processing remains bit
> > for bit significantly more expensive (in terms of
> > power at least) than TDM processing, so the packet
> > processing industry's goal as a whole should be
> > further reduction, and that additional processing
> > should be examined skeptically. This may be the wrong
> > place to cut back on, but there should be a general
> > intent to cut back on processing, (including the
> > unnecessary adding of new layers - I am not one sided
> > on this issue), where possible, and therefore we
> > should not assume that adding functionality to silicon
> > has no impact, we should justify the addition.
> > 
> > Specifically, say my PE supports 10,000 LSPs. Now the
> > design has to allow for the possibility of 10,000 OAMs
> > per second (depending on the network architecture,
> > many of them may be on the same interface). Each of
> > these OAMs requires a BIP calculation (simple logic to
> > be sure) in addition to what ever OAM processing is
> > required. The OAMs might be occurring on multiple
> > stack levels (3 or more) concurrently - so how is this impacting my 
> > pipeline? Now say there is a fault. In the midst of a 
> network error I 
> > am now creating additional processing in the form of FDI flows at
> > 1/sec. (perhaps even BDI, but most LSPs are
> > unidirectional....). So at the worst time, during a
> > fault, I am throwing even more processing in to the
> > user plane - a tractable issue (but actually an
> > interesting debate is to be had here about avoiding
> > non-linearality - yes I know, alarm storms could
> > create another type), but has to be allowed for in the
> > design. I do not say this to criticize Y.1711, I think
> > it is essential functionality for a certain type of
> > carrier, seeking to achieve certain goals - my only
> > point is that it is not clear cut to me that the
> > addition of OAM (especially for a multi-level stack of
> > indefinite depth) is painless and with out need for
> > tradeoffs in the packet processing pipeline (you can
> > do what early ATM implementations did and shunt
> > everything off to an adjunct processor, but that has
> > its own costs and complications). What would be really
> > useful is to actually have a digital logic expert
> > present on this issue - otherwise it is just opinions
> > and there is no actual engineering going on.
> > 
> > Now it is perfectly OK to implement such functionality
> > if it is highly valued by the prospective customer,
> > but it is clear that this a heterogeneous market place
> > - which is the crux of why we struggle to come to
> > consensus in areas such as this. I can well imagine it
> > being hard to go to some ISPs and justify why it was 
> implemented when 
> > it will never be used. I can just as easily imagine (in 
> fact I know) 
> > that it would be equally hard to go to some carriers and 
> justify why 
> > it was not implemented when it would be constantly used.
> > 
> > Where the process broke down, from my position on the 
> sideline in the 
> > cheap seats , was a) we as a group had a learning process 
> about how we 
> > thought of MPLS-LDP, i.e. CO, CNLS,....and that created a lot of
> > communication problems with respect to getting down to
> > the real meat of the issues and really understanding
> > the requirements (still today some people think of
> > MPLS-LDP as CO when clearly this is a really grey
> > area) b) while the IETF community understood
> > intuitively the kind of solution that was appropriate
> > to the CNLS networks of traditional target customers
> > (LSP-PING) and also for IP-VPN networks (an area which
> > I think it might be slightly stronger in, in some
> > non-trail/tunnel respects, when compared to Y.1711),
> > it was slower to understand the kind of solution that
> > was required for a carrier-class, robust SLA, CO
> > network - which based on experience is actually to be
> > expected. This may have been manifested in the
> > vilification of Y.1711 as the grand drama of
> > competitive approaches and lack of understanding
> > played out, but hopefully this can be acknowledged and
> > we can move on from here.
> > 
> > Ultimately there has to be some decision point (either 
> consciously or 
> > unconciously) by the IESG about whether we really want to merge the 
> > standards setting process for carriers, ISPs, and 
> enterprises + CO and 
> > CNLS in to one standards group; and if so, how are we going to
> > improve our sophistication about "signaling" what
> > proposal addresses what end user and what network
> > mode.
> > What I personally would like to see is as much
> > possible identification of commanility, leading to as
> > much possible reuse of PDU structures across different
> > (or subset/superset) implementations. This I think is
> > the larger tragedy that gets forgotten in the day to
> > day banter (in multiple WGs).
> > 
> > A good engineering process would, IMHO, acknowledge
> > the implications for existing equipment, acknowledge
> > where we want to be in the long run, and build a
> > roadmap to get from here to there that allows for
> > graceful evolution. This is perhaps where the mantra
> > of "one solution" may break down if we are not careful
> > (and that is not even including the issues stated
> > above WRT to different audiences and network modes).
> > Some specific comments on some snips below.
> > 
> > Thanks,
> > Mark
> > 
> > > 4) I assume the implied suggestion is that any
> > > centralized push/polling mechanism is not scalable,
> > so
> > > it can not be the long-term solution? In other
> > words,
> > > the method of invocation is kind of orthogonal as
> > long
> > > as the OAM function is doing what it needs to do;
> > the
> > > only remaining issue is whether the method of
> > > innvocation has some fundamental flaws. 
> > 
> > >>Not as much the method of invocation, it is a
> > combination of attributes: how determinitic testing
> > is, whether a fault will turn up in multiple diverse
> > places and how that is correlated such that the most
> > frugal response is possible, can responding be
> > delegated into the network etc.etc. <<
> > 
> > MS=> so now we are adding even more complexity to the
> > network element - delegated responding. So clearly two different 
> > classes of equipment are emerging with diverging paths, and 
> diverging 
> > customer bases - how to we accomodate this is one standards process?
> > 
> > > Could you be more explicit about the feedback you
> > are
> > > receiving. Is it related to the use of central
> > management tools?
> > 
> > >> The feedback is a mix depending on where the
> > carrier is using MPLS now and the experience they've
> > had, and how they envision using it in the future. <<
> > 
> > MS=> I understand the difficulty in answering the
> > question. Hopefully you understand my difficulty in 
> understanding the 
> > problem within a void of some characterization of it.
> > 
> > > I think the answer is no. And I state this only in a
> > 
> > > hope that we can reach some level of consensus
> > before
> > > continuing the logic tree.
> > 
> > >>Some potential counterpoints are:
> > 
> > 1) lots more code driving the label swapping
> > configuration and with higher frequency. As a
> > counterpoint, in an ATM PVC network, the cross connect
> > table is only touched when there is a provisioning
> > change. Even in an SVC network, a routing change
> > frequently may not change the forwarding state of the
> > switch. <<
> > 
> > MS=> Fair enough.
> > 
> > >> 2) MPLS has a label stack, so there is an extra
> > dimension to things that can go wrong. <<
> > 
> > MS=> Yes, in all forms of processing.
> > 
> > >> 3) MPLS originally assumed it would exist in a
> > hybrid IP network......<<
> > 
> > MS=> Has this changed (in the IETF)?
> > 
> > >> As far as LDP is concerned, the only question in my
> > mind is what is an appropriate response to the
> > additional modes of failure <<
> > 
> > MS=> agreed
> > 
> > >> when considering the potential frequency. <<
> > 
> > MS=> so given that LDP has been deployed, are we
> > actually seeing these types of errors with any
> > "greater" frequency. If the label mis-swap problem has
> > to be solved for any label swapping network that is
> > fine, but are we proposing something different than we
> > would for say ATM because of an assumed
> > greater/potential frequency?
> > 
> > >> Throw in the label stack as well and what you need
> > is somthing ubiquitous as the problem may not occur
> > uniquely in the LDP layer. <<
> > 
> > MS=>I assume you mean that the user plane may not be
> > carrying IP, if not then I didn't understand the
> > comment.
> > 
> > > So even though the answer is no, it is as you say a
> > > problem that other CNLS networks do not have to deal
> > 
> > > with, and therefore a problem to which a solution is
> > 
> > > required. I can envision two possible solutions: 1)
> > a
> > > P2P overlay 2) OAM messages that have the source
> > > address embedded in them (this would need to be an 
> > > interface/sub-interface address as opposed to a LSR 
> > > identifier is my guess). To me, option 2) is
> > preferable -
> > > what is wrong with this approach?
> > 
> > >> A p2p overlay is a solution, but if used in
> > isolation, you have the problem that an LDP problem
> > spills a lot of overlay p2p LSPs, therefore who owns
> > the problem. IMHO the LDP layer needs a bit of help in
> > this regard.
> > As for '2', an access point ID is the basis of the
> > villified TTSI in Y.1711. <<
> > 
> > MS=> I don't remember why the TTSI was villified
> > (though it does look like the tunnel construct is not applicable to 
> > LDP)
> > 
> > >> It is straightforward for p2p but requires the
> > egress to track many access points for mp2p. For mp2p
> > we're working on y.17fec-cv (SG13) where the FEC info
> > is encoded in the probe and that is what is checked.
> > <<
> > 
> > MS=> I couldn't see this on the ITU website, could you
> > or someone else shoot me a copy, would be interested
> > in taking a look, specifically at the TTSI.
> > 
> > > 
> > <snipped>
> > > 
> > > On the CO dimension of MPLS, it strikes me that
> > there
> > > is no RSVP-TE solution for PWE - is this correct and
> > 
> > > should this be so?
> > 
> > >> Technically an RSVP-TE LSP could carry a PW
> > directly (it does have a PID exchanged in one of the
> > objects) and not as an LDP overlay. So I'm unaware of anything that 
> > precludes this option. <<
> > 
> > MS=> I only raise this issue to ask the question that
> > if a CO mode is required, why is there not more
> > RSVP-TE based proposals for both PWE and VPLS? Clearly 
> RSVP-TE based 
> > implementation is possible.
> > > 
> > > On the issue of fault correlation, as this is
> > > inherently a multi-layer problem, can this be solved
> > 
> > > within the standards process for one layer. i.e.
> > what
> > > can be done without looking at the top to bottom
> > > solution? 
> > 
> > >> You phrase the problem strangely. <<
> >  
> > MS=> Agreed, and thanks for the explanation.
> > 
> > > >> So I would tend to characterize the debate as
> > > between those interesting in doing their perception
> > of
> > > the "right thing" where the criteria of "rightness"
> > is
> > > not necessarily aligned ;-) <<
> > > 
> > > So then you agree that both parties have good
> > > intentions to do the right thing ;-) Then it is just
> > a
> > > matter of people of good will....... ;-)
> > 
> > >> There's a few subtleties still to be addressed ;-)
> > <<
> > 
> > MS=> :-))

---

From: "Jack Pugaczewski" <[email-masked]>
Date: Tue, 3 Jun 2003 07:33:34 -0500

Great points and fully agree !

PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Thomas D. Nadeau
> Sent: Tuesday, June 03, 2003 7:15 AM
> To: [email-masked]

---

From: "David Allan" <[email-masked]>
Date: Tue, 3 Jun 2003 10:01:22 -0400

Tom:

The difference in the proposals IMO is that 1711 CV and FEC-CV PDUs are
designed to be fully processed in more or less the same number of cycles it
takes to identify that you've received an LSP ping packet. (verify BIP 16,
if function code x compare field y and you are done).

That LSP PING can run in one way mode doesn't change this. It should stick
to ad-hoc ping/loopback, which it is good at.

Dave

> Sent: Tuesday, June 03, 2003 8:15 AM
> To: [email-masked]
> You can also run it in normal mode from both sides of the PW.
>  
> this way, thus adopting it still requires the interval 
> regardless of what patches/fixes are in the works. Second, as I just 
> trying to meet 
> > > the needs of a wide range of service providers with different 
> > > mindsets and business models; including stand-alone ISPs, ISPs 
> > > within a carrier, carriers upgrading ATM networks to 
> MPLS, carriers 
> > > building new MPLS networks for Ethernet, etc.
> > > 
> > > "LSP-PING is designed to be retrofitted to existing deployed 
> > > networks....." "Y.1711 depends on some degree of ubiquitous
> > > power at least) than TDM processing, so the packet processing 
> > > industry's goal as a whole should be further reduction, and that 
> > > additional processing should be examined skeptically. This may be 
> > > the wrong place to cut back on, but there should be a general
> design has to 
> > > allow for the possibility of 10,000 OAMs per second (depending on 
> > > the network architecture, many of them may be on the same 
> > > interface). Each of these OAMs requires a BIP calculation (simple 
> > > logic to be sure) in addition to what ever OAM processing is
> unidirectional....). So 
> > > at the worst time, during a fault, I am throwing even more 
> > > processing in to the user plane - a tractable issue (but 
> actually an
> the real meat 
> > > of the issues and really understanding the requirements 
> (still today 
> > > some people think of MPLS-LDP as CO when clearly this is a really 
> > > grey
> non-trail/tunnel 
> > > respects, when compared to Y.1711), it was slower to 
> understand the 
> > > kind of solution that was required for a carrier-class, 
> robust SLA, 
> > > CO network - which based on experience is actually to be
> proposal addresses 
> > > what end user and what network mode.
> > > > 4) I assume the implied suggestion is that any centralized 
> > > > push/polling mechanism is not scalable,
> > > so
> > > MS=> so now we are adding even more complexity to the network 
> > > element - delegated responding. So clearly two different 
> classes of 
> > > equipment are emerging with diverging paths, and
> > diverging
> table is only 
> > > touched when there is a provisioning change. Even in an 
> SVC network, 
> > > a routing change frequently may not change the forwarding 
> state of 
> > > the switch. <<
> > > 
> > > MS=> Fair enough.
> > > 
> would for say 
> > > ATM because of an assumed greater/potential frequency?
> > > 
> carrying IP, if 
> > > not then I didn't understand the comment.
> > > 
> > > > can be done without looking at the top to bottom solution?
> > >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 3 Jun 2003 10:26:32 -0400

> another mechanism for just PWE implementations.

Tom,

It seems that we are moving towards consensus. As I have stated in earlier emails, my main concern is with the fault detection mechanism that we specify. If we can agree on the need for a one-way, perdiodic check, we have made progress. At this point, I don't care whether the Connection Verification message is an LSP Ping message or a Y.1711 CV message. Or better, I think the Y.1711 CV message requires less processing, but I have no reason to believe that an LSP Ping message could not serve the same purpose.

Do you plan to add the one-way, periodic mode for LSP Ping to your VCCV document?

Peter

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 3 Jun 2003 13:41:43 -0400

> Sent: Tuesday, June 03, 2003 11:31 AM
> To: 'Busschbach, Peter B (Peter)'; [email-masked]
> > From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
> > Sent: Tuesday, June 03, 2003 10:27 AM
> > To: [email-masked]'; [email-masked]

[clipped]

> > It seems that we are moving towards consensus. As I have 
> > stated in earlier emails, my main concern is with the fault 
> > detection mechanism that we specify. If we can agree on the 
> > need for a one-way, perdiodic check, we have made progress. 
> > At this point, I don't care whether the Connection 
> > Verification message is an LSP Ping message or a Y.1711 CV 
> > message. Or better, I think the Y.1711 CV message requires 
> > less processing, but I have no reason to believe that an LSP 
> > Ping message could not serve the same purpose.
> 
> 	Excellent. 
> 
> 	I agree with you that a one-way mechanism is needed.
> As I stated earlier, one is available in LSP ping. Since
> VCCV uses LSP ping as a payload type, it can thus 
> leverage this mode as well.  However, based on your suggestion,
> we should add some text to the draft that explains this
> more explicitly.
> 
> 	--Tom
> 
> 

Great! Looking forward to the new draft.

Peter

[clipped]

---

From: "David Allan" <[email-masked]>
Date: Tue, 3 Jun 2003 14:25:03 -0400

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.

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. 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. 

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. 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.

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?

cheers
Dave

> Sent: Tuesday, June 03, 2003 8:23 AM
> To: 'Mark Seery'
> Cc: [email-masked]
> 	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
> 
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 3 Jun 2003 15:27:36 -0400

> From: Luca Martini [mailto:[email-masked]]
> Sent: Tuesday, June 03, 2003 3:13 PM
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [PWE3] RE: Is PWE a layer?
> 
> 
> Tom, Peter,
> 
> I agree with the need for fault detection mechanism on a PW, 
> but right now 
> level3 has designed and deployed a PW ping based solution 
> that works quite well.

Luca,

Do you carry Frame Relay and ATM over your MPLS network? I can see that Ping is sufficient for VPLS and VPWS, but I know carriers who are offering Frame Relay service today and who want to extend those across an MPLS core, who need OAM functions similar to what they get today from an ATM core network.

The problem with regular (bi-directional) Ping is that it is a poor mechanism to localize failures. If a PE doesn't receive a reply, it doesn't know whether the forward or backward PW is down. In fact, it could even be that neither the forward nor backward PW is down, but that there is a problem in the control plane. Uni-directional Ping would solve that problem.

Peter

> I think LSP ping builds on existing IETF well understood 
> standards, and is in 
> my mind the only logical solution to this problem.
> Since the PWs are bi-directional , and IP seems to be quite 
> manageable with 
> ping, I do not see what the need for a unidirectional ping is ?
> 
> Luca
> 
> 
> 
> Busschbach, Peter B (Peter) wrote:
> > 
> >>>>networks to MPLS, carriers building new MPLS networks for 
> >>>
> >>Ethernet, 
> >>
> >>>>etc.
> >>>>
> >>>>stack levels (3 or more) concurrently - so how is this 
> >>>
> >>impacting my 
> >>
> >>>>unconciously) by the IESG about whether we really want to 
> >>>
> >>merge the 
> >>
> >>>>customer bases - how to we accomodate this is one 
> >>>
> >>standards process?
> >>
> >>>>(though it does look like the tunnel construct is not 
> >>>
> >>applicable to 
> >>
> >>>>LDP)
> >>>>
> >>>>
> >>>>objects) and not as an LDP overlay. So I'm unaware of 
> >>>
> >>anything that 
> >>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 3 Jun 2003 15:33:48 -0400

> From: David Allan [mailto:[email-masked]] 
> Sent: Tuesday, June 03, 2003 2:25 PM
> To: [email-masked]'; 'Mark Seery'
> Cc: [email-masked]
> 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

---

From: "David Allan" <[email-masked]>
Date: Tue, 3 Jun 2003 16:22:54 -0400

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 

> Sent: Tuesday, June 03, 2003 3:34 PM
> To: Allan, David [CAR:NS00:EXCH]; 'Mark Seery'
> Cc: [email-masked]
> 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, 
> 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
> 	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.
>  
> 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.
> > > 
> 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.
> > > > 
> > > > 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:
> > > >