Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt

Gyan Mishra <hayabusagsm@gmail.com> Tue, 03 November 2020 06:18 UTC

Return-Path: <hayabusagsm@gmail.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 8AA403A14AB for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2020 22:18:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZpUB3IdqL-IO for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2020 22:18:32 -0800 (PST)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A862C3A1504 for <v6ops@ietf.org>; Mon, 2 Nov 2020 22:18:10 -0800 (PST)
Received: by mail-vs1-xe35.google.com with SMTP id z123so4137524vsb.0 for <v6ops@ietf.org>; Mon, 02 Nov 2020 22:18:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tx2syzDu4cVv3PNZNL9BWUPRWlXt486sDscIaEhBWko=; b=ThYvgmesAsHxhY+ZK4ExOBe6Cmnox+8Em3rTiJrsk4OFjjPbtN1zFpgzw5PAHuasHH 4UuEzQBPu51drILhGdlhQZybSpcP6EMM7aDxqG1CH/g8ycobHd/jZDE+Ci4puVy0JAlw QIlx9XabRoLc6L2H2W1loNp+BCkFqxOMqH7QurL5eypDfg4I9FgMIDL9cW6XEOU5CPAL 5jSepAv7wWKF4PvMZIubilnb1G6Cr/BOARXct8OA1acHsYU/DAQrub4J+SlCygYhSLNf OAw1De7LykVymu9kP6IM0DQHirVCitFprTsURkBXiEY0Svkfvc6nrnD5JpWRQVqXX8gm Ghpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tx2syzDu4cVv3PNZNL9BWUPRWlXt486sDscIaEhBWko=; b=W5TLYvVX79Oyp4Hjd45bJdfThRkrEJm8hybSlKDi7RnCmVvTPSlLeTIVTXRNENkgP7 3YukgX1LcXutcvkJHR5ZoQLQtF+K9oacFEXG6quZ/PaeBoDqWPBKKEsHY965+MGvDQMI BtjO/9BgwTkR/npmNrrJyMBmfC/s5AbLXaSWfHrim5cWiNVtP8d/UTB07LgId1KTZl7y +oaLUVqGzrTwWzapZ+W9//dD+cNG4sG6Ma9xYLxpv4E+Fd6HSzF6TKVy2DKqiJ5dxiTl OVOuEKM6DwaFa/vhLj5JucjDnqPjGvfOiDU2Ez3R8qF8WyIPv21xxjEJgVEfvMO8nifH sIOQ==
X-Gm-Message-State: AOAM531Az92DvEE0YDo6336laQN2eS9+RuZa7VMjj0zwpKfu7Qd67WA2 71l7WFqYdNT9dsVGhslJ4gZu6YGLaoLtRfw9L4I=
X-Google-Smtp-Source: ABdhPJxtiKpgU5YtMv+b1P3BbRxHaJRfRV08hNDKhu25Is92+/ZzXxVW68Nx0s68BYpuIt7ifbFT7GwYLFvdyeJgGcc=
X-Received: by 2002:a67:6f06:: with SMTP id k6mr16855391vsc.20.1604384289469; Mon, 02 Nov 2020 22:18:09 -0800 (PST)
MIME-Version: 1.0
References: <160409793214.22613.15041785352190993395@ietfa.amsl.com> <CAJhXr98mPsopQrUiKfXGuN+wxSEtNiP00LBEGrYObz62FHSa_Q@mail.gmail.com> <CABNhwV1LTcVKobDpiEjnxqKbX9drz1od+RNg7EdX_WO04JQgUw@mail.gmail.com> <49DFF195-CB76-4575-BA29-F134F99D6EE1@gmail.com> <CABNhwV27Dp6g+d-MGeGTR2eg7JJoRunzh2ALPr59z4u4JN4S7g@mail.gmail.com> <d8659634-734b-d5d4-a112-1f9dfaef72cb@gmail.com>
In-Reply-To: <d8659634-734b-d5d4-a112-1f9dfaef72cb@gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 03 Nov 2020 01:12:05 -0500
Message-ID: <CABNhwV1V4LYGkuSFBYy7-N2xRnO2hpYiwCy1S-5dfWDgLEkAKg@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, Dmytro Shytyi <dmytro.shytyi@sfr.com>, Naveen Kottapalli <nkottapalli@benu.net>, IPv6 Operations <v6ops@ietf.org>, Gyan Mishra <gyan.s.mishra@verizon.com>, Alexandre Petrescu <alexandre.petrescu@cea.fr>
Content-Type: multipart/alternative; boundary="000000000000a837e605b32dd3ff"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/2REKRhdgO-j9SG24sLYrG9UAlp4>
Subject: Re: [v6ops] [E] New Version Notification for draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 03 Nov 2020 06:18:37 -0000

