Roland,
-Original Message-
From: Roland Dobbins [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 06, 2007 10:54 AM
To: Routing Research Group list
Subject: Re: [RRG] Mobility in the future -- civil aviation mobility
On Dec 6, 2007, at 10:45 AM, Fleischman, Eric wrote:
Tony,
Where did you hide the NAT-PT box? And, once you have the NAT-PT
box, why do you need LISP involved?
I'm not sure it needs to be NAT-PT due to dual stack and/or
IPv4-in-IPv6 tunneling, but if NAT-PT were used then I don't
know why it wouldn't be co-located on the ITR.
So then
, December 06, 2007 10:57 PM
To: Templin, Fred L
Cc: rrg@psg.com
Subject: Re: [RRG] LISP, IPv6 and 6to4
On Dec 6, 2007, at 6:55 PM, Templin, Fred L wrote:
I am wondering why there hasn't been more discussion about
using LISP as the vehicle to get us to IPv6, e.g. by having
EIDs
I am wondering about the palatability of the acronyms LISP
or APT (or just LISP/APT) as the name for the next-generation
Internet. The acronym IPvLX (IP with vitual Link eXtension) is
available once a converged solution is decided for moving forward...
Fred
[EMAIL PROTECTED]
--
to unsubscribe
Fragmentation is indeed harmful especially if it is left
unchecked in the presence of sustained high data rates
(RFC4963). Based on analysis over many years, complete
avoidance of all fragmentation and in all operational
scenarios is not possible if applications are to see
a reasonable path MTU.
Iljitsch,
the maximum packet size the ETR is
prepared to receive, possibly (if the ETR supports reassembly) the
maximum packet size the ETR is prepared to reassemble from fragments.
I assume you are talking here about the ETR's EMTU_R.
RFC1122 couches EMTU_R in terms of the largest packet
Iljitsch and Dino,
-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 18, 2007 4:14 AM
To: Templin, Fred L; Dino Farinacci
Cc: Routing Research Group list
Subject: MTU stuff, was Re: [RRG] LISP-NERD reachability and
MTU detection
sprite-mtu identifies conditions under which the ITR
must fragment outer packets which the ETR must reassemble.
(And, from the list discussions, we seem to be reaching
consensus that any reassembly at the ETR must be limited
to 1500 byte or smaller original packets.) But, sprite-mtu
further
then we can have the shim layer insert a 32-bit id
On further thought, we can probably just insert a 16-bit
field in the LISP shim layer that serves as an extension
of the 16-bit ip_id field to make for a combined 32-bit
ID for LISP fragmentation and reassembly.
Fred
[EMAIL PROTECTED]
--
to
I have to disagree. You obviously want identifiers in DNS replies,
regardless of the solution. If you could also return locators, that
cuts down on your startup time, as you effectively get the id-
locator lookup for free. Yes, doing locator updates within the
existing DNS is an
to keep track of who
thought of what first...
-Original Message-
From: Templin, Fred L
Sent: Tuesday, December 18, 2007 2:25 PM
To: Routing Research Group list
Subject: [RRG] LISP Fragmentation and Reassembly
sprite-mtu identifies conditions under which the ITR
must fragment
Dino,
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 20, 2007 10:47 PM
To: Brian E Carpenter
Cc: Victor Grishchenko; Tony Li; Routing Research Group list
Subject: Re: [RRG] Re: [RAM] Different approaches for
different protocols
About MTU changes due to path changes, that is a problem
that needs to be dealt with in any case and not just the
map-and-encaps case. The two ways of detecting this are
to begin receiving packet-too-bigs when none were
received previously, or to proactively probe the path,
or both. (In the
Brian,
-Original Message-
From: Brian Dickson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 02, 2008 5:30 PM
To: Templin, Fred L
Cc: Iljitsch van Beijnum; Routing Research Group list; Dino
Farinacci; Tony Li
Subject: Re: [RRG] MTU/fragmentation AGAIN
...
The real benefit
-
From: Brian Dickson [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 03, 2008 4:54 PM
To: Templin, Fred L
Cc: Iljitsch van Beijnum; Routing Research Group list; Dino
Farinacci; Tony Li
Subject: Re: [RRG] MTU/fragmentation AGAIN
Templin, Fred L wrote:
Brian,
The real benefit
Finally, while the title includes the word: Subnetwork,
the same concepts and constructs apply when the interdomain
routing core is treated as a giant subnetwork. Comments on
the list are welcome.
Fred
[EMAIL PROTECTED]
-Original Message-
From: Templin, Fred L
Sent: Friday, February 01, 2008 1
Attached please find a new draft that proposes a
Subnetwork Encapsulation and Adaptation Layer (SEAL).
This work goes a step beyond the sprite-mtu proposal, and
addresses the tunnel MTU determination and duplicate packet
detection problem spaces such as required for LISP, MANET,
etc. But, it also
formats.
Please review and comment,
Fred
[EMAIL PROTECTED]
-Original Message-
From: Templin, Fred L
Sent: Tuesday, February 12, 2008 5:07 PM
To: rrg@psg.com
Subject: RE: [RRG] Subnetwork Encapsulation and Adaptation
Layer (SEAL)
An update to this document has been posted
Dino,
Just one more word about practical and simple, I have already
built and tested an alpha version of SEAL in Linux that does
the ID extension (code was submitted on the MANET wg list).
The next version will pick up the MTU handling.
Thanks - Fred
[EMAIL PROTECTED]
--
to unsubscribe send a
Do you believe every encaps technique should carry fragmentation info
in
its own headers, or should there be a more general approach?
I believe the general approach does entail a little bit of
fragmentation info - 4 extra bytes, to be specific.
If the latter, where in the IETF/IRTF should MTU
The point about using EID space prefixes as an indication of
which sites have been upgraded is that it need not interfere
with existing deployments nor require that existing deployments
ever transition.
Per Christian's point, one benefit of this is no renumbering
for legacy deployments.
Fred
This draft follows from the comments I made at the mike
during Christian Vogt's presentation on 3/14 and also
here on the list:
http://www.ops.ietf.org/lists/rrg/2008/msg00780.html
http://www.ops.ietf.org/lists/rrg/2008/msg00781.html
The idea is that if a sufficiently large IPv6 prefix
is
-
From: Templin, Fred L
Sent: Thursday, March 20, 2008 9:52 AM
To: Routing Research Group Mailing List
Cc: Christian Vogt; Darrel Lewis (darlewis); [EMAIL PROTECTED];
Vince Fuller
Subject: [RRG] on draft-meyer-lisp-eid-block-00.txt
This draft follows from the comments I made at the mike
during
-Original Message-
From: Xu Xiaohu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2008 10:05 AM
To: 'Dino Farinacci'; 'Noel Chiappa'
Cc: rrg@psg.com
Subject: re: [RRG] What does incremental deployment mean
Hi Noel and Dino,
You can drop the Without that commitment. It's very
-Original Message-
From: Xu Xiaohu [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 7:27 AM
To: Templin, Fred L; 'Dino Farinacci'; 'Noel Chiappa'
Cc: rrg@psg.com
Subject: re: [RRG] What does incremental deployment mean
I don't think this is true at all; at least it better
Robin,
-Original Message-
From: Robin Whittle [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 4:37 PM
To: rrg@psg.com
Cc: Templin, Fred L; Xu Xiaohu; Dino Farinacci; Noel Chiappa
Subject: Re: [RRG] What does incremental deployment mean
Hi Fred,
Thanks - I should have
questions below:
-Original Message-
From: Robin Whittle [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2008 5:21 PM
To: rrg@psg.com
Cc: Templin, Fred L; Xu Xiaohu
Subject: Is ISATAP a practical solution?
Short version: From what little I know about ISATAP
Robin,
See below for some follow-up:
-Original Message-
From: Robin Whittle [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2008 6:55 PM
To: rrg@psg.com
Cc: Templin, Fred L
Subject: Re: [RRG] RE: Is ISATAP a practical solution?
Hi Fred,
Thanks for your reply. I apologise
Robin,
Some additional follow-up:
I am also keen to avoid anything like a SEAL header, at least
on the shorter packets in any map-encap tunnel.
Including the SEAL header on large packets and omitting
it on smalls is certainly an idea to be taken seriously
and not to be dismissed w/o further
Hi Robin,
-Original Message-
From: Robin Whittle [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 06, 2008 3:58 AM
To: rrg@psg.com
Cc: Templin, Fred L
Subject: Re: [RRG] RE: Is ISATAP a practical solution? IPv6 adoption
Hi Fred,
I will respond to what you wrote about header lengths
Hi Robin,
-Original Message-
From: Robin Whittle [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 06, 2008 4:24 AM
To: Routing Research Group; Templin, Fred L
Subject: SEAL, PMTUD, IPv6 header bloat, header compression
Hi Fred,
in two messages in the Is ISATAP a practical solution you
Comments below:
-Original Message-
From: Xu Xiaohu [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 09, 2008 1:37 AM
To: 'Brian E Carpenter'
Cc: 'Randall Atkinson'; 'David R Oran'; rrg@psg.com
Subject: re: [RRG] What does incremental deployment mean
-邮件原件-
发件人: Brian E
Hi Fred,
The concept of the nested address spaces is interesting, but
I'm doubt the driver for this network structure. BTW, there
may be many private address realm behind a NAT box, should
there be a realm ID to distinguish them?
An IPv6 prefix as a realm ID, maybe?
Fred
--
to unsubscribe
Robin,
Perhaps this new approach could be used with
Fred Templin's SEAL, which has just been significantly revised to
version 06:
http://tools.ietf.org/html/draft-templin-seal-06
SEAL has been ratcheted up to -08 to pick up some minor
additions that were left out of the -06. To the best of
my
Robin,
Your proposal needs to talk about the setting of DF in
the outer IPv4 header after encapsulation. Based on my
5+ years of studying this, if it sets DF=1, its busted.
IMHO, SEAL is well beyond the research phase now and
pretty deep into engineering solution space. It is
written in the form
Dave,
-Original Message-
From: David R Oran [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 21, 2008 1:12 PM
To: Christian Vogt
Cc: Michael Meisel; Dan Jen; Routing Research Group Mailing List
Subject: Re: [RRG] arguments for map and encap
On May 21, 2008, at 3:34 PM, Christian Vogt
c - The prospects for near-term (next 5 years or so) widespread
adoption of IPv6 - because we haven't formed a clear
consensus that we need to solve the IPv4 routing scaling
problem directly, but think it could or should be solved by
mass migration from IPv4 to
Hi Robin,
Sorry for the delay, but I had to dig pretty deep to find this:
Fred Templin disagreed with your text, wanting IPv4 and IPv6
solutions.
I don't disagree with what Tony said, however, there is quite
a bit left to consider in what he _didn't_ say. Tony didn't
say, for example, that we
-Original Message-
From: Tony Li [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 4:23 PM
To: Templin, Fred L; 'Brian E Carpenter'; 'RJ Atkinson'
Cc: 'IRTF Routing RG'
Subject: RE: [RRG] GSE History
|Of course, you also have to wonder just how much inertia there
|is when
-Original Message-
From: Robin Whittle [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 5:58 PM
To: Routing Research Group
Cc: Templin, Fred L
Subject: Re: [RRG] Moving forward... IPv4 now, IPv6 less
urgent and perhapsmoreambitious
Hi Fred,
You wrote:
Sorry for the delay
Tony and others,
|Likewise, does this mean that discussions about migration of large
|numbers of users to IPv6, or to a future significantly modified
|version of IPv6, are out of scope? My guess is they would be, and
|would disrupt the discussions you want to focus on.
Yes, you're correct.
Oliver et al,
Integrating LISP with SEAL is a possible next step of interest.
If you would like to try putting your implementation together
with SEAL, let me know:
http://osprey67.com/seal
(IMHO, in the future our LISP should be SEALed.)
Fred
[EMAIL PROTECTED]
-Original Message-
]
From: Luigi Iannone [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 1:56 PM
To: Templin, Fred L
Cc: [EMAIL PROTECTED]; rrg; Sébastien Barré
Subject: Re: [RRG] Publicly available LISP and shim6 implementations
Hi
I have to agree with Dino about this, and IMHO the
performance question is a red herring. My code has
been done in the linux kernel, which I realize is far
different than optimized fast-path router hardware,
but based on what I see there parsing headers is a
miniscule component of what goes on in
-Original Message-
From: Robin Whittle [mailto:[EMAIL PROTECTED]
Sent: Monday, July 28, 2008 4:54 PM
To: Routing Research Group; Routing Research Group
Cc: Pekka Savola
Subject: [RRG] Map-encap, fragmentation, PMTUD etc.
I haven't been keeping up with the list of late, but noticed
Tony,
The ONLY thing that causes MTU issues is encapsulation approaches.
I'm not sure I would say there are no MTU issues for
non-encapsulating approaches using classical path MTU
discovery because:
- routers in the Internet would have to return a PTB message
for *every* packet dropped
If lots of hosts are sending long packets with DF=0, we need to cope
with then in any map-encap scheme.
Lots of hosts sending long packets with DF=0 does not
necessarily cause problems for ITRs/ETRs, if that's what
you mean. As long as the ITR configures a large-enough
MTU on its
Removing fragmentation from the network is a really good aspect of
IPv6, I think. Ideally, I think, all packets should be sent DF=1
and all applications should be ready to cope
As with declaring fragmentation harmful, removing
in-the-network fragmentation in IPv6 was a black-and-white
-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 26, 2008 8:46 AM
To: Templin, Fred L
Cc: Routing Research Group
Subject: Re: [RRG] Consensus check: renumbering - missing dimension
On 26 aug 2008, at 17:30, Templin, Fred L wrote:
clients
-Original Message-
From: Scott Brim [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 11:16 AM
To: [EMAIL PROTECTED]
Cc: 'Noel Chiappa'; rrg@psg.com
Subject: Re: [RRG] Renumbering...
On 9/3/08 1:18 PM, Tony Li allegedly wrote:
|On 9/2/08 8:15 PM, Tony Li allegedly
-Original Message-
From: Robin Whittle [mailto:[EMAIL PROTECTED]
Sent: Monday, September 15, 2008 8:49 PM
To: Routing Research Group; Steven Blake
Subject: [RRG] 2 billion IP cellphones in 2103 mass adoption
of IPv6 by currentIPv4 users
Hi Steve,
In Re: [RRG] Re: Practical
-Original Message-
From: Flinck, Hannu (NSN - FI/Espoo) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 8:30 AM
To: Routing Research Group
Subject: RE: [RRG] 2 billion IP cellphones in 2103 mass
adoption of IPv6 by currentIPv4 users
Well, I think that the IPv6 enabled
-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 8:44 AM
To: Templin, Fred L
Cc: Routing Research Group
Subject: Re: [RRG] 2 billion IP cellphones in 2103 mass
adoption of IPv6 by currentIPv4 users
On 16 sep 2008, at 17:40
-Original Message-
From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 9:03 AM
To: Templin, Fred L
Cc: Routing Research Group
Subject: Re: [RRG] 2 billion IP cellphones in 2103 mass
adoption of IPv6 by currentIPv4 users
On 16 sep 2008, at 17:51
Noel,
-Original Message-
From: Noel Chiappa [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 3:02 PM
To: rrg@psg.com
Cc: [EMAIL PROTECTED]
Subject: RE: [RRG] 2 billion IP cellphones in 2103 mass
adoption of IPv6 by currentIPv4 users
From: Templin, Fred L [EMAIL
Dino,
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Monday, September 22, 2008 3:13 PM
To: Brian E Carpenter
Cc: RRG
Subject: Re: [RRG] A data point on transit MTU size
We've argued here about whether it's reasonable to assume 1500 byte
MTU on transit
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 8:11 AM
To: Templin, Fred L
Cc: Brian E Carpenter; RRG
Subject: Re: [RRG] A data point on transit MTU size
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED
Dino,
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 23, 2008 2:53 PM
To: Brian E Carpenter
Cc: Templin, Fred L; RRG
Subject: Re: [RRG] A data point on transit MTU size
Yes, we agree that sub-optimal implementations are a bad idea.
We also
-Original Message-
From: Dino Farinacci [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 12:56 AM
To: [EMAIL PROTECTED]
Cc: 'Brian E Carpenter'; Templin, Fred L; 'RRG'
Subject: Re: [RRG] A data point on transit MTU size
Patently nonsense. Packet reassembly in hardware
Tony,
Obviously you can optimize, but even a naïve implementation
has to have a bound on the number of reassemblies that it can
have in progress at any given time. Again a trivial
implementation is to provide a max sized buffer for each such
reassembly.
A Linux box is a far cry from a
-Original Message-
From: Stephen Sprunk [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 24, 2008 4:15 PM
To: [EMAIL PROTECTED]
Cc: Routing RG
Subject: Re: [RRG] A data point on transit MTU size
Tony Li wrote:
|The code for reassembly isn't hard, it's allocating the buffers to
61 matches
Mail list logo
