I am not following what you are suggesting.As I understand it, the ALT hierarchy is a strict delegation hierarchy. A given ALT node can only connect upwards to the node (or duplicate nodes, but they will be under a common administration) that handles the block from which the EIDs it is handling were delegated. As such, an end site is locked into the ALT nodes run by the EID manager from whom it received its EID. And if that provider is not a top level EID provider, then it is locked in to a higher level aggregation provider.
Remember that one of the goals was to remove lock-in, since lock-in encourages price increases. We have removed RLOC lock-in. But we seem to be creating EID lock-in. With NERD, that is not much of a big deal. There is no serious aggregation, so changing what "EID advertiser" advertises your EID into the system is sufficiently simple that there is little lock in power. So folks probably won't even need to change often. With CONS, there is a need for an aggregation hierarchy for advertisement / resolution. It is a bit of a lock-in issue. With ALT, where that is also a early packet forwarding infrastructure, it is more of an issue.
As a related question, with both CONS and ALT, why would an EID provider be anywhere but at the top of the tree? That is, the discussion assumes reasonable delegation and a reasonably small number of players at the top of the tree. We tried to enforce that early on for IPv6, and gave up. Why would it work for EIDs? (An EID provider might use delegation within his own organization to make deployment more flexible, but that is very different from an assumption of multiple players working at different aggregation layers.)
Yours, Joel Scott Brim wrote:
The whole scenario still feels specious to me. To start with, for redundancy a particular ALT infrastructure node will be multiply-connected to the aggregation level above it. This will be true for sites as well -- they will be multiply-connected to first-level ALT nodes, whether those ALT nodes are provided by a site's access provider or not. There is no single point of ALTconnectivity to hold hostage.However, because of aggressive aggregation of routing information, each node needs to attempt to connect to all next-level aggregators (above it), or packets might be lost if sent to the "wrong"aggregator. So there is some potential vulnerability ...... but an ALT node that pretended to have routes to all active EIDs within a prefix, while simultaneously refusing a connection to a valid holder of an EID prefix and intentionally blackholing packets to it, would be seen as a disruptor of the entire system. However, because of redundancy, the system can easily defend itself -- higher level ALT nodes can stop depending on the misbehaving node to route any packets at all, at least for the including prefix. This is not an architecture issue, it's an operations issue. -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
-- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg