Subject: RE: [Fwd: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-11.txt]

From: <[email-masked]>
Date: Thu, 5 Oct 2006 07:49:16 +0100

I would like to ask the authors a question please:

Given a prime purpose of OAM is to detect/handle misconnectivity
defects, what happens when different CC/CV options are used on different
MPLS LSPs and there is a misconnectivity defect between those LSPs?

Thanks.  regards, Neil

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: 04 October 2006 23:06
> To: pwe3
> Subject: [Fwd: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-11.txt]
> 
> 
> This is the start of last call on draft-ietf-pwe3-vccv-11.txt
> 
> Last call will finish on 28th Oct 2006, ie the Friday
> following draft cutoff.
> 
> Please read this draft and comment to the list as we need to
> get this work completed.
> 
> Thanks
> 
> Stewart
> 
> 
> -------- Original Message --------
> Subject: 	[PWE3] I-D ACTION:draft-ietf-pwe3-vccv-11.txt
> Date: 	Wed, 04 Oct 2006 15:50:01 -0400
> From: 	[email-masked]
> To: 	[email-masked]
> CC: 	[email-masked]
> 
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Pseudowire Emulation Edge to 
> Edge Working Group of the IETF.
> 
> 	Title		: Pseudo Wire Virtual Circuit 
> Connectivity Verification (VCCV)
> 	Author(s)	: T. Nadeau, et al.
> 	Filename	: draft-ietf-pwe3-vccv-11.txt
> 	Pages		: 27
> 	Date		: 2006-10-4
> 	
> This document describes Virtual Circuit Connection Verification
>    (VCCV) which provides a control channel that is associated 
>    with a pseudo wire (PW), as well as the corresponding 
>    operations and management functions such as connectivity 
>    verification to be used over that control channel. VCCV 
>    applies to all supported access circuit and transport types 
>    currently defined for PWs.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-11.tx
t

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-pwe3-vccv-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-vccv-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 5 Oct 2006 17:34:43 -0400

Neil,

This seems like a somewhat hypothetical case. Why would an operator run different CV protocols on different LSPs?

But, to answer your question: Assume that the operator uses Y.1711 on LSP1 and BFD on LSP2. If LSP1 and LSP2 are accidentally swapped, the LSP1 LER will stop receiving Y.1711 CC messages and enter the LOC state and the LSP2 LER will stop receiving BFD control messages, also entering the LOC state. The operator will be alarmed about failures on both LSPs.

Of course, if the operator would use Y.1711 on both LSPs or BFD on both LSPs, the LERs would detect CC/BFD messsages, but with incorrect TTSI/discriminator, which the operator could potentially use to detect which two LSPs are swapped. This proves that it is better to use the same protocol on all LSPs.

Peter

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 05, 2006 2:49 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Fwd: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-11.txt]
> 
> 
> You can also visit 
https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Send a message to:
	[email-masked].
In the body type:

---

From: "Danny Prairie \(dprairie\)" <[email-masked]>
Date: Thu, 5 Oct 2006 19:57:38 -0400

Hi Peter,

In general, one may wish to run multiple CVs. For example, although BFD
may detect certain classes of failures, LSP ping would detect certain
failures which BFD cannot. Running both would be desirable, albeit at
perhaps different frequencies.

Regards,

Danny

-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
Sent: Thursday, October 05, 2006 5:35 PM
To: [email-masked]'; [email-masked]
Cc: Stewart Bryant (stbryant)
Subject: RE: [Fwd: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-11.txt]

Neil,

This seems like a somewhat hypothetical case. Why would an operator run
different CV protocols on different LSPs?

But, to answer your question: Assume that the operator uses Y.1711 on
LSP1 and BFD on LSP2. If LSP1 and LSP2 are accidentally swapped, the
LSP1 LER will stop receiving Y.1711 CC messages and enter the LOC state
and the LSP2 LER will stop receiving BFD control messages, also entering
the LOC state. The operator will be alarmed about failures on both LSPs.

Of course, if the operator would use Y.1711 on both LSPs or BFD on both
LSPs, the LERs would detect CC/BFD messsages, but with incorrect
TTSI/discriminator, which the operator could potentially use to detect
which two LSPs are swapped. This proves that it is better to use the
same protocol on all LSPs.

Peter

Send a message to:
	[email-masked].
In the body type:

---

From: <[email-masked]>
Date: Fri, 6 Oct 2006 08:42:12 +0100

Thanks Peter...please see in-line.

> Sent: 05 October 2006 22:35
> To: Harrison,N,Neil,JCGA1 R; [email-masked]
> Cc: [email-masked]
> This seems like a somewhat hypothetical case. Why would an 
> operator run different CV protocols on different LSPs?
NH=> I largely agree that we should have a common approach...so why are
there lots of options then?  Is this also not creating interworking
problems (also see below)?  

