Re: [babel] WG Last Call for draft-ietf-babel-source-specific (2018-03-26 to 2018-04-09)

Denis Ovsienko <denis@ovsienko.info> Sun, 27 May 2018 23:29 UTC

Return-Path: <denis@ovsienko.info>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2344A12EAE9; Sun, 27 May 2018 16:29:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ovsienko.info
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jw3vjFZgJZ-7; Sun, 27 May 2018 16:29:02 -0700 (PDT)
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18AD127775; Sun, 27 May 2018 16:29:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1527463738; s=zohomail; d=ovsienko.info; i=denis@ovsienko.info; h=Date:From:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; l=5915; bh=JFdAYYYocL7daa2YYdNuPvxTOntNg07pKm5R6begONg=; b=DDJ02kLqnmQCvQ7AEE1IwEdEV14ledukilyDQhRz+mYVy2TpxAyOc3Ae/Y9yI9Ga TlJftd2thEXh+23BVG334Za4WWrAZFMscsoNrmAO02+BJLiTaCHtMsL2wkAzeWdeLtN sz5TIcJe3aVB+tZcSbgwTmzyTwqVDzMW+7oj9TT8=
Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1527463738548348.0912074331462; Sun, 27 May 2018 16:28:58 -0700 (PDT)
Date: Mon, 28 May 2018 00:28:58 +0100
From: Denis Ovsienko <denis@ovsienko.info>
To: Babel at IETF <babel@ietf.org>, babel-chairs@ietf.org
Message-ID: <163a3eefcb3.105e54392539813.8869059599002671510@ovsienko.info>
In-Reply-To: <CAF4+nEFa+ZFfYScDxbsCbe3bX=p6w+YKpq0eXa+tjtYZDzvwyA@mail.gmail.com>
References: <CAF4+nEHUmjUcY7PS0eVDuPr8YHaJG4t+CyoxzMR15821X+-Vsg@mail.gmail.com> <CAF4+nEFa+ZFfYScDxbsCbe3bX=p6w+YKpq0eXa+tjtYZDzvwyA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/T0adXwGqBgx_mQgsPS__-PyqvDk>
Subject: Re: [babel] WG Last Call for draft-ietf-babel-source-specific (2018-03-26 to 2018-04-09)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 May 2018 23:29:04 -0000

 ---- On Tue, 22 May 2018 16:52:04 +0100 Donald Eastlake <d3e3e3@gmail.com> wrote ---- 
 > This is a reminder that 
 > https://tools.ietf.org/html/draft-ietf-babel-source-specific-03 
 > is still in WG Last Call and should be considered to be so until the 
 > Chairs announce a consensus as to whether the document is ready or 
 > not. Thus far, in my opinion, there have been an insufficient number 
 > of responses so please indicate whether you believe the document is 
 > ready for publication or not or have any suggestions for change. 

I have studied the latest revision of the document and would like to provide some feedback on its editorial merits. My lack of experience with the implementation of this extension does not let me do a thorough proof-reading of the technical concept.


   Note that the route entry contains a source which itself contains a
   source prefix.  These are two very different concepts that should not
   be confused.

(Here it could be helpful to provide a reference that helps the reader get the difference right.)



   However, this extension is encoded using mandatory sub-TLVs,
   introduced in [BABEL], and therefore is not compatible with the older
   version of the Babel Routing Protocol [RFC6126].  Consequently, this
   extension MUST NOT be used with routers implementing RFC 6126,
   otherwise persistent routing loops may occur.

(It looks like the right moment to stop for a moment and think. Could anybody briefly remind why leaving the protocol version 2 in 6126-bis is considered better than bumping it up to 3?)



   Fields:

   Type      Set to 128 to indicate a Source Prefix sub-TLV.

   Length    The length of the body, exclusive of the Type and Length
             fields.

   Source Plen  The length of the advertised source prefix.  This MUST
             NOT be 0.

   Source Prefix  The source prefix being advertised.  This field's size
             is (Source Plen)/8 rounded upwards.


