Subject: Is PWE a layer?

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 19 May 2003 08:22:37 +0300

> > Therefore, in answer to Mark's question below, I
> > think the PWE's OAM needs to resemble ATM's OAM in
> > order to make PWE a suitable vehicle for carrying
> > Frame Relay services.
> 
> Which still leaves the question is PWE adaptation glue
> or a layer. If it is a layer, then I am a little
> confused about why MPLS and L2TP were created, but
> that's probably a different thread ;-)

So let's start that thread.

First, is MPLS a layer network?
Although originally thought of as an in-between shim,
it later became "layer 2.5" and we now certainly seem to be 
making it into a full layer network.

By elevating it to a network we define not only its
user plane protocols, OAM, etc., we also invent
new terminology and a whole new group of experts
who are more familiar with it than those layers
above and below it.

If we now turn the PWE into a new layer
between MPLS and the payload, then in addition to 
the encap protocols and the terminology we have already defined,
we must start the formal treatment of control and management issues.

As Mark asks, do we really need ANOTHER full network layer
in between, or can PWs simply transparently carry EVERYTHING
(OAM in addition to user data) transparently?

As long as we limit ourselves to the pure network interworking
case, we don't - we can leave PWs as an encap-only technology.

In network interworking one carries the native service's OAM messages,
while in service interworking one needs to translate states.
So as long as we keep service interworking out of scope, 
we don't need "PW-OAM", and the answer to Mark's question
is that we DON'T want to make PW into a layer network.

Once service interworking IS allowed, the present PWE encap technology 
is no longer sufficient anyway.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 19 May 2003 09:35:07 +0300

> Wondering why service interworking requires that PW be
> a layer. 1483 and 1490 are interworked without the
> requirement that they be layers - or did I
> misunderstand?

Mark, 

Perhaps I am not understanding your question,
so please let me define my terms.

By network interworking I mean tunelling a native service
over a network, with the SAME native service at both edges.

Thus both 1483 and 1490 provide mechanisms for network interworking, 
e.g. IP datagrams over ATM or FR relay, respectively.

By service interworking I mean connecting DIFFERENT
native services to the edges of a network, 
without first providing an IWF that converts one of the native services
to the other.

Thus connecting a FR service to one edge and an ATM service
to the other edge is service interworking. However, if I first
convert the FR into ATM, or the ATM into FR, and use a pure FR
or pure ATM encap PW, then this is still network interworking.

Since network interworking has like services at both edges,
we can transparently tunnel the OAM as well,
and the PW can be a pure encap format,
and needn't be a "layer".

True service interworking is more complex. For example, 
assume network of type A is connecting to network of type C
over a transporting network B. 
It is required to translate A's defect states into native B format
at the A-B edge, and then translate them into C's format at edge B-C.

To understand why this is absolutely required, consider
that in the true service interworking scenario, network A
does not know what the native format of network C is - 
it might be FR or it might be ATM, etc.
So the A-B edge can not "pre-translate" the messages
into C format. This is particular acute in p2mp scenarios.

Of course we COULD get away with such translations.
For example, although network C does not know a priori
what type of network A is, this COULD be kludged by having part of the 
B network format include the source network type, and to place at the egress edge
the intelligence to "post-translate" messages. 
Or we could signal C's network type back to A at setup,
and perform the pre-translation. But, in addition to being undesirable,
these kludges effectively make the scenario network interworking
at the control plane, even if the user plane is service interworking.

So what did you mean by 1483-1490 interworking?

Y(J)S

---

From: Mark Seery <[email-masked]>
Date: Mon, 19 May 2003 00:13:14 -0700 (PDT)

Yaakov,

--- Yaakov Stein <[email-masked]> wrote:
> By network interworking I mean tunelling a native
service over a network, with the SAME native service
at both edges. <

Agreed.
 
> Thus both 1483 and 1490 provide mechanisms for
network interworking, e.g. IP datagrams over ATM or FR
relay,  respectively. <

Hmmmmm, they both provide a mechanism for identifying
what the upper layer protocol is in the frame being
sent over that VC. They are an adaptation layer. When
I think of networking interworking I think of
standards like FRF 5 where the client layer
characteristics are actually mapped to the underying
service layer, i.e. ATM ensures that the Frame Relay
service gets the support it needs so that the ATM
network is transparent to each end, and the integrity
of the Frame Service is maintained.

> [SNIP]...Thus connecting a FR service to one edge
and an ATM service  to the other edge is service
interworking. <

Agreed.

> However, if I first convert the FR into ATM, or the 
ATM into FR, and use a pure FR or pure ATM encap PW,
then this is still network interworking. <

Hmmmmmm, not sure. From the end-to-end point of view
it would seem there is some service interworking.
Certainly in FRF8 (FR/ATM Service interworking) frame
is converted to ATM.

> Since network interworking has like services at both
edges, we can transparently tunnel the OAM as well,
and the PW can be a pure encap format, and needn't be
a "layer". <

Agreed on PW encap. Whether SPs want to take advantage
of an underlying segment OAM by mapping (interworking)
client / server OAMs I do not know. For example
interworking Frame and MPLS OAM (hypothetically
speaking because I don't think Frame OAM supports
segment OAM).

> [SNIP] True service interworking is more
complex.......<

Agreed
 
> So what did you mean by 1483-1490 interworking?

I was referring to the translation mode ("Mode 2") of
FRF 8 (FR/ATM PVC service interworking)

Mark

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 19 May 2003 16:25:14 +0300

> of the Frame Service is maintained.

You are saying that 1483/90 are deficient network interworking,
and I agree.

> Certainly in FRF8 (FR/ATM Service interworking) frame

Right. What I am saying is that from the PW point of view,
there is NO service interworking, that is no 
"service interworking over MPLS".
The service interworking being performed is direct FR-ATM
service interworking, and does not impact the PW.

> FRF 8 (FR/ATM PVC service interworking)

That's what I thought (see my comment above).

My bottom line is that we needn't reinvent the wheel
because of the requirement for what you called 
"end-to-end service interworking".

If we can do the interworking before we get to the MPLS
network, we can stick to PWs and bypass the issue.

The question is whether we want to make MPLS
into the new "universal network", relegating all others
to status of legacy access technologies.
Were this to happen, then indeed one access network
might not know what the other access network's type is.

In THAT case we can no longer use PWs, and have to go
for true service interworking with MPLS.

Y(J)S

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 19 May 2003 15:18:41 -0400

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Monday, May 19, 2003 1:23 AM
> To: Mark Seery; [email-masked]
> Cc: [email-masked]
> Subject: Is PWE a layer?
> 
> 

Yaakov,

My view:

- No, we don't need another full network layer
- Yes, PWs can (must) carry everything, including client-layer OAM traffic.
 
But there are a few caveats:

a) TTL > 2
Eric Rosen made the point that there are cases in which it makes sense to splice PWs together and switch based on the PW label. IMO, that turns the "PW layer" into an MPLS layer.
(It makes you wonder why there is a PW layer in the first place. Why not define how to adapt client traffic to MPLS (i.e. remove the demultiplexing function from PWE) and leave it to the service provider to decide whether there is a need for additional aggregation via MPLS label stacking.)

b) There is a need for OAM in the server layer.
When a service provider carries encapsulated traffic through a nation-wide core network, it is not enough to merely have a continuity check between the encapsulation point and the decapsulation point. E.g. if a failure occurs in the core network, the service provider needs to be able to determine as precisely as possible what the failure is and where it is located.

c) OAM and MPLS
In an MPLS network with MP2P and ECMP it is hard to do good OAM (see Neil's emails). Hence, the proposal in the VCCV draft to encapsulate the Ping message with the same label stack as the client traffic, including the PW label.

In an earlier email, I made the argument that if you can't do OAM in the MPSL layer, you need to treat the PW as a point-to-point link and do OAM on the PW. However, this is far from ideal. Since the PW is essentially a direct link between two peers, you can't use it for fault localization in the core network. 

The more I think about it, the more I believe that:

(1) You need robust OAM in the MPLS layer. If you have MPLS OAM you don't need PW OAM.

(2) in the absence of MPLS OAM, you might decide to do connectivity verification on a per-PW basis, but it is a poor alternative.

Peter

---

From: [email-masked]
Date: Mon, 19 May 2003 21:13:27 +0100

Well done Peter!  You are starting to piece it all together now....once you
grasp what is really needed it becomes obvious.  It becomes even more
obvious in the case of service-interworking if one does the proper G.805
functional modelling (and I know some guys working on that right now), which
is a precursor to building good information models for management.

regards, Neil

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: 19 May 2003 20:19
> To: 'Yaakov Stein'; Mark Seery
> Cc: [email-masked]
> Subject: [PWE3] RE: Is PWE a layer?
> 
> 
> 
> 
> Eric Rosen made the point that there are cases in which it 
> makes sense to splice PWs together and switch based on the PW 
> label. IMO, that turns the "PW layer" into an MPLS layer.
> (It makes you wonder why there is a PW layer in the first 
> place. Why not define how to adapt client traffic to MPLS 
> (i.e. remove the demultiplexing function from PWE) and leave 
> it to the service provider to decide whether there is a need 
> for additional aggregation via MPLS label stacking.)
> 
> When a service provider carries encapsulated traffic through 
> a nation-wide core network, it is not enough to merely have a 
> continuity check between the encapsulation point and the 
> decapsulation point. E.g. if a failure occurs in the core 
> network, the service provider needs to be able to determine 
> as precisely as possible what the failure is and where it is located.
> 
> c) OAM and MPLS
> In an MPLS network with MP2P and ECMP it is hard to do good 
> OAM (see Neil's emails). Hence, the proposal in the VCCV 
> draft to encapsulate the Ping message with the same label 
> stack as the client traffic, including the PW label.
> 
> In an earlier email, I made the argument that if you can't do 
> OAM in the MPSL layer, you need to treat the PW as a 
> point-to-point link and do OAM on the PW. However, this is 
> far from ideal. Since the PW is essentially a direct link 
> between two peers, you can't use it for fault localization in 
> the core network. 
> 
> (2) in the absence of MPLS OAM, you might decide to do 
> connectivity verification on a per-PW basis, but it is a poor 
> alternative.
> 
> Peter
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Mark Seery" <[email-masked]>
Date: Mon, 19 May 2003 22:26:44 -0700

Hi Yaakov,

[Multiple SNIPs]

>> You are saying that 1483/90 are deficient network interworking,
and I agree. <<

But I didn't say they are defficient encapsulation mechanisms.

>> The service interworking being performed is direct FR-ATM
service interworking......<<

agreed

>>....., and does not impact the PW. <<

But can this be said if PW has OAM?

>> If we can do the interworking before we get to the MPLS
network, we can stick to PWs and bypass the issue. <<

I assume you mean X to MPLS interworking, where X is Frame, ATM,
Etherent,.......?
So what is the point of using PWE in this case. No encapsulation is needed
because interworking has already occurred. Some muxing layer perhaps?

into the new "universal network", relegating all others
to status of legacy access technologies. <<

Actually in a "universal network" MPLS is the access technology ;-)

