Hi Jan, Thanks to bring this point out. (sorry to re-send it to the wg)
What you described is exactly in draft-cui-softwire-b4- translated-ds-lite, a per-subscriber level solution which solved the requirements on: 1) NAT offloading from CGN to CPE 2) Flexibility on IPv6 address planning 3) IPv4/IPv6 decoupling 4) reduced logging 5) hub&spoke 6) support address sharing 7) very very very simple, clean and understandable Of course, it does not solve the mesh scenario. Best wishes On Fri, Jul 27, 2012 at 9:48 PM, Jan Zorz @ go6.si <[email protected]> wrote: > On 7/27/12 2:39 PM, Lee, Yiu wrote: > >> "The EA bits encode the CE specific IPv4 >> >> address and port information. The EA bits can contain a full or part >> of an IPv4 prefix or address, and in the shared IPv4 address case >> contains a Port-Set Identifier (PSID)." >> >> >> I prefer one solution vs. N solutions given that the one solution can >> logically solve all problems and doesn't cause confusion. Consider we >> agreed on including 1:1 MAP. When an operator deployed it, he had to ask >> if I want to share v4 addresses, should I put the v4 info in the EA or >> set EA=0 and provision PSID? It will create unnecessary confusion. >> Simply put I am not "calling out for a "remove that part of the spec & >> complicate it" case". My position is quite an opposite. I am calling out >> for "not adding confusion to complicate a spec". >> > > Hi, > > I'm just admiring how the WG (usual suspects) manages to talk about the > intention to simplify things and at the end everything ends up three times > more complex than at the beginning. > > In the RFC6346 we specified the architecture and the idea of A+P way of > sharing resources. The idea was simple, clean and understandable. > > Now even I don't understand completely A+P anymore and that's probably a > bad sign - and adding also a 4RD flavor with all the header hacks did not > help either. > > So, on 1:1 - Idea of having 1:1 is simply to be able to do gradual > deployment of A+P. In ideal world, ISP today would be able to buy from his > favorite vendor A+P solution, started sending out new CPEs that are A+P > capable/aware and connect them to PRR with full IP address assigned - so no > change for a user as for now. Operator would be also able to change the > CPE-base with sending new CPEs to old customers when they break. > > When operator starts getting short on IPv4 supplies, he simply introduces > address sharing and changes the customers communication behaviour with a > flick of the switch on services configuration page - or even better, > customer applies for sharing because less price of the deal or something > similar. In this case CPE gets port-restricted address next time it > reconnects. > > So, from operational point of view, it is very important that the switch > from 1:1 to sharing model is smooth, easy and a matter of one checkbox in > services webpage - and it should be done on per-customer granularity. > > That's it. Very simple. That was how the idea should work in ideal world. > > But we are not there. A+P was delayed for years because of some people > here - but finally even those people understood that this is the only > alternative to CGN rubbish, that is currently taking over the Internet > infrastructure. > > Please stop complicating things and fighting whose flavor is better or > who's ***** is longer and loosing time. > > We need solid standard asap and I really don't care whose name is on the > top of the RFC(s). > > Med correctly pointed to the skech in RFC6346 and I hope just options 1 > and 2 will be used in real world. > > Cheers, Jan > > P.S: Unfortunately I cannot make it to Vancouver, but I encourage you all > to go into that room, lock the door and don't leave it without a result and > a clear idea, how to move forward quickly. > > ______________________________**_________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/softwires<https://www.ietf.org/mailman/listinfo/softwires> > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * ===============================================
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
