On Wed, 24 Mar 2021, 07:53 Vasilenko Eduard,
wrote:
> Hi Joseph,
>
>
>
> Currently, vendors have chosen some undisclosed big numbers for the
> reassembly buffer on the tunnel interface
>
> Or no buffer at all for tunnels that do not support reassembly.
>
> That does not create any additional rest
On Wed, 29 Mar 2023 at 19:58, Tony Przygienda wrote:
>
> Though I would like to cheer for Kireeti's 2. as well I think the point of
> SHOULD is more realistic (for now) as Joel points out ...
>
> As to ethertype, I think grown-ups in the room were since long time drily
> observing that a new IP
On Wed, 29 Mar 2023 at 22:46, Robert Raszuk wrote:
>
> Guys,
>
> What you are really saying here is that the concept of using network
> programmability should be killed and we should get stuck for decades to come
> with closed domains only innovation.
>
> I find it quite disturbing especially as
Hi Fred, Tony,
On Fri, 20 Aug 2010 13:16:05 -0700
Fred Baker wrote:
> Thanks, Tony.
>
> Let me comment on one point in your review.
>
> On Aug 20, 2010, at 11:47 AM, Tony Li wrote:
>
>
> To be really honest, I have concluded that every time we further idiot-proof
> the world, the world mak
On Fri, 07 Jan 2011 14:43:35 -0800
Joe Touch wrote:
>
>
> On 1/7/2011 2:39 PM, Brian E Carpenter wrote:
> > On 2011-01-08 10:54, Joe Touch wrote:
> >>
> >>
> >> On 1/7/2011 1:51 PM, Matthew Kaufman wrote:
> >>> Ok. So just to verify, if a box that is sold today that does NAT44
> >>> out-of-the-
On Mon, 10 Jan 2011 09:30:12 +0100
Rémi Després wrote:
>
> Le 8 janv. 2011 à 04:28, Fernando Gont a écrit :
> > On 07/01/2011 07:42 p.m., Josh Rambo wrote:
> >> That seems at odds with the goal of end-to-end transparency on the
> >> Internet.
> >> If it boots up with NAT66 out of the box, then
On Mon, 10 Jan 2011 13:51:52 -0300
Fernando Gont wrote:
> Hi, Remi,
>
> On 10/01/2011 05:30 a.m., Rémi Després wrote:
>
> >> End-to-end transparency in the sense that every node will be
> >> reachable from every node?
> >
> > The e2e transparency that IPv4 had lost, and IPv6 restores, is
> > A
On Fri, 7 Jan 2011 18:52:33 +
"George, Wes E [NTK]" wrote:
> As a direct result of discussions after Beijing about the hotly-contested
> draft regarding IANA allocating a new shared IPv4 address space, the authors
> of this draft realized that the root problem is actually the lack of IPv6
On Mon, 10 Jan 2011 15:49:51 -0500
"Lee Howard" wrote:
>
>
> > -Original Message-
> > From: Joe Touch [mailto:to...@isi.edu]
> > > This sounds like a WG chartering debate, rather than a debate about
> whether
> > > all IP-capable devices SHOULD support IPv6.
> > > It sounds like your su
Hi Lee,
On Mon, 10 Jan 2011 19:59:33 -0500
"Howard, Lee" wrote:
> > -Original Message-
> > From: Mark Smith [mailto:i...@69706e6720323030352d30312d31340a.nosense.org]
> > Sent: Monday, January 10, 2011 4:15 PM
> > I don't think I really agree wit
On Sun, 16 Jan 2011 13:37:07 +0100
Joel Jaeggli wrote:
> On 1/10/11 9:50 PM, Fernando Gont wrote:
> > On 10/01/2011 05:43 p.m., Mark Smith wrote:
> >
> >>>> The e2e transparency that IPv4 had lost, and IPv6 restores, is
> >>>> ADDRESS transparenc
On Mon, 17 Jan 2011 08:39:27 -0600
Jack Bates wrote:
> On 1/16/2011 2:52 PM, Mark Smith wrote:
> >> It's a basic and necessary feature of ipv6-supporting loadbalancer devices.
> >> >
> > I don't think that is necessarily the case either. A group of hosts
&
On Tue, 18 Jan 2011 11:50:55 +0100
Rémi Després wrote:
> Fred.
> That's very much clarifying.
> Thank you.
>
> More comments in line.
>
> Le 17 janv. 2011 à 18:54, Fred Baker a écrit :
> > On Jan 17, 2011, at 9:27 AM, Rémi Després wrote :
> > ...
> > By strictest definition, NAT66 has been
Hi Jack,
On Tue, 18 Jan 2011 07:36:23 -0600
Jack Bates wrote:
> On 1/18/2011 6:33 AM, Mark Smith wrote:
> >
> > I don't think NAPT is necessary to achieve that.
> >
> It's not. There is also DSR (Direct Server Return). However, neither is
> technically
On Wed, 19 Jan 2011 09:09:45 -0600
Jack Bates wrote:
> On 1/18/2011 10:04 PM, Fred Baker wrote:
> >
> > On Jan 18, 2011, at 1:16 PM, Jack Bates wrote:
> >
> >> I didn't see any options in current routers to support utilizing a single
> >> path for all packets from a source (required for when cur
15 matches
Mail list logo