Seriously, I know what you mean.

>> Were this to happen, then indeed one access network might not know what
the other access network's type is. <<

If there is a service interworking function, not simply by virtue of
encapsulation.

>> In THAT case we can no longer use PWs, and have to go for true service
interworking with MPLS. <<

Agreed.

Mark

---

From: "Mark Seery" <[email-masked]>
Date: Mon, 19 May 2003 22:56:10 -0700

Peter,

[SNIP]

>> Since the PW is essentially a direct link between two peers, ......<<

Which is probably why the Frame Relay OAM model appeared to be applicable.
Perhaps it was also the focus on a connectivity test.

>> .....you can't use it for fault localization in the core network. <<

Agreed

>> (1) You need robust OAM in the MPLS layer. If you have MPLS OAM you don't
need PW OAM. <<

Peter, agreed.

However, systems vendors do have this practical issue though that the server
layer may terminate on a different line card than where the client layer
originates, and therefore the server layer OAM does not provide an
end-to-end mechanism. Now the proper way to solve this is to get the client
layer to create an OAM mechanism. So just say one of the clients you want to
support is "owned" by a standards body not interested in pursuing such a
capability. You might then be tempted to create an in between layer that
gets originated on the client layer's line card, and then give it an OAM
mechanism. And of course now that single OAM mechanism can be used for
multiple clients. Sounds attractive.

Alternate solutions would be to move the server OAM termination to the line
card where the client layer originates , or to move the encapsulation to the
line card where the server layer originates; of the two, I think the later
makes the most sense - but for a variety of reasons, system architectures do
not always evolve this way.

Now if you do actually do the PWE encapsulation on the line card where the
client layer originates, and the PWE OAM terminates on that line card, then
you have created an OAM problem. When you run PWE OAM, what are you testing?
The PSN, or the client layer? What you have created is a client layer OAM,
but you are calling it a PWE OAM, but it may not go end to end because the
PWE OAM does not go end-to-end, only over the PSN "segment" of the client
layer; so you do not actually have a client-layer OAM.

So in a round about way, what I am saying, is I can see the practical reason
of why PWE OAM looks attractive, most especially for Ethernet (in fact if
Ethernet OAM is not created, then vendors will have to create something
proprietary); but I do agree it creates problems, and ultimately, it may not
solve the problem it is intended to.

So as an industry, we must work to make sure client layer OAMs are created,
otherwise non-optimal solutions will be created, and in fact there will be
no choice but to create them, or make sure that systems are architected in a
certain way, which may not create optimal engineering choices; and of course
there is no doubt the old installed base problem.

Mark

---

From: "David Allan" <[email-masked]>
Date: Wed, 21 May 2003 14:04:38 -0400

Hi Peter:

<snipped>

> - No, we don't need another full network layer

Agreed, if the PW is MPLS I thought we had one already ;-).

> label. IMO, that turns the "PW layer" into an MPLS layer. (It 
> makes you wonder why there is a PW layer in the first place. 
> Why not define how to adapt client traffic to MPLS (i.e. 
> remove the demultiplexing function from PWE) and leave it to 
> the service provider to decide whether there is a need for 
> additional aggregation via MPLS label stacking.)

I think this is a key point, I'm certainly in favor of common label
semantics to simplify implementation.

> as precisely as possible what the failure is and where it is located.

IMHO fault management is most frugally performed at the transport layer
although it must also exist to some degree at the PW layer. Performance
management hits both as well, network planners need the transport
measurements, and SLA reporting needs the PW measurements.

> stack as the client traffic, including the PW label.

Key thing is that ECMP (depending on the implementation) currently breaks
path semantics any IP payload and/or use of reserved labels. So explicit V4
as a PID, OAM alert and Router alert all have ECMP implementations that
break their use. VCCV is one response, but requires an LDP adjacency to
configure the meaning of the VCCV bit. IMHO I'd prefer the PID approach
(however it manifests itself) as the ECMP "immune" payload self identifies.

> between two peers, you can't use it for fault localization in 

One problem is sorting out the operational framework, once you move past the
ability to detect problems, you then need the ability to react appropriately
across the layers, transport, PW and PW client. Hierarchy and aggregation
mean that a single failure can impact a large number of monitored entities
(both transport and PW). Most problems will be isolated naturally (loss of
light etc.), but if you overlay e2e detection mechanisms on the network
(which you do need in some form to bridge into client OAM) and you start to
distribute that functionality into the NEs, then the issue is not one of
fault isolation but fault correlation. 

> OAM you don't need PW OAM.

You need some functionality at each layer to bridge the operational
paradigms of each layer together. Operational discontinuities between layers
are a scaling nightmare as "problem ownership" does not percolate upwards. 

Agreed.

Dave

---

From: Shahram Davari <[email-masked]>
Date: Wed, 21 May 2003 11:40:24 -0700

Mark,

>layer to create an OAM mechanism.

In that case the OAM of the in-between layer is only testing the
faults between two line cards in a single switch/router. This can
be accomplished using an internal/proprietory OAM between line cards,
and does not need inventing edge-to-edge OAM for the in-between layer.

-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Wed, 21 May 2003 11:43:19 -0700

>for additional aggregation via MPLS label stacking.)

If PW labels could be switched like MPLS labels, then why can't MPLS-ping be used to test it? 

-Shahram

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 21 May 2003 14:51:57 -0400

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Wednesday, May 21, 2003 2:43 PM
> To: 'Busschbach, Peter B (Peter)'; 'Yaakov Stein'; Mark Seery
> Cc: [email-masked]
> Subject: RE: [PWE3] RE: Is PWE a layer?
> 
> 
> >a) TTL > 2

Shahram,

My statement should be read in the context of the question: is PW an adaptation function or a network layer in itself. My point was: if you use intermediate nodes to switch based on the PW Label, then it becomes a network layer in itself.

Can one use Ping to test it? Yes, of course. Was there anything in my mail that gave you the impression that I thought one couldn't?

I still have a question about Ping, though. Is it the intention that Ping messages be sent periodically? The vccv draft doesn't specify this. IMO, for fault management you need a periodic connectivity check and you need to define how you determine that there is a defect. Is it when you miss one reply or only after missing multiple replies? Frankly, you need a state machine as defined in Y.1711.

Peter

---

From: Shahram Davari <[email-masked]>
Date: Wed, 21 May 2003 12:12:04 -0700

Peter,

>My statement should be read in the context of the question: is 
>PW an adaptation function or a network layer in itself. My 
>point was: if you use intermediate nodes to switch based on 
>the PW Label, then it becomes a network layer in itself.
>
>Can one use Ping to test it? Yes, of course. Was there 
>anything in my mail that gave you the impression that I 
>thought one couldn't?

No, I just wanted to bring people's attention to this issue.

>
>I still have a question about Ping, though. Is it the 
>intention that Ping messages be sent periodically? The vccv 
>draft doesn't specify this. IMO, for fault management you need 
>a periodic connectivity check and you need to define how you 
>determine that there is a defect. Is it when you miss one 
>reply or only after missing multiple replies? Frankly, you 
>need a state machine as defined in Y.1711.

Agree. Since MPLS-ping is a loopback mechanism, it seems that
the period, processing, state machines, etc, are local matter to the
source and probably don't need standardization. But off course if a service
provider wants to offer a consistent service SLA across its network, then these issues need to be nailed down.

-Shahram

---

From: Mark Seery <[email-masked]>
Date: Wed, 21 May 2003 12:19:25 -0700 (PDT)

Hi Sharam,

Comments below,
Mark

--- Shahram Davari <[email-masked]>
wrote:
> Mark,
> 
> 
> >However, systems vendors do have this practical
> issue though 
> >that the server
> >layer may terminate on a different line card than
> where the 
> >client layer
> >end-to-end mechanism. Now the proper way to solve
> this is to 
> >get the client

So let me start by saying I think PWE OAM is a mistake
in principal (architecturally speaking - under any
circumstances) and a mistake in practice unless we can
not get these other issues resolved. There are some
big picture issues which play in here with respect to
PWEs role and x/MPLS vs x/IP - but perhaps that should
be a separate thread.

Now to your point. In the absence of an edge-to-edge
OAM, how are you going to know where the problem is in
the first place to go use the proprietary OAM between
the line cards? You then have to go running the
proprietary OAM on every edge to find out where the
problem is don't you? Isn't this a lot of work for the
operator, not to mention the impact on historical
verification of SLAs and pinning down transient
errors. So then I guess you should run the proprietary
OAM constantly. Now what, do you interwork it with the
server layer, do you treat it as a client layer.....?
It is really the same problem all over again.

Clearly the solution is a) only design systems in
certain ways or b) work with client layers to make
sure they have the OAM they want. I think operators
might want to have a chat with their vendors and
understand a) before they put a hard stake in the
ground on this one. b) is preferrable but the
cooperation of other organizations is not exactly
guaranteed.

If as an industry we can't rely on client layers
having their own OAM, then we have to force the PSN
processing (for example MPLS) back to the client
service interface (as we do today with TDM networks)
or create an in-between kludge. Forcing the PSN
processing back to the client interface essentially
means that vendors have to develop two cards. One is a
cost effective card that does not have the PSN
processing, the other is a more expensive card that
does have the PSN processing. The reason I say this is
because MPLS processing, which essentially means IP as
well, is non trivial today; much more say than TDM
processing (and even if it is not, market forces with
create a pricing difference to the operator). This is
further complicated by the fact that for similar
reasons, vendors will often have two versions of the
network-side card already.

