Subject: Re: [mpls-tp] 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

---

From: Maarten Vissers <[email-masked]>
Date: Sat, 03 Apr 2010 03:08:15 +0200

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.
 
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... 
 
Regards,
Maarten 
 
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,

 

 

 
Regards,
Maarten

  _____  

All, 

Regards, 

Malcolm 

<[email-masked]> 

02/04/2010 10:47 AM 

To

cc

Subject

regards, Neil

---

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

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,

	[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.

	[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 
	 
	regards, Neil

		All,

		 

		 

		 
		Regards,
		Maarten

		All, 

		Regards, 
		
		Malcolm 

<[email-masked]> 

02/04/2010 10:47 AM 

To

		
		regards, Neil

---

From: Rui Costa <[email-masked]>
Date: Wed, 7 Apr 2010 17:50:36 +0100

Hi,	

I would also like to express my concern regarding a non-fixed time interval for proactive CV/CC.	

OAM is the basis for status and performance - the elementary operator's observation tools. Should be simple and predictable hence fixed time interval for proactive CV/CC.	

Regards,	
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: sexta-feira, 2 de Abril de 2010 12:57
To: [email-masked]; [email-masked]; David Ward; [email-masked]
Cc: [email-masked]; David Ward; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive CV/CC

    Neil,

    --Tom

>> think that "repetita juvant":
>>

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 07 Apr 2010 19:56:32 +0200

Hi,

I can't agree more with Rui, ehis would be a *must* for most operators.

Regards, Huub.

====

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Mon, 12 Apr 2010 15:14:49 +0200

I do agree with Rui's comments.

I have a great concern about BFD non-fixed time intervals behavior.

If the operator fixes a specific time interval for OAM messages to meet specific (client and/or infrastructural) needs (e.g. for protection switching, performance monitoring, fault detection) there is NO reason for the equipment to change automatically such a value.

Best regards,
Alessandro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: mercoledì 7 aprile 2010 18.51
To: Thomas D. Nadeau
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Hi,

Regards,
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: sexta-feira, 2 de Abril de 2010 12:57
To: [email-masked]; [email-masked]; David Ward; [email-masked]
Cc: [email-masked]; David Ward; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive CV/CC

    Neil,

    --Tom

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 12 Apr 2010 09:20:11 -0400

The point is not to allow the equipment to modify the intervals as it
wishes -- but to allow operational configurations that may differ depending
on local needs/requirements.  Surely if you talk to your operational
department you will find requirements that sometimes differ from mine or
another operator's. In these cases wouldn't it make sense for you to be able
to configure things as needed for your business?

    --Tom

On 4/12/10 9:14 AM, "D'Alessandro Alessandro Gerardo"
<[email-masked]> wrote:

> If the operator fixes a specific time interval for OAM messages to meet
> specific (client and/or infrastructural) needs (e.g. for protection switching,
> performance monitoring, fault detection) there is NO reason for the equipment
> to change automatically such a value.
> 
> Best regards,
> Alessandro
> 
> 
> OAM is the basis for status and performance - the elementary operator's
> observation tools. Should be simple and predictable hence fixed time interval
> for proactive CV/CC.
> 
> Regards,
> Rui
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
>

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Mon, 12 Apr 2010 15:33:44 +0200

HI Tom,
There are two different topics related to the same email subject (Choice of BFD mechanism/mode for proactive CV/CC):

1. allowing the protocol implementing CC and CV (BFD) to change time intervals that were configured by the operator. This is the topic I wanted to address in my previous email.

2. allowing the configuration of different time intervals at the same layer. You addressed this point in your answer.

Best regards,
Alessandro

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: lunedì 12 aprile 2010 15.20
To: D'Alessandro Alessandro Gerardo; Rui Costa
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

    --Tom

---

From: David Allan I <[email-masked]>
Date: Mon, 12 Apr 2010 09:43:02 -0400

Lets not confuse any of several issues here....

1) There is a fixed interval required to guarantee a given SLA.... Done deal, well understood...it cannot arbitrarily shift around once the service has entered the available state 

2) As a bit of history, there was a requirement in 1711 for a homogenous periodic rate network wide such that entry/exit criteria for misbranching defects could be made to work consistently and not flap. I believe this is what Tom was referring to. 

When that was relaxed in 1711, it was via adding information in the PDU that self described the periodicity of the flow so the entry/exit criteria could be properly adjusted when misbranching occurred between LSPs using substantially different periodicities. E.g. if a flow at a rate of 1/sec leaked into an LSP normally monitored at a rate of 3.3msec... The exit criteria for the misbranching defect needed to be not seeing a misbranched OAM flow for over 3 seconds.... (vs. the 10 msec that a dumb implementation would do, and hence flapping every second)....sort of thing.

I believe there is agremeent that for a given LSP, the periodicity of the OAM flow will be fixed for an LSP in the available state. The only thing being discussed around draft-asm that MAY be a source of confusion on this subject is the desire to verify that the SLA specified rate can be supported by the MEPs prior to operating the OAM flow at the fixed periodicity specified by the SLA, and the LSP then becoming available....the next respin of the draft will spell this out as well as the associated procedures much more clearly...

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of D'Alessandro Alessandro Gerardo
Sent: Monday, April 12, 2010 9:15 AM
To: Rui Costa
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Best regards,
Alessandro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: mercoledì 7 aprile 2010 18.51
To: Thomas D. Nadeau
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Hi,

