Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 18 September 2017 20:12 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 400321321A4 for <anima@ietfa.amsl.com>; Mon, 18 Sep 2017 13:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 JkQ6KPaFXxoB for <anima@ietfa.amsl.com>; Mon, 18 Sep 2017 13:12:00 -0700 (PDT)
Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 0FEF912421A for <anima@ietf.org>; Mon, 18 Sep 2017 13:12:00 -0700 (PDT)
Received: by mail-pg0-x22c.google.com with SMTP id m30so747743pgn.6 for <anima@ietf.org>; Mon, 18 Sep 2017 13:11:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uC0AyEVF6jKncpmxGH5/Ytpk28ef+95/MoVXjnRio3c=; b=KwTWmiyVH2/6hZXg2rX6PRvwjXFYdBOnnoqe+EDwCXVJFL1E1NVXMrz5NSBfBzSO10 y2KGW79l8mRMTymfpobB111FpQHGOBBEXgpmK1Gc5qB7tTMxyFvSLvx/d1RHZQyz+Zah sHKnzCaaap0hmnIKh4AfPiRbqu9Sajo3dgerYUtHn5VHuvQHN/GloTSl28W77uaEUcQq y3Yp/7ukRYlev/sFZG2N97trTo69ipZIK5N47q+VLBttUkr76dpSYy7/y6xMuTgsBQFt nEmZzpw34rsBl4TtfM4tvON7m5h+2vbOJDGykotAgTurCbbHh+YfgbOevgYEXDU40ka9 aQMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=uC0AyEVF6jKncpmxGH5/Ytpk28ef+95/MoVXjnRio3c=; b=gGQuJEIwMRQgd0G4O09AOLXbeOlIZHTd1ToKRHUxOswmJRUGMsfdZafZvgTIzBy0P5 JIw0Wn1dRnWsR+VcM+C2wV1zw03iXHCQTRx9m3LRRdDqAK3z7sPLibvSe3XA8FuffbH1 qOcgFGL4Lu49+VgrSiOxd7P6zdO42XI/GBvyquIzpuXnfq9o6TEBGN0iwtQHX8Ge9Laj G8EMjwmYiUsjerotTY+tk1IHRIYPKz1xBXK23CpFcrUShOqZ+ZmlqRYNaNWZCvVuV9HP o2LND5tJ0/09NyEalt8K8/gBEJz/669ZYvwYZWVl3yIoJfg+t7Q8ErP3dgMRdKkVy3fw QUgw==
X-Gm-Message-State: AHPjjUhNbfvDJmGj4SeTI0bteu0iSae5WK0gQu1DamsW2uSNghw3D4aj yrIDH+6//OStEIF/
X-Google-Smtp-Source: ADKCNb7giQedv99f2Br9WELVZerp3ejj74avDjpPlD2DTDMdoaph1jBmcsiu6zUTFHnfU8S2i+oAmQ==
X-Received: by 10.98.61.142 with SMTP id x14mr33440665pfj.258.1505765518559; Mon, 18 Sep 2017 13:11:58 -0700 (PDT)
Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v10sm237843pgf.8.2017.09.18.13.11.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 13:11:57 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>
Cc: Anima WG <anima@ietf.org>
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <761b1200-10ac-7dd1-267b-c0890c9cfd27@gmail.com>
Date: Tue, 19 Sep 2017 08:11:56 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170918053847.GA31832@faui40p.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/2cOFENH_LB7eiscF9sJ37hTB2Dg>
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: Mon, 18 Sep 2017 20:12:02 -0000

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
>