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

On Mon, Nov 2, 2020 at 2:10 PM Bob Hinden <bob.hinden@gmail.com> wrote:

> Hi,
>
> What Lorenzo said.
>
> Further, I did quick read and see some immediate issues.
>
> First off SLACC works just fine with any size prefix/interface ID.    The
> protocol supports different sized prefixes/IIDs.   The purported issue
> relates to interface ID sizes.   These drafts appear to be confused about
> that.
>
> The v6ops draft goes beyond a problem, it it has an IANA section
> requesting a new RA flag.
>

   Gyan> The v6ops draft is about defining the problem statement not
solution so no IANA requests in that draft - that was in error - fixed in
next revision

>
> Bob
>
>
> > On Nov 2, 2020, at 5:32 AM, Lorenzo Colitti <lorenzo=
> 40google.com@dmarc.ietf.org> wrote:
> >
> > AFAICS this is a straight violation of the text in RFC 4291 which says
> that interface IDs are 64 bits long. As such, I don't see the point in
> discussing it unless there is reason to believe that that text will change.
> >
> > There was a very long and very heated discussion about that text a few
> years ago when the 6man tried to take 4291 to full standard. That consumed
> a lot of WG time and ultimately resulted in no changes. I expect there are
> still going to be very strong opinions on both sides. If we are to reopen
> that discussion now, it should happen in 6man, not v6ops. That way those
> discussions will at least only happen in one place.
> >
> > On Mon, Nov 2, 2020 at 10:25 PM 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.
> >
> > 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?
> >
> > > 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
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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