Re: [babel] What's up with AE 0?

[David Schinazi <[e-mail]>]

My initial preference was to forbid (MUST NOT) IHU_AE=0 over multicast.
Now I understand that it can be used by implementations that do not
want bidirectional detection. I'm fine with making this a SHOULD NOT
as long as we add text in the same paragraph (or close by) that explains
that using IHU_AE=0 over multicast will disable bidirectional detection.

David Schinazi


> On Jul 19, 2017, at 18:23, Juliusz Chroboczek <[e-mail]> wrote:
> 
> Executive summary: rfc6126bis leaves the wildcard AE mostly unchanged.
> 
> AE 0 specifies a wildcard: the only element of the AE is the 0-length byte
> sequence, and represents "all the things you have".  AE 0 is allowed in
> three places:
> 
>  1. in a route request, it requests a full route dump;
>  2. in an Update with Metric=infinity, it retracts all the routes
>     announced by the sender;
>  3. in an IHU, it says "I Heard You" to anyone who receives this update.
> 
> All three applications of AE 0 remain in rfc6126bis.  We've clarified that
> for implementations with extensions, (1) and (2) apply to all routes --
> a wildcard request requests all routes, even the ones that require an
> extension, and a wildcard retraction retracts all routes.  This needs
> adding to Appendix C.
> 
> IHU(AE=0) were originally intended for implementations that are not
> interested in bidirectional detection, and perform simple inverse
> detection, RIP style; such implementation can just send IHU(AE=0), "I hear
> everyone!".  However, no implementation ever did that -- even sbabeld
> produces proper per-neighbour IHUs.
> 
> David uses IHU(AE=0) for a different purpose: he sends IHUs over unicast,
> and hence doesn't need to use the Address field to constrain the receiver.
> This was not intended, but looks to me like a perfectly valid
> implementation.
> 
> I will edit the document to say that IHU(AE=0) SHOULD NOT be used for
> multicast IHUs, and MAY be used over unicast.  (David suggests MUST NOT,
> but I feel it's too strong.)
> 
> -- Juliusz
> 
> _______________________________________________
> babel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/babel