RE: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 21 October 2020 07:39 UTC

Return-Path: <vasilenko.eduard@huawei.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 0B6033A1225; Wed, 21 Oct 2020 00:39:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 8fMYFyvgvoHe; Wed, 21 Oct 2020 00:39:25 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A07D23A121B; Wed, 21 Oct 2020 00:39:24 -0700 (PDT)
Received: from lhreml726-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 405E6B96C051343547DA; Wed, 21 Oct 2020 08:39:21 +0100 (IST)
Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 21 Oct 2020 08:39:21 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 21 Oct 2020 10:39:20 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 21 Oct 2020 10:39:20 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Olopade, Olorunloba" <Loba.Olopade@virginmedia.co.uk>, 6man <ipv6@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Subject: RE: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt
Thread-Topic: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt
Thread-Index: AQHWpke+JPdFg9XuL0GCVbkMZbBb/qmfRCqggADXTgCAAOWTUIAAoH1A
Date: Wed, 21 Oct 2020 07:39:20 +0000
Message-ID: <4faaca17276d4cf6a4306421935fb7f1@huawei.com>
References: <160313300387.7363.3016109002772518574@ietfa.amsl.com> <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> <02114d0323604e848d5107db00d976a1@huawei.com> <161b04264ec24ba9862dcb72392b466e@UKKNOPEXCH008.systems.private>
In-Reply-To: <161b04264ec24ba9862dcb72392b466e@UKKNOPEXCH008.systems.private>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.197.73]
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yJw4epq7N59JZ5eWAd5i9EZGWIA>
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: Wed, 21 Oct 2020 07:39:27 -0000

> a common factor would be the forming of a new address.
[Ed: ] Nope. Prefix could be for DHCP (A flag cleared). New address would be given not inside ND engine (DHCP demon is different in Unix).
By the way, on the problem statement: similar problem could happen for DHCP too. Timers would be better (hours against days), but it is not acceptable for user anyway (far from 50ms standards of the previous age). DHCP corner case is just have not been found in live, not yet. In reality we have here general prefix robustness problem of ND - it is not related only to SLAAC.
My "Complete" flag would resolve this problem too - enough information to deprecate DHCP after 1st RA.
How host should do DHCP address deprecation in your solution? Feedback from DHCP demon to ND?

>  So, I believe all the use cases should be covered.
[Ed: ] Nope. You see above.

> I agree that this are long term solutions. For the short term, I think we are stuck with just lowering the timers.
[Ed: ] Nope. I would show.

> We also need to consider how to do garbage collection for RIO and RDNSS
[Ed: ] RIO is better to deprecate for "telco broadband services" because of multi-prefix (many PA prefixes) environment. I would show why - MHMP is a little complex story.
RIO make sense only for Enterprise environment (with single address space, probably PI) - I have put this statement in the draft.

