A well-known BGP community to denote prefixes used for Anycast
draft-wilhelm-grow-anycast-community-03
Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Maximilian Wilhelm , Fredy Künzler | ||
Last updated | 2022-11-08 | ||
Replaced by | draft-ietf-grow-anycast-community | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Replaced by draft-ietf-grow-anycast-community | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
In theory routing decisions on the Internet and by extension within ISP networks should always use hot-potato routing to reach any given destination. In reality operators sometimes choose to not use the hot-potato paths to forward traffic due to a variety of reasons, mostly motivated by traffic engineering considerations. For prefixes carrying anycast traffic in virtually all situations it is advisable to stick to the hot-potato principle. As operators mostly don't know which prefixes are carrying unicast or anycast traffic, they can't differentiate between them in their routing policies. To allow operators to take well informed decisions on which prefixes are carrying anycast traffic this document proposes a well-known BGP community to denote this property.
Authors
Maximilian Wilhelm
Fredy Künzler
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)