(Is it correct that the model in this specification treats 0/0 same as any other source prefix, it is just the encoding convention that 0/0 is always represented with the absence of the sub-TLV? If so, it could be helpful to acknowledge this point in the document for clarity.)

Please find below a patch for the XML source file with some trivial corrections.

--- draft-ietf-babel-source-specific-03.xml.orig	2018-05-27 23:21:17.055373767 +0100
+++ draft-ietf-babel-source-specific-03.xml	2018-05-27 23:58:33.402935740 +0100
@@ -55,7 +55,7 @@
 
 <t>The Babel routing protocol <xref target="BABEL"/> is a distance vector
 routing protocol for next-hop routing.  In next-hop routing, each node
-maintains a forwarding table which maps destination prefixes to next hops.
+maintains a forwarding table, which maps destination prefixes to next hops.
 The forwarding decision is a per-packet operation which depends on the
 destination address of the packets and on the entries of the forwarding
 table.  When a packet is about to be routed, its destination address is
@@ -102,9 +102,10 @@
 <section title="Specification of Requirements">
 
 <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in <xref
-target="RFC2119"/>.</t>
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+"OPTIONAL" in this document are to be interpreted as described in
+BCP&nbsp;14 <xref target="RFC2119" /> <xref target="RFC8174" /> when, and
+only when, they appear in all capitals, as shown here.</t>
 
 </section>
 
@@ -229,7 +230,7 @@
 these messages to optionally carry a source prefix sub-TLV, as described
 in <xref target="protocol-encoding"/> below.  The sub-TLV is marked as
 mandatory, so that an unextended implementation will silently ignore the
-whole enclising TLV.  A node obeying this specification MUST NOT send
+whole enclosing TLV.  A node obeying this specification MUST NOT send
 a TLV with a zero-length source prefix: instead, it sends a TLV with no
 source prefix sub-TLV.  Conversely, an extended implementation MUST
 interpret an unextended TLV as carrying a source prefix of zero length.
@@ -288,7 +289,7 @@
 to 0 (a wildcard route request) SHOULD send a full routing table dump,
 including routes with a non-zero-length source prefix.  A node MUST NOT
 send a wildcard request that carries a source prefix, and a node receiving
-a wildcard request with a with a source prefix MUST silently ignore
+a wildcard request with a source prefix MUST silently ignore
 it.</t>
 
 </section>
@@ -377,7 +378,7 @@
 ]]></artwork></figure>
 
 <t>Fields:
-<list style="hanging" hangIndent="10">
+<list style="hanging" hangIndent="15">
 <t hangText="Type">Set to 128 to indicate a Source Prefix
 sub-TLV.</t>
 <t hangText="Length">The length of the body, exclusive of the Type and
@@ -392,7 +393,7 @@
 <t>The contents of the source prefix sub-TLV are interpreted according to
 the AE of the enclosing TLV.</t>
 
-<t>Note that this sub-TLV is a mandatory sub-TLV.  Threfore, as described
+<t>Note that this sub-TLV is a mandatory sub-TLV.  Therefore, as described
 in Section 4.4 of <xref target="BABEL"/>, the whole TLV MUST be ignored if
 that sub-TLV is not understood (or malformed).  Otherwise, routing loops
 may occur (see <xref target="loop"/>).</t>
@@ -439,7 +440,7 @@
 <section title="IANA Considerations">
 
 <t>IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV in
-the Babel Sub-TLV Numbers registry.</t>
+the Babel Sub-TLV Types registry.</t>
 
 </section>
 
@@ -475,6 +476,8 @@
 <seriesInfo name="DOI" value="10.17487/RFC2119"/>
 </reference>
 
+<?rfc include="reference.RFC.8174.xml"?>
+
 <reference anchor="BABEL"><front>
 <title>The Babel Routing Protocol</title>
 <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>

-- 
    Denis Ovsienko