Indeed, there is nothing here which says that this or that operator or body
needs to do or adopt something. It leaves the pro/con for the operator to
weigh, but to do that there must be some context. This draft thus
illustrates not only the issues attributable to A+P based solutions and
their impact, but also a likely impact to various system contexts formed by
standard/generic architectures. It happened to have been written with
operator input and in doing that we think it provides a useful picture (ie
how this stuff may actually be used in a system).


Regards,
Wojciech.


On 1 August 2011 18:37, Cameron Byrne <[email protected]> wrote:

> 2011/8/1 Rajiv Asati (rajiva) <[email protected]>:
> >> I appreciate that, and agree that the case for stateless A+P mapping is
> >> clearer for DSL and optical fibers than for 3GPP
> >
> > There are other 3GPP operators who favor using stateless A+P mapping, so
> I would shy away from the above agreement. Of course, different operators
> have different constraints that make them favor one or the other solution,
> as you rightly said.
> >
>
> Is it possible for those 3GPP operators to speak for themselves and
> not via a vendor?  If not, i understand. I always consider the source
> of information.
>
> I am looking to avoid an echo chamber where the IETF is doing
> something it thinks the 3GPP wants and therefore the 3GPP adopts
> something that it thinks the IETF wants.  Does that make sense?
>
> I would prefer that the draft drop reference to 3GPP since this is a
> generic solution, right?  It is not appropriated to try and
> sell/target this solution in the RFC to a particular market segment.
> There is no specific 3GPP engineering in this solution, so lets just
> say it is a generic solution.  Or, we can go a step further and call
> it NAT464, then people would intuitively know what it is.
>
> Cameron
>
>
>
> > Cheers,
> > Rajiv
> >
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]] On
> Behalf
> >> Of Rémi Després
> >> Sent: Monday, August 01, 2011 11:25 AM
> >> To: Cameron Byrne
> >> Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec)
> >> Subject: Re: [Softwires] 3gpp related comments on
> draft-dec-stateless-4v6-02
> >>
> >> Cameron,
> >>
> >> Thanks for the clarification.
> >> More below.
> >>
> >>
> >>
> >> Le 1 août 2011 à 16:33, Cameron Byrne a écrit :
> >> ...
> >>
> >>       > Some providers may indeed prefer to have only a stateless
> solution,
> >> especially in for DSL networks where ISP's provide CPE's, but there is
> no
> >> technical reason preventing both solutions to coexist
> >>
> >> ...
> >>
> >>
> >>       Many, if not most, 3gpp users get rfc1918 or bogon public
> addresses
> >> today.  Giving my users public addresses using 4v6 stateless probably
> does not
> >> make sense for me or many similar mobile operators. ... there are not
> enough
> >> public address to give these users (growth through 2015) each 2000
> ports.
> >>
> >> I don't se a significant disagreement here.
> >>
> >> If you have an overwhelming need for dynamic port sharing, it has to be
> faced,
> >> and you will go for CGN's. I don't argue against this.
> >>
> >> Some other operators may however have different constraints, and should
> be
> >> permitted to operate whatever simpler solution applies to their case.
> >>
> >> Note that one can expect that in 2015 users should work mostly, if not
> >> exclusively in IPv6, so that their need should be well well below 2000
> IPv4
> >> ports for each.
> >>
> >>
> >>       This is just a 3gpp data point, since the draft chooses to include
> 3gpp
> >> as motivation.
> >>
> >> I appreciate that, and agree that the case for stateless A+P mapping is
> >> clearer for DSL and optical fibers than for 3GPP
> >>
> >>
> >> Regards,
> >> RD
> >>
> >>
> >
> >
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to