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

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 21 Apr 2021 17:42:17 +0200

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 21 Apr 2021 19:26:02 +0200

> I am ashamed to say that I have not read this document.

Actually, I'd read it, but I'd forgotten.

This is a rather complex document, and I fear that citing it might give
the reader the impression that the problem is more complicated than it
actually is.  Also, a large part of this document relies on the "Rule 5.5"
proposal, which, as far as I am aware, has not been widely implemented.

I'd rather avoid citing it if permitted.

-- Juliusz

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 21 Apr 2021 18:43:21 +0000

Juliusz

I still have to reply to your previous email (last in, first out!) but my comments were not blocking and you can freely ignore them. But, THANK you for replying to them

On this specific point, I was also unsure whether RFC 8678 would be useful, hence my question about it

Regards,

-éric

-----Original Message-----
From: Juliusz Chroboczek <[email-masked]>
Date: Wednesday, 21 April 2021 at 19:26
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Donald Eastlake <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT)

    -- Juliusz

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 22 Apr 2021 12:15:00 +0000

Bonjour Juliusz,

Thank you for your reply. 

Martin, there is a question for you at my first reply below.

Please see below for EV>

Regards

-éric

-----Original Message-----
From: Juliusz Chroboczek <[email-masked]>
Date: Wednesday, 21 April 2021 at 17:42
To: Eric Vyncke <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Donald Eastlake <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT)

    Dear Éric,

EV> fair enough, let's see what Martin Vigoureux prefers then.

EV> agreeing with your separate reply

EV> thank you

EV> the discussion is OK now and in a better place regarding the flow

EV> risky proposition but I understand it

EV> new 6.1 is better indeed, thanks

EV> consistency with RFC 8966 is important but I would still suggest to apply my suggestion (up to you though)

    Done.

EV> thanks

    Done.

EV> thanks

    Thanks,

    -- Juliusz