Hi Brian,
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Monday, October 14, 2013 12:34 PM
> To: Templin, Fred L
> Cc: Fernando Gont; Ray Hunter; 6man Mailing List; ietf@ietf.org
> Subject: Re: Last Call:
> (Implicati
Hi Ron,
> -Original Message-
> From: Ronald Bonica [mailto:rbon...@juniper.net]
> Sent: Saturday, October 12, 2013 7:07 PM
> To: Brian E Carpenter; Templin, Fred L
> Cc: Fernando Gont; 6man Mailing List; ietf@ietf.org; Ray Hunter
> Subject: RE: Last Call:
> (Impl
Hi Brian,
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Friday, October 11, 2013 3:42 PM
> To: Templin, Fred L
> Cc: Fernando Gont; Ray Hunter; 6man Mailing List; ietf@ietf.org
> Subject: Re: Last Call:
> (Implicati
Hi Brian,
> -Original Message-
> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Sent: Friday, October 11, 2013 12:50 PM
> To: Fernando Gont
> Cc: Templin, Fred L; Ray Hunter; 6man Mailing List; ietf@ietf.org
> Subject: Re: Last Call:
> (Implicati
Hi Fernando,
> -Original Message-
> From: Fernando Gont [mailto:fg...@si6networks.com]
> Sent: Friday, October 11, 2013 10:04 AM
> To: Templin, Fred L; Ray Hunter; brian.e.carpen...@gmail.com
> Cc: 6man Mailing List; ietf@ietf.org
> Subject: Re: Last Call:
> (Impl
Hi Ray,
> -Original Message-
> From: Ray Hunter [mailto:v6...@globis.net]
> Sent: Friday, October 11, 2013 9:59 AM
> To: Templin, Fred L
> Cc: brian.e.carpen...@gmail.com; ietf@ietf.org; 6man Mailing List
> Subject: Re: Last Call:
> (Implications of Oversized I
Hi Fernando,
> -Original Message-
> From: Fernando Gont [mailto:fg...@si6networks.com]
> Sent: Friday, October 11, 2013 1:36 AM
> To: Ray Hunter; Templin, Fred L; brian.e.carpen...@gmail.com
> Cc: 6man Mailing List; ietf@ietf.org
> Subject: Re: Last Call:
> (Impl
Hi Ray,
> -Original Message-
> From: Ray Hunter [mailto:v6...@globis.net]
> Sent: Friday, October 11, 2013 12:49 AM
> To: Templin, Fred L; brian.e.carpen...@gmail.com
> Cc: ietf@ietf.org; 6man Mailing List
> Subject: Re: RE: Last Call: 08.txt> (Implications of
Hi Brian,
Responding in a slightly re-arranged order:
> The problem is that you are asserting that middleboxes that a tunnel
> passes through are expected to examine the complete header chain of
> the encapsulated packet even if the encapsulated packet is a fragment.
Yes, but change "are expecte
Hi Ole,
> -Original Message-
> From: Ole Troan [mailto:otr...@employees.org]
> Sent: Wednesday, October 09, 2013 10:31 AM
> To: Templin, Fred L
> Cc: Ronald Bonica; i...@ietf.org; ietf@ietf.org
> Subject: Re: Last Call:
> (Implications of Oversized IPv6 Heade
Hi Ole,
> -Original Message-
> From: Ole Troan [mailto:otr...@employees.org]
> Sent: Wednesday, October 09, 2013 9:54 AM
> To: Templin, Fred L
> Cc: Ronald Bonica; i...@ietf.org; ietf@ietf.org
> Subject: Re: Last Call:
> (Implications of Oversized IPv6 Header Chains)
> -Original Message-
> From: Ronald Bonica [mailto:rbon...@juniper.net]
> Sent: Tuesday, October 08, 2013 5:46 PM
> To: Ole Troan; Templin, Fred L
> Cc: i...@ietf.org; ietf@ietf.org
> Subject: RE: Last Call:
> (Implications of Oversized IPv6 Header Chains) to Pro
Hi Ole,
> -Original Message-
> From: Ole Troan [mailto:otr...@employees.org]
> Sent: Tuesday, October 08, 2013 9:17 AM
> To: Templin, Fred L
> Cc: ietf@ietf.org; IETF-Announce; i...@ietf.org
> Subject: Re: Last Call:
> (Implications of Oversized IPv6 Header Chains)
Path MTU minus 256 bytes in case additional
encapsulation headers are inserted by tunnels on the path."
Thanks - Fred
fred.l.temp...@boeing.com
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Templin, Fred L
> Sent: Frida
Hi, I have a concern about this document. In the definition of "IPv6
Header Chain", it says:
"However, if a second IPv6 header appears in the header chain, as
is the case when IPv6 is tunneled over IPv6, the second IPv6
header is considered to be an upper-layer header and terminates
the
Noel,
> -Original Message-
> From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]
> Sent: Thursday, November 03, 2011 8:40 AM
> To: ietf@ietf.org
> Cc: j...@mercury.lcs.mit.edu
> Subject: RE: LISP is not a Loc-ID Separation protocol
>
>
>
Hi Noel,
> -Original Message-
> From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]
> Sent: Thursday, November 03, 2011 8:28 AM
> To: ietf@ietf.org
> Cc: j...@mercury.lcs.mit.edu
> Subject: RE: LISP is not a Loc-ID Separation protocol
>
> > From: "
Hi Noel,
> But I must confess I'm kind of confused as to why any of this
> matters? I
> mean, it's fun philosophical debate (well, for some people, I
> guess :-), but
> so what?
It just circles back again to the fact that what LISP
calls "EID" is something that names an interface; not
an end sy
Hi Noel,
> -Original Message-
> From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]
> Sent: Thursday, November 03, 2011 7:43 AM
> To: ietf@ietf.org
> Cc: j...@mercury.lcs.mit.edu
> Subject: RE: LISP is not a Loc-ID Separation protocol
>
> > From: "
tocol
>
> > From: "Templin, Fred L"
>
> > Let's say the end system also has multiple loopback
> interfaces - say it
> > has two, for example.
>
> Why? What does that buy you?
The multiple loopback interfaces (or, more generally,
the multip
Noel and others,
Let's say we have an end system with as many ISP
connections as you like - each with its own "locator"
address. Let's say the end system also has multiple
loopback interfaces - say it has two, for example.
The end system connects to a first VPN and receives
the "endpoint" addres
Thankfully, I missed most of the earlier threads related
to this. But, on the subject of identifiers, Robin is right.
What the IETF protocol known as LISP calls "identifiers" are
actually IP addresses. And, IP addresses name *interfaces*;
they do not name *end systems*. Same is true also of IRON.
Christian,
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
> Behalf Of Christian Huitema
> Sent: Friday, July 29, 2011 12:17 PM
> To: Michel Py; Rémi Després
> Cc: ietf@ietf.org; Keith Moore
> Subject: RE: 6to4v2 (as in ripv2)?
>
> 6rd addresses a di
Ron,
I believe 'draft-ietf-v6ops-6to4-advisory' is both
necessary and sufficient regardless of whether
"historic" is an appropriate characterization. So,
I don't think we need this document.
Thanks - Fred
fred.l.temp...@boeing.com
> -Original Message-
> From: ietf-boun...@ietf.org [mai
> -Original Message-
> From: Ted Lemon [mailto:ted.le...@nominum.com]
> Sent: Friday, July 15, 2011 12:43 PM
> To: Templin, Fred L
> Cc: v6...@ietf.org Operations; IETF Discussion
> Subject: Re: [v6ops] Another look at 6to4 (and other IPv6
> transition issues)
>
Hi Joel,
> ipv4 is becoming less usable and it's
> taking autotunnels with it, nobody here has a proposal that
> changes that.
As far as I can tell, IPv4 is not becoming less
usable within my organization's network.
Thanks - Fred
fred.l.temp...@boeing.com
_
You cannot expect something to be configured correctly if it is simply turned
on without a) being managed by someone or b) detection mechanisms to see if
it's working. Sadly, anycasted 6to4 meets neither of these conditions.
ISATAP meets both of these conditions:
http://tools.ietf.org/html/draf
During the IPv6 panel at the plenary last night, representatives
of several major service providers discussed their experiences
with IPv6. It became clear that many of their experiments involve technologies
that delegate Provider-Aggregated (PA) IPv6 prefixes
to the customer instead of Provider-In
I'll add my voice as another former DEC colleague who
was saddened by this news.
Jim never shied away from a challenging or contentious
job. For example, the work on enterprise networks in
RFCs 4852, 4057 could only have been done by someone
with Jim's fortitude.
I believe we are all better off f
29 matches
Mail list logo
