Re: [Anima] review comments draft-ietf-anima-stable-connectivity-03-rev Med.doc

Toerless Eckert <tte@cs.fau.de> Thu, 03 August 2017 01:14 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 0E8D2129B2A; Wed, 2 Aug 2017 18:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 3-EAKHrLArcH; Wed, 2 Aug 2017 18:14:07 -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 105CB128BC8; Wed, 2 Aug 2017 18:14:07 -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 30B5E58C4BC; Thu, 3 Aug 2017 03:14:03 +0200 (CEST)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 13F0BB0C792; Thu, 3 Aug 2017 03:14:02 +0200 (CEST)
Date: Thu, 3 Aug 2017 03:14:02 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: mohamed.boucadair@orange.com
Cc: "draft-ietf-anima-stable-connectivity@ietf.org" <draft-ietf-anima-stable-connectivity@ietf.org>, "anima@ietf.org" <anima@ietf.org>
Message-ID: <20170803011402.GB12136@faui40p.informatik.uni-erlangen.de>
References: <20170727185150.GZ3889@faui40p.informatik.uni-erlangen.de> <787AE7BB302AE849A7480A190F8B93300A014351@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A014351@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/u8rj8ljHGRI3S4QqhoDBoT7aN9U>
Subject: Re: [Anima] review comments draft-ietf-anima-stable-connectivity-03-rev Med.doc
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: Thu, 03 Aug 2017 01:14:09 -0000

On Fri, Jul 28, 2017 at 12:02:25PM +0000, mohamed.boucadair@orange.com wrote:
> Hi Toerless, 
> 
> The new version looks much more better. Thanks. 

Great.

> Some comments about these two minor point:
> 
> - "IPv4 to IPv6 NAT can be used." - Do you mean RFC7915
>   I intentionally did not want to elaborate on the details of which of the 15? different
>   NAT options can be used best. When i worked on this, i got a working setup with NAT-PT and i think
>   also NAT64 statefull (RFC6146). This was mostly driven by whatever old router OS versions
>   where available.Also your note re. rfc7757. The main issue is that the stateless translations would
>   require matching address structures in he ACP, and i certainly would not want to fudge the ACP design
>   to support NAT better. Rather use some horrific NAT option. That should even accelerate pushing IPv6
>   into NOC/OAM equipment. 
> 
>   So, i didn't add any pointers to those RFCs you mentioned. I think its good if this is
>   left as an exercise to the reader ;-)
> 
> Med: Fair. Please change "IPv4 to IPv6 NAT can be used" to "IPv4 to IPv6 translation can be used" because it is more than "Address" translation. 

Please check out the just posted -05. After Brian also complained about the use of NAT i
gave in (aka: both you and brians desire to get this redone where critical mass ;-)).

There should now be no use of "NAT" in the doc, instead SIIT and EAM and how we
would suggest to build a solution with them for ACP connect (aka: suggetions for
prefixes to be mapped via EAM), but that the details of the solution are out of scope.

> - "I'm afraid NoO " - i did not get that.
> 
> Med: This was related to this part of your text: 
> 
> ==
>    Overall, the use of NAT is especially subject to the RoI (Return of
>    Investment) considerations,  
> ========
> 
> The reasoning about NAT and RoI may seem to be intuitive, but I'm afraid it does not reflect the deployment reality. The use of NAT may even come for free or be a function of the traffic and so on.
> I would delete the mention of RoI. 

Well, i did not mean to imply that NAT/SIIT would be too expensive to deploy, i rather
wanted to be neutral because i too had a customer that said "i am happy to use NAT
when you give me a working recipe". Which i was able to do. But i also do not want
to promote this of course.

If you could suggest any better text to keep the balance, i'd happliy take it ;-)

Cheers
    Toerless

> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Toerless Eckert [mailto:tte@cs.fau.de]
> > Envoyé : jeudi 27 juillet 2017 20:52
> > À : BOUCADAIR Mohamed IMT/OLN
> > Cc : anima@ietf.org; draft-ietf-anima-stable-connectivity@ietf.org
> > Objet : Re: review comments draft-ietf-anima-stable-connectivity-03-rev
> > Med.doc
> > 
> > Thanks a lot, Mohamed for the thorough review!
> > 
> > I pushed -04 of the draft out with your changes incorporated. IMHO it's
> > all great textual improvements but no logical changes, aka: should be fine
> > for prior reviewers.
> > 
> > Diff:
> > 
> > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.o
> > rg/id/draft-ietf-anima-stable-connectivity-
> > 03.txt&url2=https://www.ietf.org/id/draft-ietf-anima-stable-connectivity-
> > 04.txt
> > 
> > Your original review doc:
> > 
> > https://github.com/anima-wg/autonomic-control-plane/blob/master/draft-
> > ietf-anima-stable-connectivity/03-review-mohamed.boucadair.doc
> > 
> > My reply comments:
> > 
> > https://github.com/anima-wg/autonomic-control-plane/blob/master/draft-
> > ietf-anima-stable-connectivity/03-review-mohamed.boucadair-reply.txt
> > 
> > While incorporating your review, i also figured that it would be good if
> > ACP connect
> > would allow auto-configuration of NMS hosts, so i added a paragraph to
> > mandate RFC4191,
> > but i didn't rev ACP draft just for that yet, so here's just diff on
> > github for that;
> > 
> > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.o
> > rg/id/draft-ietf-anima-autonomic-control-plane-
> > 08.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-
> > plane/af74117400b6a5a7fca1acf2ab910d64a580a5c9/draft-ietf-anima-autonomic-
> > control-plane/draft-ietf-anima-autonomic-control-plane.txt
> > 
> > Cheers
> >     Toerless
> > 
> > On Mon, Jul 24, 2017 at 05:49:07AM +0000, mohamed.boucadair@orange.com
> > wrote:
> > > Dear Toreless,
> > >
> > > I'm resending this document as I didn't receive an ACK from your side.
> > >
> > > Please consider those as part of the WGLC comments.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : BOUCADAIR Mohamed IMT/OLN
> > > > Envoyé : vendredi 7 juillet 2017 14:58
> > > > À : 'tte+ietf@cs.fau.de'
> > > > Objet : Envoi d?un message : draft-ietf-anima-stable-connectivity-03-
> > rev
> > > > Med.doc
> > > >
> > > > Dear Toreless,
> > > >
> > > > Please find some comments about this draft.
> > > >
> > > > Cheers,
> > > > Med
> > 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
tte@cs.fau.de