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

From: [email-masked]
Date: Tue, 1 Mar 2005 12:32:40 -0000

Suping Zhai, Dave,

>From what I understand, the purpose of the FEC filter is to verify that the FEC for incoming traffic matches an egress FEC for the corresponding LSP. This verification is performed by comparing the FEC filter in the received BFD packet with the egress FEC filter for the LSP concerned. So in basic terms, if we receive a packet with a FEC of 10.2.10.1, we check that the egress LSP has been set up to forward traffic for FEC 10.2.10.1 (although the check uses a filter that represents 10.2.10.1 rather than the FEC itself). Is my understanding here correct?

Other things I would like to understand are:

1. Is the check just performed at client/server sink termination points (i.e. points in the network where a label is popped), or does the check take place at connection/flow points as well (i.e. points in the network where labels are swapped)?

2. Does this function support L1/L2 FECs as well as IP address FECs? e.g. where the FEC for a PW is an Ethernet VLAN/port or an ATM VCI/VPI?

3. Does the FEC filter detect defects that LSP ping can't? Or does it provide the same functionality (or subset of functionality) but because it is less processing intensive it can be used at more frequent time intervals?

There is obviously a need to detect data/control plane inconsistencies, and therefore the FEC filter is a useful function. However, is there likely to be a processing hit, i.e. a reduction in the number of BFD sessions I can support? If not, then from an operators perspective, if I can switch on BFD and it will detect these defects "for free" then this would be a desirable addition to BFD.

Saying that, looking at things from a vendors perspective, if this function can already be performed using LSP ping, then I guess spending time/money adding this function into BFD comes down to determining how often we need to check for these defects, i.e. LSP ping minutes, BFD seconds. I guess that only time will tell how frequently these types of defects occur based on operational experience.

Regards,
Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Thomas D. Nadeau
> Sent: 28 February 2005 21:51
> To: Jeffrey Haas
> Cc: [email-masked]; 'David Ward'
> Subject: Re: draft-suping-bfd-mpls-fecmismatch-00 questions
> 
> 
> 
> On Feb 28, 2005, at 4:00 PM, Jeffrey Haas wrote:
> 
> > On Mon, Feb 28, 2005 at 03:57:18PM -0500, David Allan wrote:
> >>> BFD won't be able to tell you what is actually broken. OAM
> >>> thingies do this.
> >>
> >> Agreed, goal is to simply know so you can follow up...
> >
> > Then wouldn't it be best to BFD for what it is good at, 
> namely checking
> > that forwarding is working, and then use another mechanism to clean
> > house when something fails?
> 
> 	I explained in my first posting on this draft that there
> already exist mechanisms that can be used to confirm the
> consistency of the sessions. There is no need for another
> mechanism, IMO.
> 
> 	--Tom
> 
> 
> 
> >
> > By analogy, one doesn't extend ICMP to check your interface 
> > configuration
> > because you want to add this to your ping.
> >
> > (Then again, seeing such a thing proposed in the IPv6 working groups
> > wouldn't shock me at all. :-)
> >
> >
> > -- 
> > Jeff Haas
> > NextHop Technologies
> >
> 
>

---

From: "David Allan" <[email-masked]>
Date: Tue, 1 Mar 2005 10:20:33 -0500

Hi Richard:

> From what I understand, the purpose of the FEC filter is to 
> verify that the FEC for incoming traffic matches an egress 
> FEC for the corresponding LSP. This verification is performed 
> by comparing the FEC filter in the received BFD packet with 
> the egress FEC filter for the LSP concerned. So in basic 
> terms, if we receive a packet with a FEC of 10.2.10.1, we 
> check that the egress LSP has been set up to forward traffic 
> for FEC 10.2.10.1 (although the check uses a filter that 
> represents 10.2.10.1 rather than the FEC itself). Is my 
> understanding here correct?

Yes, correct on both counts, the filter is simply a common "control plane
independent" encoding of the FEC.

> 1. Is the check just performed at client/server sink 
> termination points (i.e. points in the network where a label 
> is popped), or does the check take place at connection/flow 
> points as well (i.e. points in the network where labels are swapped)?

As there is no concept of a MIP in MPLS, it is only sink termination
points...

> 2. Does this function support L1/L2 FECs as well as IP 
> address FECs? e.g. where the FEC for a PW is an Ethernet 
> VLAN/port or an ATM VCI/VPI?

1713 has a place holder for encoding rules, but as the PW FECs were not
finalized at the time of publishing, an addemdum would be required (if those
rules were adopted). Not a big deal...

> 3. Does the FEC filter detect defects that LSP ping can't? Or 
> does it provide the same functionality (or subset of 
> functionality) but because it is less processing intensive it 
> can be used at more frequent time intervals?

Provides subset of functionality at a much lower processing cost... (no
traceroute, no FEC stack, simply a pairwise relationship). Answers the
question "Does LSP function at egress correspond to LSP function at
ingress". Note that this is stateless in that the egress does not maintain
per ingress state for this check....

> 
> There is obviously a need to detect data/control plane 
> inconsistencies, and therefore the FEC filter is a useful 
> function. However, is there likely to be a processing hit, 
> i.e. a reduction in the number of BFD sessions I can support? 
> If not, then from an operators perspective, if I can switch 
> on BFD and it will detect these defects "for free" then this 
> would be a desirable addition to BFD.

Processing is AND one field with the inverse of the other, (est. 16
assembler instructions for an 8 bit processor...) and if result is non zero,
there is a fault. Of course if I code it in Java....;-).

It was as close to free as it could be made...

> 
> Saying that, looking at things from a vendors perspective, if 
> this function can already be performed using LSP ping, then I 
> guess spending time/money adding this function into BFD comes 
> down to determining how often we need to check for these 
> defects, i.e. LSP ping minutes, BFD seconds. I guess that 
> only time will tell how frequently these types of defects 
> occur based on operational experience.

And the relative cost of PING when used proactively...

cheers
Dave

> > 	I explained in my first posting on this draft that 
> there already 
> > exist mechanisms that can be used to confirm the consistency of the 
> > sessions. There is no need for another mechanism, IMO.
> > 
> > 	--Tom
> > 
> > 
> > 
> > >