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

On Mon, Nov 2, 2020 at 8:25 AM Fred Baker <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.

>
> Soliciting opinions on the problem: is this something that needs a
> solution? 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> 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>
> > 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>
> >
> >
> >
> >
> > ---------- Forwarded message ---------
> > From: <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>, Alexandre Petrescu <
> alexandre.petrescu@cea.fr>, Gyan Mishra <gyan.s.mishra@verizon.com>,
> Alexandre Petrescu <Alexandre.Petrescu@cea.fr>, Dusan Mudric <
> dmudric@ciena.com>, Dmytro Shytyi <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.
> >
> > 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
> > 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