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

Sheng Jiang <jiangsheng@huawei.com> Wed, 20 September 2017 00:54 UTC

Return-Path: <jiangsheng@huawei.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 21A6F133061 for <anima@ietfa.amsl.com>; Tue, 19 Sep 2017 17:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 20yVDFAmgR0G for <anima@ietfa.amsl.com>; Tue, 19 Sep 2017 17:54:16 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0006F133023 for <anima@ietf.org>; Tue, 19 Sep 2017 17:54:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DVV13873; Wed, 20 Sep 2017 00:54:13 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 20 Sep 2017 01:54:11 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Wed, 20 Sep 2017 08:54:08 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: Toerless Eckert <tte@cs.fau.de>, Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: Anima WG <anima@ietf.org>
Thread-Topic: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017
Thread-Index: AQHTLZ8aSjvwEciiX0y/fMRrjnoBG6K0eqqAgAUkyACAAPPzAIABfGOAgADh09A=
Date: Wed, 20 Sep 2017 00:54:07 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CEC1508@NKGEML515-MBX.china.huawei.com>
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>
In-Reply-To: <20170919185323.GB10511@faui40p.informatik.uni-erlangen.de>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.185.119]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59C1BC36.0050, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 808a86cbdd82031337151673a36ba796
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/1208qD5-uZFuTJ8BvHbPMNojUIY>
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 00:54:19 -0000

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