Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC

From: "Annamaria Fulignoli" <[email-masked]>
Date: Thu, 1 Apr 2010 20:59:05 +0200

Hi Greg,
sorry for the delay in answering.
You wrote: 
"what are reasons considered to select only unidirectional BFD (based on BFD for multipoint networks work) for proactive CV/CC"

The unidirectional BFD allows to have one solution, one behavior, for all transport entities ( p2p bidirectional, p2p unidirectional, p2mp ) and it satisfies all MPLS-TP transport requirement for the proactive CV/CC, including also the unidirectional failure; it is very simple and fast tool as transport operator require.

As it could be critical to support, the group is still working together to converge asap to a common agreed solution.

We'll be glad to receive your useful comments next draft update.
Thanks   
Best Regards
Annamaria 

________________________________

From: Greg Mirsky [mailto:[email-masked]] 
Sent: mercoledì 31 marzo 2010 18.16
To: Annamaria Fulignoli; [email-masked]; [email-masked]; [email-masked]; David Ward; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Choice of BFD mechanism/mode for proactive CV/CC

I haven't seen any response from authors thus assuming that it didn't make to the list the first time.

On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky <[email-masked]> wrote:

	Dear Authors and All,
	I would like to ask several questions related to the subject I've asked at the meeting today:

	*	what are reasons considered to select only unidirectional BFD (based on BFD for multipoint networks work) for proactive CV/CC 
	*	what capabilities of BFD for multipoint networks required for use as CV/CC in MPLS-TP 
	*	what of capabilities are optional (can and may) 
	*	are there any capabilities that would not be supported (should not and must not) 

	As was demonstrated in presentation of David's analysis by Rahul today, within BFD for MPLS one can create unidirectional BFD session already, assuming that the DCN exists in some form. Thus it leave p2mp LSP that can benefit from use of BFD for multipoint networks mechanism. Or a root can "pretend" that p2mp LSP is p2p and send after first exchange of Discriminator, and ignore Discrminators from other, late-joiner leaves.
	
	Regards,
	Greg

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 2 Apr 2010 09:57:49 +0200

Dave, Greg,

I think we are mixing different aspect of requirements, solutions and consequences if requirements are not met.

The requirements have been expressed more than once but I think that "repetita juvant":

- we need a very simple and lightweight protocol that check continuity and connectivity ("are you there?" question with a "yes/no" answer)

- this check must be performed at a rate that is fully controlled by the operator (and not by the network)

- the rate must not change in any condition (only the operator can change it)

- the return path is required only on bidirectional p2p paths (either associated or co-routed) just to carry the RDI indication

There are many consequences if the requirements are not met.

One of these consequences is described in the last slide of Annamaria's presentation done in Anaheim:

http://tools.ietf.org/agenda/77/slides/mpls-24.ppt

Unidirectional BFD is not the only solution to address this requirement.

An alternative solution was also presented in draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi.

Italo

P.S. Please note my new email address, [email-masked], effective since 1 November 2009.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David Ward
> Sent: mercoledì 31 marzo 2010 18.33
> To: Greg Mirsky
> Cc: Siva Sivabalan(msiva); [email-masked]; David Ward; Sami 
> Boutros; David Ward (wardd); [email-masked]
> Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC
> 
> Greg -
> 
> On Mar 31, 2010, at 11:15 AM, Greg Mirsky wrote:
> 
> I haven't seen any response from authors thus assuming that 
> it didn't make to the list the first time.
> 
> On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky 
> <[email-masked]<mailto:[email-masked]>> wrote:
> Dear Authors and All,
>  *   what are reasons considered to select only 
> unidirectional BFD (based on BFD for multipoint networks 
> work) for proactive CV/CC
> 
> DW: This requirement has been bantered back and forth by the 
> group. Although not completely explained, it's been deemed 
> critical to support by those well versed in transport network 
> architectures.
> 
> 
> 
> DW: Certainly in the MP scenario. As discussed in the preso 
> by Rahul at the meeting it can also be used if there is no 
> return path (odd network design).
> 
> 
> DW: As you saw in the preso, many capabilities and scenarios 
> were presented.The point of the preso was they there were all 
> optional and that if any of the options were *ever* desired 
> then pure unidirectional MP BFD was not a good choice.
> 
> 
> As was demonstrated in presentation of David's analysis by 
> Rahul today, within BFD for MPLS one can create 
> unidirectional BFD session already, assuming that the DCN 
> exists in some form.
> 
> DW: And really only useful if there is never, ever a return path.
> 
> Thus it leave p2mp LSP that can benefit from use of BFD for 
> multipoint networks mechanism. Or a root can "pretend" that 
> p2mp LSP is p2p and send after first exchange of 
> Discriminator, and ignore Discrminators from other, 
> late-joiner leaves.
> 
> Regards,
> Greg
> 
> 
> 
> HIH
> 
> -DWard
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: <[email-masked]>
Date: Fri, 2 Apr 2010 09:55:13 +0100

