[c-nsp] BFD alternative

[Phil Bedard]

I believe both devices support 802.3ah (Ethernet Link OAM).  You can get
similar functionality out of 802.3ah as BFD, although it operates at an
entire link level and not L3 logical interface level.  I'm not sure how
Cisco works with regards to 802.3ah and protocol notification but other
vendors simply mark the interface as down which triggers the protocols.
  

However, BFD/802.3ah is just for control plane fault detection, it doesn't
speed up convergence at all.  So using it in conjunction with IGP timer
optimization, etc. will help with re-convergence.

We are in a similar situation with the use of rings but our vendor does
not support unnumbered Ethernet links.  We use /31s on all of the links so
the ring insertions are done by adding IP addresses in a contiguous
fashion instead of worrying about normal /30s and skipping addresses.
Additionally we are using CSPF-driven RSVP-TE with FRR and using
unnumbered links doesn't really work.  I would stay away from unnumbered
links simply due to odd feature support, which is something you are
running into already.

Phil 

On 1/9/11 1:16 PM, "Jason Lixfeld" <jason at lixfeld.ca> wrote:

>
>On 2011-01-09, at 12:23 PM, Łukasz Bromirski wrote:
>
>> On 2011-01-09 17:40, Jason Lixfeld wrote:
>>> We're in the the process of turning up an MPLS network using ASR9ks
>> > and ME3600s.  We're looking to get away from L2 and interconnect all
>> > the devices at L3.
>> 
>> Wise move.
>> 
>> > To facilitate this, we were originally going to use unnumbered on all
>> > the PE-PE, P-P, P-PE links but we just recently discovered that BFD
>> > isn't supported on unnumbered Gig/TenGig interfaces.
>> 
>> Why go for unnumbered? It will be harder to troubleshoot, and the
>> address conservation for IPv4 /30 and IPv6 /64 just doesn't make sense
>> unless you're really short for IPs.
>
>Can you give me an example of how you believe it will be harder to
>troubleshoot?  We've considered this in our decision to go unnumbered,
>but haven't found any compelling arguments yet that support the idea a
>more complicated troubleshooting methodology.
>
>The reason for going unnumbered is mainly for administrative purposes
>than IP conservation.  Because of the way our fibre plant is laid out, we
>essentially daisy chain these nodes together into a ring/loop/chain,
>whatever you want to call it.  In a L2 world, we can add a node anywhere,
>let the SVI arp itself out and it just works; very plug and play'ish.  In
>an L3 world, if we want to add a node, we need hands in the two adjacent
>nodes to configure new IPs before the new node is reachable.  This now
>increases the potential for human error tremendously.  We think that
>unnumbered would make this look and feel more like the L2 world when
>installing new nodes.
>
>
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/