Subject: VCCV OAM question

From: Shahram Davari <[email-masked]>
Date: Tue, 1 Apr 2003 11:04:13 -0800

Hi,

Would some one (Tom?) explain why can't the LSP-ping be used instead of VCCV for the PW?

Thanks,

> __________________________________________
> Shahram Davari, B.Eng., M.A.Sc.
> Senior Product Research Engineer
> PMC_Sierra, Inc.
> Tel: (613)271-4018
> Fax: (613)271-6468
> MailTo: [email-masked]
> __________________________________________
> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 01 Apr 2003 17:12:35 -0500

One reason is that use of VCCV will
get you as close as you can get to the disposition
point when using either of the supported PWE3
transports to test a particular VC.  Use of just LSP ping
may not. The requirements I have gathered from providers
have instructed me to get as close as possible
(the MPLS OAM requirements also reflect this
point).

         --Tom

>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X

---

From: Shahram Davari <[email-masked]>
Date: Tue, 1 Apr 2003 14:30:33 -0800

>(the MPLS OAM requirements also reflect this

Where in MPLS OAM requirements? And isn't this a PW issue
independent of the PSN?

-Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 01 Apr 2003 19:24:55 -0500

At 02:30 PM 4/1/2003 -0800, Shahram Davari wrote:

>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

---

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

Himanshu,
thanks for providing a reference to the draft. Clearly, it is better
to indicate status of an attachement circuit to the remote PE and
let it deal with it than to systematically withdraw a label. 

In reference to the requirement document, I classify your mechanism
in the out-of-band OAM or link management category. This is because
the notification is not forwarded in the same channel as the user
data. 

Regards,
Mustapha.
-----------
himanshu shah wrote:
> 
> 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,
> 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:
>