Subject: Re: [alto] alto Digest, Vol 65, Issue 4

From: Wendy Roome <[email-masked]>
Date: Thu, 06 Mar 2014 09:33:59 -0500

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-masked]" <[email-masked]>
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?