Re: [Babel-users] [babel] source sub-tlv

[David Schinazi]

> On Jun 21, 2017, at 09:15, Matthieu Boutier  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

Re: [Babel-users] [babel] source sub-tlv

[Matthieu Boutier]

> 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).

> (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...

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).

Matthieu


___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] source sub-tlv

[David Schinazi]

I've read draft-boutier-babel-source-specific-02 and I do agree that (3)
isn't that simple to define. However I still do find (1) wasteful.

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.

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = TBD   |Length |  RR Type 1|  RR Type 2...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

We also create a registry of Requested Route (RR) types:
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.

This does make it easy to add new extensions without each extension
knowing about other extensions.

I do realize this is more complex than option (1) but could be worth it
as it reduces overhead of extensions which allows better scalability
in the number of future extensions.

Thoughts?

David Schinazi


> On Jun 19, 2017, at 17:07, Juliusz Chroboczek  wrote:
> 
>>> - only keep (legacy) wildcard requests, and reply with a full dump.
> 
>> That's reasonable, although slightly confusing.  (Call that (1).)
> 
>>  3. Send a non-specific wildcard request for non-specific routes,
>> a source-specific wildcard request for source-specific routes, etc.
> 
>> I support (3).  Last time I spoke to him, Toke supported (4).  I am
>> opposed to (2).  I can live with (1).
> 
> After looking at the relevant code in babeld, I find that (1) is much
> simpler to implement.
> 
> Matthieu's latest draft (-2) contains a good summary of the discussion.
> 
> -- Juliusz
> 
> ___
> Babel-users mailing list
> Babel-users@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] source sub-tlv

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

> I support (3).  Last time I spoke to him, Toke supported (4).  I am
> opposed to (2).  I can live with (1).

Well, I can see the point in retaining wildcard requests for speeding up
convergence when a new node joins a network. Don't recall expressing a
preference on this matter before, but on the other hand it's quite
likely that Juliusz remembers that better than me... ;)

However, if this (helping new nodes) is the only use case, to me the
simplest seems to be option (1), i.e., a wildcard request translates to
"give me all routes you have, regardless of extensions". That's dead
simple to implement, and I'm not convinced that "mixed networks" (where
nodes speak different extensions) are going to be common enough to
warrant the complexity of what is essentially an optimisation for that
one case (i.e., option (3)).

So I prefer (1), but can live with (3).

-Toke

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] source sub-tlv

[David Schinazi]

I agree with Juliusz here. I support (3), can live with (1),
and am opposed to (2) and (4). Allocating sub-TLVs for
something that can be solved without is overkill, and I think
wildcard requests are really critical to quickly bootstrap a new node.

David


> On May 31, 2017, at 07:55, Juliusz Chroboczek  wrote:
> 
> Matthieu, could you please write up a new version of the I-D with your
> encoding?  You might want to speak to Gwendoline, since she needs to write
> up her TOS-specific encoding.
> 
>> If we keep this behaviour and mix tos-specific routes, we will have
>> to send 4 wildcard requests to have all routes.  I see two reasonable
>> options:
> 
>>  - only keep (legacy) wildcard requests, and reply with a full dump.
> 
> That's reasonable, although slightly confusing.  (Call that (1).)
> 
>>  - send one request with all sub-TLVs you know but without mandatory
>>bit, and reply to all options you know about.
> 
> That's not -- it would require allocating a full new set of sub-TLVs.
> Plus I find this confusing.  (Call that (2).)
> 
> There are two other possibilities:
> 
>  3. Send a non-specific wildcard request for non-specific routes,
> a source-specific wildcard request for source-specific routes, etc.
> 
>  4. Deprecate wildcard requests -- say that they MAY be replied to, but
> SHOULD NOT be sent by new implementations.
> 
> Now wildcard requests are fairly rare -- they are only used to speed up
> convergence at boot time, as well as by debugging tools (although we have
> no such debugging tools yet -- all debugging tools known to me connect to
> the local socket of a node).  So sending four TLVs in a single unicast
> packet instead of a single TLV is not prohibitive, and is much simpler
> than the alternatives.
> 
> I support (3).  Last time I spoke to him, Toke supported (4).  I am
> opposed to (2).  I can live with (1).
> 
> -- Juliusz
> 
> ___
> Babel-users mailing list
> Babel-users@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users


___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] [babel] source sub-tlv

[Juliusz Chroboczek]

Matthieu, could you please write up a new version of the I-D with your
encoding?  You might want to speak to Gwendoline, since she needs to write
up her TOS-specific encoding.

> If we keep this behaviour and mix tos-specific routes, we will have
> to send 4 wildcard requests to have all routes.  I see two reasonable
> options:

>   - only keep (legacy) wildcard requests, and reply with a full dump.

That's reasonable, although slightly confusing.  (Call that (1).)

>   - send one request with all sub-TLVs you know but without mandatory
> bit, and reply to all options you know about.

That's not -- it would require allocating a full new set of sub-TLVs.
Plus I find this confusing.  (Call that (2).)

There are two other possibilities:

  3. Send a non-specific wildcard request for non-specific routes,
 a source-specific wildcard request for source-specific routes, etc.

  4. Deprecate wildcard requests -- say that they MAY be replied to, but
 SHOULD NOT be sent by new implementations.

Now wildcard requests are fairly rare -- they are only used to speed up
convergence at boot time, as well as by debugging tools (although we have
no such debugging tools yet -- all debugging tools known to me connect to
the local socket of a node).  So sending four TLVs in a single unicast
packet instead of a single TLV is not prohibitive, and is much simpler
than the alternatives.

I support (3).  Last time I spoke to him, Toke supported (4).  I am
opposed to (2).  I can live with (1).

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users