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

[David Ward <[e-mail]>]

David -

On Mon, Feb 28, 2005 at 03:45:36PM -0500, David Allan wrote:
> HI Dave:
> 
> > 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 would not need a means of detecting it if the node simply knew ;-)
>

Since this is config time, the device can check vs assuming that neighboring
nodes will bail it out. If you don't trust your neighbor in the network to
program the FEC or anything into it's FIB correctly; BFD isn't going to be
able to help. 
 
> 
> > We don't want this protocol resonsbile for checking 
> > up to 4B FIB entries 
> 
> ???? not understanding the reqirement


The logical end to the twisting of BFD's architecture is to have to check
the validity of up to 4B IPv4 addrs (extend to V6, FEC, and anything else
that can be programmed into a Forwarding Information Base). This is a very
bad place to go.


> 
> > 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. 
> 
> The suggestion is to check that the FEC associated with an LSP running BFD
> via an additional token...the concern being primarily corruption of

This I understand

> forwarding at intermediate nodes... IMO not needed if we are discussing a
> p2p PHY link, as misdirection to a different BFD termination and collisions
> in the dsicriminator space are highly unlikely. Question is how often can
> you be sure when all is said and done, it truly was just a PHY...

BFD won't be able to tell you what is actually broken. OAM thingies do this.

-DWard

> 
> rgds
> Dave
>   
> > 
> > If this problem is as we seem to agree a control plane 
> > programming issue, an OAM protocol seems more applicable at 
> > config time.
> > 
> > -DWard
> > 
> > On Sun, Feb 27, 2005 at 04:21:39PM -0500, David Allan wrote:
> > > 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: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of David Ward
> > > > Sent: Sunday, February 27, 2005 10:48 AM
> > > > To: zhaisuping
> > > > Cc: [e-mail]
> > > > 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                  
> > > > [phone]
> > > > > >                           1414 Massachusetts Avenue
> > > > > >                           Boxborough, MA 01719
> > > > 
> > > > 
> > > > 
> > 
> >