Subject: RE: Re: draft-suping-bfd-mpls-fecmismatch-00 questions

From: "David Allan" <[email-masked]>
Date: Sun, 27 Feb 2005 16:21:39 -0500

It is not detecting a control plane failure, it is detecting inconsistencies
in forwarding such that synch between control and data plane has been lost..
connectivity to somewhere exists but is not necessarily correct...IMO that
is still a data plane problem...

Dave

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Ward
> Sent: Sunday, February 27, 2005 10:48 AM
> To: zhaisuping
> Cc: [email-masked]
> Subject: Re: Re: draft-suping-bfd-mpls-fecmismatch-00 questions
> 
> 
> Unfort., what you write is 180 degrees opposite from the 
> charter of the BFD WG and the philosophy of how the protocol 
> is to function. BFD is not to check the consistency of the 
> forwarding and control plane. We do not want to 
> take this protocol into the realm of control plane failure 
> detection system (as there are many better protocols or 
> protocol machinery for that) but,  focus on forwarding 
> failure detection that can send alarms, event notification, 
> diags, etc up the stack.
> 
> 
> -DWard
> 
> 
> 
> On Sat, Feb 26, 2005 at 09:41:49AM +0800, zhaisuping wrote:
> > Hi, all
> > The purpose of FEC filter in BFD is to detect the consistence of
> > the control plane and data plane. So that in the MPLS network, just
> > running the BFD session(LSP-Ping is not needed) is enough for the
> > defect detection. Or else such tools as LSP-Ping is needed because
> > the BFD session can't detect the inconsistence of the control plane
> > and data plane. 
> > In the section 2 of the draft, there is description of the 
> > problem the draft want to solve.
> > >> Wouldn't LSP-Ping (or VCCV) be a more appropriate place 
> to do this 
> > >> filter verification?
> > 
> > 
> > >
> > >LSP-Ping does a verification on the FEC itself, so a 
> filter would add 
> > >nothing.
> > >
> > >VCCV is not a protocol.  Just a little sideband for sending IP 
> > >packets down a pseudowire so that you can run LSP-Ping, BFD, etc. 
> > >between the two ends.
> > >
> > >....George
> > >
> > 
> >=============================================================
> ===========
> > >George Swallow             Cisco Systems                  
> (978) 936-1398
> > >                           1414 Massachusetts Avenue
> > >                           Boxborough, MA 01719
> 
> 
>

---

From: David Ward <[email-masked]>
Date: Sun, 27 Feb 2005 16:27:26 -0600

David -

In these cases, it would be best if the violating node sent the 
proper diag code and said that their forwarding plane was insane. We don't
want this protocol resonsbile for checking up to 4B FIB entries to see if they 
are installed correctly. To take this to a logical end, we would have to
check all addrs in all AF/SAF and all potential mismatches. The node itself
has to take some responsiblity when possible. When it is not possible, e.g.
GR, BFD can help detect some failures.   

If this problem is as we seem to agree a control plane programming issue,
an OAM protocol seems more applicable at config time.

-DWard

---

From: Dave Katz <[email-masked]>
Date: Sun, 27 Feb 2005 22:09:04 -0700

For what it's worth, we made a very conscious decision to keep 
media-specific information out of BFD, and so far at least have been 
successful.

The intent of BFD is to provide a pure liveness mechanism, which can 
operate at a very wide range of time constants, and is independent of 
media- and application-specific state and configuration management 
functions (which are typically intertwined, e.g., IGP Hellos.)

BFD is intended to run along side the media-specific protocols, given 
that BFD has no discovery mechanism, and depends on such protocols (or, 
perish the thought, static configuration.)  Further, most 
media-specific functions can either be made event-driven, or operate in 
a different magnitude of time than BFD, and as such are not appropriate 
to be carried in every packet, perhaps many times per second.

--Dave