Re: [Masque] Unifying CONNECT-IP Proposals

[Eric Kinnear <[e-mail]>]

> On Aug 27, 2021, at 12:52 PM, Tommy Pauly <[e-mail]> wrote:
> 
> Hi David,
> 
> While I appreciate the effort to show extensibility, I don’t think this is quite the right approach for what the core of CONNECT-IP would be, and how to frame collaboration on the different use cases.
> 
> Specifically, the proposed core document is still lacking a description of when the various capsules are needed, and I think it would be far simpler to say that the address assignment mode is something that is optional, rather than making extensions try to work around it. I’m also not convinced that these various use cases need to split up rather than having a more elegant and unified set of solutions.
> 
> As you mention, I’ve spoken a bit about this with the various authors and would be happy to help act as an editor to resolve these various directions. This needs to be a collaborative effort, and I think the protocol will be stronger for it.
> 
> Chairs, would you help set up a working interim call to work on how CONNECT-IP should be structured?

Thanks, Tommy! We’re working on enumerating the possible paths forward for the WG’s consideration. Stay tuned for an update.

Thanks,
Eric

> 
> Best,
> Tommy
> 
>> On Aug 27, 2021, at 8:04 AM, David Schinazi <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi MASQUE Enthusiasts,
>> 
>> As you know, we've had two distinct proposals for CONNECT-IP for a while. While
>> both of them have interesting features, we need to unify on a joint effort if
>> we want to make progress. In order to further that goal, we've made some edits
>> to the existing documents in order to create a unified coherent path forward.
>> 
>> First, we updated draft-ietf-masque-ip-proxy-reqs to reflect working group
>> consensus: since the WGLC showed consensus on everything except the
>> network-to-network use-case and the route negotiation requirement, both of
>> those were removed from the document. draft-ietf-masque-ip-proxy-reqs-03 [1]
>> now better reflects the working group's choice.
>> 
>> Based on these requirements, and on the WG consensus at IETF 110 to focus on
>> Proxying IP Packets, we also updated draft-cms-masque-connect-ip. We removed
>> all routing-related features and now draft-cms-masque-connect-ip-02 [2]
>> contains solely what is needed to satisfy the WG's requirements from
>> draft-ietf-masque-ip-proxy-reqs-03. We've had some interesting conversations
>> with Tommy Pauly on this topic and would love for him to join us as editor on
>> draft-cms-masque-connect-ip.
>> 
>> Additionally, the discussion at IETF 111 showed that folks were also interested
>> in various features that didn't have WG consensus: some are interested in
>> negotiating routing and some are interested in flow forwarding. We believe that
>> both of those are interesting features worth pursuing. The best way to
>> accomplish this is through extensions. Luckily CONNECT-IP is extensible.
>> 
>> We wrote up the routing negotiation as an extension in
>> draft-cms-masque-connect-ip-ext-routes [3]. This enables split-tunnel VPN and
>> the network-to-network use-case.
>> 
>> We also made sure that flow forwarding mode would work as an extension, and as
>> proof-of-concept wrote it up as draft-tbd-masque-connect-ip-ext-flow [4]. As
>> mentioned in that document, this is mostly copied from
>> draft-kuehlewind-masque-connect-ip-01 [5] with some minor modifications. We
>> would like to have the authors of draft-kuehlewind-masque-connect-ip author
>> this extension, given that they produced the interesting ideas in it.
>> 
>> We think this refactor would be a great path forward for the MASQUE working
>> group: it would allow us to unify multiple proposals around a common extensible
>> protocol. We did discuss merging these three documents into one, but decided
>> against it because it would unnecessarily delay the publication of CONNECT-IP.
>> We would love for the working group to adopt both extensions as they will
>> influence the design of CONNECT-IP, but both need to solve some specific hard
>> problems that don't need to delay CONNECT-IP, so they deserve their own drafts.
>> 
>> As usual, comments and thoughts are most welcome!
>> 
>> Thanks,
>> David
>> 
>> [1] https://datatracker.ietf.org/doc/html/draft-ietf-masque-ip-proxy-reqs-03 <https://datatracker.ietf.org/doc/html/draft-ietf-masque-ip-proxy-reqs-03>
>> [2] https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-02 <https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-02>
>> [3] https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-ext-routes-00 <https://datatracker.ietf.org/doc/html/draft-cms-masque-connect-ip-ext-routes-00>
>> [4] https://datatracker.ietf.org/doc/html/draft-tbd-masque-connect-ip-ext-flow-00 <https://datatracker.ietf.org/doc/html/draft-tbd-masque-connect-ip-ext-flow-00>
>> [5] https://datatracker.ietf.org/doc/html/draft-kuehlewind-masque-connect-ip-01 <https://datatracker.ietf.org/doc/html/draft-kuehlewind-masque-connect-ip-01>
>> -- 
>> Masque mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/masque
>