On Feb 3, 2011, at 23:08, Fernando Gont wrote:
> On 04/02/2011 03:53 a.m., Bhatia, Manav (Manav) wrote:
>> One of the major reasons given for not accepting this was that no new
>> extension headers need to be *ever* defined in future because you
>> MUST either use hop-by-hop ext header or the desti
Hi Vishwas,
Am 04.02.2011 18:53, schrieb Vishwas Manral:
> 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 see.
> I have men
Hi Chris,
Am 04.02.2011 16:27, schrieb Christopher Morrow:
> which options? how often would you expect this list to update? routers
> live in the network for ~7 years or so, in large networks. ASIC
> updates mean very expensive (equipment, personnel, sla) changes are
> required.
Which options dep
On 05 Feb 2011, at 02:03 , Hing-Kam (Kam) Lam wrote:
> This article also includes Cisco's behavior
> for their products and implementations.
Yes. I read the article. Thank you for posting the full URL.
I do not doubt the article's description of cisco products was
accurate -- as of the date i
>> 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.
> B
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 abo
Suresh Krishnan 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
>> significant challeng
>> 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 -- se
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 functionali
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 t
Hi Chris,
On 11-02-04 05:14 PM, Christopher Morrow wrote:
On Fri, Feb 4, 2011 at 10:27 AM, Christopher Morrow
wrote:
On Fri, Feb 4, 2011 at 7:21 AM, Roland Bless wrote:
Hi,
Christopher Morrow wrote:
My feeling is this:
hop-by-hop processing will happen in slow-path (if you permit it to
hap
On Fri, Feb 4, 2011 at 10:27 AM, Christopher Morrow
wrote:
> On Fri, Feb 4, 2011 at 7:21 AM, Roland Bless 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 toda
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
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
IPv
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 yo
> 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,
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
> 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. :)
Pe
On Fri, Feb 4, 2011 at 7:21 AM, Roland Bless 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 are creat
On Fri, Feb 4, 2011 at 8:35 AM, Thomas Narten wrote:
> Gawd, I love these sorts of discussions.
>
> 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 resort approach wil
To: Bhatia, Manav (Manav)
Cc: Joel M. Halpern; Christopher Morrow; ipv6@ietf.org
Subject: Re: Hop-by-Hop Extension Header processed in Slow Path?
Manav,
On 04/02/2011 03:53 a.m., Bhatia, Manav (Manav) wrote:
One of the major reasons given for not accepting this was
that no new
extension heade
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
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
)
> Cc: Joel M. Halpern; Christopher Morrow; ipv6@ietf.org
> Subject: Re: Hop-by-Hop Extension Header processed in Slow Path?
>
> Manav,
>
> On 04/02/2011 03:53 a.m., Bhatia, Manav (Manav) wrote:
> > One of the major reasons given for not accepting this was
> that no new
Manav,
On 04/02/2011 03:53 a.m., Bhatia, Manav (Manav) wrote:
> One of the major reasons given for not accepting this was that no new
> extension headers need to be *ever* defined in future because you
> MUST either use hop-by-hop ext header or the destination options ext
> header.
What type of o
Hi, Joel,
On 04/02/2011 12:11 a.m., Joel M. Halpern wrote:
> Lets be a little careful here:
> 1) If we say "No Extension Headers for intermediate processing", and "No
> Hop By Hop Options", then we are saying that we do not want any
> extensions intended to be processed in intermediate routers. W
o Gont
> [mailto:fernando.gont.netbook@gmail.com] On Behalf Of
> Fernando Gont
> Sent: Friday, February 04, 2011 10.54 AM
> To: Bhatia, Manav (Manav)
> Cc: Joel M. Halpern; Christopher Morrow; ipv6@ietf.org
> Subject: Re: Hop-by-Hop Extension Header processed in Slow Path?
>
On Fri, Feb 4, 2011 at 12:31 AM, Shane Amante wrote:
> Chris,
>
> I think we may want to be a little careful here. At a minimum, maybe take a
> deep breath and think about this some, before making a final decision. :-)
> See below.
>
I don't disagree with being careful.
> On Feb 3, 2011, a
Manav,
On 04/02/2011 01:05 a.m., Bhatia, Manav (Manav) wrote:
> If there are folks who ignore the hop by hop options field then it
> makes the entire discussion about not supporting
> http://tools.ietf.org/html/draft-ietf-6man-exthdr-01 moot. Given
> this, it makes all the more sense to either pro
Chris,
I think we may want to be a little careful here. At a minimum, maybe take a
deep breath and think about this some, before making a final decision. :-)
See below.
On Feb 3, 2011, at 20:17 MST, Christopher Morrow wrote:
> On Thu, Feb 3, 2011 at 10:11 PM, Joel M. Halpern wrote:
>> Lets
Hi Joel,
Options are really bad for fast path processing. To find an option,
the entire list of TLV's needs to be parsed, which is really hard
especially when you have a limited number of clock cycles.
For end-to-end processing however options can be considered better
(especially if the traffic i
2011 8.41 AM
> To: Christopher Morrow
> Cc: ipv6@ietf.org
> Subject: Re: Hop-by-Hop Extension Header processed in Slow Path?
>
> Lets be a little careful here:
> 1) If we say "No Extension Headers for intermediate
> processing", and "No
> Hop By Hop O
On Thu, Feb 3, 2011 at 10:11 PM, Joel M. Halpern wrote:
> Lets be a little careful here:
> 1) If we say "No Extension Headers for intermediate processing", and "No Hop
> By Hop Options", then we are saying that we do not want any extensions
> intended to be processed in intermediate routers. Whil
Lets be a little careful here:
1) If we say "No Extension Headers for intermediate processing", and "No
Hop By Hop Options", then we are saying that we do not want any
extensions intended to be processed in intermediate routers. While I
personally like that, I want to make really sure that we
On Thu, Feb 3, 2011 at 8:09 PM, Hing-Kam (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?
>
> http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900a
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?
http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html
If Yes, then we should not add support for more su
36 matches
Mail list logo
