Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

[Nathalie Trenaman <[e-mail]>]

Hi Jordi,

<snip>

> 
> 
> So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as SHOULD.

While I agree with most things listed below, and I also agree with your points changing 6rd to “MAY”, I don’t agree on changing DS-LITE to “MAY”. I would leave it with “SHOULD”. 
Some really large residential deployments chose for DS-LITE a while ago, (before MAP was standardised) and won’t change their plans soon. They already purchased the CGNAT equipment, etc. Their IPv6 deployment takes years….(from what I hear in all the IPv6 courses)
So, DS-LITE is a “SHOULD”, not (yet) a “MAY” but also not a “MUST”

Just my 2 cents. 

Nathalie


> 
> In my version:
> 
> 1) Considering that there’re no more IPv4 addresses and according to my experience with service providers, they will prefer to avoid dual stack in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE need to be changed to MAY.
> 
> 2) At the same time, I’ve included lw4o6, also with MAY. The rationale for this: Many service providers try to avoid the CGN, and lw4o6 is a way to do so, without increasing the cost of the CE. Basically, a CE that supports a regular IPv4 NAT+DS-Lite, is already capable of supporting lw4o6. The cost in terms of CE flash memory for DS-Lite is about 1Kb. The open source package available for DS-Lite that I’ve been digging-in takes 6Kb, but already includes also support for both MAP versions.
> 
> 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those protocols are the 3 alternatives that a service provider has to deploy IPv6-only WAN, but at the same time provide dual-stack in the LANs, with practically the same functionalities or even more, that what CGN requires. At the service provider network, it requires, instead of CGN, a stateful NAT64 (which cellular providers are already using) or a Border Relay (for MAP). Basically, a CE needs only 3Kbytes of code in the flash to support CLAT (the CE part of 464XLAT). The support for MAP (both versions and also lw6o4), requires about 6Kb.
> 
> 4) Include support for 6in4 as SHOULD. The rational for this: According to my experience, sometimes, business customers (specially SMEs) are in the same access network as residential ones, but they are provisioned manually and often require dual-stack with public IPv4 addresses, because they have to publish external services such as VPNs, or others that may not yet rely in an IPv6-only network. I’ve seen cases of service providers with 10.000 customers and 250 of those “SMEs”, and all them are provisioned manually because don’t make sense to find an automatic configuration. So, I think we must keep this support, with typically is already available in any dual-stack router today. In fact, if the router supports 6to4 or 6rd, the 6in4 support is already there. In terms of flash utilization, 6in4 requires 1Kb, 6rd 2Kb and 6to4 1Kb.
> 
> Note than I’ve been looking for the “cost” of the flash memory into open source available as GPLv2, which also means that the impact for any vendor in “updating” available firmware of actual CEs is minimal, if any, and is more an “integration” cost, probably a very few hours+testing. In fact, there are a few vendors that have it already (unfortunately very few) and I heard about some that offered it to “special big customers”, but not offered to the “general market”.
> 
> I’ve been evaluating myself, with trial customer deployments, using open-source such as OpenWRT/LEDE, the cost/functionally of those transition mechanisms and they just work. Typical CE today have a minimum of 8MB (market moving quickly to 16 or 32 MB) flash memory and 32MB (market moving quickly to 64GB and much more) RAM, and they hold perfectly all those features without any issue and without needed to take out other code.
> 
> So, the questions for the WG:
> 
> Do you agree with my changes 1, 2, 3 and 4 above?
> 
> Now a more complex question. Do you think it will be acceptable for 3 and may be 4 above, to be a MUST instead of just SHOULD?
> 
> I think vendors need a very strong signal here, otherwise, many of them (and this is happening), are reading actual 7084 and only reacting to implement those transition technologies with specific firmware versions for “very big” customers which will buy several hundred thousand units in one shot. But many small and medium service providers, buy only a few units every week when they connect new customers. This was discussed already in this list a couple of months ago.
> 
> https://www.ietf.org/mail-archive/web/v6ops/current/msg25152.html
> 
> Please, note that that this document version doesn’t include yet the details of the requirements for each transition mechanism. I’m working on those already, but will be nice to have some inputs from the WG, regarding my questions above.
> 
> Regards,
> Jordi
> 
> 
> -----Mensaje original-----
> De: <[e-mail]>
> Responder a: <[e-mail]>
> Fecha: lunes, 20 de febrero de 2017, 23:37
> Para: Jordi Palet <[e-mail]>, Jordi Palet Martinez <[e-mail]>
> Asunto: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt
> 
> 
>    A new version of I-D, draft-palet-v6ops-rfc7084-bis-00.txt
>    has been successfully submitted by Jordi Palet Martinez and posted to the
>    IETF repository.
> 
>    Name:		draft-palet-v6ops-rfc7084-bis
>    Revision:	00
>    Title:		Basic Requirements for IPv6 Customer Edge Routers
>    Document date:	2017-02-20
>    Group:		Individual Submission
>    Pages:		22
>    URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops-rfc7084-bis-00.txt
>    Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-rfc7084-bis/
>    Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-rfc7084-bis-00
> 
> 
>    Abstract:
>       This document specifies requirements for an IPv6 Customer Edge (CE)
>       router.  Specifically, the current version of this document focuses
>       on the basic provisioning of an IPv6 CE router and the provisioning
>       of IPv6 hosts attached to it.  The document also covers several
>       transition technologies, as required in a world where IPv4 addresses
>       are no longer available, so hosts in the customer LANs with IPv4-only
>       or IPv6-only applications or devices, requiring to communicate with
>       IPv4-only services at the Internet, are able to do so.  The document
>       obsoletes RFC 7084.
> 
> 
> 
> 
>    Please note that it may take a couple of minutes from the time of submission
>    until the htmlized version and diff are available at tools.ietf.org.
> 
>    The IETF Secretariat
> 
> 
> 
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops