Richard,
The immediate issue has a simple solution. A CIDR can only be in one PID.
So let¹s define the semantics of Network Map Incremental Update to be ³if
the update message puts CIDR C in PID P, then client must remove C from
whatever PID it was in before.²
Incidentally, that points out a ³gotcha² with JSON patch. We encode a
PID¹s CIDR set as a JSON array. As far as the server & client are
concerned, that¹s a set, and the order of CIDRs doesn¹t matter. But JSON
patch doesn¹t know that! The moral is that if we use JSON patch, the ALTO
server MUST create the array of CIDRs for each PID in a consistent,
repeatable order. Otherwise, if the server creates a JSON Network Map with
the same set of CIDRs but in a different order, JSON Patch will think the
entire list changed.
A higher-level question is how many CIDRs will PIDs have? 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.
Finally, there¹s the whole question of how often do Network Maps change,
and will incremental update ever be worth it for Network Maps? I believe
the ALTO protocol makes the tacit assumption that Network Maps change less
often than Cost Maps a change to a Network Map is almost a flag day. And
unless PIDs have 100¹s of CIDRs, Cost Maps will always be much larger than
Network Maps, because Cost Maps go as the square of the number of PIDs. So
do we really need to bother with incremental update for Network Maps? I
think it¹s good to define it, but I suspect few servers would implement
it, and few clients would bother to use it.
- Wendy Roome
On 03/03/2014, 15:00, "[email protected]" <[email protected]>
wrote:
>Message: 1
>Date: Sun, 2 Mar 2014 21:44:46 -0500
>From: "Y. Richard Yang" <[email protected]>
>To: IETF ALTO <[email protected]>
>Subject: [alto] Comment on
> http://tools.ietf.org/id/draft-roome-alto-incr-updates-00.txt
>Message-ID:
> <CANUuoLr0R+S6rzLuuE-zFZ1_LWYJQo73O7_v9hYHoJdK=e0...@mail.gmail.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Dear Wendy, Nico,
>
>I am reading the draft, and it is very well written.
>
>I see that you use a replacement approach for both the Network Map and
>Cost
>Map. A question is whether this provides efficient encoding, in
>particular,
>for Network Map changes. Assume that a change is to move an IP prefix
>pref1
>from PID1 to PID2, then the replacement based approach will require that
>the values of both PID1 and PID2 to be sent out on the wire. This can be
>large.
>
>I agree that RFC6902 could be difficult to use as well.
>
>To be concrete, consider the following Network Map, and the goal is that
>192.0.2.0/24 is moved from PID1 to PID2:
>
>HTTP/1.1 200 OK
> Content-Length: 449
> Content-Type: application/alto-networkmap+json
>
> {
> "meta" : {
> "vtag": {
> "resource-id": "my-default-network-map",
> "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
> }
> },
> "network-map" : {
> "PID1" : {
> "ipv4" : [
> "192.0.2.0/24",
> "198.51.100.0/25"
> ]
> },
> "PID2" : {
> "ipv4" : [
> "198.51.100.128/25"
> ]
> },
> ...
>}
>
>In particular, using RFC6902, a compact encoding might be the following:
>
>[
> { "op": "move", "from": "/network-map/PID1/ipv4/0", "path":
>"/network-map/PID2//ipv4/0"
> }
>]
>
>I agree that this requires the Client to remember the original JSON array
>to know the index. But I do see that it can be more compact.
>
>In other words, at sub-array level operations, RFC6902 can provide compact
>encoding.
>
>A related question is whether we always use replacement semantics for all
>future updates, if we consider consistency of protocol design.
>
>Any thought?
>
>Thanks for the always good work!
>
>Richard
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
