[babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT)

Alvaro Retana via Datatracker <noreply@ietf.org> Tue, 03 November 2020 15:11 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: babel@ietf.org
Delivered-To: babel@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C210D3A0855; Tue, 3 Nov 2020 07:11:51 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake <d3e3e3@gmail.com>
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <160441631177.15161.14360810315064872038@ietfa.amsl.com>
Date: Tue, 03 Nov 2020 07:11:51 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/o8_GbE8HSfst8gUvDrOCC3vP7eE>
Subject: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT)
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 03 Nov 2020 15:11:52 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-babel-source-specific-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am balloting DISCUSS because I believe that the document is missing important
considerations/details related to the operation of Babel in a network.  I hope
these points should be easy to address.

This draft describes destination-first forwarding.  If I understand correctly,
for the table in §4:

             destination                source     next-hop
       2001:DB8:0:1::/64                  ::/0            A
                    ::/0     2001:DB8:0:2::/64            B

...and the example presented of a "source 2001:DB8:0:2::42 and destination
2001:DB8:0:1::57", the result is that the packet is forwarded to A.  Is this
the correct interpretation?  If so, then I believe there are important
assumptions made that are not mentioned.

In line with this document being "applicable to small networks" (§1), BCP
84/§4.3 recommends the following:

   For smaller edge networks that use provider-based addressing and
   whose ISPs implement ingress filters (which they should do), the
   third option is to route traffic being sourced from a given
   provider's address space to that provider.

Given that the draft provides no details, I assume that being "compatible with
[BCP84]" (§1) means at least that Babel nodes aim to "route traffic being
sourced from a given provider's address space to that provider".

(a) While I understand the table above is just an example, it can be
interpreted as indicating that B is the provider that assigned the
2001:DB8:0:2::/64 prefix.  If traffic sourced from that prefix is sent to A,
then there's a good chance that the packet will be dropped (in line with BCP
84, BCP 38, etc.).

Maybe the table is not intended to illustrate the routing table at a multihomed
edge router. Still, it shows how easy it is to define a policy that may not
result in the expected behavior because of the destination-first operation. 
Please add some guidance on the advertisements and how they may interact in the
routing table.

Note that what I'm asking for may just be a good example of what to do/not to
do.  rfc8678/§5 presents an example of how the forwarding table is constructed
based on a set of routes -- something like that would be great!

(b) How is the source address selected by the host?

rfc8678 uses guidance from rfc8028 and other RFCs as part of a set of
"Mechanisms for Hosts To Choose Good Default Source Addresses in a Multihomed
Site".  rfc8678 significantly differs from this document in that it assumes
source-first forwarding when discussing the selection of the source address. 
Are any of the recommendations in rfc8678 applicable here?

I may be missing something, but it seems to me that the current standards-based
recommendations/mechanisms don't easily apply to this specification.  I don't
think there's anything wrong with doing things a different way -- but I expect
those differences to be explicitly explained.

SS-ROUTING suggests a trial-and-error mechanism: for "destination
addresses...the sending host tries them all...similarly, all possible source
addresses are tried in turn."  Is that the expectation here?

Even though this document is about Babel and not the host, I would like to see
a (short) discussion about how the host is expected to behave (or what it needs
to consider) in light of the destination-first operation.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) §4 talks about "lower layers", what are those?  Please be specific.

(2) The second bullet in §4 says that "Babel...MUST either silently ignore any
source-specific routes, or disambiguate..."  Given the required (use of MUST)
nature of the disambiguation, I would like to see an algorithm for it, not just
an example.  I do not include this point in the DISCUSS section because I think
there are ways not to require disambiguation; perhaps something along the lines
of:

   ...SHOULD silently ignore any source-specific routes.  A router can also
   choose to use a disambiguation algorithm (see SS-ROUTING for an example),
   but the details are out of this document's scope.

(3) §7.1: "Source Plen  The length of the advertised source prefix."  Indicate
in bits.