Re: [v6ops] Update of RFC 7084 -- Re: Slides from AWS, SAP, ESnet, Dell in side meeting and call for volunteers on 3 research topics

"Delong.com" <owen@delong.com> Mon, 07 August 2023 21:13 UTC

Return-Path: <owen@delong.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 CD454C137368 for <v6ops@ietfa.amsl.com>; Mon, 7 Aug 2023 14:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.com
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 rjz7LqBwgzSP for <v6ops@ietfa.amsl.com>; Mon, 7 Aug 2023 14:13:48 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id CB913C169502 for <v6ops@ietf.org>; Mon, 7 Aug 2023 14:13:23 -0700 (PDT)
Received: from smtpclient.apple (162-225-212-17.lightspeed.sntcca.sbcglobal.net [162.225.212.17]) (authenticated bits=0) by owen.delong.com (8.17.1/8.15.2) with ESMTPSA id 377LCYOW1979636 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 7 Aug 2023 14:12:35 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 377LCYOW1979636
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1691442755; bh=ahIeS/SvmiJz1WSovmgTGE20mXDrW4iSHGW4LmuCbiw=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=zqmf8mGdUENi5ok6+fxgeooKc3ebRW8QD+tvdrBqdEcDhGI6XIcaizSGsEzBaOh4z AFfXZYOPb2Kb55tkxUplg/2tLJsyWTGSsYYi0m5erwF0wYDmQ6MjYJ5Axc2Ff/L+dh /5MomZva2Y9ay8NovuXojcx851wdHU+/SvtAbtQ0=
From: "Delong.com" <owen@delong.com>
Message-Id: <207D8822-4AAF-4E1B-8400-E653D1CCCA63@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AF8D17D6-497A-498C-9146-1CC425B21A20"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Mon, 07 Aug 2023 14:12:24 -0700
In-Reply-To: <74e6d46a0d364003933c26b6f5d8c1a5@huawei.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ted Lemon <mellon@fugue.com>, Gábor LENCSE <lencse@hit.bme.hu>, Ole Trøan <otroan=40employees.org@dmarc.ietf.org>, Timothy Winters <tim@qacafe.com>, "v6ops@ietf.org" <v6ops@ietf.org>
To: Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org>
References: <fc112f43d5334e2fb307e57dd4824dd0@huawei.com> <4650D33E-D607-4426-9735-AB3717007AB6@employees.org> <CAPt1N1ntcgt15=MhaiNA3jiupHN15ZDBX9Ee1JjMP1a4-+=eAA@mail.gmail.com> <c1d5fdb9-d99e-de9d-8260-afc02d2533f6@hit.bme.hu> <CAPt1N1ncvLV=8qRLeXvb71qezsWT_A577pmO_qNUM_icfTBzsw@mail.gmail.com> <2f4da251-94b2-ce1b-38e6-e25dbf94fea1@gmail.com> <74e6d46a0d364003933c26b6f5d8c1a5@huawei.com>
X-Mailer: Apple Mail (2.3731.600.7)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (owen.delong.com [192.159.10.2]); Mon, 07 Aug 2023 14:12:35 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/rbJtW3beodaWm1vDQhHERDgHaOQ>
Subject: Re: [v6ops] Update of RFC 7084 -- Re: Slides from AWS, SAP, ESnet, Dell in side meeting and call for volunteers on 3 research topics
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: Mon, 07 Aug 2023 21:13:55 -0000

No, IPv4aaS is a way to say Delivering IPv4 capabilities over an IPv6-only Infrastructure.

IPv6-only works just fine without IPv4aaS, IPv4aaS is only necessary for IPv4 to continue functioning in an IPv6-only environment.

So I’m inclined to believe that IPv4aaS does belong squarely in an IPv4 document.

Owen