My preference would be for the IETF to go back to
client layer organizations and let them know that
services can not be offered using their technology,
that have strong SLAs, unless they do certain things.
In the case of Ethernet, EFM has already done some
work on OAM which **may** be a start. If this option
is seen as beeing too much work (and too much delay to
get solutions in to the field), then we are left with
a kludge by any method, vendors creating two different
solutions, or some other trickery to extend the PSN
OAM back to the client interface (but then I would ask
are you testing what you think you are testing? - but
it can be done).

If the above logic is right, and obviously interested
in your feedback, then it is just one of those
unfortunate real world issues where principal meets
reality (for some transient period of time = the time
it takes to make MPLS or other PSNs a commodity
technology - which it is far from today).

Mark

---

From: Shahram Davari <[email-masked]>
Date: Wed, 21 May 2003 12:58:04 -0700

Mark,

>PWEs role and x/MPLS vs x/IP - but perhaps that should

Agree.

>operator,

I don't think so. This is confined within a box and should
be easily configurable.

 ?ot to mention the impact on historical
>OAM constantly.

Yes, my suggestion was to run it continuously.

>Now what, do you interwork it with the

I think you have to generate AIS on the payload the PW
is carrying such as ATM AIS.

>that have strong SLAs, unless they do certain things.

Agreed. As I said before the tunnel LSP (and even
the multiplexing LSP) could be tested using MPLS-ping.
If the client/server mapping needs to be tested then client segment 
OAM should be used. If that is not available, then the client/server
mapping can't be tested.

-Shahram

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 21 May 2003 16:26:22 -0400

> Sent: Wednesday, May 21, 2003 3:12 PM

[snipped] 

> provider wants to offer a consistent service SLA across its 
> network, then these issues need to be nailed down.
> 
> -Shahram
> 

Shahram,

I think you need a tighter coupling between both ends of a PW than LSP Ping provides. E.g. the downstream end should generate an alarm if it doesn't receive the periodic connectivity verification message (which could be the same LSP Ping message, but with different semantics) from the upstream end. To enable such behavior, you need a standardized solution.

Peter

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 21 May 2003 16:55:04 -0400

> From: Mustapha Aissaoui [mailto:[email-masked]]
> Sent: Wednesday, May 21, 2003 4:36 PM
> To: Busschbach, Peter B (Peter)
> Cc: 'Shahram Davari'; 'Yaakov Stein'; Mark Seery; [email-masked]
> Subject: Re: [PWE3] RE: Is PWE a layer?
> 
> 

[snipped]

> 
> A Ping mechanism is similar to a connectivity verification
> mechanism. This is not suited for alarm indication/suppression. It
> is intended to be mostly proactive and can have a significant
> processing impact on the node for monitoring a large number of
> entities. 
> Let us consider again the scenario of ATM-MPLS-FR service
> interworking, with local termination of ATM and FR at each PE. If
> the ATM port in the ingress PE fails, you need to generate a
> reactive alarm indication on all PWs which are sourced on this port
> to inform the remote PE of the defect. You need to be able to do
> that without injecting connectivity verification traffic. A
> lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is
> more suitable.

Thanks, Mustapha.

Two things:

- If an ATM port fails, the ATM NSP function should generate the appropriate I.610 messages. This is independent of whether the port is a PW or otherwise. I think you agree with that, but your comment somehow links ATM port failures with injecting connectivity verification, which confuses me. I would think it is the other way around: through connectivity verification you find that a PW is down, which is reported to the NSP, which in turn will generate AIS and RDI.

- I don't have any experimental evidence that LSP Ping is too heavy-weight to serve as a periodic connectivity verification messages. I leave that to the experts to decide.

Peter

---

From: [email-masked]
Date: Wed, 21 May 2003 23:05:42 +0100

Hi Mustapha......Please see below. regards, Neil

Mustapha Aissaoui wrote 21 May 2003 21:36
<snipped>
> lightweight mechanism such as I.610 AIS/RDI or Y.1711 FDI/BDI is

This is how to trivially interwork ATM and MPLS as peer layer networks (aka
service-interworking).  Note:
-	assumes defect detection/handling is unidirectional, and implemented
as an inherent property (ie distributed/automatic executive action) of the
trail sink (which was effectively a point I saw Peter B make earlier about
requiring simple 'state machines' defined in Y.1711);
-	assumes all defects are unambiguously specified, ie entry-exit
criteria and consequent actions (all done in Y.1711);
-	assumes we run CV/CC in each technology partition in a sort of
'segment' sense (using I.610 terminology);
-	but map FDI/AIS and BDI/RDI across IWF to reflect defects in other
technology partition;
-	may need new DT (defect type) for FDI/AIS and BDI/RDI to reflect
'other partition' detected defect;
-	in following description I have used CV, FDI and BDI as the generic
terms for either MPLS or ATM case......to save repeating as the functions
are similar.

Network model:
[CPEa]-------ATM partition-------{IWF}--------MPLS partition-------[CPEm]

Consider 2 cases of L1 defects and L2 defects.  In former case we have a
simple L2/L1 client/server (aka network-interworking) defect handling model
(as there are L1 trails between adjacent L2 nodes in either ATM or MPLS
partitions), whilst in L2 case we have the peer mode (aka
service-interworking).
 
L1 DEFECTS 
 
(i) In direction *towards* IWF:
FDI mapped up from L1 to ATM or MPLS partition as relevant.  At IWF incoming
FDI suppresses alarm that would otherwise exist from missing CV.  FDI mapped
immediately across to other partition in 1:1 fashion and CV generation there
suppressed.  There is now a question wrt to BDI.  Does this get mapped back
at the IWF *or* do we wait for the BDI to come back from far-end CPE, eg for
failure in ATM partition above this would be CPEm?  Note - In next case
considered only a simple mapping across the IWF is required, which tends to
suggest waiting for a far-end CPE BDI reflection is the simplest solution.
The alternative is to 'OR' this at the IWF for defects in direction towards
the IWF.
 
(ii) In direction *towards* CPE:
FDI mapped up from L1 to ATM or MPLS partition as relevant.  At CPE (either
a or m) incoming FDI suppresses alarm that would otherwise exist from
missing CV.  Incoming FDI at CPE generates corresponding BDI towards IWF.
BDI must have 1:1 mapping across IWF.  Note in this case the CV flow in the
partition *not* affected by the failures carries on as normal (and in *both*
directions here).
 
L2 DEFECTS
 
(i) In direction *towards* IWF:
At IWF defects detected from CV flow (consequent actions are dependent on
type of defect).  FDI generated immediately in other partition and CV
generation there suppressed.  We have the same question as before as to
whether the BDI is generated at the IWF.  However, like suggested before I
propose we either wait for a far end CPE turn round and then do 1:1 mapping
across IWF or do an 'OR' on this with a locally turned-round BDI.
 
(ii) In direction *towards* CPE:
At CPE (either a or m) defects detected from CV flow (consequent actions are
dependent on type of defect).   CPE generates corresponding BDI towards IWF
in other direction.  BDI must have 1:1 mapping across IWF.  Note in this
case the CV flow in the partition *not* affected by the failures carries on
as normal (and in *both* directions here).

And it's as simple as that.

Now I saw Mark raise questions about layer network technologies that don't
have proper OAM specified.  Well, the right answer is to fix the problem in
the layer network in question.  Note that this could be either a client or
server layer when a pair of technologies is being considered in such a
relationship.  You can of course rely on the server to proxy for missing
client defect detection *iff* we are considering client/serrver network
interworking....but of course this assumes the server layer is *not*
functionally deficient.  The wrong answer (under all circumstances) is to
create such functionality in some new entity that resides between the client
and server layers (this should be simple adaptation).  The folly of this
idea should be obvious, but if its not think what this means when one wants
to have peer service-interworking between 2 technologies....all of sudden
this artifical entity has disappeared!

regards, Neil

---

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 21 May 2003 18:23:06 -0400

Peter,
see a couple of clarification points below.

Regards,
Mustapha.
------------
"Busschbach, Peter B (Peter)" wrote:
> - If an ATM port fails, the ATM NSP function should generate the >appropriate I.610 messages. This is independent of whether the port is a >PW or otherwise. I think you agree with that, but your comment somehow >links ATM port failures with injecting connectivity verification, which >confuses me. I would think it is the other way around: through >connectivity verification you find that a PW is down, which is reported >to the NSP, which in turn will generate AIS and RDI.

Maybe I misunderstood what you said. I thought you were describing a
method relying on turning connectivity verification on all PWs in
the egress PE in order to detect such a failure of a ATM port in the
ingress PE.

My point was that it is more suitable to have a built in fault
indication mechanism to inform the egress PE that the PWs sourced on
the failed ingress PE ATM port are in defect state. But because in
the scenario above ATM is terminated at the ingress PE, you cannot
use ATM AIS but will need a defect indication mechanism for the PW
or inner LSP. The ATM facing side of the PE will continue to operate
as in I.610.
 
> - I don't have any experimental evidence that LSP Ping is too >heavy-weight to serve as a periodic connectivity verification messages. >I leave that to the experts to decide.

I do not have any evidence about LSP Ping either. I meant that using
connectivity verification for detecting a failure is process
intensive because it requires injecting OAM messages continuously.
You do not expect a service provider to run continuously
connectivity verification on all connections (be they VCs, PWs, or
what have you) in the hope to catch a failure. Connectivity
verification has a different role than alarm indication. So for
fault management of PWs, we need both alarm indication/suppression
and connectivity verification. I noticed most of the discussion on
this list focused on the latter and omitted the former.

---

From: "Himanshu Shah" <[email-masked]>
Date: Thu, 22 May 2003 09:14:42 -0400

Another approach to connection verification 
is to have ingress PE notify egress PE about
the status of the AC via PWE3 control signaling
(in lieu of withdrawing VC label which is what
the current approach is).

The PWE3 status signaling can also be used by
the head end PE to notify the status of his PW
(in the event tunnel carrying the PW is
inoperational).

I find low grade loopbacks such as ping or 
in line notification via some control bits in
the control word, less appealing.

Such extensions to PWE3 control signaling has
been proposed by an extension draft.

There is, however, one disadvantage to this approach.
It does not detect compromised forwarding 
capability of PE (PW handoff) or P (tunnel traffic
propagation) if the control elements on the 
affected box does not detect it either.

/himanshu
wavesmith networks

PS. It seems that this discussions is repeating.

