Hi Wendy, On Tuesday, March 4, 2014, Wendy Roome <[email protected]> wrote:
> 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.² > > So the concern is that generic JSON Patch need to produce a subset of operations (i.e., some pairing) to produce consistent result. This is a good point. > 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. Correct. This means that if it is built on top of JSON Patch, it may not be a good idea to use a "layered" architecture. It will be "cross-layer" design in the sense that only the wire format is used. > > 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? Richard > 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] <javascript:;>" < > [email protected] <javascript:;>> > wrote: > > >Message: 1 > >Date: Sun, 2 Mar 2014 21:44:46 -0500 > >From: "Y. Richard Yang" <[email protected] <javascript:;>> > >To: IETF ALTO <[email protected] <javascript:;>> > >Subject: [alto] Comment on > > http://tools.ietf.org/id/draft-roome-alto-incr-updates-00.txt > >Message-ID: > > <CANUuoLr0R+S6rzLuuE-zFZ1_LWYJQo73O7_v9hYHoJdK= > [email protected] <javascript:;>> > >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] <javascript:;> > https://www.ietf.org/mailman/listinfo/alto > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