Italo, 

Many years ago when drafting Y.1710/1711 I pointed out that having different CV rates in a network would cause 'alarm cycling' problems under cases of misconnectivity, eg a trail with a CV rate of 1 per minute misconnected (ie merged) into a trail with a CV rate of 1 per sec will cause a behaviour of (i) declare defect and take consequent actions at t=T (eg could include invoking prot-sw as per Anamaria's slide), (ii) declare defect cleared at t=T+3 and remove all consequent actions (maybe even switch traffic back to old path at some point?), (iii) declare defect again at t=T+60...and continue to repeat this cycle.

If there are N different CV rates in a network then there will be a number of 'select 2 from N' combinatorial defect cases to deal with....not a great idea, so I would strongly suggest that the CV rate be consistent in a given layer network.

BTW - if you set the CV rate too fast you run the danger of declaring defects, and taking unnecessary consequent actions, on error bursts that could clear of their own accord.

Defect detection OAM should always be unidirectional in nature in co mode layer networks....the p2mp case clearly shows why this is required......noting that consequent actions are also unidirectional in nature and taken at the trail sink, eg activation/suspension of perf counters, raise local alarm, etc.

The CV (or BFD) packet should contain the proper trail source address for that layer network...not some arbitrary source generated identifier.  This does assume of course that the layer network being considered has been given decent addressing in the first place.....not the case with MPLS and for sure not with PWs!

One can piggy-back BDI flag in CV for the p2p case but not the p2mp case.

I would also advise forward-looking caution and clarity on these points:

1	Before committing to any TCM be very clear how nested TCM levels are configured and activated/deactivated (including synchronisation of any perf mon counts) across failure and restore events.  Only the true end points of trails always remain invariant across failure/restore events.

2	Note that in a transport network if one direction enters the unavailable state then both directions are deemed unavailable.  The key point here is that any perf monitoring for SLAs must be suspended in both directions for the duration of the unavailability event.  And from above point, this applies to all nested TCM levels.  

3	From transparency considerations a (parent) connection should only have a single CoS for its (child) traffic units.  However, it seems possible that this arch requirement could be violated.  In such a case there will be a need to consider how the entry/exit criteria of the unavailable state (and all the consequent actions that would apply) is to be defined for the (parent) connection based on some weighted combinatorial of loss/delay in the (child) traffic units of each CoS.  .....I have mentioned some of these consequential action considerations above wrt to suspending perf mon counts in both directions and across all nested TCM levels.  The right answer here of course is don't create this problem in the first place, ie a connection should only have a single CoS level.

regards, Neil

> Behalf Of BUSI ITALO
> Sent: 02 April 2010 08:58
> To: David Ward; Greg Mirsky
> Cc: [email-masked]; David Ward (wardd); Siva Sivabalan(msiva); 
> [email-masked]; Sami Boutros
> I think we are mixing different aspect of requirements, 
> solutions and consequences if requirements are not met.
> 
> - we need a very simple and lightweight protocol that check 
> continuity and connectivity ("are you there?" question with a 
> "yes/no" answer)
> 
> - this check must be performed at a rate that is fully 
> controlled by the operator (and not by the network)
> 
> - the return path is required only on bidirectional p2p paths 
> (either associated or co-routed) just to carry the RDI indication
> 
> One of these consequences is described in the last slide of 
> Annamaria's presentation done in Anaheim:
> 
> An alternative solution was also presented in 
> draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi.
> 
> Italo
> 
> P.S. Please note my new email address, 
> [email-masked], effective since 1 November 2009.
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of David Ward
> > Cc: Siva Sivabalan(msiva); [email-masked]; David Ward; Sami Boutros; 
> > David Ward (wardd); [email-masked]
> > DW: This requirement has been bantered back and forth by the group. 
> > Although not completely explained, it's been deemed critical to 
> > support by those well versed in transport network architectures.
> > 
> > 
> >

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 02 Apr 2010 07:57:21 -0400

Neil,

    While such mis-configuration may be a problem as you discuss, one of the
major problems with Y.1711 was that it mandated a fixed time interval for
operations. The majority of operators I worked with at the time found this
to be a a non-starter. Actually their Operations people did.

    The operational requirements for MPLS-TP should not be to revisit this
mistake again, but instead to require consistency, or mechanisms to
reconcile the differences in cases where it is critical to discern them.
Flexibility with consistency is what we need to aim for here.

    --Tom

> Italo, 
> 
> Many years ago when drafting Y.1710/1711 I pointed out that having different
> CV rates in a network would cause 'alarm cycling' problems under cases of
> misconnectivity, eg a trail with a CV rate of 1 per minute misconnected (ie
> merged) into a trail with a CV rate of 1 per sec will cause a behaviour of (i)
> declare defect and take consequent actions at t=T (eg could include invoking
> prot-sw as per Anamaria's slide), (ii) declare defect cleared at t=T+3 and
> remove all consequent actions (maybe even switch traffic back to old path at
> some point?), (iii) declare defect again at t=T+60...and continue to repeat
> this cycle.
> 
> If there are N different CV rates in a network then there will be a number of
> 'select 2 from N' combinatorial defect cases to deal with....not a great idea,
> so I would strongly suggest that the CV rate be consistent in a given layer
> network.
> 
> BTW - if you set the CV rate too fast you run the danger of declaring defects,
> and taking unnecessary consequent actions, on error bursts that could clear of
> their own accord.
> 
> Defect detection OAM should always be unidirectional in nature in co mode
> layer networks....the p2mp case clearly shows why this is required......noting
> that consequent actions are also unidirectional in nature and taken at the
> trail sink, eg activation/suspension of perf counters, raise local alarm, etc.
> 
> The CV (or BFD) packet should contain the proper trail source address for that
> layer network...not some arbitrary source generated identifier.  This does
> assume of course that the layer network being considered has been given decent
> addressing in the first place.....not the case with MPLS and for sure not with
> PWs!
> 
> 1 Before committing to any TCM be very clear how nested TCM levels are
> configured and activated/deactivated (including synchronisation of any perf
> mon counts) across failure and restore events.  Only the true end points of
> trails always remain invariant across failure/restore events.
> 
> 2 Note that in a transport network if one direction enters the unavailable
> state then both directions are deemed unavailable.  The key point here is that
> any perf monitoring for SLAs must be suspended in both directions for the
> duration of the unavailability event.  And from above point, this applies to
> all nested TCM levels.
> 
> 3 From transparency considerations a (parent) connection should only have a
> single CoS for its (child) traffic units.  However, it seems possible that
> this arch requirement could be violated.  In such a case there will be a need
> to consider how the entry/exit criteria of the unavailable state (and all the
> consequent actions that would apply) is to be defined for the (parent)
> connection based on some weighted combinatorial of loss/delay in the (child)
> traffic units of each CoS.  .....I have mentioned some of these consequential
> action considerations above wrt to suspending perf mon counts in both
> directions and across all nested TCM levels.  The right answer here of course
> is don't create this problem in the first place, ie a connection should only
> have a single CoS level.
> 
> regards, Neil
> 
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Fri, 2 Apr 2010 15:47:29 +0100

Just be a bit careful here Tom....if one has SLAs to meet then one needs a consistent method of measurement. Maybe not such a big issue in isolated operator layer networks, but if there is any requirement to interwork then consistent availability and performance metrics/objectives will need defining.

However, the major point wrt the alarm cycling issue is consistent use of CV rates within the same layer network....whatever the chosen rate.

regards, Neil

> From: Nadeau,TD,Tom,DEE1 R 
> Sent: 02 April 2010 12:57
> To: Harrison,N,Neil,DKQ7 R; [email-masked]; 
> David Ward; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; David Ward
> Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode 
> for proactive CV/CC
> 
> 
> 
>     Neil,
> 
>     While such mis-configuration may be a problem as you 
> discuss, one of the major problems with Y.1711 was that it 
> mandated a fixed time interval for operations. The majority 
> of operators I worked with at the time found this to be a a 
> non-starter. Actually their Operations people did.
> 
>     The operational requirements for MPLS-TP should not be to 
> revisit this mistake again, but instead to require 
> consistency, or mechanisms to reconcile the differences in 
> cases where it is critical to discern them.
> > Many years ago when drafting Y.1710/1711 I pointed out that having 
> > different CV rates in a network would cause 'alarm cycling' 
> problems 
> > under cases of misconnectivity, eg a trail with a CV rate of 1 per 
> > minute misconnected (ie
> > merged) into a trail with a CV rate of 1 per sec will cause a 
> > behaviour of (i) declare defect and take consequent actions 
> at t=T (eg 
> > could include invoking prot-sw as per Anamaria's slide), 
> (ii) declare 
> > defect cleared at t=T+3 and remove all consequent actions 
> (maybe even 
> > switch traffic back to old path at some point?), (iii) 
> declare defect 
> > again at t=T+60...and continue to repeat this cycle.
> > 
> > If there are N different CV rates in a network then there will be a 
> > number of 'select 2 from N' combinatorial defect cases to deal 
> > with....not a great idea, so I would strongly suggest that 
> the CV rate 
> > be consistent in a given layer network.
> > 
> > BTW - if you set the CV rate too fast you run the danger of 
> declaring 
> > defects, and taking unnecessary consequent actions, on error bursts 
> > that could clear of their own accord.
> > 
> > Defect detection OAM should always be unidirectional in 
> nature in co 
> > mode layer networks....the p2mp case clearly shows why this is 
> > required......noting that consequent actions are also 
> unidirectional 
> > in nature and taken at the trail sink, eg 
> activation/suspension of perf counters, raise local alarm, etc.
> > 
> > The CV (or BFD) packet should contain the proper trail 
> source address 
> > for that layer network...not some arbitrary source generated 
> > identifier.  This does assume of course that the layer 
> network being 
> > considered has been given decent addressing in the first 
> place.....not 
> > the case with MPLS and for sure not with PWs!
> > 
> > configured and activated/deactivated (including 
> synchronisation of any 
> > perf mon counts) across failure and restore events.  Only 
> the true end 
> > points of trails always remain invariant across 
> failure/restore events.
> > 
> > 2 Note that in a transport network if one direction enters the 
> > unavailable state then both directions are deemed unavailable.  The 
> > key point here is that any perf monitoring for SLAs must be 
> suspended 
> > in both directions for the duration of the unavailability 
> event.  And 
> > from above point, this applies to all nested TCM levels.
> > 
> > 3 From transparency considerations a (parent) connection 
> should only 
> > have a single CoS for its (child) traffic units.  However, it seems 
> > possible that this arch requirement could be violated.  In 
> such a case 
> > there will be a need to consider how the entry/exit criteria of the 
> > unavailable state (and all the consequent actions that 
> would apply) is 
> > to be defined for the (parent) connection based on some weighted 
> > combinatorial of loss/delay in the (child) traffic units of 
> each CoS.  
> > .....I have mentioned some of these consequential action 
> > considerations above wrt to suspending perf mon counts in both 
> > directions and across all nested TCM levels.  The right 
> answer here of 
> > course is don't create this problem in the first place, ie 
> a connection should only have a single CoS level.
> > 
> > regards, Neil
> > 
> >> Of BUSI ITALO
> solutions and 
> >> consequences if requirements are not met.
> >> 
> >> The requirements have been expressed more than once but I 
> think that 
> >> "repetita juvant":
> >> 
> >> - the return path is required only on bidirectional p2p 
> paths (either 
> >> associated or co-routed) just to carry the RDI indication
> >> 
> >>> DW: Certainly in the MP scenario. As discussed in the 
> preso by Rahul 
> >>> at the meeting it can also be used if there is no return 
> path (odd 
> >>> network design).
> >>> 
> >>> 
> >>> DW: As you saw in the preso, many capabilities and scenarios were 
> >>> presented.The point of the preso was they there were all optional 
> >>> and that if any of the options were *ever* desired then pure 
> >>> unidirectional MP BFD was not a good choice.
> >>> 
> >>> 
> >>> As was demonstrated in presentation of David's analysis by Rahul 
> >>> today, within BFD for MPLS one can create unidirectional 
> BFD session 
> >>> already, assuming that the DCN exists in some form.
> >>> 
> >>> multipoint networks mechanism. Or a root can "pretend" 
> that p2mp LSP 
> >>> is p2p and send after first exchange of Discriminator, and ignore 
> >>> Discrminators from other, late-joiner leaves.
> >>> 
> >>> Regards,
> >>> Greg
> >>> 
> >>> 
> >>> 
> >>> HIH
> >>> 
> >>> -DWard
> >>>

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 02 Apr 2010 17:23:38 +0200

Hello Tom,

> reconcile the differences in cases where it is critical to discern them.

The two major differences from an operational point of view
are operators used to maintain an MPLS network and operators
used to maintain a transport network.

Reconciling these differences requires compromises that will
give both of them a hard time.

> Flexibility with consistency is what we need to aim for here.

Consistency for each kind of operator can be addressed by
designing two sets of OAM tools for MPLS-T:
-- a set of tools for the MPLS operators, and
-- a set of tools for the transport network operators
Flexibility can be addressed by allowing the operator
to select/provision only one of the two toolsets at the
same time.

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: [email-masked]
Date: Fri, 2 Apr 2010 11:25:21 -0500

All,

I think the key point is that to avoid the alarm cycling the CV rate must 
be consistent across the network.  To achieve this the CV rate must be set 
by the operator and not by negotiation along each path.

Regards,

Malcolm

<[email-masked]> 
Sent by: [email-masked]
02/04/2010 10:47 AM

To
<[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>
cc
[email-masked], [email-masked], [email-masked], [email-masked]
Subject
Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Just be a bit careful here Tom....if one has SLAs to meet then one needs a 
consistent method of measurement. Maybe not such a big issue in isolated 
operator layer networks, but if there is any requirement to interwork then 
consistent availability and performance metrics/objectives will need 
defining.

However, the major point wrt the alarm cycling issue is consistent use of 
CV rates within the same layer network....whatever the chosen rate.

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 02 Apr 2010 19:36:39 +0200

All,
 
In Ethernet OAM we deploy multiple CCM rates. Generation of CCM frames can
be enabled/disabled.
 
The rate is set by the NMS (or GMPLS) and depends on the most demanding
application:
 
- 1 CCM per 10 or 1 minute, or 10 seconds: enterprise application or
possible for home gateway connectivity checking
- 1 CCM per 1 second: default for fault management in transport network
- 1 CCM per 100 microseconds: default for performance monitoring in
transport network
- 1 CCM per 10 milliseconds: option for protection switching in transport
network
- 1 CCM per 3.33 milliseconds: default for protection switching in transport
network.
 
To detect for inconsistent configuration between MEP functions, the period
of the CCM frame is encoded in the frame and checked by each MEP_Sk
function. If there is a mismatch an alarm is raised.
 
When a misconnection connects a MEP_So function with CCM period of e.g. 1
second with a MEP_Sk function with CCM period of e.g. 100 ms the receipt of
the first CCM frame with an incorrect MEGID will detect the MMG defect. The
MMG defect clearing algorithm uses the period value in the unexpected CCM
frame to determine the clearing of the fault condition.
 
The MMG defect detection process runs always, also when the MEG does not
generate CCM frames itself. In this way a misconnection with another VLAN
will always be detected.
 
Different CCM periods and a mix of VLANs with and without CCM generation are
as such not a problem in the Ethernet networks.
 
MPLS-TP OAM should use the same periods, same configuration method and same
defect detection method. MPLS-TP OAM (for PW and LSP) and Ethernet OAM (for
VPLS and Ethernet section layers) will be used in PE nodes side by side, and
it would be bad to deploy different policies for PW/LSP and VPLS/Ethernet
sections.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: vrijdag 2 april 2010 18:25
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive
CV/CC

All, 

I think the key point is that to avoid the alarm cycling the CV rate must be
consistent across the network.  To achieve this the CV rate must be set by
the operator and not by negotiation along each path. 

Regards, 

Malcolm 

<[email-masked]> 

02/04/2010 10:47 AM 

To

cc

Subject

However, the major point wrt the alarm cycling issue is consistent use of CV
rates within the same layer network....whatever the chosen rate.

regards, Neil

---

From: <[email-masked]>
Date: Fri, 2 Apr 2010 19:59:02 +0100

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?
 
I think reference to Ethernet or any other specific technology is not relevant.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
	Sent: 02 April 2010 18:37
	To: [email-masked]; [email-masked]
	Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/modefor proactive CV/CC

	All,
	 
	In Ethernet OAM we deploy multiple CCM rates. Generation of CCM frames can be enabled/disabled.
	 
	The rate is set by the NMS (or GMPLS) and depends on the most demanding application:
	 
	- 1 CCM per 10 or 1 minute, or 10 seconds: enterprise application or possible for home gateway connectivity checking
	- 1 CCM per 1 second: default for fault management in transport network
	- 1 CCM per 100 microseconds: default for performance monitoring in transport network
	- 1 CCM per 10 milliseconds: option for protection switching in transport network
	- 1 CCM per 3.33 milliseconds: default for protection switching in transport network.
	 
	To detect for inconsistent configuration between MEP functions, the period of the CCM frame is encoded in the frame and checked by each MEP_Sk function. If there is a mismatch an alarm is raised.
	 
	When a misconnection connects a MEP_So function with CCM period of e.g. 1 second with a MEP_Sk function with CCM period of e.g. 100 ms the receipt of the first CCM frame with an incorrect MEGID will detect the MMG defect. The MMG defect clearing algorithm uses the period value in the unexpected CCM frame to determine the clearing of the fault condition.
	 
	The MMG defect detection process runs always, also when the MEG does not generate CCM frames itself. In this way a misconnection with another VLAN will always be detected.
	 
	Different CCM periods and a mix of VLANs with and without CCM generation are as such not a problem in the Ethernet networks.
	 
	MPLS-TP OAM should use the same periods, same configuration method and same defect detection method. MPLS-TP OAM (for PW and LSP) and Ethernet OAM (for VPLS and Ethernet section layers) will be used in PE nodes side by side, and it would be bad to deploy different policies for PW/LSP and VPLS/Ethernet sections.
	 
	Regards,
	Maarten

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: vrijdag 2 april 2010 18:25
	To: [email-masked]
	Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

	All, 
	
	I think the key point is that to avoid the alarm cycling the CV rate must be consistent across the network.  To achieve this the CV rate must be set by the operator and not by negotiation along each path. 
	
	Regards, 
	
	Malcolm 

<[email-masked]> 

02/04/2010 10:47 AM 

To
<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]> 
cc
[email-masked], [email-masked], [email-masked], [email-masked] 
Subject
Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive        CV/CC	

	
	regards, Neil

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 2 Apr 2010 17:44:33 -0700

Dear Italo,
You wrote:
"- we need a very simple and lightweight protocol that check continuity and
connectivity ("are you there?" question with a "yes/no" answer)"
I do agree with Neil that mechanism should be unidirectional with CV
messages sent asynchronously at predetermined frequencies (can be asymmetric
in case of bidirectional connection).
And, unfortunately, we have to argument BFD with proper ID through ACH TLVs.
I think that  "lightweight" can be true or not only relative to an
alternative solution.

Regards,
Greg

On Fri, Apr 2, 2010 at 12:57 AM, BUSI ITALO
<[email-masked]>wrote:

> Dave, Greg,
>
> I think we are mixing different aspect of requirements, solutions and
> - we need a very simple and lightweight protocol that check continuity and
> connectivity ("are you there?" question with a "yes/no" answer)
>
> - the return path is required only on bidirectional p2p paths (either