I agree with Tommy here. If network advertised proxies can be used in multiple kinds of networks it makes sense to have a common discovery method.
IPv6 RAs are extensively used in 3GPP networks and have a broader applicability than PCOs, so it does seem like a good fit. BR Marcus From: Int-area <int-area-boun...@ietf.org> On Behalf Of mohamed.boucad...@orange.com Sent: Wednesday, 26 July 2023 18:53 To: Tommy Pauly <tpa...@apple.com> Cc: int-area@ietf.org; mas...@ietf.org Subject: Re: [Int-area] [Masque] draft-pauly-intarea-proxy-config-pvd Re-, Not sure why using PvD would be “cleaner” vs. what they are doing with PCO IEs. There are plenty proxies that are enabled in cellular networks and being discovered by UEs already (CSCFs, etc.). Cheers, Med De : Tommy Pauly <tpa...@apple.com<mailto:tpa...@apple.com>> Envoyé : mercredi 26 juillet 2023 09:17 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc : Marc Blanchet <marc.blanc...@viagenie.ca<mailto:marc.blanc...@viagenie.ca>>; int-area@ietf.org<mailto:int-area@ietf.org>; mas...@ietf.org<mailto:mas...@ietf.org> Objet : Re: [Int-area] [Masque] draft-pauly-intarea-proxy-config-pvd Indeed, I don’t think 8801 is currently deployed by the carriers, but the target of this document is to have a standard, cross-network way to bootstrap the discovery of these proxies. Using IPv6 RAs and related information to advertise proxies would allow 3GPP to provide this as a clean discovery option, and one that will work on any network attachment as well. This makes the incentive for clients to adopt higher since it will work across all networks. Tommy On Jul 26, 2023, at 7:48 AM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Tommy, - ... on cellular carrier networks, which is one of the main deployment targets here. Unless I'm mistaken 8801 is not required/supported in 3GPP specs. Typically, PCO IEs are used there. FWIW, the network already provides the following to a UE (excerpt from 23501): == (0-RTT Converter) iii) The network shall send MPTCP proxy information to UE, i.e. the IP address, a port number and the type of the MPTCP proxy. The following type of MPTCP proxy shall be supported in this release: - Type 1: Transport Converter, as defined in IETF RFC 8803 [82]. The MPTCP proxy information is retrieved by the SMF from the UPF during N4 session establishment. The UE shall support the client extensions specified in IETF RFC 8803 [82]. == And == (MPQUIC Proxy) The network shall send MPQUIC proxy information to UE, i.e. one IP address of UPF, one UDP port number and the proxy type (e.g. "connect-udp"). This information is used by the UE for establishing multipath QUIC connections with the UPF, which implements the MPQUIC Proxy functionality. = Cheers, Med -----Message d'origine----- De : Int-area <int-area-boun...@ietf.org<mailto:int-area-boun...@ietf.org>> De la part de Tommy Pauly Envoyé : mardi 25 juillet 2023 23:34 À : Marc Blanchet <marc.blanc...@viagenie.ca<mailto:marc.blanc...@viagenie.ca>> Cc : int-area@ietf.org<mailto:int-area@ietf.org>; mas...@ietf.org<mailto:mas...@ietf.org> Objet : Re: [Int-area] [Masque] draft-pauly-intarea-proxy-config- pvd Hi Marc, To start — I have no objection to there being some mechanism to discover a proxy using dns-sd / bonjour! If someone has a good use case for that, that certainly is a possibility. I do think it would be a different use case than the one for this network-provided proxy provisioning, however. A couple salient points to consider: - While the local router may be able to point you to the appropriate proxies to use, the proxies themselves are likely not on the local link or multicast area. Instead, they would likely be some infrastructure associated with the network operator, deeper in the network. - A dns-sd solution would allow many parties to advertise such capabilities on the network. The case we’re concerned with here is knowing the one that comes from a network operator, not other peers. - While I can’t rule it out categorically, I’m not aware of many cases where we’d be able to use multicast dns-sd on cellular carrier networks, which is one of the main deployment targets here. Thanks, Tommy On Jul 25, 2023, at 3:57 PM, Marc Blanchet <marc.blanc...@viagenie.ca<mailto:marc.blanc...@viagenie.ca>> wrote: Hello, Saw your presentation yesterday at masque and now read your draft. Fine by the overall approach, but I was wondering if you have considered to use DNS-SD (aka Bonjour)? I could see a proxy on the local network advertising its proxy service and the client « finding » the proxy by the DNS-SD/Bonjour mechanism. Seems straightforward to me. Also enables multiple proxies to « offer » their service, so redundancy right out of the box. In other words, I’m looking at this as a service discovery not provisioning. I am surely missing something? Regards, Marc. -- ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
