Re: [babel] 6126bis: new appendix

[David Schinazi <[e-mail]>]

The new appendix looks good to me.

David

On Fri, Aug 16, 2019 at 8:50 PM STARK, BARBARA H <[e-mail]> wrote:

> Editorial comments in-line.
> Barbara
>
> >    The protocol defined in this document is a successor to the protocol
> >    defined in [RFC6126] and [RFC7557].  While the two protocols are not
> >    entirely compatible, the new protocol has been designed so that it
> >    can be deployed in existing RFC 6126 networks without requiring a
> >    flag day.
> >
> >    There are two optioal features that make the new protocol
>
> optioal ->optional
>
> >    incompatible with its predecessor.  First of all, RFC 6126 did not
> >    define Unicast hellos (Section 3.4.1), and an implementation of RFC
>
> Should RFC 6126 be [RFC6126]? Same comment for all references.
>
> >    6126 will mis-interpret a Unicast Hello for a Multicast one; since
> >    the sequence number space of Unicast Hellos is distinct from the
> >    sequence space of Multicast Hellos, sending a Unicast Hello to an
> >    implementation of RFC 6126 will confuse its link quality estimator.
> >    Second, RFC 7557 did not define mandatory sub-TLVs (Section 4.4);
> >    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
> >    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
> >    old protocol.
> >
> >    Two changes need to be made to an implementation of RFCs 6126 and
> >    7557 so that it can safely interoperate in all cases with
> >    implementations of this protocol.  First, it needs to be modified to
> >    either ignore or process Unicast Hellos.  Second, it needs to be
> >    modified to parse sub-TLVs of all the TLVs that it understands and
> >    that allow sub-TLVs, and to ignore the TLV is an unknown mandatory
>
> is -> if
>
> >    sub-TLV is found.  It is not necessary to parse unknown TLVs, since
> >    these are ignored in any case.
>
> Suggestion: ", since these are ignored in any case" -> "that are ignored"
>
> >    There are other changes, but these are not of a nature to prevent
> >    interoperability:
> >
> >    o  the conditions on route acquisition (Section 3.5.3) have been
> >       relaxed;
> >
> >    o  route selection should no longer use the route's sequence number
> >       (Section 3.6);
> >
> >    o  the format of the packet trailer has been defined (Section 4.2);
> >
> >    o  router-ids with a value of all-zeros or all-ones have been
> >       forbidden (Section 4.1.2);
> >
> >    o  the compression state is now specific to an address family rather
> >       than an address encoding Section 4.5;
> >
> >    o  packet pacing is now recommended (Section 3.1).
> >
> > _______________________________________________
> > babel mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.ietf.org_mailman_listinfo_babel&d=DwICAg&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Ww-
> > PiMuGBmrgnsxmDiWQjuvjD2a3d9sjPHErqmsKK4o&s=YwB1wNm3C00CXoHIB
> > 0D-3MnLvK2IgsV59pdDIEETajI&e=
>
> _______________________________________________
> babel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/babel
>