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

[Erik Kline <[e-mail]>]

And AT&T has a very large 6rd deployment, so I wouldn't be surprised to see
push back from them on downgrading 6rd to MAY (though perhaps they don't
much care, idk).

It's hard to see how this discussion won't just degrade into "my deployment
technology should be SHOULD or even MUST, everyone else can be MAY".

On 21 February 2017 at 18:32, Nathalie Trenaman <[e-mail]> wrote:

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