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

"Michael H. Behringer" <michael.h.behringer@gmail.com> Wed, 20 September 2017 07:17 UTC

Return-Path: <michael.h.behringer@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 A48EA1331F6 for <anima@ietfa.amsl.com>; Wed, 20 Sep 2017 00:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 i5NvvlvpZ6Yg for <anima@ietfa.amsl.com>; Wed, 20 Sep 2017 00:17:54 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 8DBC0133209 for <anima@ietf.org>; Wed, 20 Sep 2017 00:17:53 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id a137so3309829wma.0 for <anima@ietf.org>; Wed, 20 Sep 2017 00:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=jE6lgXnQe5j4VlC+j/WVHz4gvnEsPHiXCuzBv40r8UI=; b=QyQl3P9kw2m2m/nbkUaMWO0CH4/UzJEk//gd/FIo+f0conN+j6HTJyJGGfZJongzdT X5K0Mb8rik13ZuoUIHqbIcsy2JPpouS3cvOaok0+jKsh+CEPmH5lZW62hpTrPqPud/E0 jXBMHFVRz/NacUhq4bnkHzlN8vDfyf7ZQVmL7eFBjEhf+yjiXnqzsUr4E2cN3d7S6Ky8 4bw3F9pMgcXbD5OS6oIIfZObk9g8Nn483sNmfSjxya92TycOlc2ZpyWPemkyAKuDIwml djeSzqnPIHS9JF3aBe9JrBWhAu2fdUDBG+os3uskytlBJsypSXelj0RmPykbaNPDPeuo my5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jE6lgXnQe5j4VlC+j/WVHz4gvnEsPHiXCuzBv40r8UI=; b=eFJ+QD/LHXiqRv6PTZTu6RLGDW0mIzx6I2b7LeBLZC/9osdn81oLLHj3kT+eLowV2L e6wKgrDh62NRFlRTOiHsrrN03cDgVQQ3VF4g3rL5RnHy7QJ2/hAa0AZc+h1L7X3G+Waz 9tFQYFvLa+JLnvRol7m37etYydd9LSx3AtynZwyRlcoo5bNy27WH1Amf38nJG1v1T8PP aWqCNvu+31N90To6AW6nU1a5yj725UGsQUsz2gHacoGuhrSZbNVMYBbqKd3+/jSgZXd5 /RQ5IIQjqHNAF4f7y4S8Ual43eIJq84qVIjjs/6gou56gMyr8qcs9ynJLfYsfVa1bAHJ wZgw==
X-Gm-Message-State: AHPjjUhau71S45aRUJCWzRqAOMSUYcvk0LiibibXswC/BcKg28m6YvlI mIIz0hSpjUqhD1vHZHnqJJJncK6x
X-Google-Smtp-Source: AOwi7QCVfJVLbw/G6sS+F6hWmnyGf5IhnH1qXh8S1wEmWS324zlTpXnNwBZq6eaZQ+2/T9aueeybpA==
X-Received: by 10.28.97.11 with SMTP id v11mr3139744wmb.45.1505891871831; Wed, 20 Sep 2017 00:17:51 -0700 (PDT)
Received: from [192.168.1.25] (ANice-652-1-72-101.w86-205.abo.wanadoo.fr. [86.205.71.101]) by smtp.gmail.com with ESMTPSA id 109sm1104592wrc.25.2017.09.20.00.17.50 for <anima@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 00:17:50 -0700 (PDT)
From: "Michael H. Behringer" <michael.h.behringer@gmail.com>
X-Google-Original-From: "Michael H. Behringer" <Michael.H.Behringer@gmail.com>
To: "anima@ietf.org" <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> <761b1200-10ac-7dd1-267b-c0890c9cfd27@gmail.com> <20170919185323.GB10511@faui40p.informatik.uni-erlangen.de> <5D36713D8A4E7348A7E10DF7437A4B927CEC1508@NKGEML515-MBX.china.huawei.com>
Message-ID: <b8b9ea6d-c33d-3c4f-92f9-82696a5759fe@gmail.com>
Date: Wed, 20 Sep 2017 09:17:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CEC1508@NKGEML515-MBX.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/DttTk1TnLZUBN_RbKgqk98HDezc>
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: Wed, 20 Sep 2017 07:17:57 -0000

Hi Sheng,

I'm not aware of any IPR relating to this document.

Michael


On 20/09/17 02:54, Sheng Jiang wrote:
> Hi, Toerless,
>
> Thanks for your hard and fruitful work. Giving the change mount from -03 version, which is the base for the first WGLC, I feel another WGLC is needed. I will launch a short one-week WGLC on this. Meanwhile, I still not receive IPR disclosure from all authors. I would not be able to move this document forward with the proper IPR disclosures, even after the WGLC passed.
>
> Cheers,
>
> Sheng
>
>> -----Original Message-----
>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Toerless Eckert
>> Sent: Wednesday, September 20, 2017 2:53 AM
>> To: Brian E Carpenter
>> Cc: Anima WG
>> Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 -
>> Respond by July 28, 2017
>>
>> 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-garde
>>>>>>> ns
>>>>>> 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 mailing list
>> Anima@ietf.org
>> https://www.ietf.org/mailman/listinfo/anima
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima