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