Re: [mpls-tp] BFD sessions wrt protection types

Hi,

As I said, all references to protection will be removed from the I-D.  This means that there is no mandated coupling of which mode is run with which protection scheme.

Thanks,

John

> -----Original Message-----
> From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf
> Of John E Drake
> Sent: Monday, June 14, 2010 8:26 AM
> To: Lavanya Srivatsa; MPLS TP; David Allan I
> Subject: Re: [mpls-tp] BFD sessions wrt protection types
> 
> Hi,
> 
> The latest version of cc-cv-rdi will remove all references to protection
> switching.
> 
> In order to have a mode in which an LSP failure in one direction did not
> cause a failure in the other direction, it turns out that using two
> essentially uni-directional BFD sessions minimized the changes to BFD.  As
> indicated in the I-D, we basically just have several clarifications to
> existing BFD behavior.
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On
> Behalf
> > Of Lavanya Srivatsa
> > Sent: Sunday, June 13, 2010 12:10 PM
> > To: MPLS TP; David Allan I
> > Subject: Re: [mpls-tp] BFD sessions wrt protection types
> >
> > Dave,
> >
> > Please see inline.
> >
> > - Lavanya
> >
> > ________________________________
> >
> > From: David Allan I [david.i.allan@ericsson.com]
> > Sent: Wednesday, June 09, 2010 11:32 PM
> > To: Lavanya Srivatsa; MPLS TP
> > Subject: RE: BFD sessions wrt protection types
> >
> >
> > HI Lavanya:
> >
> >
> >
> > When the draft-ietf-mpls-tp-cc-cv-rdi states:
> >
> > "A single bi-directional BFD session is used for fate sharing operation.
> > Two independent BFD sessions are used for independent operation.
> >
> > ....
> >
> > The normal usage is that 1:1 protected paths must use fate sharing, and
> > independent operation applies to 1+1 protected paths."
> >
> >
> >
> > Does this mean that every time (and whenever it is done so) the
> protection
> > switching architecture is changed by configuration/administrator from
> one
> > to the other, the number of BFD sessions must change? Changing BFD
> > sessions would include tear down or new setup of sessions?
> >
> >
> >
> > As currently written the answer would be "yes". However how frequently
> do
> > you actually expect this to happen in practice. Isn't this a change that
> > moves at the speed of lawyers?
> >
> >
> >
> > [LS] Agreed, this is not expected to change often, maybe only once
> during
> > network setup too. But I was trying to make a different point here. I
> feel
> > that protection is one way of using the, if I may call it, "output" of
> an
> > OAM process. As an alternate, (and just for argument's sake), faults
> > detected by an OAM process need not necessarily result in a protection
> > switch. An operator (again just for argument's sake) could simply choose
> > to have alarms generated and to take corrective actions through manual
> > intervention.
> >
> > Similarly, a protection switch onto a recovery path need not be the
> result
> > of an OAM indication, but could be manually driven.
> >
> > So, on the whole, I feel the OAM and protection switch processes are
> > related but not dependent. Therefore imposing restrictions on the number
> > of BFD sessions based on the protection switching architecture, IMHO,
> does
> > not seem to be right.
> >
> > For eg: if 1:1 requires fate share, it should be of no interest to the
> > protection switch process, whether the OAM process chose to run 1
> OAM/BFD
> > session or 2 OAM/BFD sessions. All the protection switch process needs
> is
> > that, irrespective of the number of sessions, the traffic of both
> > directions of the path fate share even during an unidirectional fault.
> How
> > the OAM process does this should not be of any concern to the protection
> > switch process.
> >
> >
> >
> > Since protection switching is an "application" that uses the OAM
> > functionality to protect traffic, why should the "underlying" OAM
> > operation be disturbed just because the "application" above it undergoes
> a
> > change?
> >
> >
> >
> > I am unable to understand the dependency of the number of BFD-OAM
> sessions
> > based on the protection switching architectures/types.
> >
> >
> >
> > In a perfect world specifying a greenfield technology you'd get that
> > decoupling. My take is that BFD cares about whether somthing is up or
> down
> > in order to conserve nodal resources. When something is broken, the node
> > has better things to do than expend compute cycles originiating large
> > numbers of messages that simply black hole. That is when the nodal
> > resources are better spent being available for management or CP
> activity,
> > and restoration will happen faster in some implementations as a
> > consequence of dialing back superfluous BFD message generation.
> >
> >
> >
> > I hope this helps
> >
> > D
> >
> >
> 
> _______________________________________________
> mpls-tp mailing list
> mpls-tp@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-tp