Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017
Toerless Eckert <tte@cs.fau.de> Tue, 19 September 2017 18:53 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D541213436E for <anima@ietfa.amsl.com>; Tue, 19 Sep 2017 11:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 br47XYWU5u-6 for <anima@ietfa.amsl.com>; Tue, 19 Sep 2017 11:53:29 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C66F13435C for <anima@ietf.org>; Tue, 19 Sep 2017 11:53:29 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 255BE58C4F5; Tue, 19 Sep 2017 20:53:24 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1061DB0CC22; Tue, 19 Sep 2017 20:53:23 +0200 (CEST)
Date: Tue, 19 Sep 2017 20:53:23 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Anima WG <anima@ietf.org>
Message-ID: <20170919185323.GB10511@faui40p.informatik.uni-erlangen.de>
References: <5D36713D8A4E7348A7E10DF7437A4B927CDFE66F@NKGEML515-MBX.china.huawei.com> <136a3ebd-dedb-9e2b-86be-a7d5fd12ad9b@gmail.com> <20170803010809.GA12136@faui40p.informatik.uni-erlangen.de> <a12a758e-9edc-14c0-a4e5-a051b83c9e97@gmail.com> <20170914211845.GA30086@faui40p.informatik.uni-erlangen.de> <475b3f59-5cda-0d35-aee7-cedf204d9f5f@gmail.com> <20170918053847.GA31832@faui40p.informatik.uni-erlangen.de> <761b1200-10ac-7dd1-267b-c0890c9cfd27@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <761b1200-10ac-7dd1-267b-c0890c9cfd27@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/nM7qEzj94qvjgyGsy1FAk2ZuVDc>
Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Sep 2017 18:53:33 -0000
Thanks, Brian! Sheng: i think/hop i am trough all outstanding issues with stable-connectivity. Please decide what to do next to move to next stage, eg: another WG last call or pass to IETF/IESG. Cheers Toerless On Tue, Sep 19, 2017 at 08:11:56AM +1200, Brian E Carpenter wrote: > This is embarassing. For some reason I completely missed the announcement > of draft-ietf-anima-stable-connectivity-05, until today. > > I have now looked at the -05 and -06 versions and I'm happy with the result. > > Regards > Brian > > On 18/09/2017 17:38, Toerless Eckert wrote: > > Thanks, Brian: > > > > The "OLD" paragraph you list was from -04. After your review i had already > > changed this in -05 to > > > > NEW: > > > > To connect IPv4 only management plane devices/applications with the > > ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is > > necessary. The basic mechanisms for this are defined in SIIT > > ([RFC7915]). There are multiple solutions using this mechanisms. To > > understand the possible solutions, we consider the requirements: > > .... > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt > > > > I also did spend a good amount of time because of your -04 review and prior > > request by mohammed to detail in the following parapgraphs the possible > > options in more detail. That text leverages the 'SIIT' term and > > discusses the EAM solutions (RFC7757 is best). > > > > Given how this is an informational OPS document, > > i think it is helpfull to elaborate on the understood details of > > requirements and how known current solutions fit them. > > > > The fact that none of the > > currently defined NAT solutions provides for the most simple possible > > configuration (aka: minimum number of prefix EAM's to configure) is > > also IMHO a perfectly valid outcome for an OPS document. > > > > It could mean that users will simply accept the need for longer mnaual > > NAT config (long list of 1:1 mappings) or vendors implement a proprietary > > EAM (explicit address mapping) CLI to make it simpler. Or users will > > move faster to IPv6 on the NOC ;-) > > > > So, for the time being, i just commited -06 with the second fix. > > > > Let me know what you folks think about WG last call status of > > the stable connectivity draft. > > > > Cheers > > Toerless > > > > On Fri, Sep 15, 2017 at 11:05:51AM +1200, Brian E Carpenter wrote: > >> To cut a long story short, here's a friendly suggestion. The goal is to avoid > >> comments during IETF/IESG review that the NAT text is too vague: > >> > >> OLD > >> To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6 > >> NAT can be used. This NAT setup could for example be done in Rt1r1 > >> in above picture to also support IPv4 only NMS hots connected to > >> NOClan. > >> > >> NEW > >> To bridge an IPv4-only management plane with the ACP, IPv4 to IPv6 > >> translation [RFC 6145] could be used. This could for example be done in Rt1r1 > >> in the above picture to also support IPv4-only NMS hosts connected to > >> NOClan. Details of the address mapping to be used would depend on > >> the exact scenario and are not specified here. > >> > >> And yes, I like this: > >> > >>> i'd suggest to replace the "split-horizon" sentence with: > >>> > >>> Operators may therefore need to use a private DNS setup for the ACP ULA > >>> addresses. This is the same setup that would be necessary for using > >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, last > >>> paragraph. In [RFC6950] section 4, these setups are discussed in more detail. > >> > >> Regards > >> Brian > >> > >> On 15/09/2017 09:18, Toerless Eckert wrote: > >>> > >>> Hi Brian, > >>> > >>> Sorry, for the delay. I have not sen further feedback on stable-connectivity-05 > >>> bside this mail of yours. See answers below, let me know if you want me to rev > >>> with the one possible textual improvement or if we think -05 is good enough. > >>> > >>> Cheers > >>> Toerless > >>> > >>> On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote: > >>>> I'm just coming back on a couple of points. Generally -05 is almost there... > >>>> > >>>>> See the rewritten SIIT section. IMHO, there can be no simpler "network" based > >>>>> address translation. Where network based means that the translation happens > >>>>> in some device he network operator needs to provision. Like the ACP edge device. > >>>>> Or even an additional address translation device. > >>>>> > >>>>> So, the only IMHO easier option is when the OS of the NMS host would internally > >>>>> have IPv4/IPv6 translation so the device/VM looks to the outside like full IPv6. > >>>> > >>>> Yes, that is exactly the effect of 464XLAT in the end-system (not in the > >>>> router). > >>> > >>> I found rfc6877 a confusing read, but from what i figure, it's not exactly what > >>> i was thinking of: with rfc6877, you still need the server side to have a reachable/mappable > >>> IPv4 address, and that is something any device in the ACP does not have naturally. > >>> (aka: NOC server as client connecting to ACP device, ACP device is server). > >>> > >>> If i already need to set up some other form of NAT to give an ACP device an outside IPv4 > >>> address, then 464XLAT does not buy me any simplifications. > >>> > >>> I was rather thinking of taking the NAT network function that i was describing > >>> and simply embody them in a set of linux NAT rules configured on on the NOC linux > >>> system that runs the IPv4-only NMS application. Aka: Not a novel NAT scheme, > >>> but just a way to avoid having to deal with the problem in the network (adding a NAT > >>> device you would otherwise not need): > >>> > >>> Its a NMS host problme, deal with it in the NMS host. If you can not change the app, > >>> let the OS do the NAT. Of course, this would not work for the poor customer who bought > >>> a black-blox NMS soution which may run windows, or where you can not configure the > >>> linux. Then again, nowadays, most NOC components should be software in VMs, and > >>> for those, you should certainly be able to do the NAT in the vswitch of the server. > >>> > >>> In any case: my interest in expanding the NAT section further is quite limited. > >>> The whole goal of the NAT section was to explain that you need 1:1 address mapping > >>> and that you can hack this up in likely most available routers with NAT support, > >>> but do not consider this to be a good long term solution but use it as a stopgap > >>> to upgrade your NOC software to IPv6. > >>> > >>> No idea why IETF draft/RFC doesn't allow me to write such a simple paragraph ;-)) > >>> > >>> So, let me know if you feel strongly anything that should be added/modified to the > >>> NAT section. > >>> > >>>>> Alas, i didn't have the time to investigate these options. And most likely if at > >>>>> all you could only make those work for linux. > >>>> > >>>> Linux or Windows, yes. In a vendor's router o/s, who knows? But maybe they > >>>> will all support IPv6 anyway? > >>> > >>> Lets hope so, yes. > >>> > >>>>> So, for now i just remove the note and clarified the last sentence a bit. > >>>>> > >>>>> If there is anything specific to be said bout why 464XLAT might be better > >>>>> longer term, let me know and i can add it. For now it looks like yet another > >>>>> network device configured option to me, but i have not tried to understand it > >>>>> all the way. > >>>> > >>>> I think you'd need one of the 464XLAT authors to have a look at the scenario, > >>>> because I don't claim to understand it all. > >>> > >>> Well, the analysis i made above (server must support IPv4 as stated in the RFC) > >>> makes me discount it as a more beneficial option to mention. > >>> > >>>>>>> Using current registration options implies that there will not be > >>>>>>> reverse DNS mapping for ACP addresses. > >>>>>> > >>>>>> Really? I assume we're talking about two-faced DNS, and afaik nothing > >>>>>> stops an operator providing reverse mapping in the private DNS. > >>>>>> That seems to be implied by the following paragraphs, so the text > >>>>>> seems inconsistent anyway. > >>>>> > >>>>> I know it under the name "split-horizon DNS". Is there any reference ? > >>>> > >>>> The DNS community in the IETF hates split DNS so much that > >>>> not much has been written about it. I did find these: > >>>> https://tools.ietf.org/html/rfc6950#section-4 > >>>> https://tools.ietf.org/html/rfc7157#section-6.3 > >>>> https://tools.ietf.org/html/draft-richardson-homenet-secret-gardens > >>> > >>> RFC1918 actually explains it succinctly without giving it a name. > >>> RFC4193 only tells you what you shouldn't do with DNS. How helpfull ;-) > >>> > >>> So, let me know if you think it's worth creating another stable-connectivity rev, > >>> i'd suggest to replace the "split-horizon" sentence with: > >>> > >>> Operators may therefore need to use a private DNS setup for the ACP ULA > >>> addresses. This is the same setup that would be necessary for using > >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, last > >>> paragraph. In [RFC6950] section 4, these setups are discussed in more detail. > >>> > >>> Cheers > >>> Toerless > >>> > >>>> Regards, > >>>> Brian > >>> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > > -- --- tte@cs.fau.de
- [Anima] WGLC on draft-ietf-anima-stable-connectiv… Sheng Jiang
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Brian E Carpenter
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Toerless Eckert
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Brian E Carpenter
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Brian E Carpenter
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Toerless Eckert
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Brian E Carpenter
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Michael Richardson
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Brian E Carpenter
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Toerless Eckert
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Toerless Eckert
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Brian E Carpenter
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Toerless Eckert
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Sheng Jiang
- Re: [Anima] WGLC on draft-ietf-anima-stable-conne… Michael H. Behringer