> > My statement should be read in the context of the question: 
> is PW an adaptation function or a network layer in itself. My 
> intention that >Ping messages be sent periodically? The vccv 
> draft doesn't specify this. >IMO, for fault management you 
> need a periodic connectivity check and you >need to define 
> how you determine that there is a defect. Is it when you 
> >miss one reply or only after missing multiple replies? 
> Frankly, you need >a state machine as defined in Y.1711.
>

---

From: "David Allan" <[email-masked]>
Date: Thu, 22 May 2003 11:16:26 -0400

Hi, reply in line...

I think you're confusing notification with verification. I think there is
agreement that notification of attachment circuit status is required and
this is required for proper alarm suppression. I think there is general
agreement that label withdrawl as a notification mechanism is not a good
idea. However IMHO there are numerous mechanisms available ranging from
service OAM (e.g. I.610 AIS), PW data plane and PW control plane. 
[Himanshu>] I am wondering why notification is not adequate for
verification. 

[Dave] I don't think we're talking the same language. I think of
notification as informing peer systems of a problem, and verification as
performing some type of probing action to detect a problem.  Detection
results in notification...

> (in the event tunnel carrying the PW is 

This comment I did not understand. COuld you clarify the scenario you are
discussing. 
[Himanshu>] I am refering to the status of the unidirectional VC-LSP. 2
VC-LSPs make PW bidirectional. Each head end PE is responsible for
notification of status changes of his AC and VC-LSP. 

[Dave] My question is more how does the head end PE know the status of his
PW. A secondary issue would be that if there is a PW failure, there is a
possiblity of control plane discontinuity as well. 

> the control word, less appealing. 

I'm curious as to your reasoning, as the net result of  control plane
notification frequently would be some type of dataplane action in the far
attachment circuit.
[Himanshu>]  I am referring to method of connection verification via
notification only when the status changes. For example, if you are
terminating FR AC, I believe you can respond to LMI status query locally
without generating in line ping over PW. If the status changes (as notified
by PW3-control), receiving PE would generate LMI async status for the
corresponding AC. 

[DAVE] IMHO apriori distribution of e2e status  is not verification. Some
mechanism is required to determine the status of each disjoint piece of
technology before such status information is available for distribution...I
do agree that the information should be distributed rather than having to be
queried.

I think the disconnect is that in your description above, you are proposing
an alternative to triggering a ping as a result of an LMI status query. I
would not so tightly couple the maintenance entities. If the PW is broken,
it should be known independent of the AC OAM mechanisms and the network be
able to distribute that information to the AC facing PEs.

cheers

Dave

---

From: "David Allan" <[email-masked]>
Date: Thu, 22 May 2003 13:25:21 -0400

Himanshu:

I think we are misunderstanding each other.

Agreed ;-)

I am assuming that underlying tunnelling
mechanisms is used to determine the
status of the PW. Sort of like, if interface goes
down, so does the DLCIs. If tunnel status is
down, so are the PWs mapped on it.

Yes, although actually determining the tunnel is "down" in the presence of
LDP, ECMP etc. it a good trick. IMHO I'd rather see the PWs inherit "down"
status from the tunnel status but I do not think that is always possible.
With ECMP, you may see failure of only a subset of the PWs carried by the
tunnel. Or your ability to detect PSN problems may be much slower than the
PW client OAM mechanisms...

If LDP is used as tunneling than it is possible that
tunnel going down also translates to inability to
signal PW status. But in this case, LDP session
will go down too. However, in case of RSVP-TE,
tunnel may take diff path than directed LDP session
and tunnel going down does not translate to inability
to signal PW status.

BTW, I am not proposing that ping be triggered. All 
I am saying is that I don't see a need to generate at
some time intervals to verify the PW connection. It
has scalability issues. 

Agreed, as mentioned above, would prefer to inherit availability from teh
tunnel and simply cover off corner cases...
 
Dave 

/himanshu

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Thursday, May 22, 2003 11:16 AM
To: Himanshu Shah; Mustapha Aissaoui; Busschbach, Peter B (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery; [email-masked]
Subject: RE: [PWE3] RE: Is PWE a layer?

Hi, reply in line...

cheers

Dave

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 22 May 2003 14:04:55 -0400

> Sent: Wednesday, May 21, 2003 6:23 PM
[snipped]

> or inner LSP. The ATM facing side of the PE will continue to operate

Mustapha,

Just to be precise: PWE is a form of network interworking, not service interworking. Therefore, ATM in not "terminated" in the PE. All ATM traffic, including OAM cells, is carried over PWs.

Your email suggests that you believe AIS and RDI can not be carried over PWs and that therefore there is a need for some kind of fault indication message to convey failures on the access circuit. That is incorrect.

There are two scenarios.

1) An access circuit fails. In that case, the NSP function in the PE that interfaces with that access circuit will generate the appropriate AIS and RDI messages. 

2) A PW between two PEs fails. The downstream PE will find out because the PW connectivity verification check fails. The downstream PE will generate AIS and RDI. In fact, it will generate an RDI message that is sent to the upstream PE over the "return PW".

I can see only one scenario where you need an additional PW error indication message: if for some reason it is possible that the NSP function in a PE goes down, while the PW adaptation function still works (e.g. when the two are implemented on different circuit packs), then it might be necessary to inform the remote PE of that condition. However, one could probably just rely on the continuity check in the client layer.

Peter

> > - I don't have any experimental evidence that LSP Ping is 
> too >heavy-weight to serve as a periodic connectivity 
> verification messages. >I leave that to the experts to decide.
>

---

From: "David Allan" <[email-masked]>
Date: Thu, 22 May 2003 09:51:55 -0400

Himanshu:

<snipped to end>

Dave

---

From: "Himanshu Shah" <[email-masked]>
Date: Thu, 22 May 2003 10:52:44 -0400

Comments in line.

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Thursday, May 22, 2003 9:52 AM
To: Himanshu Shah; Mustapha Aissaoui; Busschbach, Peter B (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery; [email-masked]
Subject: RE: [PWE3] RE: Is PWE a layer?

Himanshu: 

I think you're confusing notification with verification. I think there is agreement that notification of attachment circuit status is required and this is required for proper alarm suppression. I think there is general agreement that label withdrawl as a notification mechanism is not a good idea. However IMHO there are numerous mechanisms available ranging from service OAM (e.g. I.610 AIS), PW data plane and PW control plane. 
[Himanshu>] I am wondering why notification is not adequate for verification.

> (in the event tunnel carrying the PW is 

This comment I did not understand. COuld you clarify the scenario you are discussing. 
[Himanshu>] I am refering to the status of the unidirectional VC-LSP. 2 VC-LSPs make PW bidirectional. Each head end PE is responsible for notification of status changes of his AC and VC-LSP.

> the control word, less appealing. 

I'm curious as to your reasoning, as the net result of  control plane notification frequently would be some type of dataplane action in the far attachment circuit.
[Himanshu>]  I am referring to method of connection verification via notification only when the status changes. For example, if you are terminating FR AC, I believe you can respond to LMI status query locally without generating in line ping over PW. If the status changes (as notified by PW3-control), receiving PE would generate LMI async status for the corresponding AC.

/himanshu

<snipped to end> 

Dave

---

From: "Himanshu Shah" <[email-masked]>
Date: Thu, 22 May 2003 11:47:48 -0400

/himanshu

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Thursday, May 22, 2003 11:16 AM
To: Himanshu Shah; Mustapha Aissaoui; Busschbach, Peter B (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery; [email-masked]
Subject: RE: [PWE3] RE: Is PWE a layer?

Hi, reply in line...

[Dave] I don't think we're talking the same language. I think of notification as informing peer systems of a problem, and verification as performing some type of probing action to detect a problem.  Detection results in notification...

[Dave] My question is more how does the head end PE know the status of his PW. A secondary issue would be that if there is a PW failure, there is a possiblity of control plane discontinuity as well. 

[DAVE] IMHO apriori distribution of e2e status  is not verification. Some mechanism is required to determine the status of each disjoint piece of technology before such status information is available for distribution...I do agree that the information should be distributed rather than having to be queried.

I think the disconnect is that in your description above, you are proposing an alternative to triggering a ping as a result of an LMI status query. I would not so tightly couple the maintenance entities. If the PW is broken, it should be known independent of the AC OAM mechanisms and the network be able to distribute that information to the AC facing PEs.

cheers

Dave

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 22 May 2003 14:39:20 -0400

Peter,
I think we are in agreement for the network interworking case. I was
referring to a service interworking case where each Layer 2 access
technology is terminated locally at a PE.

Regards,
Mustapha.
----------

---

From: [email-masked]
Date: Thu, 22 May 2003 17:30:34 +0100

Hi Dave...I agree with your comments....but wish to add a small extra point.
regards, Neil

NH=>Date-plane defect handling should be automatic/executive, independent of
the control-plane signalling (and must work the same with no signalling) and
be unidirectional, ie actions are to be taken at the sink.

NH=> Correct.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 May 2003 15:38:30 -0400

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Busschbach, Peter B (Peter)
> Sent: Wednesday, May 21, 2003 4:26 PM
> To: 'Shahram Davari'; Busschbach, Peter B (Peter); 'Yaakov 
> Stein'; Mark Seery
> Cc: [email-masked]
> > Agree. Since MPLS-ping is a loopback mechanism, it seems that the 
> > period, processing, state machines, etc, are local matter to the 
> > source and probably don't need standardization. But off course if a 
> > service provider wants to offer a consistent service SLA across its

	And that is precisely what my customers are doing -- nailing
down the problem based on local constraints.  Even in a
multi-vendor network, this still works. There is no need for
the tools to mandate specifically how they should be used.

	--Tom

> > 
> > -Shahram
> > 
> 
> Shahram,
> 
> I think you need a tighter coupling between both ends of a PW 
> than LSP Ping provides. E.g. the downstream end should 
> generate an alarm if it doesn't receive the periodic 
> connectivity verification message (which could be the same 
> LSP Ping message, but with different semantics) from the 
> upstream end. To enable such behavior, you need a 
> standardized solution.
> 
> Peter

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 May 2003 15:48:42 -0400

> Behalf Of Mustapha Aissaoui
> > > >Eric Rosen made the point that there are cases in which it makes 
> > > >sense to splice PWs together and switch based on the PW 
> label. IMO, 
> > > >that turns the "PW layer" into an MPLS layer. (It makes 
> you wonder 
> > > >why there is a PW layer in the first place. Why not 
> define how to 
> > > >adapt client traffic to MPLS (i.e. remove the demultiplexing 
> > > >function from PWE) and leave it to the service provider 
> to decide 
> > > >whether there is a need for additional aggregation via 
> MPLS label 
> > > >stacking.)
> > >
> is PW an 
> > adaptation function or a network layer in itself. My point 
> was: if you 
> > use intermediate nodes to switch based on the PW Label, then it 
> > becomes a network layer in itself.
> > 
> anything in my 
> > mail that gave you the impression that I thought one couldn't?
> > 
> intention that 
> > >Ping messages be sent periodically? The vccv draft doesn't specify 
> > this. >IMO, for fault management you need a periodic connectivity 
> > check and you >need to define how you determine that there is a 
> > defect. Is it when you >miss one reply or only after 
> missing multiple 
> > replies? Frankly, you need >a state machine as defined in Y.1711.
> 
> mechanism. This is not suited for alarm 
> indication/suppression. It is intended to be mostly proactive 
> and can have a significant processing impact on the node for 
> monitoring a large number of entities. 

	Not necessarily. The triggering of CV (whether 
VCCV, ICMP ping or LSP ping) can be automated on a device, 
and this can be done in such a way as to have
minimal impact on the device's CPU. This same device 
can also be programmed to trigger or suppress alarms 
based on the status of such actions.  

	But arguing about this in theory is a waste of 
time. The proof is in the pudding, so check the 
implementations that have implemented these tools 
and see how scalable they are. As usual, the market
will decide which solutions are most appropriate.

> interworking, with local termination of ATM and FR at each 
> PE. If the ATM port in the ingress PE fails, you need to 
> generate a reactive alarm indication on all PWs which are 
> sourced on this port to inform the remote PE of the defect. 
> You need to be able to do that without injecting connectivity 
> verification traffic. A lightweight mechanism such as I.610 
> AIS/RDI or Y.1711 FDI/BDI is more suitable. 

	Since Y.1711 only works for MPLS 
as the PSN, this doesn't seem appropriate for PWE3 which
must have solutions that work for both L2TPv3 and MPLS.
BTW, VCCV works for both L2TPv3 and MPLS as of the next 
draft, and provides a consistent interface for operators
regardless of the underlying PSN or VC type being
tested.

	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 22 May 2003 16:14:43 -0400

> Sent: Thursday, May 22, 2003 3:45 PM
> To: [email-masked]'; Busschbach, Peter B (Peter); 
> 'Shahram Davari'; 'Yaakov Stein'; 'Mark Seery'
> Cc: [email-masked]
> > > draft doesn't specify this. IMO, for fault management you 
> > > need a periodic connectivity check and you need to define how 
> > > you determine that there is a defect. Is it when you miss one 
> > > reply or only after missing multiple replies? 
> > 
> > 	This is more of an operational issue.
> > My team and I have spoken to over 25 operators about VCCV and
> > LSP Ping, and all 25 give me preciesely different answers about 
> > how often they want to run either tool. It depends largely on 
> > the application being used, as well as the SLA. Based on these
> > data points, the VCCV draft does not specify any periodicity.
> > 
> > > Frankly, you need a state machine as defined in Y.1711.
> > 
> > 	This is contrary to the aforementioned customer
> > input I have received.
> > 
> 
> Tom,
> 
> When you say "how often they want to run the tool", what is 
> the model?:
> 
> a) the operator (or network management system) instructing 
> the PE to execute LSP Ping
> 
> or,
> 
> b) the PE autonomously generating LSP Ping messages.
> 
> In case of b), is a failure on the PW translated to an alarm 
> indication in the client layer (e.g. ATM AIS/RDI)?

	Both, and not necessarily one or the other (i.e.:
some like a combination of the two simultaneously).  
As I mentioned, I have spoken to a lot of customers 
about using this tool, and all of them like using 
LSP ping/VCCV, but all of them have different ideas 
about just how to use these tools.  Many have different
ideas about how to use the tools *together* as well, BTW. 
Some want to run the tools from remote management stations 
(and have it integrated into their existing OSS), while 
others want the device to do as much as possible and only 
tell them when something has gone really wrong (i.e.: the 
device cannot fix things itself), at which point they
might do ad hoc trouble-shooting using one or more of the
tools (vrf-aware ping, LSP ping, ICMP ping, VCCV).

	--Tom

