Advertise support for boundary markers
01BGP means Border Gateway Protocol. Peers exchange routing information; a Routing Information Base (RIB) stores it. Enhanced Route Refresh adds boundaries around a re-advertisement so a receiver can reconcile its saved routes.
Separate comparison: A has not received capability70. The enhanced procedures are outside scope for this peer; this is not a claim that classic refresh is unavailable.
Source for this drawing: RFC 7313 · Read RFC section 3.1 ↗
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.
Capability70 enables explicit beginning/end subtypes in the former Reserved octet; the classic normal request remains subtype0.
Read the updated RFC section ↗A supporting speaker SHOULD advertise Enhanced Route Refresh capability code70, with capability length0. Advertising it says that the speaker supports the subtypes and related procedures.
- A supporting speaker SHOULD advertise Enhanced Route Refresh capability code70, with capability length0. Advertising it says that the speaker supports the subtypes and related procedures.
- The enhanced procedures apply only after the speaker has received capability70 from its peer. The drawing checks that received direction, not merely whether the local speaker advertised it. In the illustrated two-way exchange, both peers have received the other’s capability70 before sending enhanced markers.
- The classic Route Refresh capability is code2 (RFC2918); code70 is the enhancement, not a replacement name for code2. Refresh remains subject to the base family and outbound-policy rules.
RFC7313 §§3.1,4,6 and RFC2918 §§2–4; capability TLVs are defined by RFC5492. Peers and routes are fictional. No adoption or interoperability claim.
Read the RFC section ↗