On 9/25/12 6:45 AM, Suresh Krishnan wrote:
a) whether there is WG consensus towards continuing working on MAP-T and
4rd as experimental documents.
b) whether there is WG consensus that MAP-E should be progressed to
working group last call IESG review before MAP-T and 4rd.**
Please state
On 8/24/12 9:52 PM, Mark Townsley wrote:
We cannot have a standards track protocol RFC coming out of softwires
for every manner in which a technology might show up in an RFP. This
simply does not scale.
+1
we need a procurement guidance document then how to use all of those :)
Cheers, Jan
On 8/8/12 12:02 AM, Suresh Krishnan wrote:
Hi all,
During the softwire WG meeting at IETF84 a series of questions* to
determine the preferred solution in the meeting room indicated that the
sense of the room was in favor of MAP-E as the basis for the proposed
standard stateless solution.
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
On 4/26/12 11:50 AM, Mark Townsley wrote:
Perhaps we would have been better off with the coin toss.
+1
bingo.
Cheers, Jan
P.S: I'll not waste more bits on this topic as it's apparently a waste
of bandwidth :)
P.P.S: Should we deprecate RFC6346?
On 4/10/12 10:01 AM, Fuyu (Eleven) wrote:
Hi Jan,
ISPs can't deploy MAP-E/T and use the two mechanism to transmit IPv4
traffic in their network at the same time. So I aggree with Gang that
MAP-E and MAP-T should be treated as separate solutions.
Dear Fuyu.
Please read my message again and
On 4/9/12 8:17 AM, Sheng Jiang wrote:
We would like to see both solution published. So that, operators can
choose according to their own networks and preference.
Disagree. This would hypothetically be nice for operators to have a
choice, but vendors (looks like) will not implement two
On 4/9/12 9:24 AM, Maoke wrote:
hi Yiu and others,
1. both published does surely conflict with the design goal of 4rd-U
itself:
unification of multiple standards. politically speaking, the 4rd-u
authors'
positition is now quite confusing.
2. operators surely need to choose IPv6
On 4/9/12 11:37 AM, Liubing (Leo) wrote:
On 4/9/12 8:17 AM, Sheng Jiang wrote:
...
Operators have their own brains. They may listen to vendors, but
they do think by themselves and make decisions by themselves.
Vendors would implement whatever the operators order.
...
+1 I believe most of the
On 4/4/12 3:22 AM, Tom Taylor wrote:
I have been advised privately by a couple of people that I erred in my
description of relative support for MAP vs. 4rd-U at the meeting.
Support for MAP was predominant, but not to the point of rough consensus.
I was startled at the meeting by how much
On 4/3/12 3:53 AM, Satoru Matsushima wrote:
FYI, choosing MAP doesn't mean that committing to a 'single'. But
choosing 4rd-u means that committing to a 'single'.
There're just transport variants, which are encapsulation,
translation and new one we've never seen before. Proponents of the
new one
Dear Softwires WG chairs.
For how long will you leave this useless cockfight go on instead of
steering the working group into a direction, that may enable us to
decide on something and chose the direction?
We are running in circles here and just amplificating the noise, coming
from certain
On 4/2/12 12:33 PM, Ole Trøan wrote:
the status quo; with no path forward just means that we'll
effectively kill A+P. I would certainly not recommend my product
managers to implement either of this given the risk. is there
consensus to abandon these efforts (which is basically what we do by
On 4/1/12 3:24 AM, Fuyu (Eleven) wrote:
Agree. I think we shouldn't drop other stateless solutions as:
draft-cui-softwire-b4-translated-ds-lite-05
draft-penno-softwire-sdnat-02
They are all belong to stateless scope and with the same network
architecture of IPv4 traffic across IPv6 access
On 3/20/12 12:38 AM, Alain Durand wrote:
Q1: Without pre-supposing which one will be selected, do you agree to
publish 1 of the 3 proposals on the Standard Track and publish the
other(s) as Informational if still asked to?
If the answer is NO, then the process stops and we will publish
On 10/16/11 10:53 AM, Masanobu Kawashima wrote:
Dear all,
I have submitted a draft regarding 464XLAT.
Dear Masanobu-san,
Another flavor of CGN? Is this really needed?
Cheers, Jan
___
Softwires mailing list
Softwires@ietf.org
On 8/19/11 4:17 AM, Satoru Matsushima wrote:
This way no address translation is needed, just ports needs to be
redirected to right ones.
It seems to me that no modification for any system call, correct?
AFAIK, Nejc insists some system call modification, bind(), etc.,
Yes, if CPE is doing
On 8/18/11 3:59 PM, GangChen wrote:
A+P is the same case if I understand correctly. NAT44 is one of three
fundamental functions in A+P architecture. Otherwise, it can’t connect
to legacy end-hosts.
Usually yes, but not necessary. PAT could also do the work, if you
connect behind CPE a host
On 8/16/11 5:03 PM, mohamed.boucad...@orange-ftgroup.com wrote:
2) An alternative structure has been proposed off-line by A. Durand:
discuss dynamic vs. static and stateful vs. dynamic. The analysis
would elaborate the pros and cons of each solution (static stateless,
static stateful, dynamic
On 7/29/11 11:41 AM, Rémi Després wrote:
Dear all,
Dave rightly expresses in the Softwire meeting the need to separate/clarify
discussion about:
- Stateless vs stateful
– Static vs dynamic port sets
Does this belong to softwires anymore? New WG maybe?
Cheers, Jan Zorz
On 7/30/11 3:38 PM, Satoru Matsushima wrote:
On 2011/07/30, at 8:26, Peng Wu wrote:
a) Stateful+Dynamic port sets: e.g. DS-Lite
b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06
c) Stateless + Static port set: e.g. 4rd, 4via6 translation
d) Stateless + Dynamic port set:
On 8/1/11 4:22 PM, Rémi Després wrote:
Le 1 août 2011 à 15:36, Rajiv Asati (rajiva) a écrit :
... Interesting enough, the static port-set is one of the reasons why many
find 4v6 being so useful.
Indeed: operation simplicity, scalability, possible direct CE-CE paths.
Very legitimate.
Let
On 8/1/11 1:07 PM, Satoru Matsushima wrote:
So my question is that how dynamic is dynamic, and how static is
static. The analogy of dynamic routing is that dynamic for updating
routing information for prefixes but forwarding plane is stateless.
If you imagine dynamic port ranges within
On 8/1/11 5:04 PM, Qiong wrote:
So, this is a problem about how to define appropriate port set for our
customers, or to define maximum concurrent subscribers for a given IPv4
address pool. Otherwise, there would either be a waste of resource, or
port exhaustion. Maybe we can even make some more
On 8/1/11 5:50 PM, Ole Troan wrote:
Jan Zorz @ go6.si wrote, on 08/01/2011 10:36 AM:
Well, is short words, whatever number of ports you assign in
port-set/range, end user can exhaust them.
The fact that most ISPs have been successfully operating with 65536
ports per subscriber demonstrates
On 3/1/11 8:58 PM, Daniel Roesen wrote:
If the chosen approach is DS-Lite, the ISP needs at some point in time
start to provision customers in a way to make sure they'll use DS-Lite
for IPv4 connectivity to conserve IPv4 addresses in a plannable manner.
plannable manner means specifically that
26 matches
Mail list logo
