Subject: Re: VCCV OAM question

From: Mustapha Aissaoui <[email-masked]>
Date: Wed, 02 Apr 2003 10:26:47 -0500

Tom and Shahram,
I think there are a couple of points in terms of OAM for pseudo-wires:

1. Yes it is important to be able to check connectivity all the way to the PW
endpoints. Having said that, I do not think that connectivity verification
such as the proposed VCCV is sufficient. Connectivity verification is a
pro-active OAM function. We also need to have reactive OAM such as reasonably
fast defect indication that will be triggered without having the service
provider inject traffic on thousands of PWs.

I believe we need to discuss the following:
- a defect indication for a PW: in this case we should try to rely as much as
possible on the native service OAM capabilities. This is true in the case of
same L2 access technology (e.g., ATM-MPLS-ATM). In the case where there is a
different L2 access technology (e.g., ATM-MPLS-Ethernet), then each
technology will have to rely on its own OAM since the interworking here is at
a higher layer.
- connectivity verification.
- performance monitoring.

2. Correlation of defect states between the PSN and the PW levels. You cannot
assume that a PW is just being set up independently of the PSN it is riding
on. For example, when a transport LSP is in defect state (whether this is
detected through inband or out-of band), there is a need to generate defect
indication at the PW level.

Mustapha.
----------
"Thomas D. Nadeau" wrote:

> At 02:30 PM 4/1/2003 -0800, Shahram Davari wrote:
>
> > >(the MPLS OAM requirements also reflect this
> > >point).
> > >
> >
> >Where in MPLS OAM requirements?
>
>          Packets must flow the way of data
> packets.
>
> >And isn't this a PW issue independent of the PSN?
>
>          Yes, but when MPLS is the PSN the MPLS
> requirements apply. I have spoken with L2TP customers
> that feel the same way, which makes complete
> sense to me.  I suspect your customers will tell you the
> same.
>
>          --Tom
>
> >-Shahram
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
>
> http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 02 Apr 2003 10:49:35 -0500

>provider inject traffic on thousands of PWs.

         As I pointed out during the meeting, we are not proposing
VCCV as the be-all-end-all to OAM for PWE3. It is just one
diagnostic mechanism in the quiver of OAM tools for PWE3
as is LSP ping and native end-to-end OAM that is passed
transparently over the PWs.  When these are used in combination,
we get a complete solution.

>possible on the native service OAM capabilities.

         I totally agree with you. I think that native capabilities used
in conjunction with mechanisms like LSP ping/VCCV to bridge
the gaps make for a complete solution.  This should also
make those architectural purists happy as well, since we
make separate tools/functions for each piece of the network
and then determine how each works together instead of trying to
design the OAM swiss army knife, as has been proposed elsewhere.
We also describe how to bridge these gaps in the OAM message
mapping draft.

>This is true in the case of

         Yes, I agree. Again, this is why message mapping
between the PSN, PWs and the native services is important.

         --Tom

---

From: "himanshu shah" <[email-masked]>
Date: Wed, 2 Apr 2003 11:04:58 -0500

There is a proposal to extend PWE3 control signaling
to notify VC status to the remote peer. The VC status
could either be attachment circuit or head end PW status
or both.

There are two aspects of VC status
1) generation - based on attachment circuit or head end PW
2) processing of received status
	- propagating it to attachment circuit
	- pkt processing action on incoming PW

Please refer to draft-shah-pwe3-control-protocol-extension-00.txt.

/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mustapha Aissaoui
Sent: Wednesday, April 02, 2003 10:27 AM
To: Thomas D. Nadeau; Shahram Davari
Cc: [email-masked]'
Subject: Re: [PWE3] VCCV OAM question

Tom and Shahram,

1. Yes it is important to be able to check connectivity all the way to the
PW
endpoints. Having said that, I do not think that connectivity verification
such as the proposed VCCV is sufficient. Connectivity verification is a
pro-active OAM function. We also need to have reactive OAM such as
reasonably
fast defect indication that will be triggered without having the service
provider inject traffic on thousands of PWs.

I believe we need to discuss the following:
- a defect indication for a PW: in this case we should try to rely as much
as
possible on the native service OAM capabilities. This is true in the case of
same L2 access technology (e.g., ATM-MPLS-ATM). In the case where there is a
different L2 access technology (e.g., ATM-MPLS-Ethernet), then each
technology will have to rely on its own OAM since the interworking here is
at
a higher layer.
- connectivity verification.
- performance monitoring.

2. Correlation of defect states between the PSN and the PW levels. You
cannot

Mustapha.
----------

---

From: Mustapha Aissaoui <[email-masked]>
Date: Thu, 03 Apr 2003 12:04:52 -0500

Tom,

> we get a complete solution.

Not quite complete. In the case of dissimilar L2 access to the PSN,
say ATM-PSN-Ethernet, we need a specific PW defect indication to be
sent inband or out-of band in response to a failure of the
attachement circuit or inside the PE between the PW endpoint and the
tunnel originating point. Himanshu made a proposal for a possible
mechanism for sending status messages out-of-band in
draft-shah-pwe3-control-protocol-extension. We need another one for
inband notification.