> On Jun 21, 2017, at 09:15, Matthieu Boutier <bout...@irif.fr> wrote: > >> I still do find (1) wasteful. > > I really would like to feel your intuition. From my point of view: > > - either you'll have very few some-specific routes, in which case the > waste is negligible (isn't it the case of multihomed networks ?), > > - or you'll have so much some-specific routes that non-specific routers > will be almost useless (and so you'll have to update them).
You're right to call it an intuition, I do not have any experimental data or back of the envelope math to prove this. To be fair it might be overkill for me to worry about this at all. Because option (5) is built using a sub-TLV, it could always be added as an optimization later. >> (3) isn't that simple to define. > >> How about Proposal 5, which I define as: >> > >> By default, a vanilla wildcard request triggers a dump of all >> regular routes (by regular I mean from the original spec so >> not source-specific). We define a new non-mandatory sub-TLV >> on Route Requests called "Requested Route Types" that >> contains an array of all the types of routes this request is requesting. > > You need to say that routes resulting in a combination of extensions are > sent if each type of the extension is understood. (and if the node > understand such combination, but this is straightforward). > >> 0 = Regular >> 1 = Source-Specific >> 2 = TOS-specific >> etc. >> >> For example, if you send: >> [Type = TBD, Length=2, 0, 1] >> it means that you'd like all regular and source-specific routes. > > and if you send [type = RRT, length=2, 1, 2], it means that you'd like > source-specific routes, ToS-routes and source-tos-routes. Of course, > if the requesting node doesn't understand the combination, it might > receive a some wasteful routes... I think it's a safe assumption that if an implementation supports both extension A and extension B, it should support routes that combine both. > And, even if state is evil, this request can be encoded as the following > by requesting that wildcard requests are combined in the whole message. > > [Wildcard Route Request + source-specific sub-TLV] > [Wildcard Route Request + ToS-specific sub-TLV] > > In the babeld code, I would just put an int to handle that... Does this > make a 6th proposition ? > >> Thoughts? > > Summary: > > 1. Put one Wildcard Route Request (WRR). May waste routes. No parser > state. > > 3. Put one WRR per extension and per combinations. No wasted routes. > No parser state. > > 5. Define a new sub-TLV with one field per extension. Send understood > combinations. Might waste routes. No parser state. > > 6. Put one WRR per extension. Send understood combinations. Might > waste routes. Have a parser state (an int is clearly sufficient). > > I think I prefer 6 over 5. (My preferences are: 1 < 6 < 5 < 3). (6) feels more complicated than 5 to me, but it does have the benefit of being even more specific. All in all I can live with (1), especially if people agree that if (1) becomes a problem we'll work together to build an extension that fixes said problems. Thanks, David Schinazi _______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
