search

scionassociation / scion-dp_I-D

Specification of the SCION data plane
https://scionassociation.github.io/scion-dp_I-D/
Other
1 stars 0 forks source link

Clarify handling link failures #36

Open nicorusti opened 1 month ago

nicorusti commented 1 month ago

Path revocation in case of link failures is not clear. We only mention something in controlplane-02 section 2.4:

On link failures, endpoints route around the failed link by switching to
different paths in the data plane.

We should make this clearer in -dataplane too.

TODO:

Feedback details

Harald Alvestrand harald@alvestrand.no Once sent, a packet’s path cannot be changed; path changes are handled by routers discovering that the path no longer exists and (I assume, this is likely documented in -controlplane) sending an alert back “don’t use this path”.

Form my lunch with Harald at IETF120: Path revocation in case of link down should be clarified, the mechanism to signal endpoints how to react quickly to failures should be described better. Right now the draft only hints to this. This topic is very relevant also for webRTC. I mentioned SCMP Interface Down messages: This has been a topic of discussion within the SCION community for a long time. Currently, in the deployment routers send a non-authenticated SCMP message, while it should be. There are some proposals to leverage the PKI to authenticate this. Harald proposed to say out loud that we don’t have support for authentication in current deployment but that this should be authenticated, showing this is a known problem. We should avoid saying in the draft that a feature exists but then it is not specified. Ok to say some problems still need to be solved but not yet a concern in current deployment. (he shared story about irc and ICMP destination unreachable)

Relates to https://github.com/scionassociation/scion-research_I-D/issues/25

nicorusti commented 1 month ago

In the current implementation, a SCMP interface down is sent if BFD is enabled for the interface.