On Mon, Nov 2, 2020 at 3:08 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 03-Nov-20 06:13, Gyan Mishra wrote:
> >
> >
> > On Mon, Nov 2, 2020 at 8:25 AM Fred Baker <fredbaker.ietf@gmail.com
> <mailto:fredbaker.ietf@gmail.com>> wrote:
> >
> >     Let me ask a question of the operators. This draft, as of today, is
> in discussion in 6man and will probably be discussed in the 6man meeting. I
> have not offered the authors a slot in v6ops, as it is not being discussed
> here. That said, it is presumably a solution to an operational problem, in
> that the prefix that SLAAC is being used to generate an address in is not
> exactly 64 bits.
> >
> >
> >     Gyan> Agreed on 6MAN slot.  Yes, solution to operational problem.
> We would discuss both problem and solution during the time slot so I think
> 6MAN would be the right spot.  Correct.
>
> Why would 6man spend time on solving a problem before the operational
> community agreees that there is a problem?
>
> My understanding is that the principal operational requirement is already
> stated in BCP198 (RFC7608). There was a previous attempt to change the
> status quo in
> https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6 but that
> didn't advance.
>
> So let's have a discussion whether there is a new operational problem here
> first:
>
>   "The main problem is that SLAAC RA or PD allocates a /64 by the
>    wireless carrier 4G, 5G, 3GPP to mobile handset or hotspot, however
>    segmentation of the /64 via SLAAC is required so that downstream
>    interfaces can be further sub-netted."
>

      Gyan> Correct.  That is the issue.

>
> Why isn't that in v6ops scope?
>

    I think the problem would be I would think in scope to v6ops however as
Fred & Lorenzo pointed out that it maybe better to keep the entire
discussion in 6MAN as it pertains to operations problem but then also
solutions to the problem that updates slaac which is in a separate 6man
draft.  So having the entire discussion in 6man makes sense.  I see you
already started the thread there so I will join in.


>
> >     Soliciting opinions on the problem: is this something that needs a
> solution?
>
> Is there any reason why the mobile devices can't be given a /56 or /48,
> which solves the problem immediately?
>

  4G & 5G carrier standard is /64 per handset for both IPv6 only and dual
stack deployments.  Even though there is a way tremendous amount of space
in IPv6 I believe last count worldwide is 14 billion handsets.
  This issue with /64 segmentation does become more pronounced with 5G  as
it competes with broadband use case and in many cases SOHO customers may
eliminate their broadband and rely solely on 5G and need the segmentation.


