Re: [babel] Éric Vyncke's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT)

[Juliusz Chroboczek <[e-mail]>]

Dear Éric,

Thanks for your comments.

> Generic comment: did the author read draft-ietf-rtgwg-dst-src-routing ? It is
> an expired RTG WG adopted document and is not even cited as informative
> reference.

As mentioned earlier, it was cited in previous versions, but the
responsible AD requested that we not depend on an expired draft.  I have
therefore rewritten the introduction and the security considerations to
make the document more self-contained.

I have no objection to reinstating the citation should the responsible AD
change his mind.

> Same for reference to RFC 8678.

I am ashamed to say that I have not read this document.  I have just put
it on my to-do list.  Please let me know if you feel strongly that it
should be cited, and I'll move it higher in my queue.

> -- Section 3.1 --
> Is the first "prefix" the "destination prefix" in the following text? If so,
> then I suggest to write "destination prefix" or explain what is this "prefix"
> with reference to the Bable RFC:
>    "The source table is now indexed by triples of the form (prefix,
>    source prefix, router-id)."

Yes, the notations were inconsistent between this document and RFC 8966.
This has hopefully been fixed now.

> -- Section 4 --
> May I suggest to add another example with 2 entries have the same destination
> prefix but different source prefixes ?

Discussion has been added in Section 1.3.  Please let me know if you still
feel something is missing.

> -- Section 6 --
> May be my lack of knowledge in Babel is the reason why I do not understand the
> loop avoidance description... As written in the text, a single non-source-aware
> router in the network could be enough to introduce loop (in specific
> configurations). Writing the following text appear to me as a little hand
> waving because how can this be ensure (I was about to file a block DISCUSS on
> this but I am trusting the routing AD on this topic): "  Consequently, this
> extension MUST NOT be used
>    with routers implementing RFC 6126, otherwise persistent routing
>    loops may occur."

This extension interoperates with RFC 8966.  It does not interoperate with
RFC 6126. To quote RFC 8966 Appendix F:

   RFC 7557 did not define mandatory sub-TLVs
   (Section 4.4), and thus an implementation of RFCs 6126 and 7557 will
   not correctly ignore a TLV that carries an unknown mandatory sub-TLV;
   depending on the sub-TLV, this might cause routing pathologies.

   An implementation of this specification that never sends Unicast or
   unscheduled Hellos and doesn't implement any extensions that use
   mandatory sub-TLVs is safe to deploy in a network in which some nodes
   implement the protocol described in RFCs 6126 and 7557.

This extension uses mandatory sub-TLVs, and is not safe to deploy together
with implementations of RFC 6126.

The issue was debated at length by the Babel WG, and we came to the
conclusion that it was a risk we were willing to take.  There exist four
independent implementations of Babel, of which two are actually used in
production.  These two implementations have been updated to follow 8966 in
early 2018, and we have done a fair amount of work to hunt down any Babel
networks and make sure they patched their implementations of Babel.  Thus,
we believe that it is now safe to deploy extensions that break RFC 6126.

> -- Section 6.2 --
> The last paragraph is also a little hand waving where it is assumed that
> network topology/configuration is specific to avoid a route starvation.

I've tried to clarify this paragraph.  Let me know if you feel I haven't
done enough.

> -- Section 7.1 --
> Should the text state the obvious by stating that the prefix (non 8 multiple)
> is padded with bits set to 0 on transmission and those bits are ignored on
> reception ?

That's also not done in RFC 8966.  Let me know if you feel strongly about it.

> -- Section 4 and possibly others --
> Please use RFC 5952 to write IPv6 addresses.

Done.

> -- Section 5.2 --
> Please introduce the "AE" acronym at first use (even if guessable in the
> context).

Done.

Thanks,

-- Juliusz