Regards,
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: sexta-feira, 2 de Abril de 2010 12:57
To: [email-masked]; [email-masked]; David Ward; [email-masked]
Cc: [email-masked]; David Ward; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] 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.
Flexibility with consistency is what we need to aim for here.

    --Tom

> different CV rates in a network would cause 'alarm cycling' problems 
> 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 
> with....not a great idea, so I would strongly suggest that the CV rate 
> BTW - if you set the CV rate too fast you run the danger of declaring 
> Defect detection OAM should always be unidirectional in nature in co 
> 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 
> identifier.  This does assume of course that the layer network being 
> considered has been given decent addressing in the first place.....not 
> 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.
>
> key point here is that any perf monitoring for SLAs must be suspended 
> in both directions for the duration of the unavailability event.  And 
> 3 From transparency considerations a (parent) connection should only 
> possible that this arch requirement could be violated.  In such a case 
> unavailable state (and all the consequent actions that would apply) is 
> combinatorial of loss/delay in the (child) traffic units of each CoS.  
> 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
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of BUSI ITALO
>>> 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).
>>>
>>>
>>> today, within BFD for MPLS one can create unidirectional BFD session 
>>> multipoint networks mechanism. Or a root can "pretend" that p2mp LSP

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Mon, 12 Apr 2010 17:44:24 +0200

Dave,
please see my comment inline:

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: lunedì 12 aprile 2010 15.43
To: D'Alessandro Alessandro Gerardo; Rui Costa
Cc: [email-masked]
Subject: RE: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

>[dalessandro] what do you mean with "the service has entered the available >state?". Do you refer to BDF entering the UP state? If yes, I agree.

>[dalessandro] aligned with my previous email to Tom

>[dalessandro] ok

>[dalessandro] Does "LSP in the available state" means that the BFD session for that particular LSP is in the UP state?, If yes, I agree.
Anyway I expect to have fixed periodicity at all levels: PW, LSP and Section.
Verifying the possibility to provide the requested OAM message periodicity (e.g. BFD) before LSP becoming available is good. I don't know if you are referring to the usage of the "slow rate" mechanism (slow transmission of BFD Control Packets) during the provisioning phase. Anyway, it must be limited to the provisioning phase (e.g. the protocol cannot go to "slow rate" in case of fault along the monitored session). In other words, given a PW or LSP or Section, the periodicity must not change once the operator fixes it and the network support it.

Cheers
Dave

>[dalessandro] Best regards,
Alessandro
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of D'Alessandro Alessandro Gerardo
Sent: Monday, April 12, 2010 9:15 AM
To: Rui Costa
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Best regards,
Alessandro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: mercoledì 7 aprile 2010 18.51
To: Thomas D. Nadeau
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Hi,

Regards,
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: sexta-feira, 2 de Abril de 2010 12:57
To: [email-masked]; [email-masked]; David Ward; [email-masked]
Cc: [email-masked]; David Ward; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive CV/CC

    Neil,

    --Tom

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 12 Apr 2010 10:04:14 -0700

Dear Alessandro,
I think that service availability is not identical to Up state of
corresponding BFD session. In my view, the there's time axis in availability
determination. We can say that the service is available based on duration of
verified connectivity for, in case of BFD-based CV, at least transmission
interval multiplied by detection multiplier.

Regards,
Greg

On Mon, Apr 12, 2010 at 8:44 AM, D'Alessandro Alessandro Gerardo <
[email-masked]> wrote:

