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.
At that point, we go to the question of whether, for those packets that
want hop-by-hop processing by some routers distinct from the end point
to which the packet is addressed, how should we do it.
1) Don't.
2) Extensions: Note that our underlying documents specifically say not
to do that, for very good reasons. Even the new document on extension
headers was only describing extension headers for end-to-end processing.
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.
My own preference is (1). We have found, repeatedly, that pretending we
can direct packets to every router along a path is just not a good idea.
Note that even our OAM fanatics (MPLS-TP) have given up on trying that
trick.
That of course would bring us back to discussing where extensions with
end-to-end semantics should go. I am still unclear why the end-to-end
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.
Yours,
Joel
On 2/4/2011 2:23 AM, Bhatia, Manav (Manav) wrote:
Fernando,
If you deprecate HbH then if you need an extension that requires such a
behavior then you would need a new header. Routers that don't implement that
will skip over it, while the ones that understand that will process it. This is
different from bundling everything inside HbH where all routers will have to
process this packet in slow path.
Cheers, Manav
-----Original Message-----
From: Fernando Gont
[mailto:[email protected]] On Behalf Of
Fernando Gont
Sent: Friday, February 04, 2011 12.39 PM
To: Bhatia, Manav (Manav)
Cc: Joel M. Halpern; Christopher Morrow; [email protected]
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 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 options are you envisioning that would not fit in any of
the existing extension headers? -- That was the main argument against
the publication of the aforementioned I-D.
Thanks,
--
Fernando Gont
e-mail: [email protected] || [email protected]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
