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> De la part de Tommy
> Pauly
> Envoyé : mardi 25 juillet 2023 23:34
> À : Marc Blanchet <marc.blanc...@viagenie.ca>
> Cc : int-area@ietf.org; 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> 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.
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to