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
