IETF Logo Mail Archive

Re: Comments on presentation of draft-lemon-stub-networks-ps-00

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 28 July 2020 13:47 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235793A0C54 for <ipv6@ietfa.amsl.com>; Tue, 28 Jul 2020 06:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.com
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 zoOOyH4Avipa for <ipv6@ietfa.amsl.com>; Tue, 28 Jul 2020 06:47:01 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D823A0C49 for <ipv6@ietf.org>; Tue, 28 Jul 2020 06:47:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 06SDknQb006013; Tue, 28 Jul 2020 09:46:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1595944018; bh=thOPukqqAkXaOSES2Nr3A8ZJ503VvcbUp6ZBhDKcJ2Q=; h=From:To:CC:Subject:Date:From; b=Y7P8IdTABF2/EESYTjCqya0El7eQ5L5bnpH/j6ORcNSeczutBiPgPzeXE6ApuN/XF xbM17aokgbxpDekDAsm++lmLAegIHFHF32nTwR8ZTfETlqsy5Y+mGiDpuQtRbB1fdd SLRN9FaZqSlViM4ldEjAh9m6X8YkEeJvvhqn9s/azVlqe5tZ1ASE72RMsWJdx4ymQF 4DBT229QAiUb9vKpHw+RG9BrOYzDZ2RooA1jvR+2QzjlB+SXarxjrgnpGM1hyKk4ZO uxgLvh/vQUWWfUz2ce74i+CjzLsFbB8nhxjDj5UoQJNNTjrEX1sRmVmb7Jkg3ZUO0R Ov/ImJdijWRUg==
Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 06SDkiWx005973 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 28 Jul 2020 09:46:44 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Tue, 28 Jul 2020 06:46:43 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.1979.003; Tue, 28 Jul 2020 06:46:43 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Ted Lemon <mellon@fugue.com>, Alexandre Petrescu <alexandre.petrescu@gmail.com>
CC: IPv6 <ipv6@ietf.org>
Subject: Re: Comments on presentation of draft-lemon-stub-networks-ps-00
Thread-Topic: Comments on presentation of draft-lemon-stub-networks-ps-00
Thread-Index: AdZk5NbryKRG5+kGTyCQqDDhlufkag==
Date: Tue, 28 Jul 2020 13:46:43 +0000
Message-ID: <031d58ccb8af4d38ac204396fcf1b7d1@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 6A212ED0B4100648DA87243AD8088D25BB9FD7F4A7A399460E439578828F98DA2000:8
Content-Type: multipart/alternative; boundary="_000_031d58ccb8af4d38ac204396fcf1b7d1boeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/sR3Rx9YqG8XwJaTFHtH76YaFSmI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 13:47:05 -0000

Hi, I also have a comment – I think there may be significant overlap between this
document and “IPv6 Prefix Delegation and Multi-Addressing Models”:

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

That document evolved over the course of many years with working group input,
and I think could be used as a starting basis for what is trying to be done here.

Thanks - Fred

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Tuesday, July 28, 2020 6:06 AM
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: IPv6 <ipv6@ietf.org>
Subject: Re: Comments on presentation of draft-lemon-stub-networks-ps-00




On Jul 28, 2020, at 8:58 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>> wrote:
- targetting an IPv4 setting: it would be difficult to work on that.  I mean, one could formulate a problem that says 'IPv4' among other things, but then when solution time arrives... write an I-D with a solution in IPv4 space at IETF?

Maybe formulate it as an 'IP' problem could be considered.

It’s a matter of practicality, whether it’s documented in the IETF or not. We know how to do NAT64, so one way to solve the “cloud-over-IPv4-infrastructure” problem is with NAT64. I don’t think this is unreasonable to document, and I’m certainly not suggesting that it be the primary answer. But practically speaking, if it’s not documented, it will just be done differently in each implementation.


- more clearly defining a stub network might be necessary.  The slide showed a 'stub router' and a 'stub host' but I am not sure a stub network is made of a stub router and a stub host.  At the same time, it might be that a stub network connecting to another stub network renders this latter just a network (not a stub network).

I would definitely appreciate comments on the document. :)


This could make think that a stub network might be made of only one subnet(?)

Yes, that’s explicit in the document—sorry for not explaining it.

- in the slide overviewing the solution space, an additional thing could be mentioned: that of using SLAAC with a non-64 prefix length.

How would this help?  Do you mean something like the 6lo backbone router proposal?  How does subdividing the prefix help with that?

v2.23.0 | Report a Bug | By Email