Re: [v6ops] Updating RFC 7084
Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 30 November 2022 15:43 UTC
Return-Path: <vasilenko.eduard@huawei.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A98C152590 for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 07:43:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Level:
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tJgyJpcNwUh for <v6ops@ietfa.amsl.com>; Wed, 30 Nov 2022 07:43:01 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0549CC1524D1 for <v6ops@ietf.org>; Wed, 30 Nov 2022 07:43:01 -0800 (PST)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4NMk3r6bd4z67M7f for <v6ops@ietf.org>; Wed, 30 Nov 2022 23:42:32 +0800 (CST)
Received: from mscpeml100001.china.huawei.com (7.188.26.227) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 30 Nov 2022 16:42:57 +0100
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml100001.china.huawei.com (7.188.26.227) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 30 Nov 2022 18:42:56 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2375.031; Wed, 30 Nov 2022 18:42:56 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: David Farmer <farmer=40umn.edu@dmarc.ietf.org>, Ted Lemon <mellon@fugue.com>
CC: list <v6ops@ietf.org>
Thread-Topic: [v6ops] Updating RFC 7084
Thread-Index: AQHY+1zN9qjGTF7iKUuZ5LFbbY25UK5E6EIAgBKzh5b//9SNgIAAB2QAgAA1shA=
Date: Wed, 30 Nov 2022 15:42:56 +0000
Message-ID: <4865d216d61545fe92d02a5b2787fedc@huawei.com>
References: <CAJgLMKs5oYT1Eoq1Z-_3FYDVLvq6q8ecf+-g8cc1zZR5pJtJNw@mail.gmail.com> <8ae52b55-86f7-3b3f-7677-cde43d92a22d@gmail.com> <202211302236271413958@chinatelecom.cn> <CAPt1N1kE2V9prmqQTN8GNiuEhrnWWo-cZ_ZzS4C89_htAUGaAQ@mail.gmail.com> <CAN-Dau0jcyPpUGOvMu+xuy6hkQi8zGGhAA0Fx6mmfvk6_TmYsg@mail.gmail.com>
In-Reply-To: <CAN-Dau0jcyPpUGOvMu+xuy6hkQi8zGGhAA0Fx6mmfvk6_TmYsg@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.195.244.194]
Content-Type: multipart/alternative; boundary="_000_4865d216d61545fe92d02a5b2787fedchuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/F2OgG7egmB56iJk2dkjICqhNYaI>
Subject: Re: [v6ops] Updating RFC 7084
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2022 15:43:03 -0000
When the stub router is connecting to the “infrustrcutre”, There is no way to predict how many PA-prefixes from different Carriers it would receive. Especially in the future, when we assume MHMP would work. Eduard From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of David Farmer Sent: Wednesday, November 30, 2022 6:28 PM To: Ted Lemon <mellon@fugue.com> Cc: list <v6ops@ietf.org> Subject: Re: [v6ops] Updating RFC 7084 I think you are both correct. I would consider mobile backup to be multi-homing if it occurs automatically; for example, if my home router had a 5G radio in addition to a fiber connection, or I had two home routers, one fed by fiber and the other fed with a 5G Radio. However, I would not consider manually tethering my laptop to my phone operating as a hotspot to be multi-homing. Just like I would not consider using my neighbor's WIFi as multihoming either. Thanks On Wed, Nov 30, 2022 at 9:02 AM Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote: Isn’t mobile backup a form of multi-homing? Op wo 30 nov. 2022 om 09:36 schreef Chongfeng Xie <xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn>> Regarding to multi-homing, home users have no needs for multi-homing, which provides access by two wireline uplinks of different operators. Independent 4G/5G mobile broadband has gradually become the backup of home broadband, some users even prefer to use use mobile link to access the Internet at home. Chongfeng ________________________________ xiechf@chinatelecom.cn<mailto:xiechf@chinatelecom.cn> From: Brian E Carpenter<mailto:brian.e.carpenter@gmail.com> Date: 2022-11-19 04:02 To: Timothy Winters<mailto:tim@qacafe.com>; IPv6 Operations<mailto:v6ops@ietf.org> Subject: Re: [v6ops] Updating RFC 7084 On 19-Nov-22 03:47, Timothy Winters wrote: > Hello, > > I've started a draft to update RFC 7084 to support prefix delegation on the LAN interfaces. The current state of IPv6 in home networks is ISP are assigning prefixes of appropriate sizes but they currently are under utilized due to the lack of prefix delegation on LAN interfaces. > > This draft is an attempt to add that support to the draft. > > https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/ <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/> > > This is only an update to 7084 at the moment, there has been some discussion on the snac working group about leveraging this work as well. > > One item being discussed is this currently doesn't solve multi-homed networks. As a historical note, we've spent a lot of time in the past on multi-homing and more or less failed (and the HOMENET approach was designed for home nets, not for enterprises where the problem is probably more important). I To summarise what I've said over on SNAC: 1. If we're going to mention PvDs in the 7084 update, I think we should also mention RFC 8028. It isn't that a CE router should necessarily support 8028, but that in a network that does implement 8028 on its subnet routers, the following part of 8028 applies: 2.2. Expectations of Multihomed Networks Networking equipment needs to support source/destination routing for at least some of the routes in the Forwarding Information Base (FIB), such as default egress routes differentiated by source prefix. Installation of source/destination routes in the FIB might be accomplished using static routes, Software-Defined Networking (SDN) technologies, or dynamic routing protocols. Those egress routes of course lead to CE routers. (There is some other thinking about this topic in draft-vv-6man-nd-support-mhmp). Brian > > I welcome any feedback about the proposal. > > ~Tim > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org<mailto:v6ops@ietf.org> > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org<mailto:v6ops@ietf.org> https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org<mailto:v6ops@ietf.org> https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org<mailto:v6ops@ietf.org> https://www.ietf.org/mailman/listinfo/v6ops -- =============================================== David Farmer Email:farmer@umn.edu<mailto:Email%3Afarmer@umn.edu> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================
- [v6ops] Updating RFC 7084 Timothy Winters
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Lorenzo Colitti
- Re: [v6ops] Updating RFC 7084 Lorenzo Colitti
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ole Troan
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Timothy Winters
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 Chongfeng Xie
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 David Farmer
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 - alternate logic Vasilenko Eduard
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 Gert Doering
- Re: [v6ops] Updating RFC 7084 Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Brian E Carpenter
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic otroan
- Re: [v6ops] Updating RFC 7084 - alternate logic Timothy Winters
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Ole Troan
- Re: [v6ops] Updating RFC 7084 - alternate logic Olorunloba Olopade
- Re: [v6ops] Updating RFC 7084 - alternate logic Ted Lemon
- Re: [v6ops] Updating RFC 7084 - alternate logic Esko Dijk
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu
- Re: [v6ops] Updating RFC 7084 - alternate logic Gert Doering
- Re: [v6ops] Updating RFC 7084 - alternate logic Alexandre Petrescu