> 1) There is a fixed interval required to guarantee a given SLA.... Done
> deal, well understood...it cannot arbitrarily shift around once the service
> has entered the available state
>
> >[dalessandro] what do you mean with "the service has entered the available
> >state?". Do you refer to BDF entering the UP state? If yes, I agree.
>
>
> 2) As a bit of history, there was a requirement in 1711 for a homogenous
> periodic rate network wide such that entry/exit criteria for misbranching
> defects could be made to work consistently and not flap. I believe this is
> what Tom was referring to.
>
> When that was relaxed in 1711, it was via adding information in the PDU
> that self described the periodicity of the flow so the entry/exit criteria
> could be properly adjusted when misbranching occurred between LSPs using
> substantially different periodicities. E.g. if a flow at a rate of 1/sec
> leaked into an LSP normally monitored at a rate of 3.3msec... The exit
> criteria for the misbranching defect needed to be not seeing a misbranched
> OAM flow for over 3 seconds.... (vs. the 10 msec that a dumb implementation
> would do, and hence flapping every second)....sort of thing.
>
> >[dalessandro] ok
>
>
> I believe there is agremeent that for a given LSP, the periodicity of the
> OAM flow will be fixed for an LSP in the available state. The only thing
> being discussed around draft-asm that MAY be a source of confusion on this
> subject is the desire to verify that the SLA specified rate can be supported
> by the MEPs prior to operating the OAM flow at the fixed periodicity
> specified by the SLA, and the LSP then becoming available....the next respin
> of the draft will spell this out as well as the associated procedures much
> more clearly...
>
> >[dalessandro] Does "LSP in the available state" means that the BFD session
> for that particular LSP is in the UP state?, If yes, I agree.
> Verifying the possibility to provide the requested OAM message periodicity
> (e.g. BFD) before LSP becoming available is good. I don't know if you are
> referring to the usage of the "slow rate" mechanism (slow transmission of
> BFD Control Packets) during the provisioning phase. Anyway, it must be
> limited to the provisioning phase (e.g. the protocol cannot go to "slow
> rate" in case of fault along the monitored session). In other words, given a
> PW or LSP or Section, the periodicity must not change once the operator
> fixes it and the network support it.
>
>
> Cheers
> Dave
>
> Of D'Alessandro Alessandro Gerardo
> specific (client and/or infrastructural) needs (e.g. for protection
> switching, performance monitoring, fault detection) there is NO reason for
> the equipment to change automatically such a value.
>
> Best regards,
> Alessandro
>
>
> Of Rui Costa
> observation tools. Should be simple and predictable hence fixed time
> interval for proactive CV/CC.
>
> Regards,
> Rui
>
> Thomas D. Nadeau

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 12 Apr 2010 21:16:08 +0200

One question related to some of the writing. SLAs are associated with the
transport service instances. Transport path instances don't have a SLA.
Section instances don't have a SLA either.
 
It is much simpler to have the following default values:
 
- 1 per second if fault management is to be supported without performance
monitoring/protection switching
- 10 per second if fault management and performance monitoring is to be
supported without protection swtiching
- 300 per second if fault management, performance monitoring and protection
swithcing are to be supported.
 
The request to set up a PW or a LSP will be indicating which applications
have to be supported, and this determines the required rate. 
If the PW MEP or LSP MEP can not support the required rate, the application
can not be supported and another PW/LSP MEP set has to be used instead.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Mirsky
Sent: maandag 12 april 2010 19:04
To: D'Alessandro Alessandro Gerardo
Cc: Rui Costa; [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive
CV/CC

Dear Alessandro,

Regards,
Greg

On Mon, Apr 12, 2010 at 8:44 AM, D'Alessandro Alessandro Gerardo
<[email-masked]> wrote:

Dave,

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: lunedì 12 aprile 2010 15.43
To: D'Alessandro Alessandro Gerardo; Rui Costa
Cc: [email-masked]

Subject: RE: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive
CV/CC

>[dalessandro] aligned with my previous email to Tom

When that was relaxed in 1711, it was via adding information in the PDU that
self described the periodicity of the flow so the entry/exit criteria could
be properly adjusted when misbranching occurred between LSPs using
substantially different periodicities. E.g. if a flow at a rate of 1/sec
leaked into an LSP normally monitored at a rate of 3.3msec... The exit
criteria for the misbranching defect needed to be not seeing a misbranched
OAM flow for over 3 seconds.... (vs. the 10 msec that a dumb implementation
would do, and hence flapping every second)....sort of thing.

Anyway I expect to have fixed periodicity at all levels: PW, LSP and
Section.

Cheers
Dave

Alessandro

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Tue, 13 Apr 2010 00:51:36 +0200

Dear Greg,
The message I'd like to remain from my previous email is the recommendation about BFD behavior: the BFD periodicity must not change once the operator fixes it and the network supports it.

To reply to your email, in my understanding we are saying the same thing...

Best regards,
Alessandro

-----Original Message-----
Sent: 12 aprile 2010 19.04 Greg Mirsky wrote:

Dear Alessandro,
I think that service availability is not identical to Up state of corresponding BFD session. In my view, the there's time axis in availability determination. We can say that the service is available based on duration of verified connectivity for, in case of BFD-based CV, at least transmission interval multiplied by detection multiplier.

Regards,
Greg
On Mon, Apr 12, 2010 at 8:44 AM, D'Alessandro Alessandro Gerardo <[email-masked]<mailto:[email-masked]>> wrote:
Dave,
please see my comment inline:

-----Original Message-----
Sent: lunedì 12 aprile 2010 15.43 David Allan wrote:

Cheers
Dave

Alessandro
-----Original Message-----
Sent: Monday, April 12, 2010 9:15 AM D'Alessandro Alessandro wrote:

Best regards,
Alessandro

-----Original Message-----
Sent: mercoledì 7 aprile 2010 18.51 Rui Costa worte:

Hi,

Regards,
Rui

-----Original Message-----
Sent: sexta-feira, 2 de Abril de 2010 12:57 Thomas D. Nadeau wrote:

   Neil,

   --Tom

>> Sent: 02 April 2010 08:58 Italo Busi wrote:
>> Dave, Greg,
>>
>> P.S. Please note my new email address, [email-masked]<mailto:[email-masked]>,
>> effective since 1 November 2009.
>>
>>> Sent: 31 marzo 2010 18.33 David Ward wrote:
>>>
>>> Greg -
>>>
>>> On Thu, Mar 25, 2010 at 2:55 PM, Greg Mirsky wrote:
>>> Dear Authors and All,

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Tue, 13 Apr 2010 07:43:05 +0200

Hi Alessandro,
You wrote:
>[dalessandro].....I expect to have fixed periodicity at all levels: PW, LSP and Section.

I fully agree with you. This was the main open issue that stopped the progress of 
http://tools.ietf.org/html/draft-asm-mpls-tp-bfd-cc-cv-01 (see section 4). The problem of bidirectional BFD is not the slow startup; the problem of bidirectional BFD is that the configured transmission rate is not maintained when the session transits from the UP state to DOWN state due to a failure; I reported a consequence of that in the last slide of my presentation at Anaheim: http://tools.ietf.org/agenda/77/slides/mpls-24.ppt 

We are still working to address that in the next respin of the draft.

Kind Regards
Annamaria
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of D'Alessandro Alessandro Gerardo
Sent: lunedì 12 aprile 2010 17.44
To: David Allan I
Cc: Rui Costa; [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFDmechanism/mode for proactive CV/CC

Dave,

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: lunedì 12 aprile 2010 15.43
To: D'Alessandro Alessandro Gerardo; Rui Costa
Cc: [email-masked]
Subject: RE: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Cheers
Dave

Alessandro
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of D'Alessandro Alessandro Gerardo
Sent: Monday, April 12, 2010 9:15 AM
To: Rui Costa
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Best regards,
Alessandro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: mercoledì 7 aprile 2010 18.51
To: Thomas D. Nadeau
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Hi,

Regards,
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: sexta-feira, 2 de Abril de 2010 12:57
To: [email-masked]; [email-masked]; David Ward; [email-masked]
Cc: [email-masked]; David Ward; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive CV/CC

    Neil,

    --Tom

---

From: David Allan I <[email-masked]>
Date: Tue, 13 Apr 2010 03:35:45 -0400

HI

To clarify, available = BFD UP state...

Hence I think we are in agreement ;-)

D

-----Original Message-----
From: D'Alessandro Alessandro Gerardo [mailto:[email-masked]]
Sent: Monday, April 12, 2010 11:44 AM
To: David Allan I
Cc: [email-masked]; Thomas D. Nadeau; Rui Costa
Subject: RE: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Dave,

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: lunedì 12 aprile 2010 15.43
To: D'Alessandro Alessandro Gerardo; Rui Costa
Cc: [email-masked]
Subject: RE: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Cheers
Dave

Alessandro
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of D'Alessandro Alessandro Gerardo
Sent: Monday, April 12, 2010 9:15 AM
To: Rui Costa
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Best regards,
Alessandro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: mercoledì 7 aprile 2010 18.51
To: Thomas D. Nadeau
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

Hi,

Regards,
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: sexta-feira, 2 de Abril de 2010 12:57
To: [email-masked]; [email-masked]; David Ward; [email-masked]
Cc: [email-masked]; David Ward; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive CV/CC

    Neil,

    --Tom

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 13 Apr 2010 16:07:37 +0200

Dave,

I see the following statement in Alessandro's mail: "Anyway, it must be limited to the provisioning phase (e.g. the protocol cannot go to "slow rate" in case of fault along the monitored session)."

As far as I know, BFD can leave the UP state also after the provisioning phase.

Please amend my understanding if mistaken.

If my understanding is correct, we still have to face the issue of how not to change the interval if BFD goes DOWN after the provisioning phase.

Thanks, Italo

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Allan I
> Sent: martedì 13 aprile 2010 9.36
> From: D'Alessandro Alessandro Gerardo 
> [mailto:[email-masked]]
> 1) There is a fixed interval required to guarantee a given 
> SLA.... Done deal, well understood...it cannot arbitrarily 
> shift around once the service has entered the available state
> 
> >[dalessandro] what do you mean with "the service has entered 
> the available >state?". Do you refer to BDF entering the UP 
> state? If yes, I agree.
> 
> 
> 2) As a bit of history, there was a requirement in 1711 for a 
> homogenous periodic rate network wide such that entry/exit 
> criteria for misbranching defects could be made to work 
> consistently and not flap. I believe this is what Tom was 
> referring to.
> 
> When that was relaxed in 1711, it was via adding information 
> in the PDU that self described the periodicity of the flow so 
> the entry/exit criteria could be properly adjusted when 
> misbranching occurred between LSPs using substantially 
> different periodicities. E.g. if a flow at a rate of 1/sec 
> leaked into an LSP normally monitored at a rate of 3.3msec... 
> The exit criteria for the misbranching defect needed to be 
> not seeing a misbranched OAM flow for over 3 seconds.... (vs. 
> the 10 msec that a dumb implementation would do, and hence 
> flapping every second)....sort of thing.
> 
> >[dalessandro] ok
> 
> 
> I believe there is agremeent that for a given LSP, the 
> periodicity of the OAM flow will be fixed for an LSP in the 
> available state. The only thing being discussed around 
> draft-asm that MAY be a source of confusion on this subject 
> is the desire to verify that the SLA specified rate can be 
> supported by the MEPs prior to operating the OAM flow at the 
> fixed periodicity specified by the SLA, and the LSP then 
> becoming available....the next respin of the draft will spell 
> this out as well as the associated procedures much more clearly...
> 
> >[dalessandro] Does "LSP in the available state" means that 
> the BFD session for that particular LSP is in the UP state?, 
> If yes, I agree.
> Verifying the possibility to provide the requested OAM 
> message periodicity (e.g. BFD) before LSP becoming available 
> is good. I don't know if you are referring to the usage of 
> the "slow rate" mechanism (slow transmission of BFD Control 
> Packets) during the provisioning phase. Anyway, it must be 
> limited to the provisioning phase (e.g. the protocol cannot 
> go to "slow rate" in case of fault along the monitored 
> session). In other words, given a PW or LSP or Section, the 
> periodicity must not change once the operator fixes it and 
> the network support it.
> 
> 
> Cheers
> Dave
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of D'Alessandro 
> Alessandro Gerardo
> If the operator fixes a specific time interval for OAM 
> messages to meet specific (client and/or infrastructural) 
> needs (e.g. for protection switching, performance monitoring, 
> fault detection) there is NO reason for the equipment to 
> change automatically such a value.
> 
> Best regards,
> Alessandro
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rui Costa
> OAM is the basis for status and performance - the elementary 
> operator's observation tools. Should be simple and 
> predictable hence fixed time interval for proactive CV/CC.
> 
> Regards,
> Rui
> 
> Behalf Of Thomas D. Nadeau
> Questo messaggio e i suoi allegati sono indirizzati 
> esclusivamente alle persone indicate. La diffusione, copia o 
> qualsiasi altra azione derivante dalla conoscenza di queste 
> informazioni sono rigorosamente vietate. Qualora abbiate 
> ricevuto questo documento per errore siete cortesemente 
> pregati di darne immediata comunicazione al mittente e di 
> provvedere alla sua distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may 
> contain privileged information intended for the addressee(s) 
> only. Dissemination, copying, printing or use by anybody else 
> is unauthorised. If you are not the intended recipient, 
> please delete this message and any attachments and advise the 
> Questo messaggio e i suoi allegati sono indirizzati 
> esclusivamente alle persone indicate. La diffusione, copia o 
> qualsiasi altra azione derivante dalla conoscenza di queste 
> informazioni sono rigorosamente vietate. Qualora abbiate 
> ricevuto questo documento per errore siete cortesemente 
> pregati di darne immediata comunicazione al mittente e di 
> provvedere alla sua distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may 
> contain privileged information intended for the addressee(s) 
> only. Dissemination, copying, printing or use by anybody else 
> is unauthorised. If you are not the intended recipient, 
> please delete this message and any attachments and advise the

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 13 Apr 2010 07:19:19 -0700

