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

From: Jeff Tantsura <[email-masked]>
Date: Wed, 7 Apr 2010 13:06:28 -0400

Can't agree more with Thomas, this would be 'no go' for most of operators.

Regards,
Jeff

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Thomas D. Nadeau <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Wed Apr 07 11:50:36 2010
Subject: Re: [mpls-tp] [mpls] Choice of BFD mechanism/mode for	proactive	CV/CC

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,

    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!
> 
> 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
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> 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
>> Subject: Re: [mpls] Choice of BFD mechanism/mode for proactive CV/CC
>> 
>> 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,
>>> 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
>>> 
>>> 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.
>>> 
>>> 
>>> 
>>>  *   what capabilities of BFD for multipoint networks
>>> required for use as CV/CC in MPLS-TP
>>> 
>>> 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).
>>> 
>>> 
>>>  *   what of capabilities are optional (can and may)
>>> 
>>> 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.
>>> 
>>> 
>>>  *   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.
>>> 
>>> 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
>>> 
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls
>> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp