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

["Michael H. Behringer" <[e-mail]>]

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