> Thanks,

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 22 May 2003 16:15:36 -0400

Tom,

> based on the status of such actions.

Sure. Nontheless, a ping mechanism is a query mechanism. You need to
turn it on continously on LSPs in order to catch a fault. Fault
detection should be automatic and OAM messages are only generated at
the detection of a fault for the impacted LSPs only.

Though connectivity verification is important for detecting
discontinuity in the user plane which are not the result of a
physical layer fault or which are not detected through the control
plane.
 
> and see how scalable they are. 

Good for you :-)

>As usual, the market

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 22 May 2003 15:45:25 -0400

[snipped]

Tom,

When you say "how often they want to run the tool", what is the model?:

a) the operator (or network management system) instructing the PE to execute LSP Ping

or,

In case of b), is a failure on the PW translated to an alarm indication in the client layer (e.g. ATM AIS/RDI)?

Thanks,

Peter

---

From: Mark Seery <[email-masked]>
Date: Thu, 22 May 2003 14:21:51 -0700 (PDT)

Hi Tom,

> data points, the VCCV draft does not specify any

Good to see you are getting much feedback. Was curious
what your team/25 operators have been hearing about
the interworking of these mechanisms to other networks
and the "theoretical" problem caused by the PWE
"layer" disappearing when you do; and whether theye
are concerned with interworking applications.

And of course whatever your thoughts are on the
subject.

Thanks,
Mark

---

From: "David Allan" <[email-masked]>
Date: Fri, 23 May 2003 13:10:57 -0400

Tom:

As the previous VCCV draft used LDP as a negoitation/configuration
mechanism, and either ICMP PING or LSP-PING as the test protocol, could you
outline how this combination is applicable to L2TPv3? Or is VCCV a generic
term that can have many instantiations?

Dave

> Sent: Thursday, May 22, 2003 4:16 PM
> To: [email-masked]
> Cc: 'Busschbach, Peter B (Peter)'; 'Shahram Davari'; 'Yaakov 
> Stein'; 'Mark Seery'; [email-masked]
> > > > > If PW labels could be switched like MPLS labels, then 
> why can't 
> > > > > MPLS-ping be used to test it?
> > > > >
> > > >
> > > > Shahram,
> > > >
> indication/suppression. It 
> > VCCV, ICMP ping or LSP ping) can be automated on a device, and this 
> > can be done in such a way as to have minimal impact on the device's 
> > CPU. This same device can also be programmed to trigger or suppress 
> > alarms based on the status of such actions.
> 
> Sure. Nontheless, a ping mechanism is a query mechanism. You 
> need to turn it on continously on LSPs in order to catch a 
> fault. Fault detection should be automatic and OAM messages 
> are only generated at the detection of a fault for the 
> impacted LSPs only.
> 
> physical layer fault or which are not detected through the 
> control plane.
>  
> implementations that 
> > have implemented these tools and see how scalable they are.
> 
> Good for you :-)
> 
> >As usual, the market
> > BTW, VCCV works for both L2TPv3 and MPLS as of the next draft, and 
> > provides a consistent interface for operators regardless of the 
> > underlying PSN or VC type being tested.
> > 
> >         --Tom
> >

---

From: [email-masked]
Date: Fri, 23 May 2003 18:20:56 +0100

Something is awry with mail I think......however just to respond to Tom's
point (though I await the orginal).  I believe this is misinformation.  I
assume you (tom) were discussing LDP and specifically the rfc2547
application when you spoke to those 25 operators?  You certainly were when
you came to see us in BT.  Further, we made it quite clear to you that when
we consider X/MPLS we want Y.1711.....and I thought you understood that too.
LSP-Ping is no answer here.

regards, Neil

> Sent: 22 May 2003 20:45

---

From: [email-masked]
Date: Fri, 23 May 2003 11:13:29 +0100

Hi Mustapha...please see below for an answer to your question.  regards,
Neil

> 
> Neil,
> thanks for the details. My main point in the message to Peter, and
> you said that below too, was that the forward and backward defect
> indication should be automatic and not be queried for. While
> connectivity verification is a query mechanism.
> 
> Also, see a question below.
> 
> Mustapha.
> ----------
> [email-masked] wrote:
> 
> [snipped]
>  
> > L2 DEFECTS
> > 
> > generation there suppressed.  
> 
> I am not sure I understand why the CV generation in the defect-free
> partition should be suppressed. Since the ATM and MPLS (innel LSP)
> are peer layers in this case, I would have thought that the CV in
> the other partition should continue to operate since it checks only
> that parition.
NH=> The simple answer is that architecturally one should never allow both a
valid CV (ie contains expected TTSI) and an FDI flow together on the same
trail.  Further, defect processing is only based on the CV (both entry and
exit criteria) to decouple it from user traffic behaviour and to ensure
consistent (and effectively simultaneous) recovery of nested trails after a
failure is corrected (there are several subtle issues here wrt I.610 that I
don't want to get into on mail....would take to long to explain.  If you
want to know more give me a call.).

Y.1711 is about as sparse/powerful as you can get for a defect
detection/handling solution in *any* co pkt-sw technology.  It corrects all
(or at least I tried as best I could) of the problems I discovered in I.610.
Indeed, Y.1710 is effectively a statement of the requirements to force these
corrections.

regards, Neil

---

From: Shahram Davari <[email-masked]>
Date: Fri, 23 May 2003 06:57:30 -0700

>regardless of the underlying PSN or VC type being

The only thing in Y.1711 that is MPLS specific is the identification
of OAM packets. Everything else in Y.1711 applies to any co-pkt-sw network.
Pretty much like VCCV in which you are reusing LSP-ping for any PSN type, but without explicit null label.

-Shahram

---

From: "Mark Seery" <[email-masked]>
Date: Fri, 23 May 2003 20:52:45 -0700

Tom,

>> Tom: We do have a real implementation of any-to-any PWE3, so yes our
customers are interested in these issues. As with like-to-like, we are
providing customers with LSP ping/VCCV/ICMP ping as well as other automated
tools both now and very soon to solve the any-to-any case, which seems to
satisfy the requirements we are getting. I won't get into more details here,
but if you are interested more, contact me off-line. <<

