Subject: [babel] 6126bis: new appendix

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 17 Aug 2019 03:28:53 +0200

Please proofread.

Appendix F.  Compatibility with previous versions

   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
   incompatible with its predecessor.  First of all, RFC 6126 did not
   define Unicast hellos (Section 3.4.1), and an implementation of RFC
   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
   sub-TLV is found.  It is not necessary to parse unknown TLVs, since
   these are ignored in any case.

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sat, 17 Aug 2019 03:49:58 +0000

Editorial comments in-line.
Barbara  

>    There are two optioal features that make the new protocol

optioal ->optional

>    define Unicast hellos (Section 3.4.1), and an implementation of RFC

Should RFC 6126 be [RFC6126]? Same comment for all references.

>    that allow sub-TLVs, and to ignore the TLV is an unknown mandatory

is -> if 

>    these are ignored in any case.

Suggestion: ", since these are ignored in any case" -> "that are ignored"

> _______________________________________________
> babel mailing list
> [email-masked]
> 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=

---

From: David Schinazi <[email-masked]>
Date: Fri, 16 Aug 2019 22:39:44 -0700

The new appendix looks good to me.

David

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

> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sat, 17 Aug 2019 10:42:12 +0200

> The new appendix looks good to me.

+1

-Toke