Keep Graceful Restart EoR separate
04Graceful Restart has its own End-of-RIB marker, abbreviated EoR. Enhanced Route Refresh uses EoRR. Their names are similar, but their meanings and ordering rules differ.
A later BoRR can now start the enhanced refresh procedure. Matching routes become stale; their eventual refresh cleanup still waits for EoRR or permitted local policy.
Source for this drawing: RFC 7313 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A speaker supporting Graceful Restart MUST NOT send BoRR for a family before sending that family’s EoR to its neighbor.
- A speaker supporting Graceful Restart MUST NOT send BoRR for a family before sending that family’s EoR to its neighbor.
- A speaker that received the neighbor’s Graceful Restart capability MUST ignore BoRR for a family before receiving its EoR from that neighbor, and SHOULD log this condition.
- EoR is defined by RFC4724 using an UPDATE message. EoRR here is a ROUTE-REFRESH message with subtype2. They are not interchangeable cleanup signals.
- Only after the relevant EoR does this example accept BoRR and start refresh stale marking. Do not use an early BoRR to purge Graceful Restart stale routes.
RFC7313 §4 and RFC4724 §2: EoR’s encoding differs by address family. The drawing labels message types; it does not invent one universal EoR payload.
Read the RFC section ↗