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

["Eric Vyncke (evyncke)" <[e-mail]>]

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 <[e-mail]>
Date: Wednesday, 21 April 2021 at 17:42
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Donald Eastlake <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT)

    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.

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

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

EV> agreeing with your separate reply

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

EV> thank you

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

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

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

EV> risky proposition but I understand it

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

EV> new 6.1 is better indeed, thanks

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

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

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

    Done.

EV> thanks

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

    Done.

EV> thanks

    Thanks,

    -- Juliusz