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

Yes that's a fair assessment.

I believe the current use of SHOULD for the transition technologies
allows flexibility to those with the aforementioned concerns that
would be OK with a limited sub-set, whilst still providing overall
guidance to those wishing for complete compliance.
Although does this also mean that it's possible for a CE to comply
with this draft, yet not implement any method under §5.3?

-Richard

On 17 April 2018 at 21:32, Fred Baker <fredbaker.ietf@gmail.com> wrote:
> 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?
>
>> 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
>>>
>