Hi Italo/ Annamaria,

I have not read the whole thread. However as the BFD protocol talks
about a slower rate it does not make any change in the protocol
because of the same.

A simple solution to your problem is to use the same value for slow
timer as well as Tx timer for MPLS-TP. That way the BFD can be used
without any changes.

We can do the same on our current BFD implementation without any
changes (just a configuration knob).

Thanks,
Vishwas

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 13 Apr 2010 18:01:14 +0300

Italo and all,
I fully agree that BFD sessions can go DOWN after the provisioning stage.
I'd also say that is exactly what makes it useful...

My 2c,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI ITALO
Sent: Tuesday, April 13, 2010 5:08 PM
To: David Allan I; D'Alessandro Alessandro Gerardo
Cc: Rui Costa; [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFDmechanism/mode for proactive CV/CC

Dave,

Thanks, Italo

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 13 Apr 2010 09:10:55 -0700

Hi Sasha,

This is about going to a slower rate when a session is down which may
not be to a liking for some people, not about the session going down
itself.

Like I mentioned there are mechanisms within the scope of BFD to allow
this to happen by configuring the same value for slow interval and the
fast hello interval.

Thanks,
Vishwas

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 12 Apr 2010 21:03:39 +0200

Regards,
Maarten

  _____  

Dear Alessandro,

Regards,
Greg

Dave,

-----Original Message-----
From: David Allan I [mailto:[email-masked]]
Sent: lunedì 12 aprile 2010 15.43
To: D'Alessandro Alessandro Gerardo; Rui Costa
Cc: [email-masked]

Cheers
Dave

Alessandro
-----Original Message-----

Best regards,
Alessandro

-----Original Message-----

Hi,

I would also like to express my concern regarding a non-fixed time interval
for proactive CV/CC.

Regards,
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas D. Nadeau
Sent: sexta-feira, 2 de Abril de 2010 12:57
To: [email-masked]; [email-masked]; David Ward;
[email-masked]
Cc: [email-masked]; David Ward; [email-masked]; [email-masked]
Subject: Re: [mpls] [mpls-tp] Choice of BFD mechanism/mode for proactive
CV/CC

   Neil,

   --Tom

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Wed, 14 Apr 2010 14:10:26 +0200

Hi Vishwas,
Yes I agree and it was proposed in draft-asm since the beginning ( see ver 00 and ver 01).
However not all author agreed at last with it. 

Please not also that in the in draft-ietf-bfd-base, section 6.8.3 is reported:
" When bfd.SessionState is not Up, the system MUST set bfd.DesiredMinTxInterval to a value of not less than one second(1,000,000 microseconds.)  This is intended to ensure that the bandwidth consumed by BFD sessions that are not Up is negligible, particularly in the case where a neighbor may not be running BFD."

Kind regards

Annamaria 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vishwas Manral
Sent: martedì 13 aprile 2010 16.19
To: BUSI ITALO
Cc: Rui Costa; [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFDmechanism/mode for proactive CV/CC

Hi Italo/ Annamaria,

I have not read the whole thread. However as the BFD protocol talks about a slower rate it does not make any change in the protocol because of the same.

A simple solution to your problem is to use the same value for slow timer as well as Tx timer for MPLS-TP. That way the BFD can be used without any changes.

We can do the same on our current BFD implementation without any changes (just a configuration knob).

Thanks,
Vishwas

On Tue, Apr 13, 2010 at 7:07 AM, BUSI ITALO <[email-masked]> wrote:
>> 1) There is a fixed interval required to guarantee a given SLA.... 
>> Done deal, well understood...it cannot arbitrarily shift around once 
>> the service has entered the available state
>>
>> the available >state?". Do you refer to BDF entering the UP state? If 
>> yes, I agree.
>>
>>
>> homogenous periodic rate network wide such that entry/exit criteria 
>> for misbranching defects could be made to work consistently and not 
>> flap. I believe this is what Tom was referring to.
>>
>> When that was relaxed in 1711, it was via adding information in the 
>> PDU that self described the periodicity of the flow so the entry/exit 
>> criteria could be properly adjusted when misbranching occurred 
>> between LSPs using substantially different periodicities. E.g. if a 
>> flow at a rate of 1/sec leaked into an LSP normally monitored at a 
>> rate of 3.3msec...
>> The exit criteria for the misbranching defect needed to be not seeing 
>> a misbranched OAM flow for over 3 seconds.... (vs.
>> the 10 msec that a dumb implementation would do, and hence flapping 
>> every second)....sort of thing.
>>
>> >[dalessandro] ok
>>
>>
>> I believe there is agremeent that for a given LSP, the periodicity of 
>> the OAM flow will be fixed for an LSP in the available state. The 
>> only thing being discussed around draft-asm that MAY be a source of 
>> confusion on this subject is the desire to verify that the SLA 
>> specified rate can be supported by the MEPs prior to operating the 
>> OAM flow at the fixed periodicity specified by the SLA, and the LSP 
>> then becoming available....the next respin of the draft will spell 
>> the BFD session for that particular LSP is in the UP state?, If yes, 
>> I agree.
>> Verifying the possibility to provide the requested OAM message 
>> periodicity (e.g. BFD) before LSP becoming available is good. I don't 
>> know if you are referring to the usage of the "slow rate" mechanism 
>> (slow transmission of BFD Control
>> Packets) during the provisioning phase. Anyway, it must be limited to 
>> the provisioning phase (e.g. the protocol cannot go to "slow rate" in 
>> case of fault along the monitored session). In other words, given a 
>> PW or LSP or Section, the periodicity must not change once the 
>> operator fixes it and the network support it.
>>
>>
>> Cheers
>> Dave
>>
>> If the operator fixes a specific time interval for OAM messages to 
>> meet specific (client and/or infrastructural) needs (e.g. for 
>> protection switching, performance monitoring, fault detection) there 
>> is NO reason for the equipment to change automatically such a value.
>>
>> Best regards,
>> Alessandro
>>
>>
>> operator's observation tools. Should be simple and predictable hence 
>> fixed time interval for proactive CV/CC.
>>
>> Regards,
>> Rui
>>
>> Of Thomas D. Nadeau
>>     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.
>> >>>  *   what are reasons considered to select only unidirectional 
>> >>> BFD (based on BFD for multipoint networks
>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente 
>> alle persone indicate. La diffusione, copia o qualsiasi altra azione 
>> derivante dalla conoscenza di queste informazioni sono rigorosamente 
>> vietate. Qualora abbiate ricevuto questo documento per errore siete 
>> cortesemente pregati di darne immediata comunicazione al mittente e 
>> di provvedere alla sua distruzione, Grazie.
>>
>> This e-mail and any attachments is confidential and may contain 
>> privileged information intended for the addressee(s) only. 
>> Dissemination, copying, printing or use by anybody else is 
>> unauthorised. If you are not the intended recipient, please delete 
>> this message and any attachments and advise the sender by return 
>> e-mail, Thanks.
>>
>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente 
>> alle persone indicate. La diffusione, copia o qualsiasi altra azione 
>> derivante dalla conoscenza di queste informazioni sono rigorosamente 
>> vietate. Qualora abbiate ricevuto questo documento per errore siete 
>> cortesemente pregati di darne immediata comunicazione al mittente e 
>> di provvedere alla sua distruzione, Grazie.
>>
>> This e-mail and any attachments is confidential and may contain 
>> privileged information intended for the addressee(s) only. 
>> Dissemination, copying, printing or use by anybody else is 
>> unauthorised. If you are not the intended recipient, please delete 
>> this message and any attachments and advise the sender by return 
>> e-mail, Thanks.
>>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 14 Apr 2010 12:16:49 -0400

[snipped rest of message as the list is rejecting long posts]

    I think its important to hear from operators who might want to deploy
this technology as to what their preferred defaults would be.  My concern
with regard to these defaults is also that some lower-end equipment may not
be able to support them at a high enough volume. That is, your statement is
only concerned with the defaults for ONE MPLS-TP service instance, but there
may be 100s or 1000s (or more) potentially serviced by the device in
question. If it cannot support even the default values, then they are of no
value.

    --Tom

On 4/12/10 3:03 PM, "Maarten Vissers" <[email-masked]> wrote:

> The request to set up a PW or a LSP will be indicating which applications have
> to be supported, and this determines the required rate.

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 14 Apr 2010 19:43:52 +0200

Tom,
 
The default values are designed to meet the basic requirements for fault
management, performance monitoring and protection switching.
 
What you are referring to is addition of MPLS-TP OAM to existing equipment
that is not capable to support those default values. 
For such case we have to understand what the capabilities of such equipment
are and which applications are to be supported.
 
Let's analyse:
 
1) fault management application can be supported when CC/CV and AIS OAM is
added to the existing equipment. Typically such equipment can not meet (as
you indicate) the default (fault management) rate for a large number of
terminating PWs and LSPs in that equipment. E.g. OAM can be supported by
system processor only, and e.g. 100 or 500 OAM messages per second can be
generated for the complete system. If 1000 PW/LSP MEPs are present in the
equipment, it will be possible in this example to generate 1 CC/CV OAM
message per 10 seconds or per 2 seconds.
AIS generation and insertion will most likely also take some of the
processor's OAM generation capability, so that CC/CV/AIS OAM can be
generated for fewer PWs/LSPs, or less often generated.
 
In Ethernet OAM we have introduced the following rates for such existing
equipment cases:
- 1 CCM message per 10 seconds
- 1 CCM message per minute
- 1 CCM message per 10 minutes.
 
And for AIS message we have introduced as second value - 1 per minute
(default is 1 per second).
 
Fault management is possible with those CCM and AIS rates, but the
performance will not meet the typical fault management performance. I.e. it
takes much longer to detect a defect and generate the alarm, and with the 1
per minute AIS there will be a loss of continuity (LOC) alarm for about 1
minute before the LOC failure is suppressed.
 
MPLS-TP CC/CV and AIS OAM can copy these values. This would result in one
common approach in packet transport networks, independent of the packet
technology (ethernet of mpls-tp).

2) the basic performance monitoring application could be supported with less
accuracy when CC/CV without LM is added to existing equipment. Performance
monitoring conssits of two components: (i) detection of signal fail
condition in a second and (ii) detection of signal degrade (packet loss).
Only the first part could be supported with less accuracy then normal; i.e.
defect detection takes more then 1-second and this will delay the detection
of a severely errored second. If a customer runs CC/CV/LM OAM with default
rate, then there will be a difference in the number of SESs and a difference
in the number of UASs detected by the customer and network.
 
