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:[email protected]] 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 > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/anima > > > > > -- > --- > [email protected] > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
