Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/modefor proactive CV/CC

From: <[email-masked]>
Date: Sat, 3 Apr 2010 08:35:17 +0100

Apologies for re-send...but got a message saying 'too big' so snipped
this version.

________________________________

	From: Harrison,N,Neil,DKQ7 R 
	Sent: 03 April 2010 08:31
	To: 'Maarten Vissers'; [email-masked]; [email-masked]
	Subject: RE: [mpls] [mpls-tp] Choice of BFD mechanism/modefor
proactive CV/CC

	Thanks Maarten....couple of minor observations in-line:

________________________________

		From: Maarten Vissers
[mailto:[email-masked]] 
		Sent: 03 April 2010 02:08
		To: Harrison,N,Neil,DKQ7 R; [email-masked];
[email-masked]
		Subject: RE: [mpls] [mpls-tp] Choice of BFD
mechanism/modefor proactive CV/CC

		Neil,
		 
		See inline..

________________________________

		From: [email-masked]
[mailto:[email-masked]] 
		Sent: vrijdag 2 april 2010 20:59
		To: [email-masked]; [email-masked];
[email-masked]
		Subject: RE: [mpls] [mpls-tp] Choice of BFD
mechanism/modefor proactive CV/CC

		Thanks Maarten,
		 
		I believe the key point you are trying to make here is
that when we have a mismerge defect it is the lowest CV rate (and not
simply the offending mismerged CV rate that you state below) that should
determine the defect processing algorithm at the sink.  This seem a
reasonable idea on the face of it.  Or have I missed something?
		 
		[maarten] this is indeed the principle. To be noted in
addition is that the defect setting is based on reception of the first
CCM frame with unexpected MEGID value, which makes the defect setting
independent of the period. Only the defect clearing is dependent on the
period of the unexpected CCM frame. 
		NH=> Thanks.  So it looks like we have a way of dealing
with different CV rates.  This seems a good step forward.   We should
not however have lots of CV rates in the same layer network as the '2
from N' combinatorial issue has not gone away, we have just stated a way
to deal with it.
		 
		I think reference to Ethernet or any other specific
technology is not relevant. 
		 
		[maarten] The principle is currently implemented in
Ethernet, but can be applied generically...  
		NH=> Agreed.  I should also have said that if we
consider this a 'best-case' architectural practice then it should be the
goal for the OAM of all co-ps mode technologies.  
		 
		Note - I still stand by all the other points I made in
my initial response to Italo on things like transparency, CoS level
relationship to a connection, etc.
		 
		regards, Neil  
		 
		Regards,
		Maarten 
		 
		 <SNIPPED>