scenario. Because the
TUNNEL-MIB defined the objects on the view of interface, the DS-Lite-MIB need defined the
tunnel objects to extend the NAT binding entry by interface for accordance.
Best Regards
Yu
-Original Message-
From: Tom Taylor [mailto:tom.taylor.s...@gmail.com]
Sent: Monday
.
Thanks
BR
Yu
-Original Message-
From: Softwires [mailto:softwires-boun...@ietf.org] On Behalf Of Tom Taylor
Sent: Friday, February 06, 2015 5:34 AM
To: Yong Cui; softwires@ietf.org
Subject: Re: [Softwires] WGLC for draft-ietf-softwire-dslite-mib-07
I finally got around to looking
coordination between the two drafts is clearly required.
Tom Taylor
On 21/01/2015 7:05 AM, Yong Cui wrote:
Hi folks,
This message starts a two week softwire working group last call on
advancing the draft of DS-Lite MIB as a Standards Track RFC.
After we had the first wglc on draft-ietf-softwire-dslite
will
see a minor update shortly, and there is a bit more work to be done on
the natv2 draft. We would love to have comments on that one.
In any event, I see an action on myself to look over the Softwire MIB
documents.
Tom Taylor
On 22/01/2015 1:57 AM, Tina TSOU wrote:
Dear Sheng et al,
Below
As a WG participant aware of the history of this whole effort, I would
support adding the statement to MAP-T in particular.
Tom Taylor
On 15/11/2014 11:45 PM, Ole Troan wrote:
Remi,
It is true that double translation has the problem that the DF bit is not
communicated through
I'd replace Warning with the more conventional Note. I would also
drop the last sentence on grounds of redundancy. This is NOT a big issue
as I understand from my reading of various lists, because no one expects
RFC 4821 discovery to work anyway.
Tom Taylor
On 16/11/2014 11:55 AM, Rémi
DIME. From there I've suggested they create a Softwires
mapping document describing the mapping from the Diameter attributes to
DHCP.
Tom Taylor
On 02/09/2014 5:37 AM, meng.w...@zte.com.cn wrote:
Hi Softwirers，
There are some softwire technologies already in the WG, and generally,
there also
We would like to draw your attention to this draft. It is still awaiting
blessing from the DIME WG (which has reviewed previous versions), but I
think the content is firming up and should be reviewed by Softwires.
Tom Taylor
Original Message
Subject: New Version
DHCPv4 over DHCPv6.
So if a CE changes the binding IPv6 address in the context of normal DHCPv6
operation, it has a chance to update the information to the DHCP server.
Best Regards,
Qi
On Jul 2, 2014, at 10:46 AM, Tom Taylor tom.taylor.s...@gmail.com wrote:
Suppose a CE changes the IPv6 address
(such as the DHCPv6 lease expiring), the lwB4's
dynamic provisioning process must be re-initiated.
Cheers,
Ian
On 02/07/2014 04:46, Tom Taylor tom.taylor.s...@gmail.com wrote:
Suppose a CE changes the IPv6 address it uses for tunnel endpoint
subsequent to the initial establishment of the tunnel. What would
Suppose a CE changes the IPv6 address it uses for tunnel endpoint
subsequent to the initial establishment of the tunnel. What would the
message flow be between the CE and the DHCP server(s) to update the latter?
Tom Taylor
On 01/07/2014 7:28 AM, Qi Sun wrote:
Dear all,
We have submitted
OK with me.
Nits: Section 11 would normally be entitled Contributors. Within that
section, you have Alex Clauberg. s/Alex/Axel/
Tom Taylor
On 05/06/2014 12:37 AM, Suresh Krishnan wrote:
Hi all (specifically people in the To: list),
Since you were involved in the discussion on this topic
Not sure how you read that, but it can be fixed by putting a comma after
SHOULD be 0 and replacing to allocate with thus allocating.
Tom
On 02/06/2014 12:14 PM, Wojciech Dec wrote:
Uhm, this appears to mean that the RECOMMENDED a-bits SHOULD be 6.
On 26 May 2014 13:24, Ian Farrer
be questioned. The
latter is not a regular normative term, and arguably if the recommendation
is for excluding 0-1024 then a=6 looks like the SHOULD. If anyone wants the
full port set, then a=0 would be an obvious consequence.
On 2 June 2014 19:50, Tom Taylor tom.taylor.s...@gmail.com wrote:
Not sure how
Looks good to me.
Tom
On 26/05/2014 7:24 AM, Ian Farrer wrote:
Hi,
This one slipped my mind….
From a discussion with Ole during the MAP dhcp last call, there was a
discussion about the exclusion of provisioning WKPs to CPEs -
that there is a 1-1 correspondence
between the BMRs and the provisioned End-user IPv6 prefixes.
Is my understanding correct?
Tom Taylor
On 07/04/2014 12:37 AM, Suresh Krishnan wrote:
Hi all,
This message starts a two week softwire working group last call on
advancing the draft about the DHCPv6 Options
On 23/04/2014 9:47 AM, Ole Troan wrote:
Ian,
thanks!
[ian] Couple of changes to 4.5:
Old:
The Port Parameters Option specifies optional Rule Port Parameters
that MAY be provided as part of the Mapping Rule for CEs using the
MAP algorithm.
New:
The Port Parameters Option specifies
On 07/03/2014 3:04 AM, Wojciech Dec wrote:
On 6 March 2014 21:06, Lee, Yiu yiu_...@cable.comcast.com wrote:
In the current text, there is no comparison term such as “more optimizing”
or “reducing”. These terms are used to comparing two solutions. I echo
Qiong and Qi in their replies: this is
On 07/03/2014 6:11 AM, Qiong wrote:
Hi Tom,
I think this document would be helpful for operators to understand
different solutions. Just two quick questions:
1) As now the outline is a little similar to the deployment drafts of
different solutions, are you going to give step-by-step guidance
more techniques and do planning /
management considerations, but I believe I can assist you.
Edwin Cordeiro
Em 06/03/14 17:36, Tom Taylor escreveu:
Comments and additions are invited. If there is no enthusiasm for the
project I'll drop the subject.
Scope
-
This would cover the various
Unified CPE. I thought
we had determined during DHCP discussions that MAP-E and LW4o6 are too
different to unify very much.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
When in doubt, take it out.
I'll propose methodology for another draft comparing the various
approaches in a separate E-mail message.
On 06/03/2014 1:27 PM, Wojciech Dec wrote:
On 6 March 2014 15:41, Lee, Yiu yiu_...@cable.comcast.com wrote:
I still have problem to include text to compare
in number of subscribers
- growth in traffic
Fault Management
- resilience to network failures
- traceability of subscriber issues
Network Attachment
Data Plane Issues
- fragmentation
- multicast
- check sums
QoS
- delay
- jitter
Tom Taylor
I'd be willing to tackle an initial version as an intellectual exercise.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
this is a political rather than a technical point, but one could
sort of reverse the claim and suggest that if 1:1 mode is desired, LW4o6
is the better way to go.
Tom Taylor
On 25/02/2014 5:12 AM, Wojciech Dec wrote:
Hi Qi,
your answers didn't answer the majority of the concerns raised. And some
of those
of
the paragraph.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
On 21/11/2013 8:54 PM, Tom Taylor wrote:
The text describing client validation of OPTION_S46_PORTPARAMS in the
second-last paragraph of Section 4.5 currently reads as follows:
When receiving the Port Parameters option with an explicit PSID, the
client MUST use this explicit PSID
Berlin minutes and the odd bit of list discussion since.
Tom Taylor
(1) DHCP Provisioning of IPv4 Options
The conclusion out of Berlin is that the best general solution to
provisioning of IPv4 and transition-specific options is to use DHCPv4
over DHCPv6
The results on the relationship of offset 'a' to sharing ratio are shown
in the latest version of
draft-tsou-softwire-port-set-algorithms-analysis beginning with the
notes to Table 3 in Section 3.2.4 and continuing in Section 4. (BTW, the
title of Table 3 is wrong due to a cut-and-paste
. Others
may also be confused.
-- Is there a more usual notation for a binary value x, instead of
bin(x)?
I'll read the rest of the document, so there may be more comments, but
this is a start.
Tom Taylor
___
Softwires mailing list
Softwires
Looks like we had a misunderstanding. Did the authors think of the
configured subnetwork identifier of the existing text as being
configured for a particular rule, in effect another rule parameter? I
took it to be configured as a single value used in conjunction with all
FMRs to calculate the
OK, how about this for the complete paragraph:
By default, the MAP subnetwork identifier is the first subnetwork
within the End-user IPv6 prefix (all bits set to zero). An alternative
subnetwork value MAY be configured. All nodes within a MAP domain MUST
be configured to use the same value
On 09/04/2013 3:14 PM, Ole Troan wrote:
Tom,
...
I think that captures the intent. However, I see a possible difficulty:
differing lengths of the End-user IPv6 prefix for different CEs. We have to add
two conditions:
-- the configured subnetwork identifier is at least
64 -
In the previous note, I meant the BMR used as FMR, to be technical. But
here's another point from the same section:
The length of r MAY be zero, in which case the complete IPv4 address
or prefix is encoded in the EA bits. If only a part of the IPv4
address/prefix is encoded in the EA
Support.
On 26/03/2013 12:27 AM, Suresh Krishnan wrote:
Hi all,
This message starts a two week softwire working group last call on
advancing the draft defining the DHCPv6 Option for IPv4-Embedded
Multicast and Unicast IPv6 Prefixes as a Standards Track RFC. The
authors believe that this
of a particular prefix from a
particular option is indicated by a prefix length of zero. If so, should
that be mentioned somewhere in section 3, or is it covered by standard
DHCP practice?
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https
The meeting minutes record a disagreement over what port mapping
algorithm to use. This affects both MAP-E and LW 4over6. As I understand it:
- either of these two technologies will work with either contiguous
ports or ports scattered according to the GMA algorithm
- the real objection to
Support.
On 19/03/2013 1:13 PM, Suresh Krishnan wrote:
Hi all,
This draft was presented during the softwire WG meeting at IETF86 and
a subsequent poll of the room indicated that there was strong support
for adopting this draft as a WG document.
This call is being initiated to confirm
I would think the number of blocks through which the ports are scattered
has very little relevance to the user experience. Surely the key factor
is the sharing ratio?
Tom Taylor
On 17/03/2013 5:12 AM, Shishio Tsuchiya wrote:
I know 3 Geeks who lived in IPv4 15 port and IPv6 internet
, on the grounds
that this is a set of generic tools and that specific use cases rather could go
in a deployment document.
does anyone else have strong opinions on current text versus Tom's proposed
changes?
cheers,
Ole
On Feb 21, 2013, at 16:43 , Tom Taylor tom.taylor.s...@gmail.com wrote:
The two
OK, I await the WG's verdict.
On 25/02/2013 8:17 AM, Ole Troan wrote:
Tom,
to state it another way. I don't want rewrite section 5, unless there is a
clear benefit in doing so.
I'm not against better text of course, and if you want to propose an
alternative section 5, then the working group
in all cases.
On 21/02/2013 10:43 AM, Tom Taylor wrote:
The two bullets below were actually a Trojan Horse of sorts. They set
the agenda for Sections 5.2 and 5.3 respectively. I think those two
sections should have different titles to start with:
5.2 Provisioning the MAP IPv4 Address, MAP IPv6
be minimal.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
I know that my own feeling is that MAP-E as currently described has a
split personality. On the one hand, there are those algorithms in
support of address sharing. On the other hand, there is provision for
doing without the algorithms (especially when o=0), in which case
ordinary provisioning
Thanks. What about the assertions in the bullets?
On 12/02/2013 3:27 AM, Ole Troan wrote:
Tom,
I'm still hoping to see a response to this.
On 06/02/2013 8:42 AM, Tom Taylor wrote:
Section 5 of the latest version of MAP has the following:
1. Basic Mapping Rule (BMR) - mandatory, used
to this.
On 06/02/2013 8:42 AM, Tom Taylor wrote:
Section 5 of the latest version of MAP has the following:
1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix,
address or port set assignment. There can only be one Basic
Mapping Rule per End-user IPv6 prefix
I'm still hoping to see a response to this.
On 06/02/2013 8:42 AM, Tom Taylor wrote:
Section 5 of the latest version of MAP has the following:
1. Basic Mapping Rule (BMR) - mandatory, used for IPv4 prefix,
address or port set assignment. There can only be one Basic
node can use the matching
FMR to derive the MAP IPv6 address of the interface through
which that destination address-port combination can be reached.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman
I support (a).
On 05/02/2013 8:38 AM, Ole Troan wrote:
But there has been a firm requirement in the WG that, even for shared
addresses, one of the CE could have the well-known ports.
The WKPs-authorized option has been added to 4rd to satisfy this requirement.
I don't think this requirement
Support.
On 05/02/2013 12:29 AM, Suresh Krishnan wrote:
Hi all,
This draft was a result of the discussion initiated at the softwire
meeting in Atlanta to attempt to come up with a unified CPE
specification that can work with both MAP and lw4o6. This call is being
initiated to determine
Below.
On 30/01/2013 5:41 AM, Ole Troan wrote:
Tom,
...
The basic idea is that, instead of assigning a single sequence of
ports to a CE, the port space from whatever to 65535 is divided up
into equal-size chunks, or blocks, and the CE is assigned a
sequence of m ports from each block. I
Below, with [PTT].
On 30/01/2013 7:47 AM, Ole Troan wrote:
Tom,
[...]
I don't at all see why moving the port mapping algorithm out of
the document would make things simpler. it would make it a lot
more complex. then you'd end up with having to support many
different port algorithms.
My
system ports are likely to be servers, the full
address solution makes sense on another level too.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
, by the formula: Block size = 65536 /
2^a
I'm not sure of the meaning of 'Block size', which is equal to
2^(k+m). As I interpret, each CE can get 2^(a+m) ports and each port
range is 2^m. What can we use the 'Block size' for?
Thanks in advance!
Best Regards, Qi Sun
On 2013-1-29, at 上午12:59, Tom
I made some editorial comments about Section 5.1 the other day. I have a
substantive comment now, and a text proposal to pull it all together.
Comment: the statement
For a = 0, A MAY be 0 to
allow for the provisioning of the system ports.
just below Figure 2 is illogical, since if
prefix, the complete
shared IPv4 address, and the PSID explicitly, then describe how to
construct the MAP endpoint IPv6 address.
Getting back to draft-cui-softwire-b4-translated-ds-lite, I'd say it's
ready to be adopted.
Tom Taylor
___
Softwires mailing
.
BTW: potential global change: instead of full address, how about
unrestricted address?
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Oops. Got mixed up between the Rule IPv6 prefix and the end-user IPv6
prefix.
On 27/01/2013 10:13 AM, Tom Taylor wrote:
Section 5.2 talks about BMRs being shared amongst CEs. This is only
possible with certain restrictions, which should perhaps be enumerated.
Fundamentally, anything unique
field
= 6 EA bits, Rule IPv6 prefix is a /50.
Here's an alternative example (assuming we can say something sensible
about what gets reserved if there is no subnet ID field):
- /64 assigned to the subscriber
- same assumptions as above on sharing
= Rule IPv6 prefix is a /58
Tom Taylor
On 26/01
9030 in example 2) is known in advance to be one that will reach
the desired endpoint?
Is there anything special about MAP compared with the general NAT
situation that makes it easier or harder for senders to learn what ports
they can send to?
Tom Taylor
can get two million CEs
per mapping rule.
I think limiting the prefix length to 64 bits is reasonable. Comments?
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
Figure 1: Network Topology
Just to complete the description of Figure 1: the MAP BR is
responsible for connecting external IPv4 networks to
the IPv4 nodes in one or more MAP domains.
Tom Taylor
___
Softwires mailing list
Softwires
We have two choices on this one:
a) prohibit the use of an end user IPv6 prefix of length greater than 64
bits;
b) simply remove the reference to RFC6052, or qualify it by saying that
the IID conforms to Section 2.2 of RFC 6052 except in the case of end
user IPv6 prefixes of length greater
That should be OK.
On 25/01/2013 1:36 PM, Ole Troan wrote:
Tom,
We have two choices on this one:
a) prohibit the use of an end user IPv6 prefix of length greater than 64 bits;
b) simply remove the reference to RFC6052, or qualify it by saying that the IID
conforms to Section 2.2 of RFC
This caught my eye too. Why repeat the PSID?
On 24/01/2013 11:27 AM, Ole Troan wrote:
hi,
can we please keep discussion on the list. not via the issue tracker?
does anyone else have an opinion?
(if I don't hear anything from anyone else, I'll default to keep current text.)
cheers,
Ole
On
of the explanation of the algorithm in
Section 5.1. Section 5.1.3 should change only by replacing excluded
ports by whether system ports are excluded and the default value of
that to yes.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https
Below.
On 21/01/2013 10:55 AM, Ole Troan wrote:
Tom,
Section 5.1.3 calls for the (optional) provisioning of a range of
excluded ports as part of a mapping rule. As my notes in Decemeber
hopefully made clear, the key issue is really whether system ports
(0-1023) are to be excluded or not. How
as part of the Mapping Rule.
Hope this helps.
Tom Taylor
5.2 Deriving the MAP IPv6 Address From the End-User IPv6 Prefix and the
Basic Mapping Rule
As indicated above, the end-user IPv6 prefix is an IPv6 prefix
provisioned on the CE and unique to it. This prefix has a special
structure
draft-ietf-softwire-map-02 mentions excluded ports in several places:
Section 5.1: talks about excluding ports 0-4095. The reason for choosing
that limit is not given at that point. Further discussion below.
Section 5.1.1 says:
For a 0, j MUST be larger than 0. This ensures that the
with the individual issues I see in the draft.
On 24/12/2012 1:57 PM, Tom Taylor wrote:
I hate to raise an old topic, but based on the explanation in the text I
proposed in my previous note, a is the number of bits required to
represent the value 65536/(M*R) - 1. Even if this value comes out to
zero
for
the partitioning of P (leaving a simple procedural declaration in its
place) or excluding a=0 from the set of possible values of a.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
I'd say they are, in that the IPv6 address for MAP has semantics buried
in it.
But the really relevant difference between MAP and LW4over6 is the
latter's requirement for the AFTR to carry and use per-subscriber data.
That is a fundamental factor in the cost equation. However, the cost of
someone confirm this?
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
: cathy.z...@huawei.com, ji...@chinatelecom.com.cn,
tina.tsou.zout...@huawei.com
A new version of I-D, draft-tsou-softwire-6rd-multicast-02.txt
has been successfully submitted by Tom Taylor and posted to the
IETF repository.
Filename:draft-tsou-softwire-6rd-multicast
Revision:02
Support. It's time a decision was made.
On 07/08/2012 6:02 PM, 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
So there is. I had forgotten.
So: will the WG consider adopting draft-tsou-softwire-6rd-multicast as a
WG deliverable? And if the WG so decides, the Sarikaya approach could
also be added to the draft with a discussion of the realm of
applicability of the respective drafts.
Tom Taylor
On 20
Chairs: if draft-ietf-softwire-dslite-multicast is not to be
generalized, could a charter item be added for 6rd multicast?
draft-tsou-softwire-6rd-multicast seems to be a reasobale candidate.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
On 13/07/2012 1:44 AM, Stig Venaas wrote:
On 12.07.2012 20:21, Jacni Qin wrote:
On 7/10/2012 Tuesday 4:46 AM, Behcet Sarikaya wrote:
Well, from the so many mails below it is clear that
No, it's clearly clarified from the mails, about the motive, and the
problems to be solved.
My view has been similar to yours, with a twist: that the generic
document could be followed up by documents that describe how the generic
architecture relates to specific transition architectures like that of
DS-Lite.
Tom Taylor
On 27/06/2012 4:08 PM, Stig Venaas wrote:
FWIW, here is my
An old cartoon I once saw, making fun of ISDN IIRC, showed a single
socket on the outside of the wall, connected to a rat's-nest of
connections on the inside. This seems apt for the present enterprise.
Tom Taylor
On 26/06/2012 9:48 PM, Maoke wrote:
dear Satoru,
2012/6/26 Satoru Matsushima
I think what Dapeng wants to convey would be achieved if you changed the
may to will typically:
... state will typically exist in the customer premises side
Is this acceptable?
On the second point, I agree with the existing text.
Tom Taylor
On 13/06/2012 7:42 AM, mohamed.boucad
Well, it is still in the Softwires domain if it tunnels the multicast
data, is it not?
On 12/06/2012 4:11 PM, Behcet Sarikaya wrote:
I think that a decision should be made on this draft. If it is going
to present a generic solution it could be fine but then such a draft
does not meet Softwire
Behcet, I apologize. Even if we differ on what constitutes a multicast
solution, I was wrong to refer to your drafts in a pejorative manner.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
:21:07 -0700
From: internet-dra...@ietf.org
To: tom.taylor.s...@gmail.com
CC: cathy.z...@huawei.com, ji...@chinatelecom.com.cn,
tina.tsou.zout...@huawei.com
A new version of I-D, draft-tsou-softwire-6rd-multicast-01.txt has been
successfully submitted by Tom Taylor and posted to the IETF
interested in the MAP and 4rd work.
Rather than argue over the use of the term, perhaps you could describe
the engineering solution that interests you (though I suppose the
question below gives a hint).
Tom Taylor
On 28/02/2012 9:06 AM, liu dapeng wrote:
...
Hi Remi,
Thanks
Would Gateway-Initiated 6rd [draft-tsou-softwire-gwinit-6rd] fit within
the charter or would it have to go the AD-sponsored route?
On 19/04/2011 12:36 PM, IESG Secretary wrote:
A modified charter has been submitted for the Softwires (softwire) working
group in the Internet Area of the IETF.
...@huawei.com,cathyz...@huawei.com
A new version of I-D, draft-tsou-multicast-transition-taxonomy-01.txt
has been successfully submitted by Tom Taylor and posted to the IETF
repository.
Filename:draft-tsou-multicast-transition-taxonomy
Revision:01
Title: A Classification
(I've already sent this to my co-authors and Yiu, but forgot that the
IETF lists are currently rejecting my posts from my normal address.)
Thanks for your comments. Responses below. BTW, we are going to follow a
suggestion to write this draft as a more general mechanism, to cover any
case
We have updated this document to allow for any type of tunnel, not just
6-in-4. Delegated addresses now mimic the 6rd form, but we supply a
reasonably credible example of how to derive /56 or even /48 from that form.
Original Message
Subject: New Version Notification for
I see I should have made sure my mail was downloaded before replying ):
On 09/11/2010 9:18 AM, Tom Taylor wrote:
One point about gateway-initiated 6rd is that the gateway IPv4 address
can be truncated, depending on the length of mask used for the network
device address space. That gives more
I believe Ted is saying the operator achieves its objectives because
when DHCP resolves the FQDN in order to distribute the address, it
invokes the DNS mappings that have been set up by the regional teams.
I see a potential gap in this reasoning. Could it be that the regional
teams manage
91 matches
Mail list logo