3) the basic protection switching application could be supported with longer
detection times and thus switching will occur much later then by default.
 
I had a discussion with George this afternoon to see how the switching time
could be reduced by using an LDI indication in AIS messages. We concluded
that if AIS is generated within 1 second after the signal fail defect
detection, then AIS message with LDI set can be used by protection switch
located in the equipment with the low rate CC/CV OAM as signal fail
indication and start the protection protocol. This can reduce the switching
time from e.g. 3.5 seconds to less then 1 second, or from 35 second (3.5 x
10 seconds) to less then 1 second. Of course if the AIS insertion has to be
done in a node with slow rate OAM, then AIS insertion is most likely done
within 1-minute and it may not be of any help to reduce protection switching
time.
 
Note that in the above numbers I have not taken into account possible
further delays due to slow rate APS message generation. 1:1 SNC protection
requires the use of APS OAM to synchronise both endpoints (necessary to
retore the traffic flow).
 
In Ethernet OAM we also have introduced a CCM rate of 100 CCM messages per
second (10 ms periodicity).  Loss of CC detection will now take 35 ms
(instead of 11 ms). A little bit slower. 
 
Would the above values be sufficient to support the addition of some subset
of MPLS-TP OAM to existing equipment?
 
---------
 
To minimize the OAM message generation demand in equipment (especially
important for existing equipment) it would be important to minimise the
number of pro-active OAM messages to be generated per PW/LSP MEP. It would
be best to put the following OAM functions in one OAM message:
- CC
- CV
- LM (forward, backward)
- DM
- RDI.
 
