Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

> Let me ask an additional question. We have had at least one operator speak
> against adoption of this draft as a working group draft, because she doesn't
> want to add requirements to customer-edge (CE) routers, which potentially
> make them more complex and therefore expensive (every line of code costs
> something and has some probability of containing a bug or attack). It sounds
> like you would support adoption of the draft if it contains the right set of
> features and doesn't contain anything else, and if (as it is currently written)
> that it would be implemented in addition to RFC 7084. "The right set of
> features", from your perspective, includes MAP-T.
> 
> Is that a correct deduction?

Coming back from vacation and finally responding...

I support adoption of this draft by the WG. 
I believe it will be useful to many operators in driving CE router feature implementation that is needed by several operators today. Operators implementing dual stack today will be glad this document exists when they get ready to shut down IPv4, and I think it's better for them that the document exists sooner rather than later.

But that doesn't mean I believe the draft has exactly the right set of features included. My understanding of "adoption" is that it is still possible post-adoption to discuss whether specific features / requirements do or don't belong. If the precise set of features and requirements must be agreed upon prior to adoption, then I would not be in support of adoption. Hopefully we aren't setting the bar that high?

Here are some items I'd like to discuss (hopefully post-adoption and not as a pre-condition to adoption):
 - Each mechanism included needs to be carefully considered whether it is in or out. Is there significant (multiple providers) deployment support (not just lab trials) for each and every one of the mechanisms listed? [I think the current list looks pretty good, and see support expressed for most of these, but still believe we need additional discussion.]
 - Positioning against RFC7084. Should we bring DS-Lite into this document so there is one place to see all transition technology requirements? What to say about 6rd (I saw other comments on this)? Does this really update RFC7084? Or is it simply a nice companion to it?
 - IPv4 Multicast Support. Most retail routers do a pretty bad job of dealing with IPv4 multicast (especially wrt IPTV) without tunneling it over IPv6. I disagree that we should be encouraging all CE routers to support tunneling of IPv4 multicast over IPv6, when they often don't get native IPv4 multicast right.

So as long as we can still discuss these items post-adoption, I support adoption.
Barbara

> > On Apr 17, 2018, at 12:20 PM, Richard Patterson <richard@helix.net.nz>
> wrote:
> >
> > Hi Fred, et al.
> >
> > Speaking as an Operator who is currently validating MAP-T as a
> > solution, I'm in favour of making sure it itself is included in future
> > versions of this draft.
> >
> > There are multiple vendors offering MAP-T Border Relays, and we've
> > been testing both OpenWRT-based CPEs as well as a custom CPE based on
> > the Broadcom BCM63138 SoC.
> > The Broadcom reference SDK comes with the CERNET kernel module and
> > userland tool, and supports hardware acceleration of MAP-T translated
> > flows with Broadcom's Runner fastpath.
> >
> > I was also quite impressed with OpenWRT's implementation; aside from
> > initially needing internet connectivity to install the map-t module
> > after a fresh install, no further configuration is required to have
> > the CPE dynamically configure itself with MAP-T, given the appropriate
> > DHCPv6 options.  Kudos to the OpenWRT/LEDE devs on their support.
> >
> > Re: the draft's §5.3.4.  It's succinct enough, whilst still directing
> > implementors to the relevant RFCs, however I'm still mulling over the
> > NAT44 and iptables/netfilter concerns that I raised in softwires a few
> > months back.[1]   The address-sharing mode's algorithm for port
> > allocations, isn't easily implementable with the current
> > iptables/netfilter behaviour.  OpenWRT's approach creates rule
> > shadowing and port ranges that never get utilised.
> >
> > -Richard
> >
> >
> > [1]
> > https://www.ietf.org/mail-archive/web/softwires/current/msg06832.html
> >
> > On 15 April 2018 at 06:00, Fred Baker <fredbaker.ietf@gmail.com> wrote:
> >> At IETF 101, Jordi Palet Martinez presented draft-palet-v6ops-transition-
> ipv4aas. The draft is at https://tools.ietf.org/html/draft-palet-v6ops-
> transition-ipv4aas, and his presentation deck is at
> https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-
> transition-requirements-for-ipv6-ce-routers-to-support-ipv4-as-a-service-
> 00.
> >>
> >> I would like to invite discussion.
> >>
> >> In particular, this draft derives from draft-ietf-v6ops-rfc7084-bis, and the
> chairs wonder if it should be reposted as the next version of draft-ietf-v6ops-
> rfc7084-bis. That should happen if an only if the working group thinks it
> should be published as an RFC (now or at some point) adding considerations
> for implementors of RFC 7084 and also implementing transition services.
> >>
> >> A key comment at IETF 101 was that there remain far too many transition
> mechanisms listed. It would be helpful, if you hold that opinion, if you could
> give that advice, identify the mechanism or mechanisms you think should be
> listed, and indicate the reasoning behind your viewpoint. For example, if you
> think MAP-T should be listed, it would be helpful to know what operators are
> implementing MAP-T and are looking for CE Routers that support it. The
> same comment applies to any such mechanism or service.
> >>
> >>
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >>