On 2009-8-11, at 19:55, Dino Farinacci wrote:
If we changed the text in the LISP draft from MUST to MAY, would
we still need to write the accompanying document to RFC 2460?
Maybe Lars can comment on this.
In my opinion, any change from the MUST in RFC2460 requires updating
RFC2460.
Lars
revises the standing IETF consensus, and
there's a process for that.)
Lars
On 2009-8-13, at 18:24, Dino Farinacci wrote:
On 2009-8-11, at 19:55, Dino Farinacci wrote:
If we changed the text in the LISP draft from MUST to MAY,
would
we still need to write the accompanying document to RFC
The chairs of 6MAN would like to here feedback on these drafts as
they apply to the problem spaces raised (AMT, v4/v6 translators, and
LISP).
From my perspective, AMT and LISP both have the same requirements in
terms of performance and having encapsulation work well over LAGs. It
turns
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is what
the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum field to 0.
Could you tell us how to achieve this on commonly
Hi Dino,
On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote:
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is
what the LISP authors intended and has been implemented this way.
The spec says ITRs MUST set the UDP checksum
Yours,
Joel
Dino Farinacci wrote:
Hi Dino,
On Aug 11, 2009, at 11:37 AM, Dino Farinacci wrote:
On Aug 8, 2009, at 8:34 PM, Dino Farinacci wrote:
The spec says ETRs MUST ignore the UDP checksum field. This is
what the LISP authors intended and has been implemented this way.
The spec says
packet because its addressed to itself
and when an ITR receives packets from site hosts, that it is forwarding?
Dino
Yours,
Joel
Dino Farinacci wrote:
Given that LISP ITRs work by intercepting packets that are not
addressed to them, a host implementation would need to be able
Joel Given that LISP ITRs work by intercepting packets that are
Joel not addressed to them, a host implementation would need to
Joel be able to intercept packets in the stack. That is going
Joel to need some ability to modify kernel behavior.
I'm trying to figure out how an ITR does
Copying ipv6@ietf.org for a question.
If we changed the text in the LISP draft from MUST to MAY, would
we still need to write the accompanying document to RFC 2460?
Maybe Lars can comment on this.
See below for details.
Dino
On Aug 11, 2009, at 9:47 AM, Margaret Wasserman wrote:
On Aug
On Aug 11, 2009, at 12:46 PM, Dino Farinacci wrote:
Every host I'm aware of has a facility for setting up an interface
that routes some set of packets--including potentially the default
route--through a tunnel interface that then passes the packet to
userspace for processing.
We call LISP
Dino == Dino Farinacci d...@cisco.com writes:
Dino We call LISP tunnels as dynamic encapsulating tunnels
Dino where an implementation must not implement the tunnel as a
Dino logical interface. The implementation cannot scale if it
Dino does this. You get the level of indirection
I think this is off topic. If you want to continue the discussion,
send me email privately.
Hi Dino,
On Aug 11, 2009, at 2:05 PM, Dino Farinacci wrote:
Why couldn't LISP be implemented as a logical interface that
encapsulates or not based on the contents of the LISP Mapping
cache
References: f3fc18ff-e085-47e9-8376-2c4da00d9...@americafree.tv fa1a0c09-fde5-4acd-aea1-476b090c7...@cisco.com c3c481ad-5ab6-462c-a48c-f16e968de...@nokia.com
c8f93853-fb91-4abc-9cf5-e599fd274...@cisco.com 0e71fc61-5a42-4c5a-a22a-69b3213a9...@nokia.com
the O UDP checksum proposal obsoletes all the today deployed nodes
which check them (so all hosts I know and perhaps a lot of routers
too)
OK, so what are the other options for encapsulating a packet in a
IPv6
packet?
Um, surely, routers are not specified to validate layer-4
checksums
And what about multicast? ;-)
Dino
On Aug 8, 2009, at 7:39 AM, Noel Chiappa wrote:
From: Christopher Morrow morrowc.li...@gmail.com
The original version of this discussion started on ipv6@, and was
about
what to do if/when a 4to6 (say a nat64 device) translator gets a
packet
that
I suggest that your draft
1) Indicate whether receivers should be specially configured to accept
0 checsums or whether all stacks should accept 0 checksums.
The spec says ETRs MUST ignore the UDP checksum field. This is what
the LISP authors intended and has been implemented this way.
The
Not sensible enough.
Dino
On Aug 4, 2009, at 7:58 AM, Margaret Wasserman wrote:
On Jul 30, 2009, at 6:33 PM, Dino Farinacci wrote:
What I'm saying is that *if* UDP us used, it needs to be used
according to the RFCs that capture the IETF consensus on their
use, or the IETF consensus
Since we're up-levelling the discussion, I don't understand why one
would use UDP as a router-router protocol in the first place,
especially for IPv6, where the chance that the packet will hit a NAT
are probably exactly zero.
Because when you use tunnel encapsulation, core routers attached
Hi,
could you share some data on how much of a performance impact we're
talking about here? I was under the (maybe naive) impression that
checksum offloading was practically ubiquitous these days.
One of the problems with IPv6 is that is so similar to IPv4 but
different enough to cause pain
Because we want to make all combinations work. Because we want IPv6 to
be real.
Why move it to another draft when the same contention will occur.
The opponents just have to face the music. And if they are going to
take issue with this, what about the bigger more critical issues? Will
that says that UDP
checksums could avoid use for tunneling protocols.
Why can't we just go forward with that idea?
Now, on to the specific points in your latest email:
On 2009-7-31, at 8:58, Dino Farinacci wrote:
I already told the list the cost of sacrificing some gates. It's a
non-starter
Hi, Dino,
On 2009-7-29, at 14:02, Dino Farinacci wrote:
From a practical perspective, we prefer that a LISP encapsulator (ITR
and PTR) not incurred additional work when encapsulating packets.
could you share some data on how much of a performance impact we're
talking about here? I was under
We need to consider what will happen if one of these packets is
received by a non-LISP node. Are you assuming
Non-LISP nodes cannot decapsulate LISP packets so they don't have this
problem. ;-)
Zero UDP checksums are build in an outer UDP header by an ITR, and an
ETR which decapsulates
This is a reminder that draft-fairhurst-6man-tsvwg-udptt and
http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
are still open and will be discussed at the 6man meeting Wednesday.
Basically, one prescribes no checksum for the outer packet in
IPv6 encapsulations, the other a fixed
24 matches
Mail list logo