Ed/
> -----Original Message-----
> From: Olopade, Olorunloba [mailto:Loba.Olopade@virginmedia.co.uk]
> Sent: 21 октября 2020 г. 2:14
> To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; 6man <ipv6@ietf.org>;
> v6ops@ietf.org
> Subject: RE: New Version Notification for draft-olopade-6man-slaac-signaling-
> 00.txt
> 
> Hello Eduard,
> 
> Yes, I do mean Multicast RS.
> 
> Yes, we do need synchronisation. I believe some form of "feedback" is needed
> to achieve a "stable system". This is the premise I'm working on. With SLAAC as
> it currently is, we don't have a means of feeding back information from hosts to
> routers. That area is what I'm trying to address in this draft. By including
> information in RS messages, routers can learn about the state of the host.
> 
> This is an initial draft. So I wasn't attempting to document the complete solution
> at this time. But wanted to see if others would see the benefit of moving in this
> direction. In my opinion, I will like to see 2 changes to increase SLAAC
> robustness. This and a means for the router to indicate that it is sending
> "complete"  information (like you are indicating with the flag).
> 
> But if we are to look into the various use cases, a common factor would be the
> forming of a new address. Hence, my proposal leverages on this, by sending the
> RS, as the address transitions from tentative to preferred. So, I believe all the
> use cases should be covered.
> 
> Although, I'm having a change of heart on how to achieve this. I now think that
> using options in RS is better than relying on the source address. The key
> difference is that the current proposal is limited to PIO information. We also
> need to consider how to do garbage collection for RIO and RDNSS
[Ed: ] RIO is better to deprecate. I would show why.
> 
> I agree that this are long term solutions. For the short term, I think we are stuck
> with just lowering the timers.
> 
> 
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Vasilenko Eduard
> Sent: 20 October 2020 09:04
> To: Olopade, Olorunloba
> <Loba.Olopade=40virginmedia.co.uk@dmarc.ietf.org>; 6man <ipv6@ietf.org>;
> v6ops@ietf.org
> Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-
> signaling-00.txt
> 
> Hi Loba,
> I was the loudest shouting that "tweaking timers" is a very bad solution.
> Hence, it was logical consequences that Ole did push me to develop my draft.
> I am very close to publish it. I am in the context of this discussion. I have spent
> couple of weeks exclusively on this problem.
> 
> You probably mean: "multicast RS " or "multicast NS to all routers".
> It is not possible to find "multicast" in your draft.
> 
> Your proposal by itself is not bad. Synchronization is needed, indeed.
> I have proposed here (and it would be discussed in my draft) 1 additional flag in
> RA message that information is "complete".
> IMHO: It is a little better way for synchronization, because it does not need
> additional messages to synchronize states.
> 
> But such type of solutions are considered by me as "long-term". It needs host
> support. It could not happen very soon.
> Something for short-term is needed too.
> 
> Additionally, you have not discussed solutions for all use cases presented by
> Fernando in draft-ietf-v6ops-slaac-renum.
> For example: abrupt prefix change on the router (without deprecation) Or abrupt
> VLAN change on L2 (802.1X) Or prefix is just disconnected from Carrier, because
> uplink is down (replacement is not proposed yet) Or situation in multi-homing
> when many PA prefixes from different Carriers are announced and some could
> be disconnected from carrier.
> But maybe it was not your goal to develop comprehensive solution for "ND
> prefix robustness" (the last term is the name of my draft)
> 
> Eduard
> > -----Original Message-----
> > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Olopade,
> > Olorunloba
> > Sent: 19 октября 2020 г. 21:54
> > To: 6man <ipv6@ietf.org>; v6ops@ietf.org
> > Subject: Re: [v6ops] New Version Notification for
> > draft-olopade-6man-slaac- signaling-00.txt
> >
> > Hello all,
> >
> > I'm proposing an alternate way to address the SLAAC flash renumbering
> > issue, and I've been advised to put this in a draft. This is the
> > initial draft, and definitely need more work, but will like to know if
> > people think this approach is worth considering.
> >
> > Regards.
> >
> > Loba Olopade
> >
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: 19 October 2020 19:43
> > To: Olopade, Olorunloba <Loba.Olopade@virginmedia.co.uk>
> > Subject: New Version Notification for
> > draft-olopade-6man-slaac-signaling-00.txt
> >
> >
> > A new version of I-D, draft-olopade-6man-slaac-signaling-00.txt
> > has been successfully submitted by Loba Olopade and posted to the IETF
> > repository.
> >
> > Name:		draft-olopade-6man-slaac-signaling
> > Revision:	00
> > Title:		Explicit signaling of Stateless Address Autoconfiguration (SLAAC)
> > to Renumbering Events
> > Document date:	2020-10-19
> > Group:		Individual Submission
> > Pages:		7
> > URL:            https://www.ietf.org/archive/id/draft-olopade-6man-slaac-
> > signaling-00.txt
> > Status:         https://datatracker.ietf.org/doc/draft-olopade-6man-slaac-
> > signaling/
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-olopade-6man-
> slaac-
> > signaling
> > Htmlized:       https://tools.ietf.org/html/draft-olopade-6man-slaac-signaling-
> 00
> >
> >
> > Abstract:
> >    After a renumbering event in an IPv6 network utilizing SLAAC, hosts
> >    might continue to use stale addresses, as they are unaware of the
> >    changes. Likewise, routers, who may deprecate the use of these
> >    prefixes, are unaware of their use on the hosts. This scenario could
> >    have an adverse effect on communication with the host. This document
> >    proposes changes to the SLAAC algorithm that will explicitly allow
> >    routers to learn of these stale prefixes that are still assigned on
> >    the network.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> > --------------------------------------------------------------------
> > Save Paper - Do you really need to print this e-mail?
> >
> > Visit www.virginmedia.com for more information, and more fun.
> >
> > This email and any attachments are or may be confidential and legally
> > privileged and are sent solely for the attention of the addressee(s).
> >
> > Virgin Media will never ask for account or financial information via
> > email. If you are in receipt of a suspicious email, please report to
> > www.virginmedia.com/netreport
> >
> > If you have received this email in error, please delete it from your
> > system: its use, disclosure or copying is unauthorised. Statements and
> > opinions expressed in this email may not represent those of Virgin
> > Media. Any representations or commitments in this email are subject to
> contract.
> >
> > Registered office: 500 Brook Drive, Reading, RG2 6UU
> >
> > Registered in England and Wales with number 2591237
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> --------------------------------------------------------------------
> Save Paper - Do you really need to print this e-mail?
> 
> Visit www.virginmedia.com for more information, and more fun.
> 
> This email and any attachments are or may be confidential and legally privileged
> and are sent solely for the attention of the addressee(s).
> 
> Virgin Media will never ask for account or financial information via email. If you
> are in receipt of a suspicious email, please report to
> www.virginmedia.com/netreport
> 
> If you have received this email in error, please delete it from your system: its
> use, disclosure or copying is unauthorised. Statements and opinions expressed in
> this email may not represent those of Virgin Media. Any representations or
> commitments in this email are subject to contract.
> 
> Registered office: 500 Brook Drive, Reading, RG2 6UU
> 
> Registered in England and Wales with number 2591237