Will do, thanks for the offer, very interested in how it is going in the
real world - certainly an important data point.

>> Tom: Regarding the theoretical "layer" disappearing and causing problems,
I personally think it is a bit of a red herring that the layering purists
are trying to use to obfuscate things. <<

I assume you mean to have Y.1711 adopted, or some draft that encapsulates
it? Certainly in a number of WGs we see strong advocation for various
approaches, by the primary authors/promoters - and clearly the last year has
seen strong disagreement and conflict over a number of OAM issues; so I can
understand the frustration you express, especially in light of pressures we
all feel to help our customers move forward with solutions/services and keep
the industry moving. Hopefully the organization/system has a framework that
encourages us all to rise above our personal interests and provide
facilitation of our differences and move towards solutions which we can feel
good about; alternatively, an organization that attempts to serve the needs
of such a broad range of service providers is going to encourage this kind
of tension, unless very special people (and there are precious few of them)
are able to step in with broad competence and broker understanding and
progress. So while we try to do this **incredibly** difficult thing of
trying to create a common framework over both CO and CNLS networks, we will
have to expect these kind of problems.

FWIW, I do perceive a deep commitment to these layered principles of network
architecture, a sense of investment from many years of developing and using
these principles, and a real belief that they deliver important benefits. I
have to admit to finding these principles one tool (I try not to use one
data point to the exclusion of others), among a number, that is useful in
thinking through certain issues. I will however concede that despite the
fact that in theory CNLS networks comply to layered principles, these
layered principles do seem to me, who probably does not understand them as
well as I should, to be more intuitive to CO networks, which might be one of
the problems we are finding in trying to create a common framework above
both CO and CNLS networks.

We also have to find ways to balance short-term vs long-term interests. We
can not focus on the short-term to the exculsion of the long-term, and
vice-versa we can not focus on the long-term to the exclusion of people's
and organizations short-term success, careers, etc. I do feel that examining
some of these layering issues might be one tool we can use to examine the
impact on our long-term interests.

I also understand it is challenging to be a leader and author as yourself,
because it is always easier to criticize and modify, than to do the original
creation.

I think we need to evaluate whether the framework we are working under is
inevitably going to create conflict, or whether we just need to work harder
at finding a common ground. I often think people get in to personal conflict
because of the environment they are working in, sometimes more than because
of the individuals involved (it can go both ways of course).

>> Tom: I personally think that this issue needs to be addressed and spelled
out clearly based on the requirements so that defect handling is well
defined. If it is, then both devices and management systems can have a
well-defined set of actions and assumptions about what to do when defects
occur, and how to possibly handle them. <<

That sounds more than reasonable to me.

Best,
Mark

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 27 May 2003 08:37:48 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Himanshu
Shah
Sent: Thursday, May 22, 2003 11:48 AM
To: David Allan; Mustapha Aissaoui; Busschbach, Peter B (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery; [email-masked]
Subject: RE: [PWE3] RE: Is PWE a layer?

 

    As with any tool, when used incorrectly undesired 
results will occur. If used wisely however, a tool such
as LSP ping/VCCV can be quite effective AND scalable.
 
    --Tom

 
/himanshu

-----Original Message-----
From: David Allan [mailto:[email-masked]]
Sent: Thursday, May 22, 2003 11:16 AM
To: Himanshu Shah; Mustapha Aissaoui; Busschbach, Peter B (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery; [email-masked]
Subject: RE: [PWE3] RE: Is PWE a layer?

Hi, reply in line...

cheers

Dave

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 27 May 2003 08:43:53 -0400

-----Original Message-----
From: David Allan [mailto:[email-masked]] 
Sent: Friday, May 23, 2003 1:11 PM
To: 'Mustapha Aissaoui'; [email-masked]
Cc: 'Busschbach, Peter B (Peter)'; 'Shahram Davari'; 'Yaakov Stein'; 'Mark
Seery'; [email-masked]

Tom: 

    The next version of the VCCV draft will include full support for L2TPv3
and should be out this week.

    --Tom

Dave

---

From: "Himanshu Shah" <[email-masked]>
Date: Tue, 27 May 2003 09:47:42 -0400

[Himanshu>] On demand connection verification using
LSP Ping/VCCV can indeed be very effective. However,
I am skeptical on how continuous monitoring for fault 
detection of few hundred thousands PWs by all PE peers
using LSP Ping/VCCV could be scalable.
 
Perhaps you could address this issue in your next revision of
VCCV draft.
 
regards,
himanshu
 
 ----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Tuesday, May 27, 2003 8:38 AM
To: [email-masked]
Subject: RE: [PWE3] RE: Is PWE a layer?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Himanshu Shah
Sent: Thursday, May 22, 2003 11:48 AM
To: David Allan; Mustapha Aissaoui; Busschbach, Peter B (Peter)
Cc: Shahram Davari; Yaakov Stein; Mark Seery; [email-masked]
Subject: RE: [PWE3] RE: Is PWE a layer?

<snip>

 
    --Tom

---

From: "David Allan" <[email-masked]>
Date: Tue, 27 May 2003 10:26:07 -0400

Mark:

> I personally think it is a bit of a red herring that the 
> layering purists are trying to use to obfuscate things. <<
> 
> I assume you mean to have Y.1711 adopted, or some draft that 
> encapsulates it? Certainly in a number of WGs we see strong 
> advocation for various approaches, by the primary 
> authors/promoters - and clearly the last year has seen strong 
> disagreement and conflict over a number of OAM issues; so I 
> can understand the frustration you express, especially in 
> light of pressures we all feel to help our customers move 
> forward with solutions/services and keep the industry moving. 
> Hopefully the organization/system has a framework that 
> encourages us all to rise above our personal interests and 
> provide facilitation of our differences and move towards 
> solutions which we can feel good about; alternatively, an 
> organization that attempts to serve the needs of such a broad 
> range of service providers is going to encourage this kind of 
> tension, unless very special people (and there are precious 
> few of them) are able to step in with broad competence and 
> broker understanding and progress. So while we try to do this 
> **incredibly** difficult thing of trying to create a common 
> framework over both CO and CNLS networks, we will have to 
> expect these kind of problems.

I trying to understand the fundamentals under your words above and the
aspersions cast as to motivations of proponents of different solutions.

Underlying this whole OAM discussion is a more fundamental tension as to
whether OAM means functionality pushed into the network fabric, and designed
as an operational system, or whether at least initial instantiations of this
are a centralized bolt-on box that uses telnet etc. to periodically poke the
network and direct boxes to ping specific resources. The network is a
system, or the system is overlaid upon the network. 

I see this as an issue independent of personal agendas, or layering. Large
carriers do have paranoia based upon experience with this technology. Some
may claim that layering is a red herring, that's not the anecotal feedback I
get from folks who've deployed 2547 networks. 

LDP and PWs do pose a challenge as we are overlaying CO networks on
Connectionless behavior, and there are many issues with how one
operationalizes this in a scalable fashion and harmonizes this with the
service carried (which may have its own OAM, e.g. ATM I.610). IMHO
insufficient thought has been given to the problem space whereby MPLS
introduces path failures into what normally is a connectionless hop by hop
network. 
Simply overlaying path testing and measurement is not necessarily a scalable
answer, as if you tighten your criteria, it breaks quite promptly as you
cannot rationalize both e2e testing and hop by hop testing without some
centralized fault correlation function; the more you are testing
simultaneously, the more indications of failure a centralzied system needs
to process when somthing goes wrong. IMHO more functionality needs to be
pushed into the network elements for this to scale (and appropriately filter
fault indications) and has been noted this means specifying much more than
has been done to date. Similarly there is a connection oriented dimension to
MPLS that suffers a dearth of tools as most of the engergy has been focused
on replicating IP. 

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 ;-)

cheers
Dave 

> 
> FWIW, I do perceive a deep commitment to these layered 
> principles of network architecture, a sense of investment 
> from many years of developing and using these principles, and 
> a real belief that they deliver important benefits. I have to 
> admit to finding these principles one tool (I try not to use 
> one data point to the exclusion of others), among a number, 
> that is useful in thinking through certain issues. I will 
> however concede that despite the fact that in theory CNLS 
> networks comply to layered principles, these layered 
> principles do seem to me, who probably does not understand 
> them as well as I should, to be more intuitive to CO 
> networks, which might be one of the problems we are finding 
> in trying to create a common framework above both CO and CNLS 
> networks.
> 
> We also have to find ways to balance short-term vs long-term 
> interests. We can not focus on the short-term to the 
> exculsion of the long-term, and vice-versa we can not focus 
> on the long-term to the exclusion of people's and 
> organizations short-term success, careers, etc. I do feel 
> that examining some of these layering issues might be one 
> tool we can use to examine the impact on our long-term interests.
> 
> I also understand it is challenging to be a leader and author 
> as yourself, because it is always easier to criticize and 
> modify, than to do the original creation.
> 
> I think we need to evaluate whether the framework we are 
> working under is inevitably going to create conflict, or 
> whether we just need to work harder at finding a common 
> ground. I often think people get in to personal conflict 
> because of the environment they are working in, sometimes 
> more than because of the individuals involved (it can go both 
> ways of course).
> 
> out clearly based on the requirements so that defect handling 
> is well defined. If it is, then both devices and management 
> systems can have a well-defined set of actions and 
> assumptions about what to do when defects occur, and how to 
> possibly handle them. <<
>

---

From: Mark Seery <[email-masked]>
Date: Tue, 27 May 2003 11:43:02 -0700 (PDT)

Thanks Dave.

Enjoyed reading your response.

Comments below,
Mark

>> Dave: Underlying this whole OAM discussion is a
more fundamental tension as to whether OAM means
functionality pushed into the network fabric, and
designed as an operational system, or whether at least
initial instantiations of this are a centralized
bolt-on box that uses telnet etc. to periodically poke
the network and direct boxes to ping specific
resources. The network is a system, or the system is
overlaid upon the network. <<

If I am understanding what you are saying, then this
raises the following questions (in my mind):

1) If I am a service provider that wants to offer a
best effort, low operations overhead service, that
philisophically believes in "lazy error checking",
should I have to pay the burden of this capability
being incorporated into the network?

2) If I am a service provider that has a great deal of
installed equipment and I want to test market a
service, or see it as not ever being very large,
should I have to replace all my equipment to provide
that service?

