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

[Fred Baker <[e-mail]>]

> On Apr 17, 2018, at 1:58 PM, Richard Patterson <[e-mail]> wrote:
> 
> 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

You're correct. There is more than one way people use "SHOULD"; "MUST" is a lot like its dictionary definition. I use "SHOULD" to mean "I'd like to say 'MUST', but I think there is a case in which the implementer might legitimately choose not to", which is pretty much what the RFC says. What an implementer often does, though, is decide that "SHOULD" makes something optional, and does only what MUST be done.

That said, this kind of RFC is commenting on market requirements. In the final analysis, each company or implementer has to determine what market they are trying to address, and what its requirements are; they are going to read this document, but it's one of many inputs they will consider. If they are designing a product for the MAP-T market, they're going to do what 5.3 says. If they are designing for ONLY the MAP-E market (which basically differs from MAP-T in a subroutine call), they could probably convince themselves to leave MAP-T out entirely. I tend to think the document should be very explicit about claims of compliance to it - something like "if an implementation claims compliance with this document, it must implement every MUST, and either implement every SHOULD or say which ones it does not implement, and why." "That feature is in the next release, assuming of course someone offers to pay for its development" is a common dodge from vendors, and needs to be explicitly not OK.

Of course, you've never heard a vendor say that. Neither have I. But I have heard rumors...

> On 17 April 2018 at 21:32, Fred Baker <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> 
>>