Given that PIDs could have 100¹s of CIDRs, I suggest we use a different
format for Network Map incremental updates. The servers¹s response would
have three lists: add-cidrs, drop-cidrs and drop-pids. Something like
{
"add-cidrs": {"PID1": {"ipv4": ["1.2.3.0/24", ... }],
"PID2": { ... } }
"drop-cidrs": {"ipv4": ["4.3.2.1/24", ... ]},
"drop-pids": ["PID12", "PID13", ... ]
}
add-cidrs gives cidrs to be added to pids. The client is expected to
remove those cidrs from whatever pid they had been in before. drop-cidrs
means remove those cidrs from the network map altogether. drop-pids means
remove those pids and the cidrs they contain (except for cidrs named in
add-cidrs).
I think that representation is compact, simple for a server to generate
from the network changes, and easy for a client to apply to whatever data
structure the client uses to store the network map. It does assume the
client keeps an index from cidrs to pids, but I think any client who wants
incremental updates would keep such an index.
- Wendy Roome
On 03/06/2014, 05:08, "[email protected]" <[email protected]>
wrote:
>>
>>
>>
>>A higher-level question is how many CIDRs will PIDs have?
>
>
>This is the key question. I start to think BGP, which can go up to
>hundreds
>or thousands.
>
>
>>Our incremental
>>update proposal updates a PID?s CIDR set as a unit. So if one CIDR is
>>added to a PID, the incremental update message gives all the CIDRs that
>>were in the PID. That?s fine if PIDs only have (say) 5 or 10 CIDRs. But
>>if we expect PIDs to have 100 or more CIDRs, then it?s not. In that case
>>we need to consider an add/delete model to update a PID?s CIDR set
>>without
>>repeating the ones that didn?t change.
>>
>>
>Yes. Indeed. If possible, I want to see what this model might look like.
>What do you think?
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