> On Aug 7, 2023, at 03:38, Xipengxiao <xipengxiao=40huawei.com@dmarc.ietf.org> wrote:
> 
> Hi Ole, Ted, Gabor, Brian,
>  
> I think IPv4aaS is a different way to say IPv6-only.  So I don't follow the logic that "IPv4aaS would belong in a IPv4 CE document. Not in an IPv6 one".  But I will search the mail archive to find out why some people thought that way (or some key points for my education will be appreciated).
>  
> Regarding update of 7084 and 8585, here is my thinking:
>  
> Let's separate this "requirements for IPv6 CPE" draft from an "IPv6 BCP" draft (to be started).  Recommending 464XLAT that Ted/Brian asked for can go to the BCP draft if getting enough support.
> We do want to minimize changes as Gabor/others suggested.  So if we can reference 9313 or other RFCs, let's reference them.  But I prefer including the IPv4aaS requirements as a section in this new draft to create a single requirement document.
> Personally, I agree with Ted to reduce IPv4aaS options in the requirement document.  For example, of the IPv4aaS options listed by Gabor, I don’t believe MAP-E and Lw4o6 have ever been deployed so I would be happy to leave them out.  But if this will cause too much debate, I suggest we just reference 9313 and 8585 to keep the status quo, and leave this debate to the BCP draft.  The main purpose to update 7084 this time is to advise against EUI-64 to deal with the privacy issue reported by MAPrg.  Other purposes should be handled in an opportunistic way (i.e. if we can get them we get them, if not we don’t insist).
>  
> Thanks and regards,
>  
> XiPeng 
>  
> -----Original Message-----
> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter
> Sent: Sunday, August 6, 2023 10:52 PM
> To: Ted Lemon <mellon@fugue.com>; Gábor LENCSE <lencse@hit.bme.hu>
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] Update of RFC 7084 -- Re: Slides from AWS, SAP, ESnet, Dell in side meeting and call for volunteers on 3 research topics
>  
> On 07-Aug-23 07:24, Ted Lemon wrote:
> > That’s what I was getting at when I said we might not be ready. I don’t think we should require anything if we don’t have a specific thing to require. Requiring half a dozen different things will make people not want to use the RFC.
>  
> However, RFC 9313 doesn't provide a simple decision tree for an operator, or a set of valid use cases. I'd like to see that somewhere. Possibly in draft-ietf-v6ops-framework-md-ipv6only-underlay or possibly not in an RFC at all.
>  
>      Brian
>  
> > 
> > Op zo 6 aug 2023 om 14:39 schreef Gábor LENCSE <lencse@hit.bme.hu <mailto:lencse@hit.bme.hu <mailto:lencse@hit.bme.hu%20%3cmailto:lencse@hit.bme.hu>>>
> > 
> >     Dear Ted,
> > 
> >     8/6/2023 8:18 PM keltezéssel, Ted Lemon írta:
> >     [...]
> >      > Personally I think that we should decide what to recommend if we
> >      > specify IPv4aas. 8585 mentions numerous options. This doesn’t feel
> >      > like something that should be in a router requirements document. I
> >      > suspect we have enough operational experience at this point to make a
> >      > specific recommendation; probably NAT64/464xlat. If we aren’t ready to
> >      > do that, I don’t think we’re ready to include this in 7084bis.
> >      >
> >     I do not think that a draft that recommends any one of the five IPv4aaS
> >     solutions (464XLAT, DS-Lite, Lw4o6, MAP-E, MAP-T) as THE GOOD SOLUTION
> >     will achieve consensus.
> > 
> >     In RFC 9313, we followed the approach that we analyzed the pros and cons
> >     of all the above five solutions and left the decision to the network
> >     operators. It was not only a tactic to get our draft published. I
> >     honestly believe that depending on various circumstances, one of them
> >     can be the most appropriate solution in one case, and another one can be
> >     more suitable in another case.
> > 
> >     So my suggestion is that if 7084bis will be done then it should not
> >     elaborate much about IPv4aaS, but is should talk about the general
> >     router requirements plus regarding the IPv4aaS solutions, it should cite
> >     RFC 8585 and say that all five solutions should be supported by the CEs,
> >     and also cite RFC 9313 as a guideline that helps the operators to choose
> >     the one that is most appropriate for their specific case.
> > 
> >     What do you think?
> > 
> >     Best regards,
> > 
> >     Gábor
> > 
> >     _______________________________________________
> >     v6ops mailing list
> >     v6ops@ietf.org <mailto:v6ops@ietf.org> <mailto:v6ops@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/v6ops <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