If we would put those 5 OAM functions in 5 different OAM messages we will
increase the minimal OAM processing capability in every equipment, or have
more equipment that can not support the default application values.
 
Regards,
Maarten

  _____  

From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: woensdag 14 april 2010 18:17
To: Maarten Vissers; 'Greg Mirsky'; 'D'Alessandro Alessandro Gerardo'
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive
CV/CC

    --Tom

Regards,
Maarten

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 15 Apr 2010 16:36:09 -0700

Hi Annamaria,

Though I agree to the reccomendation that we should not use a timer
less than 1 second, I am not sure we should have a requirement like
that in the BFD spec itself.

That said why don't we remove the restriction for MPLS-TP and all will be good.

Thanks,
Vishwas

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Fri, 16 Apr 2010 11:48:06 +0200

Hi Vishwas,
Yes, I agree. 
I made the same proposal in draft-asm but it was rejected by some co-editor/author.

Kind regards
Annamaria
-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]] 
Sent: venerdì 16 aprile 2010 1.36
To: Annamaria Fulignoli
Cc: BUSI ITALO; Rui Costa; [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFDmechanism/mode for proactive CV/CC

Hi Annamaria,

Though I agree to the reccomendation that we should not use a timer less than 1 second, I am not sure we should have a requirement like that in the BFD spec itself.

Thanks,
Vishwas

On Wed, Apr 14, 2010 at 5:10 AM, Annamaria Fulignoli <[email-masked]> wrote:
>>> the available >state?". Do you refer to BDF entering the UP state? 
>>> If yes, I agree.
>>>
>>>
>>> PDU that self described the periodicity of the flow so the 
>>> entry/exit criteria could be properly adjusted when misbranching 
>>> occurred between LSPs using substantially different periodicities. 
>>> E.g. if a flow at a rate of 1/sec leaked into an LSP normally 
>>> monitored at a rate of 3.3msec...
>>> The exit criteria for the misbranching defect needed to be not 
>>> seeing a misbranched OAM flow for over 3 seconds.... (vs.
>>> I believe there is agremeent that for a given LSP, the periodicity 
>>> of the OAM flow will be fixed for an LSP in the available state. The 
>>> periodicity (e.g. BFD) before LSP becoming available is good. I 
>>> don't know if you are referring to the usage of the "slow rate" 
>>> mechanism (slow transmission of BFD Control
>>> Packets) during the provisioning phase. Anyway, it must be limited 
>>> to the provisioning phase (e.g. the protocol cannot go to "slow 
>>> rate" in case of fault along the monitored session). In other words, 
>>> given a PW or LSP or Section, the periodicity must not change once 
>>> the operator fixes it and the network support it.
>>>
>>>
>>> Cheers
>>> Dave
>>>
>>>     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.
>>>
>>> revisit this mistake again, but instead to require consistency, or 
>>> mechanisms to reconcile the differences in cases where it is 
>>> critical to discern them.
>>> > 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 
>>> > defects, and taking unnecessary consequent actions, on error 
>>> > bursts that could clear of their own accord.
>>> >
>>> > unavailable state then both directions are deemed unavailable.  
>>> > The key point here is that any perf monitoring for SLAs must be
>>> suspended
>>> > 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
>>> >>> optional and that if any of the options were *ever* desired then 
>>> >>> pure unidirectional MP BFD was not a good choice.
>>> >>>
>>> >>>
>>> >>> is p2p and send after first exchange of Discriminator, and 
>>> >>> ignore Discrminators from other, late-joiner leaves.
>>> >>>
>>> >>> Regards,
>>> >>> Greg
>>> >>>
>>> >>>
>>> >>>
>>> >>> HIH
>>> >>>
>>> >>> -DWard
>>> >>>

---

From: Rui Costa <[email-masked]>
Date: Mon, 19 Apr 2010 07:53:15 +0100

I would say the values indicated by Maarten. Don't currently see the need for periods longer than 10s.

As I wrote before, CV/CC will be the basic observation tool for operators in PTNs. A dynamic period instead of supervised by the operator's provision control is like using fancy sunglasses in a dark place where eyesight is critical to what we're doing. Please choose provisioned fixed CV/CC periods.

Regards,
Rui
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: quarta-feira, 14 de Abril de 2010 18:17
To: Maarten Vissers; 'Greg Mirsky'; 'D'Alessandro Alessandro Gerardo'
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

    I think its important to hear from operators who might want to deploy this technology as to what their preferred defaults would be.  My concern with regard to these defaults is also that some lower-end equipment may not be able to support them at a high enough volume. That is, your statement is only concerned with the defaults for ONE MPLS-TP service instance, but there may be 100s or 1000s (or more) potentially serviced by the device in question. If it cannot support even the default values, then they are of no value.

    --Tom

On 4/12/10 3:03 PM, "Maarten Vissers" <[email-masked]> wrote:
One question related to some of the writing. SLAs are associated with the transport service instances. Transport path instances don't have a SLA. Section instances don't have a SLA either.

- 1 per second if fault management is to be supported without performance monitoring/protection switching
- 10 per second if fault management and performance monitoring is to be supported without protection swtiching
- 300 per second if fault management, performance monitoring and protection swithcing are to be supported.

The request to set up a PW or a LSP will be indicating which applications have to be supported, and this determines the required rate.
If the PW MEP or LSP MEP can not support the required rate, the application can not be supported and another PW/LSP MEP set has to be used instead.

Regards,
Maarten

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Mon, 19 Apr 2010 19:20:03 +0200

The defaults values proposed by Marteen are reasonable.
TP profiled equipment should be able to support an adequate number of OAM instances at those values. If they shouldn't be, probably network planning was not adequate.

Best regards,
Alessandro
------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport & OPB Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

________________________________
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: mercoledì 14 aprile 2010 18.17
To: Maarten Vissers; 'Greg Mirsky'; D'Alessandro Alessandro Gerardo
Cc: [email-masked]
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for proactive CV/CC

    --Tom

Regards,
Maarten