Re:Rtg-bfd Digest, Vol 163, Issue 25

["Albert Fu (BLOOMBERG/ 120 PARK)" <[e-mail]>]

Hi Robert,


> Imagine two scenarios which were already highlighted as justification for
> this work:

> *Scenario 1 -* IGP with nodes interconnected with ECMP links

> *Scenario 2 -* IGP nodes interconnected with L2 emulated circuits which in
> turn are riding on telco IP network with ECMPs or LAGs.

> *Questions Ad 1 - *

> Is the idea to use in those cases "ECMP-Aware BFD for LDP LSPs" vendor's
> feature to be able to detect MTU issues on any of the L3 paths ? Is there
> feature extension to accomplish the same without LDP just when using ECMP
> with OSPF ?
The draft does not go into the specific use cases. I think most BFD uses cases (certainly in our case) are on p2p IGP/eBGP links. (btw some vendors do not support control-plane BFD independence for multihops BFD, making it unreliable for fast detection). 


The end to end paths may have multiple multiple-ECMP links/paths. The BFD sessions on the individual link along the path will detect large packet issue.


> How do you solve this when there is L2 LAG hashing across N links enabled ?
This is a situation where you need more than standard BFD. It is a reason why some customers like us prefer not to run LAG on parallel WAN circuits, so we can diagnose interface issues easily via standard tools like ping. It is a design compromise.


> *Question Ad 2 - *

> How do you detect it if your L2 circuit provider maps BFD flows to one
> underlay path and some encapsulated data packets is hashed to traverse the
> other path(s) ? Clearly running multiple BFD sessions is not going to help
> much in this scenario .... For example if someone is using v6 flow label it
> may be directly copied to the outer service header.
We won't have control over how the Provider maps our traffic (BFD/data). In my experience, the chances of this happening is prob small based on my involvement with all of these issues, in that when the issue happened, all packets > certain size would fail, not some getting through and some failing.


Thanks

Albert