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-gardens
> >>>
> >>> 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
