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

"Michael H. Behringer" <> Wed, 20 September 2017 07:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A48EA1331F6 for <>; Wed, 20 Sep 2017 00:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i5NvvlvpZ6Yg for <>; Wed, 20 Sep 2017 00:17:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DBC0133209 for <>; Wed, 20 Sep 2017 00:17:53 -0700 (PDT)
Received: by with SMTP id a137so3309829wma.0 for <>; Wed, 20 Sep 2017 00:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id v11mr3139744wmb.45.1505891871831; Wed, 20 Sep 2017 00:17:51 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id 109sm1104592wrc.25.2017. for <> (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" <>
X-Google-Original-From: "Michael H. Behringer" <>
To: "" <>
References: <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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 [] 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:
>>>> ....
>>>> /
>>>> 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:
>>>>>>> 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 mailing list
> _______________________________________________
> Anima mailing list