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
