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

Not sure if we should continue this thread  ....  I think all what needs to
be said has been said already regarding proposed draft. But just to clarify
on your questions:

> Learning two paths for given net with different NHs (even if RS has more
>> then two) seems to provide sufficient robustness and enables you to
>> measure
>> quality to the destinations as well as do things line multipath TCP
>>
>
> This would require a major rearchitecting of pretty much all network
> components out there because we'd be doing away with the concept of having
> one best path that's chosen by each hop handling a packet.

When IX client advertises a route to Route Server it will still advertise
best path only as he sets nhs. When RS today already import to per client
bRIB all paths (if available) and selects best then advertises it to all
peers (subject to policy).

Only change is needed is to advertise with either add-paths or diverse-path
second best. No major change at all. One line config on existing routers.

N
>> ow if someone is really so weak on the edge and attaches to IX to only
>> peer locally we should perhaps invent co-located with RS pair of data
>> plane
>> boxes where such weak guys would for forwarding just default to such data
>> plane gateway. That way those two forwarders could have as many paths as
>> RS
>> feeds it with yet all weak clients are happy to forward and reach all open
>> peers of a given IX.
>>
>> In fact most IX switches while running in L2 mode could be configured for
>> L3 as well so no need to even invest new $$$ needed.
>>
>
> As Nick said, not even wrong.
>
> Route servers decouple the forwarding plane from the control plane in an
> additional way beyond what already happens inside routers for hardware
> design reasons.

I am not saying that Route Servers should be doing forwarding ... if this
is what you are trying to address by the above comment.

RS would send all paths they know about to device which will act as a
forwarder in the middle of IX. Sitting close or being a function of L3
forwarding on the switch allows to have all weak clients go via such pair
of routers. No suboptimal routing as packets go via the switch anyway, no
1000 x 1000 BFD sessions between all clients, quick local repair in case of
path failure ... and such device could be used only for those open policy
destinations which do have more then one path in the first place.

Yes this is not the model IX do today ... but is this sufficient reason to
dismiss it - provided above basic solution of sending more then best path
would perhaps be not feasible.

Thx,
R.

> This draft seeks to add a mechanism to signal any dislocations, improving
> robustness of existing deployments.
>
> Regards,
>
>
>         -- Niels (former IXP operator, current IXP participant hat)
>
> --
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>