If we want deterministic fault/perf behaviour and we are using
label-swapping for forwarding (as we can in the co-ps mode IFF we adhere
to what defines a connection, ie single source, single route from source
to any sink) then we need to use a consistent CV rate on all
connections.  Why?  Well if we don't and we have misconnectivity we can
get defect (and consequent action) cycling, which is clearly not a good
idea.  However, if we have non-swapped forwarding labels and one
includes the SA in all traffic units (as in the case of PBT say) then:
(i) we get misconnectivity robustness with no OAM flows at all
(ii) we can run different CV rates on different connections (still
needed to differentiate breaks from quiescent traffic case) to effect a
distributed protection-switching priority behaviour.

These are useful behaviours as I am sure you would agree.
> 
> But, to answer your question: Assume that the operator uses 
> Y.1711 on LSP1 and BFD on LSP2. If LSP1 and LSP2 are 
> accidentally swapped, the LSP1 LER will stop receiving Y.1711 
> CC messages and enter the LOC state and the LSP2 LER will 
> stop receiving BFD control messages, also entering the LOC 
> state. The operator will be alarmed about failures on both LSPs.
NH=> In this specific swapped case I agree with you and we would see the
(actually incorrect) indication of 'LOC'.  But what if traffic from one
of these LSPs was NOT broken but merely leaking (ie unintended
replication) into the other LSP....you get no indication now.

> 
> Of course, if the operator would use Y.1711 on both LSPs or 
> BFD on both LSPs, the LERs would detect CC/BFD messsages, but 
> with incorrect TTSI/discriminator, which the operator could 
> potentially use to detect which two LSPs are swapped. This 
> proves that it is better to use the same protocol on all LSPs.
NH=> Exactly Peter...one should use the SAME defect detection/handling
OAM on ALL connections in a given layer network....see also unintended
replication example above.  Further, if one is using a label-swapping
approach the CV rate should also be consistent.  This restriction is not
required however in a non-swapping case.

regards, Neil
> > defects, what happens when different CC/CV options are used on 
> > different MPLS LSPs and there is a misconnectivity defect between 
> > those LSPs?
> > 
> > Thanks.  regards, Neil
> > 
> > > Last call will finish on 28th Oct 2006, ie the Friday following 
> > > draft cutoff.
> > > 
> > > Please read this draft and comment to the list as we need to get 
> > > this work completed.
> > > 
> > > Thanks
> > > 
> > > Stewart
> > > 
> > > 
> > > directories. This draft is a work item of the Pseudowire 
> Emulation 
> > > Edge to Edge Working Group of the IETF.
> > > 

Send a message to:
	[email-masked].
In the body type:

---

From: <[email-masked]>
Date: Fri, 6 Oct 2006 08:53:11 +0100

Danny....please also see my response to Peter, and also some small
remarks below.

> From: Danny Prairie (dprairie) [mailto:[email-masked]] 
> Sent: 06 October 2006 00:58
> To: Busschbach, Peter B (Peter); Harrison,N,Neil,JCGA1 R; 
> [email-masked]
> In general, one may wish to run multiple CVs.  For example, 
> although BFD may detect certain classes of failures, LSP ping 
> would detect certain failures which BFD cannot.
NH=> We should differentiate the 'always-on' defect detection/handling
OAM from the 'on-demand' diagnostics OAM.  In the former case the OAM
approach SHOULD be consistent right across the entire layer network.  If
it isn't then we can get defect cycling, eg if a connection with a 1/min
CV rate leaks into a connection with a 1/s CV rate we get a cycle of:
-	3s of defect state with (hopefully) alarms and traffic squelched
-	57s of defect free state (though it isn't really) with no alarms
or traffic squelched...so we are allowing one customer's traffic to leak
into another for most of the time.  This is not a good design/approach
IMO.

BTW - If we use network significant labels for forwarding and include
the trail SA in each traffic unit then we can't get such cases of
misconnectivity in the 1st place.  CF a cl-ps traffic unit like IP with
network significant SA/DA labels, this too is also self-robust to
misconnectivity.  This is a very useful property.

> Running both 
> would be desirable, albeit at perhaps different frequencies.
NH=> Well, it's not a good idea IMO for the reason noted above.

regards, Neil

Send a message to:
	[email-masked].
In the body type:

---

From: "Danny Prairie \(dprairie\)" <[email-masked]>
Date: Fri, 6 Oct 2006 04:00:00 -0400

Hi Neil,

Different CV mechanisms have levels of verification capabilities which
differ. Those that can detect a larger class of failures modes are
usually more expensive to use, hence the interest, IMO, to use a tiered
approach.

Regards,

Danny

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 06, 2006 3:53 AM
To: Danny Prairie (dprairie); [email-masked]; [email-masked]
Cc: Stewart Bryant (stbryant)
Subject: RE: [Fwd: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-11.txt]

regards, Neil

Send a message to:
	[email-masked].
In the body type: