Hi,
Christopher Morrow wrote:
My feeling is this:
hop-by-hop processing will happen in slow-path (if you permit it to
happen at all), you can't build a router today with an asic that'll
know how to handle options which are created in the future :(
while the latter is surely true, I don't
Gawd, I love these sorts of discussions.
Remind me. How many HBH options has the IETF approved in the last ten
years?
How many proposed HBH options are in the pipeline for approval?
Could we please skip this silly discussion until such a time as
someone actually proposes a HBH option that makes
Your reasoning does not follow, Manav.
Given what we know about packet processing, any extension that believes
it will be processed by every router along the path is probably fooling
itself. Therefore, documenting something that claims to provide that
functionality is probably a mistake.
Brian E Carpenter brian.e.carpen...@gmail.com writes:
OK, something like
Although the flow label is defined as immutable once it has
been set to a non-zero value, implementers should be aware
that it is an unprotected field that could have been accidentally
or intentionally
On Fri, Feb 4, 2011 at 8:35 AM, Thomas Narten nar...@us.ibm.com wrote:
Gawd, I love these sorts of discussions.
snip
And to be clear, I suspect we will not be approving any HBH options
any time soon. We know they are generally a bad idea. It is unlikely
that the reasons that HBH are a last
On Fri, Feb 4, 2011 at 7:21 AM, Roland Bless roland.bl...@kit.edu wrote:
Hi,
Christopher Morrow wrote:
My feeling is this:
hop-by-hop processing will happen in slow-path (if you permit it to
happen at all), you can't build a router today with an asic that'll
know how to handle options which
fair enough, though having some documented (at least in email)
reasoning that Oh, a new HBH will be cool! is bad, certainly isn't
bad, right?
Well, it's been documented before in email, and I have little hope
that documenting it again in email will be remembered six months from
now. :)
Hi Thomas,
On 11-02-04 10:29 AM, Thomas Narten wrote:
fair enough, though having some documented (at least in email)
reasoning that Oh, a new HBH will be cool! is bad, certainly isn't
bad, right?
Well, it's been documented before in email, and I have little hope
that documenting it again in
options header is not sufficient for those cases. However, if the WG
things it can not or should not ban end-to-end extension
headers, then
having a document giving them a more regular format still seems worth
while to me.
Which is more or less what that draft does. If you require a
Hi Thomas,
I would like to hear your take on how we should encode conex information
in IPv6 packets
(http://datatracker.ietf.org/wg/conex/charter/)
This is critical for conex and we are not clear on how we could do this
in a way that could be deployed.
Thanks in advance for any opinions
Hi Roland,
The problem is not just about known options here, like I mentioned
earlier. A structure where there is a list which needs to be walked
serially and no fixed place for an information, it is bad for the fast
path.
I have mentioned cases for how bad it can get for IPv6. One good thing
Marcelo,
Right off, I don't have enough understanding of what kind of
architecture conex envisions to have any useful thoughts, but if you
are thinking of using HBH options, the effort is certainly faces
significant challenges.
But rather than saying don't use HBH I'll suggest that you make the
On 2011-02-05 03:02, Thomas Narten wrote:
Brian E Carpenter brian.e.carpen...@gmail.com writes:
OK, something like
Although the flow label is defined as immutable once it has
been set to a non-zero value, implementers should be aware
that it is an unprotected field that could
On Fri, Feb 4, 2011 at 10:27 AM, Christopher Morrow
christopher.mor...@gmail.com wrote:
On Fri, Feb 4, 2011 at 7:21 AM, Roland Bless roland.bl...@kit.edu wrote:
Hi,
Christopher Morrow wrote:
My feeling is this:
hop-by-hop processing will happen in slow-path (if you permit it to
happen at
Hi Chris,
On 11-02-04 05:14 PM, Christopher Morrow wrote:
On Fri, Feb 4, 2011 at 10:27 AM, Christopher Morrow
christopher.mor...@gmail.com wrote:
On Fri, Feb 4, 2011 at 7:21 AM, Roland Bless roland.bl...@kit.edu wrote:
Hi,
Christopher Morrow wrote:
My feeling is this:
hop-by-hop processing
Hi Thomas,
On 11-02-04 01:05 PM, Thomas Narten wrote:
Marcelo,
Right off, I don't have enough understanding of what kind of
architecture conex envisions to have any useful thoughts, but if you
are thinking of using HBH options, the effort is certainly faces
significant challenges.
But rather
On 4th February 2011 at 09:00:15 -0500, Joel Halpern wrote:
Given what we know about packet processing, any extension that believes
it will be processed by every router along the path is probably fooling
itself.
Therefore, documenting something that claims to provide
that functionality is
3) Use HbH anyway. There is hardware that can ignore it.
There is hardware that can parse it. We coudl certainly
couple that with discouraging all such use.
+1 to everything above.
To me, (3) -- including advice explaining why the hop-by-hop behaviour is
problematic -- seems like a
Suresh Krishnan suresh.krish...@ericsson.com wrote:
On 11-02-04 01:05 PM, Thomas Narten wrote:
Right off, I don't have enough understanding of what kind of
architecture conex envisions to have any useful thoughts, but if you
are thinking of using HBH options, the effort is certainly faces
On Friday 4th February 2011, at 06:39:51 +0530, Hing-Kam Lam wrote:
The below white paper from Cisco asserts that most vendors including
Cisco process Hop-by-Hop extension headers in CPU (slow path).
Is this correct?
In general, it is not wise to trust any vendor X when they are
talking about
The below white paper from Cisco asserts that most vendors including
Cisco process Hop-by-Hop extension headers in CPU (slow path).
Is this correct?
In general, it is not wise to trust any vendor X when they are
talking about some different vendor Y's products or implementations.
Business
21 matches
Mail list logo