>
>     Brian
>
> On the solution: what do you think of it? Does it have holes?
> >
> >
> >     Gyan> Yes soliciting opinions on the problem is the first step and
> poking holes on v6ops before we get to solution - so v6ops ML is perfect
> spot for that.
> >
> >
> >
> >     > On Nov 2, 2020, at 12:14 AM, Gyan Mishra <hayabusagsm@gmail.com
> <mailto:hayabusagsm@gmail.com>> wrote:
> >     >
> >     >   Dear v6OPS,
> >     >
> >     > This draft addresses the problem statement to change SLAAC's
> historical fixed 64 bit boundary to variable PIO so that VLSM masking is
> supported just as it is today with static & DHCPv6 & DHCPv6 PD.
> >     >
> >     > This change to SLAAC to variable, ensures that parity is
> maintained between the three address deployment mechanisms that exist today
> with IPv6.  This draft as well addresses the MAJOR gap that exists today
> with lack of parity and the historical framework of the impact of this lack
> of partify that has existed since the IPv6 specification was published 20+
> years ago.
> >     >
> >     > We have a solutions draft below that is referenced in this draft
> that goes over in detail the solution on 6MAN.
> >     >
> >     > ! Variable SLAAC
> >     > https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/
> >     >
> >     > Bob & Ole,
> >     >
> >     > Please review.  Based on the feedback received from 6MAN, I would
> like to request a time slot on IETF 109.
> >     >
> >     > Kind Regards
> >     >
> >     > Gyan
> >     >
> >     >
> >     >
> >     > ---------- Forwarded message ---------
> >     > From: Mishra, Gyan S <gyan.s.mishra@verizon.com <mailto:
> gyan.s.mishra@verizon.com>>
> >     > Date: Fri, Oct 30, 2020 at 6:50 PM
> >     > Subject: Fwd: [E] New Version Notification for
> draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
> >     > To: Hayabusanew <hayabusagsm@gmail.com <mailto:
> hayabusagsm@gmail.com>>
> >     >
> >     >
> >     >
> >     >
> >     > ---------- Forwarded message ---------
> >     > From: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> >     > Date: Fri, Oct 30, 2020 at 6:46 PM
> >     > Subject: [E] New Version Notification for
> draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
> >     > To: Naveen Kottapalli <nkottapalli@benu.net <mailto:
> nkottapalli@benu.net>>, Alexandre Petrescu <alexandre.petrescu@cea.fr
> <mailto:alexandre.petrescu@cea.fr>>, Gyan Mishra <
> gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>>, Alexandre
> Petrescu <Alexandre.Petrescu@cea.fr <mailto:Alexandre.Petrescu@cea.fr>>,
> Dusan Mudric <dmudric@ciena.com <mailto:dmudric@ciena.com>>, Dmytro
> Shytyi <dmytro.shytyi@sfr.com <mailto:dmytro.shytyi@sfr.com>>
> >     >
> >     >
> >     >
> >     > A new version of I-D,
> draft-mishra-v6ops-variable-slaac-problem-stmt-01.txt
> >     > has been successfully submitted by Gyan Mishra and posted to the
> >     > IETF repository.
> >     >
> >     > Name:           draft-mishra-v6ops-variable-slaac-problem-stmt
> >     > Revision:       01
> >     > Title:          SLAAC with prefixes of arbitrary length in PIO
> (Variable SLAAC) - A Problem Statement
> >     > Document date:  2020-10-30
> >     > Group:          Individual Submission
> >     > Pages:          12
> >     > URL:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01.txt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=dtYY-cXn0FCho9ZftXjO-TuTH19Nr6MO5spHMPP0xR4&e=
> >     > Status:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt_&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=r_lKH89Jv_SyFjyIiw5PnM-0tsi2rCVZBfiR8Q9kHxc&e=
> >     > Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=eKzBB98mFai1psOcqSKEFKAB4ex0TTkH1qE3KwlktF8&e=
> >     > Htmlized:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=BWr8XoPyMxt4e9KnLojwGX54ODGu0gmDToc_EweEdtI&e=
> >     > Diff:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dmishra-2Dv6ops-2Dvariable-2Dslaac-2Dproblem-2Dstmt-2D01&d=DwICaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D-RfNVLML28ZU&m=ZpKJS8hFoz8oYRnxB625Sh8r1NsuITN0k-oDx27MAoo&s=ZnQw7BqnqoVfmkBjFXkEWMDk_QEIRHI-11QPkt3b1bU&e=
> >     >
> >     > Abstract:
> >     >    In the past, various IPv6 addressing models have been proposed
> based
> >     >    on a subnet hierarchy embedding a 64-bit prefix.  The last
> remnant of
> >     >    IPv6 classful addressing is a inflexible interface identifier
> >     >    boundary at /64.  This document details the 64-bit boundary
> problem
> >     >    statement.
> >     >
> >     >
> >     >
> >     >
> >     > 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 <http://tools.ietf.org>.
> >     >
> >     > The IETF Secretariat
> >     >
> >     >
> >     >
> >     >
> >     > --
> >     >
> >     >
> >     > Gyan Mishra
> >     > Network Solutions Architect & SME
> >     > Data Center Planning | Common Core | Development & Engineering Lab
> Services
> >     > Global Technology Services | ITNUC
> >     > O 240 970-6287
> >     > M 301 502-1347
> >     > 13101 Columbia Pike Rm 304-D
> >     > Silver Spring, MD 20904
> >     >
> >     > IETF  & ISOC Member since 2015
> >     > https://www.ietf.org/
> >     > https://www.internetsociety.org/
> >     >
> >     >
> >     >
> >     >
> >     > --
> >     >
> >     >
> >     > Gyan Mishra
> >     > Network Solutions Architect
> >     > M 301 502-1347
> >     > 13101 Columbia Pike
> >     > Silver Spring, MD
> >     >
> >     > _______________________________________________
> >     > v6ops mailing list
> >     > v6ops@ietf.org <mailto:v6ops@ietf.org>
> >     > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > --
> >
> > <http://www.verizon.com/>
> >
> > *Gyan Mishra*
> >
> > /Network Solutions A//rchitect /
> >
> > /M 301 502-1347
> > 13101 Columbia Pike
> > /Silver Spring, MD
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>
>

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD