Subject: Re: RE: Is PWE a layer?

From: George Swallow <[email-masked]>
Date: Tue, 03 Jun 2003 11:12:30 -0400

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

The one-way mode is part of LSP-Ping.  But some details on how to use
it for CV need to be added to VCCV.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 3 Jun 2003 11:30:57 -0400

> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
> Sent: Tuesday, June 03, 2003 10:27 AM
> To: [email-masked]'; [email-masked]
> Subject: RE: [PWE3] RE: Is PWE a layer?
> 
> 
> 
> 
> > -----Original Message-----
> > From: Thomas D. Nadeau [mailto:[email-masked]]
> > Sent: Tuesday, June 03, 2003 8:15 AM
> > To: [email-masked]
> > Subject: RE: [PWE3] RE: Is PWE a layer?
> > 
> > 
> > 
> > 	Hi,
> > 
> > 	Just catching up on some old emails...
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Busschbach, Peter B (Peter)
> > > Sent: Thursday, May 29, 2003 6:02 PM
> > > To: 'Mark Seery'; David Allan
> > > Cc: [email-masked]
> > > Subject: RE: [PWE3] RE: Is PWE a layer?
> > > 
> > > 
> > > 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
> > 
> 
> Tom,
> 

	Hi Peter,

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

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

	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

> Peter 
> 
> 
> > 
> > 
> > > This would not require any vendor to implement
> > > the function in ASICs or provide some other form of HW 
> acceleration.
> > > 
> > > Peter
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Mark Seery [mailto:[email-masked]]
> > > > Sent: Tuesday, May 27, 2003 10:00 PM
> > > > To: David Allan
> > > > Cc: [email-masked]
> > > > Subject: RE: [PWE3] RE: Is PWE a layer?
> > > > 
> > > > 
> > > > 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=> :-))
> > > > _______________________________________________
> > > > pwe3 mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > > 
> > > _______________________________________________
> > > 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: Luca Martini <[email-masked]>
Date: Tue, 03 Jun 2003 13:12:38 -0600

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.
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:
>>downstream LSR determine that that direction is not working.
>>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 
>>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
>>
> 
> 
> 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 
> 
> 
> 
>>
>>>the function in ASICs or provide some other form of HW acceleration.
>>>
>>>Peter
>>>
>>>
>>>
>>>>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.
>>>>
>>>>"LSP-PING is designed to be retrofitted to existing
>>>>deployed networks....."
>>>>"Y.1711 depends on some degree of ubiquitous
>>>>equipment and that other approaches may not be optimized for that 
>>>>purpose and b) substantial benefits may only accrue via Y.1711 if 
>>>>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,
>>>>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
>>>>am now creating additional processing in the form of FDI flows at
>>>>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
>>>>- 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 
>>>
>>>>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
>>>>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
>>>>improve our sophistication about "signaling" what
>>>>proposal addresses what end user and what network
>>>>mode.
>>>>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
>>>>>4) I assume the implied suggestion is that any
>>>>>centralized push/polling mechanism is not scalable,
>>>>
>>>>so
>>>>
>>>>>only remaining issue is whether the method of
>>>>>innvocation has some fundamental flaws. 
>>>>
>>>>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 
>>>
>>>>MS=> I understand the difficulty in answering the
>>>>question. Hopefully you understand my difficulty in 
>>>
>>>understanding the 
>>>
>>>>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
>>>>would for say ATM because of an assumed
>>>>greater/potential frequency?
>>>>
>>>>
>>>>is somthing ubiquitous as the problem may not occur
>>>>uniquely in the LDP layer. <<
>>>>
>>>>carrying IP, if not then I didn't understand the
>>>>comment.
>>>>
>>>>
>>>>>problem that other CNLS networks do not have to deal
>>>>
>>>>>P2P overlay 2) OAM messages that have the source
>>>>>address embedded in them (this would need to be an 
>>>>>identifier is my guess). To me, option 2) is
>>>>
>>>>preferable -
>>>>
>>>>spills a lot of overlay p2p LSPs, therefore who owns
>>>>the problem. IMHO the LDP layer needs a bit of help in
>>>>this regard.
>>>>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.
>>>><<
>>>>
>>>>>On the issue of fault correlation, as this is
>>>>>inherently a multi-layer problem, can this be solved
>>>>
>>>>>intentions to do the right thing ;-) Then it is just
>>>>
>>>>a
>>>>