Subject: Re: [RAM] Terminology: Routing Entropy

From: RJ Atkinson <[email-masked]>
Date: Fri, 29 Dec 2006 10:10:39 -0500

On  29 Dec 2006, at 09:53, Jeremy Hall wrote:
> Are you talking about auto-summarization? Surely not.

No -- and I am NOT talking about ANY specific mechanism
or protocol.  I'm talking about architecture here.

Kindly zoom up several thousand metres in altitude. :-)

Ran

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: "Jeremy Hall" <[email-masked]>
Date: Fri, 29 Dec 2006 09:53:54 -0500

Part of the problem here is that not all routers have the smise the Routing Entropy (at least within the DFZ),
> while retaining existing capabilities (e.g. site multi-homing)

I fear even "site multi-homing" is actually ambiguous, despite that we 
all feel we know that that means.  Of course it means that there is 
more than one last hop from the DFZ to the site.  But what does it 
imply about how far the multiple paths to the site extend.  Shall we 
make hot-potato routing, which is often implicit, explicit, or can this 
assumption be relaxed to limit how far routing entropy extends to other 
realms?  One way to clarify this is to ask against what failures site 
multi-homing is to protect.

> and maybe also adding some new practical-to-use capabilities
> (e.g. native mobility support, host multi-homing).
>
> 	I have some concrete ideas on ways that this might
> be approached, in an incrementally-deployable way, but I'd like
> to see whether there is agreement on terminology and goals first.

Please share your ideas while consensus forms on terminology and goals. 
  Sometimes the terminology "discussion" lasts longer than the problem.  
;-)

John

---

From: "Jeremy Hall" <[email-masked]>
Date: Fri, 29 Dec 2006 09:53:54 -0500

Part of the problem here is that not all routers have the same "view"
and only the best path is propogated in BGP.  If one upstream router
were to pick a path not in his "space", i.e. another peer that grafts
onto the default-free zone, other routers would not have the ability to
pick the correct path, causing huge traffic swings.  The only way
aggregation can be properly handled is if the originating as aggregates
his traffic.

_J

>>> RJ Atkinson <[email-masked]> 12/29/06 9:36 AM >>>

	While I think the absolute size of the RIB/FIB is a
practical issue, separately there is a broader architectural issue
about the entropy in the routing table.

	If I might, let me try to define a term in the interest
of clarity and a more focused discussion...

"Routing Entropy" is the measure of how much additional detail,
beyond the bare minimum needed to reach all advertised destinations,
exists in the Routing table in (the, any) Default-Free Zone.

For example, if one advertised 3.0/8 then it is not strictly
required for *reachability* (ignoring other aspects like
multi-homing) to advertise 3.1.0/24.

More Examples:
A routing table with minimum entropy has zero more-specific prefixes.
A routing table with high entropy has many more-specific prefixes.

Ran

ame "view"
and only the best path is propogated in BGP.  If one upstream router
were to pick a path not in his "space", i.e. another peer that grafts
onto the default-free zone, other routers would not have the ability to
pick the correct path, causing huge traffic swings.  The only way
aggregation can be properly handled is if the originating as aggregates
his traffic.

_J

>>> RJ Atkinson <[email-masked]> 12/29/06 9:36 AM >>>

	While I think the absolute size of the RIB/FIB is a
practical issue, separately there is a broader architectural issue
about the entropy in the routing table.

	If I might, let me try to define a term in the interest
of clarity and a more focused discussion...

"Routing Entropy" is the measure of how much additional detail,
beyond the bare minimum needed to reach all advertised destinations,
exists in the Routing table in (the, any) Default-Free Zone.

For example, if one advertised 3.0/8 then it is not strictly
required for *reachability* (ignoring other aspects like
multi-homing) to advertise 3.1.0/24.

More Examples:
A routing table with minimum entropy has zero more-specific prefixes.
A routing table with high entropy has many more-specific prefixes.

Ran