Re: [Idr] I-D Action: draft-ietf-idr-rs-bfd-02.txt

[Robert Raszuk <[e-mail]>]

Nick,

I am afraid you have completely missed my point.

I never said clients must not detect other clients liveness before using it
for best path selection and in their local data planes.

I said RS does not need to bothered with that information.

In fact I explicitely said that modern clients will detect health of the
path well beyond local peer's next hop.

Cheers,
R.


On Mar 13, 2017 11:32 AM, "Nick Hilliard" <[e-mail]> wrote:

Robert Raszuk wrote:
> Let's observe that the ultimate objective of this draft (and in fact
> much more) can be achieved by assuring that clients receive more then
> one path to given bgp destinations at normal operation.

This is a fundamental misunderstanding.  The aim of this draft is to
ensure that traffic isn't blackholed if there is a layer 2 incongruity
on the IXP which causes connectivity to be non commutative.

Given the following topology, A's connectivity to RS works fine, and B's
connectivity to RS works fine, but A cannot communicate with B:

>    +-----+    +-----+
>    |     +--> |     |
>    |  A  |    |  B  |
>    |     | <--+     |
>    +-----+    +-----+
>       |           |
>       | +------+  |
>       +-+      +--+
>         |  RS  |
>         |      |
>         +------+

What's needed is some protocol running between A and B to ensure that
they can still talk to each other, i.e. BFD.

No amount of alternative paths will save you in this situation because
the control plane (RS) has connectivity to both data plane routers.

Nick

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr