[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.
- [babel] Alvaro Retana's Discuss on draft-ietf-bab… Alvaro Retana via Datatracker
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Toke Høiland-Jørgensen
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Alvaro Retana
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Toke Høiland-Jørgensen
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Toke Høiland-Jørgensen
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Juliusz Chroboczek
- Re: [babel] Alvaro Retana's Discuss on draft-ietf… Alvaro Retana