3) What role does a centralized bolt-on solution
provide in the standards process. For example, if by
such stroke of luck we were to reach consensus about
the long-term requirements for OAM, would we forgo
standardization of an approach that allows service
providers to leverage their existing assets?

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.

>> Dave: I see this as an issue independent of
personal agendas, or layering. <<

If I understood you correctly, then yes I agree.

>> Large carriers do have paranoia based upon
experience with this technology. Some may claim that
layering is a red herring, that's not the anecotal
feedback I get from folks who've deployed 2547
networks. <<

Could you be more explicit about the feedback you are
receiving. Is it related to the use of central
management tools?

>> LDP and PWs do pose a challenge as we are
overlaying CO networks on Connectionless behavior, and
there are many issues with how one operationalizes
this in a scalable fashion and harmonizes this with
the service carried (which may have its own OAM, e.g.
ATM I.610). IMHO insufficient thought has been given
to the problem space whereby MPLS introduces path
failures into what normally is a connectionless hop by
hop network. <<

I have now come to the conclusion, that you obviously
did some time ago, that LDP-MPLS (I think we should
get in the habit of being specific and not just saying
MPLS) uses hop-by-hop identifiers in the user plane,
but those identifiers do not represent connections
(and hence do not require connection state within the
transit nodes) they represent FECs. So at this point,
I would have to say I am trending towards the position
that LDP-MPLS is a CNLS network, with the complication
of having CO fault modes introduced through incorrect
label swapping. To this then I would respond, is it
any more likely that LDP-MPLS would create incorrect
label swapping, than in any other CO network? 

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.

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?

>> Simply overlaying path testing and measurement is
not necessarily a scalable answer, as if you tighten
your criteria, it breaks quite promptly as you cannot
rationalize both e2e testing and hop by hop testing
without some centralized fault correlation function;
the more you are testing simultaneously, the more
indications of failure a centralzied system needs to
process when somthing goes wrong. IMHO more
functionality needs to be pushed into the network
elements for this to scale (and appropriately filter
fault indications) and has been noted this means
specifying much more than has been done to date.
Similarly there is a connection oriented dimension to
MPLS that suffers a dearth of tools as most of the
engergy has been focused on replicating IP. <<

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?

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?

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

Mark

---

From: "David Allan" <[email-masked]>
Date: Tue, 27 May 2003 16:23:47 -0400

> Enjoyed reading your response.

Good...;-), replies in line

<snipped>
> philisophically believes in "lazy error checking", should I 
> have to pay the burden of this capability being incorporated 
> into the network?

The "burden" you refer to is a function of commoditization (and the
corresponding "ease of commoditization"). The good news about Moore's law is
that relative to the cost of other components (optics, lasers etc.), adding
packet processing capability drops in relative cost quite quickly. If you
believe that any solution in this space will migrate to some form of H/W
assist, the cost will be built into your gear at some point whether you use
it or not and compared to the overall complexity of the system, will only be
a small component. 

> installed equipment and I want to test market a service, or 
> see it as not ever being very large, should I have to replace 
> all my equipment to provide that service?

You state this like deploying a PW service is the only motivation for OAM
and deploying OAM requires a network wide fork lift.
 
> standardization of an approach that allows service providers 
> to leverage their existing assets?

Orthogonal question IMO. As an extension of a craftsperson CLI interface,
we'd do it anyway. 

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

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

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

2) MPLS has a label stack, so there is an extra dimension to things that can
go wrong. 

3) MPLS originally assumed it would exist in a hybrid IP network, and
packets coming up for air at arbitrary plances in the middle was "OK", so
failure to configure LDP on a link or using independent label distribution
mode etc. was only a minor inconvenience rather than service disrupting.

As far as LDP is concerned, the only question in my mind is what is an
appropriate response to the additional modes of failure when considering the
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.

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

<snipped>
> is no RSVP-TE solution for PWE - is this correct and

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.

> can be done without looking at the top to bottom

You phrase the problem strangely. Each layer is required to communicate
knowledge of the fault to the NE that has knowledge of the impacted clients
(usually means the egress LSR for a given layer). Meeting that requirement
will naturally telescope upwards. 

The wrinkle is when a layer implements local resilience to the fault and the
node detecting the fault has no knowledge of the workaround (it doesn't know
when to stop or withdraw the notification). It also throws a curve if the
MTTR of a layer is slower that the detection time of a client, now we're
into hold off timers etc.

> matter of people of good will....... ;-)

There's a few subtleties still to be addressed ;-)

rgds
Dave

---

From: Mark Seery <[email-masked]>
Date: Tue, 27 May 2003 19:00:22 -0700 (PDT)

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

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

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.

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

> identifier is my guess). To me, option 2) is
preferable - 

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

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

>> You phrase the problem strangely. <<
 
MS=> Agreed, and thanks for the explanation.

>> There's a few subtleties still to be addressed ;-)
<<

MS=> :-))

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 29 May 2003 18:01:39 -0400

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.

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.

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? 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]

---

From: Mark Seery <[email-masked]>
Date: Thu, 29 May 2003 15:48:46 -0700 (PDT)

Hi Peter,

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

I have a couple of challenges with this:

a) what has to be implemented
b) if the rate is lessoned, are the exit/entry
requirements met.

What is implemented
===================

If a standard is written in such a way as to suggest
that an operator may wish to operate a feature at its
boundary conditions, on all layers of the network,
then I have a problem in terms of what I tell
engineers to implement. Now you could probably
respond, that if I had any clue about what I was
doing, then the answer would be obvious - which is a
far comment in this case ;-) - but then it brings up
the issue of what does it mean to be standards
compliant. You suggested one compromise in that maybe
we don't need the same functionality (transport) at
every layer of the network - thank you for offering
that and it would be interesting to see if there is
any support for that position.

Meeting entry/exit requirements
===============================

The authors of Y.1711 have done a great job in really
thinking through what they want to achieve; but if
course in this business you can't win for losing. The
downside of the meticulous detail they have gone to is
that I now question if I know whether entry/exit
criterias can be met if I start running at different
rates. 

Now Y.17fec-cv does try to give some guidance on this
(fig.1 required probe insertion rate); and Dave was
kind enough to shoot me a message offline explaining
at that in the MP2P case there may be room for
relaxing requirements, but to me this then becomes the
issue: what rate achieves the desired goal, and until
I feel comfortable with that issue, it is hard for me
to make implementation tradeoffs about what rates I
would offer to a customer.

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

At this point I question whether LSP Ping and Y.1711
have the same goals, so I am not sure that is a valid
assertion. For example, if Y.1711 is a robust
mechanism for carrier class transport layer fault
management, whereas the LSP PING is really focused on
some connectivity verification and SLA feedback, then
I don't think the assertion stands; moreover, maybe
both are applicable, which may be what Dave was
alluding to in: allan-y1711-and-lsp-ping

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

So I can only comment once I understand the
requirements that LSP Ping is trying to meet, though
obviously looking at your statement at face value, I
can see the problem; and if LSP Ping purports to be a
robust fault detection mechanism, then it has some
defficiences WRT requirements as they have been
interpreted by other standards bodies + the desired
tools by a class of carriers.

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

This seems like a valid assertion.

> 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? This would not
> require any vendor to implement the function in
> ASICs or provide some other form of HW acceleration.

So putting aside the question should we do any OAM at
the PWE "layer" ;-) the next issue is does that OAM
capability need to be a robust transport layer like
fault detection mechanism; if so, then will it work
over other PSNs is the next question; followed by does
it have functionality that Y.1711 does not (seems like
it has some pretty good VPN support which Y.1711 is
now addressing but might be some room for requirements
merge here at least).

Mark

---

From: [email-masked]
Date: Fri, 30 May 2003 13:10:33 +0100

Hi Peter......agree with all of your comments....few small remarks however
in-line.  regards, Neil

Peter B wrote 29 May 2003 23:02
> 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".
NH=> The only reason CV rates are 'fixed' at a 1/s default is to ensure
consistency of defect entry/exit criteria and consquent actions, and set a
sensible/pragmatic period over which defects are detected (and subsequently
cleared).  One does not want too fast a reaction (else inapproriate actions
may result, eg unecessary prot-sw on error bursts) nor does one want too
slow a reaction.  This also has consequences for consistent SLA
specifications (of availability and performance metrics) and vendor/operator
interworking.  However, if one does not wish such consistency one can change
the CV rate.  One word of warning however:  If you have different CV rates
on different LSPs in the same network it can lead to odd behaviour.  For
example, consider 1 LSP with a 1/sec CV rate and another with a 1/min CV
rate.  If the 'slow' CV LSP leaks into the 'normal' CV LSP then it will
cause the following cycle of events:
-	detection of dmismerge at t=3s (and take consequent actions, eg
suppress traffic, issue FDI to client layers, etc);
-	dmismerge cleared at t=6s (remove all consequent actions)
-	re-detection of dmismerge at t=63s
-	etc
This may also have some implications on protection switching (if revertive
in a period less than the 'slow' rate).
> 
> 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.
NH=> Correct.  Defect detection/handling must be unidirectional.
> 
> 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.
NH=> I don't think Tom was discussing PWs with those customers (but he can
correct me if I am wrong).  I assume BT is one of these and when he came to
see us the key topic was fault management of rfc2547 VPNs when a LDP mp2p
server layer is used.  LSP-Ping (or something like this) seems a necessary
consequence of doing mp2p......but we can also do rfc2547 over IP and don't
need LSP-Ping in that case.  Architecturally speaking, if one wants an
any-any behaviour than use the proper cnls mode for this.  Conversely, if
one want hard/measurable SLAs then a co pkt-sw mode using p2p constructs is
required.  These 2 cases also apply to X/IP and X/MPLS relationships
......there is not reason at all (except for dogma) why they should be
treated the same.  Its horses for courses.

Y.1711 is all about optimised defect detection/handling in the topologies
that make sense using a co pkt-sw forwarding mode.  Its about as
simple/sparse yet powerful as you can get and we are getting a bit hacked
off when misinformation is given about this.  When one considers
service-interworking the PWs can't exist.  I would imagine all large
operators like BT have the same issue of migrating their FR/ATM network
services to a common co pkt-sw core.  If this core is to be MPLS then we
want a form of MPLS that will suit this and we need service-interworking.
So given PWs can't exist with edge conversion service-interworking then its
high time people realised what was required here.
> 
> 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? This would not require any vendor to implement 
> the function in ASICs or provide some other form of HW acceleration.
NH=> Sure you can do this (that is the whole point of the *same mode*
functional convergence argument that one can use a best-of-breed solution in
all cases where it is appropriate).  I wrote Y.1711 to be generic for any
p2p co pkt-sw case.  However, I must point out that a PW is not a layer
network (ie it is not switched/routed) and so is quite different to MPLS.
Further, since one has to manage the MPLS network anyway then do it right
from the off.  Finally, with service-interworking PWs disappear and the need
to native interwork the X and MPLS layer networks becomes very
obvious.....solutions are already drafted for ATM/MPLS interworking in
Y.17iw

---

From: "Jack Pugaczewski" <[email-masked]>
Date: Fri, 30 May 2003 07:26:44 -0500

I think it is important to distinguish between an OAM Loopback and OAM
Continuity Check (CC).
The OAM CC is a continuous stream once per second.  The OAM Loopback can be
a single request.  The OAM Loopback provides much benefit and does not
require a lot of resources.  Utilization of the Loopback Location ID
provides the ability to determine dynamic topology which is also very useful
for a carrier.

PJMWBGJJREGTATALDBJHJHSLDHGSDWJAMY

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, May 30, 2003 7:11 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 30 May 2003 08:27:43 -0400

> Behalf Of Mark Seery
> Sent: Thursday, May 29, 2003 6:49 PM
> Cc: [email-masked]; [email-masked]

	Even in the P2P case, there is room for
relaxing the 1 second interval. Just ask any operator's
operational department and you will hear 9 times out of 
10 that they want control over whatever interval is used!  
I assert that there is no need to specify an interval; 
just that it SHOULD be  consistent at ends of a particular 
path. This does not imply that ALL paths must be measured 
in the same way either, as they may have different 
constraints. 

> assertion. For example, if Y.1711 is a robust mechanism for 
> carrier class transport layer fault management, whereas the 
> LSP PING is really focused on some connectivity verification 
> and SLA feedback, then I don't think the assertion stands; 
> moreover, maybe both are applicable, which may be what Dave 
> was alluding to in: allan-y1711-and-lsp-ping

	IMHO, they have many of the same goals in mind,
but they might achieve those goals in different ways.
It will be up to the market to decide which solution
is preferred.

> tools by a class of carriers.

	This seems to be the case. Other standards bodies
seem to have seen fit to design the other mechanism
without much if any real world operational feedback
in mind, thus there is no way it could work as
originally designed in the majority of cases that 
are deployed.
 
> This seems like a valid assertion.

	Again, this comes down to an argument over
architectural purity versus practicality of use
and implementation.  On the one hand the other standards
body asserts that it is okay to write standards in
a vaccuum making all sorts of convenient assumptions
which were found to be wrong once, so who is to say
that they won't be again? Meanwhile, we are re-writing
our code and redeplying hardware based on these
standards? OTOH, while I will be the first to admit 
the mechanisms being proposed here are not perfect, 
they have specific practical use today and tomorrow 
for sure.

> now addressing but might be some room for requirements

	It isn't an issue of requirements; we are working
from the same set of basic requirements for these 
solutions. It is IMHO a matter of perspective, as I 
explained above.

	--Tom

---

From: [email-masked]
Date: Fri, 30 May 2003 13:51:39 +0100

Good point Jack.  I'd regard LB as a complimentary tool for operators.  It's
not designed to take executive actions (at the sink and in a unidirectional
sense), it can detect breaks (but not which direction) but it is not
designed to detect swaps/mismerges (Note that the stuff in I.610 on MLT
(multiple level LB technique) which is supposed to help diagnose (not
detect) misbranching has some technical problems).  And if its not periodic
but just on-demand, then it still requires detection by some other means, eg
customer complaint 1st.   However, where continuous connectivity
verification is not required then LB is a useful tool (also for a check of
RTD).

BTW don't confuse the ATM CC and the Y.1711 CV.  There are several things
wrong with I.610 that have been corrected in Y.1711.

regards, Neil

> From: Jack Pugaczewski [mailto:[email-masked]]
> Sent: 30 May 2003 13:27
> To: Harrison,N,Neil,IKL2 R; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
<snipped NH>

---

From: "Jack Pugaczewski" <[email-masked]>
Date: Fri, 30 May 2003 07:58:57 -0500

Absolutely.  However, most ATM implementations are utilizing a subset of the
functionality of I.610.  The OAM LB is most likely invoked from a TMN
network (or element) management system as part of a fault isolation process.
The modes of operation provide end-to-end and segment loopbacks.  The entire
functionality (if implemented fully) provides the carrier with an extremely
useful tool for end-to-end connectivity verification.  This same
functionality will be absolutely necessary in a PWE-3 network.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 30, 2003 7:52 AM
> To: [email-masked]; [email-masked]; [email-masked];

---

From: [email-masked]
Date: Fri, 30 May 2003 15:42:29 +0100

Tom,
<snipped>
> It will be up to the market to decide which solution

NH=> The market (and I assume we realise this has little relevance to
Internet stds now) has little choice when the dominant supplier just goes
and does X.  To be fair though, we deserve what we get as operators if we
abdicate our role in stds production/moderation, as has been the case for
too many years now.....but maybe things are starting to change again.

regards, Neil

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 30 May 2003 11:24:48 -0400

> Sent: Friday, May 30, 2003 8:28 AM
> To: [email-masked]

[snipped]

Tom,

I am not sure I understand your argument. If we want to check the state of a PW, there are two ways to do it:

1. The ingress PE sends an LSP-Ping message and declares a failure if it doesn't receive a reply

2. The ingress PE sends CV messages at regular intervals and the egress PE declares a failure if it doesn't receive several messages in a row.

My assertion was that 2) is superior to 1) for obvious technical reasons. You counter with two arguments:

a) That 2) is an attempt to "write standards in a vaccuum making all sorts of convenient assumptions which were found to be wrong once, so who is to say that they won't be again?" 

b)There are existing implementations for 1) and we don't want to rewrite code and redeploy hardware.

Regarding a), it would help if you could identify why mechanism 2) wouldn't work for connectivity verification of PW. I don't see why the "convenient assumptions" that you refer to have any relevance to this case.

Regarding b), I don't see why that is relevant at all. The whole PWE stndardization work is still based on draft documents. The fact that code may need to be rewritten is the risk that a vendor willingly accepts if he decides to bring out a product based on proprietary protocols.

Finally, the issue is not whether it should be one or the other. I haven't seen anyone argue that LSP-Ping as defined in the VCCV draft is not a useful tool to have. But there are several people who feel (strongly) that it should be augmented with additional OAM tools for those operators who need it. 

Peter

---

From: "David Allan" <[email-masked]>
Date: Fri, 30 May 2003 12:03:09 -0400

I get the feeling that claiming the "wrong approach to standards" is to
"assume in a vaccuum" sentences us to re-prove the validity of Murphy's law
over and over again.

Given the amound of experience we've accumulated with label switching
technologies, and more recently with label stacking, I'd assume we have a
body of knowledge and experience that "fills the vaccuum".

cheers
Dave

> Sent: Friday, May 30, 2003 11:25 AM
> To: [email-masked]'; [email-masked]
> I am not sure I understand your argument. If we want to check 
> the state of a PW, there are two ways to do it:
> 
> 2. The ingress PE sends CV messages at regular intervals and 
> the egress PE declares a failure if it doesn't receive 
> several messages in a row.
> 
> My assertion was that 2) is superior to 1) for obvious 
> technical reasons. You counter with two arguments:
> 
> a) That 2) is an attempt to "write standards in a vaccuum 
> making all sorts of convenient assumptions which were found 
> to be wrong once, so who is to say that they won't be again?" 
> 
> Regarding a), it would help if you could identify why 
> mechanism 2) wouldn't work for connectivity verification of 
> PW. I don't see why the "convenient assumptions" that you 
> refer to have any relevance to this case.
> 
> Regarding b), I don't see why that is relevant at all. The 
> whole PWE stndardization work is still based on draft 
> documents. The fact that code may need to be rewritten is the 
> risk that a vendor willingly accepts if he decides to bring 
> out a product based on proprietary protocols.
> 
> Finally, the issue is not whether it should be one or the 
> other. I haven't seen anyone argue that LSP-Ping as defined 
> in the VCCV draft is not a useful tool to have. But there are 
> several people who feel (strongly) that it should be 
> augmented with additional OAM tools for those operators who need it. 
> 
> Peter
> 
> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 30 May 2003 14:26:04 -0400

> PW. 

	It will. I am not arguing that it will not.
Periodic CV is what I am advocating, just NOT
with Y.1711. There is nothing wrong with using
the other mechanisms we have discussed for this.

> I don't see why the "convenient assumptions" that you 

	The authors of Y.1711 originally convienently
disregarded LDP-signalled LSPs, which we all know 
is used in about %95 of MPLS deployments. In a
vaccuum, it apparently made sense to disregard this
small point in exchange for focusing on p2p LSPs. 
Yes, it has been pointed out by the authors that 
this is incorrect now, but it IS still an ITU 
recommendation nonetheless.

> out a product based on proprietary protocols.

	But the base MPLS stuff is not. Since PWE runs over
MPLS, it is very relevant to re-use what is there as
much as possible to preserve operators' investments in
hardware and OSS used to manage this rather than re-invent
the wheel. In fact, isn't this part of the reason why
we are tryin to emulate VCs over existing MPLS/IP cores?
 
> in the VCCV draft is not a useful tool to have. 
> But there are several people who feel (strongly) that it should be 

	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. There is no one tool that is applicable 
to any one application of MPLS; instead, many need to be 
used in concert to satisfy all of the requirements. Meanwhile, 
those who were proponents of Y.1711 were arguing against this 
approach in favor of Y.1711 being used as the sole and ultimate 
OAM solution. Just think about this. If we had drank 
the Y.1711 Koolaid 2 years ago, we would have all re-designed 
our devices/OSS for a tool that does not apply 
to %90+ of the cases being used.

	--Tom

---

From: Mark Seery <[email-masked]>
Date: Fri, 30 May 2003 21:09:56 -0700 (PDT)

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

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sat, 31 May 2003 09:31:02 -0400

> Sent: Saturday, May 31, 2003 12:10 AM
> To: [email-masked]
> Cc: [email-masked]
> 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

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