[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Re: TRRP-Via - option header vs. encapsulation
RW> Is there any reason to think that routers in general - BGP and
RW> internal routers - will be upset by an option header, specifically a
RW> new kind of option header as you suggest?
BH> Another gentleman mentioned to me privately that currently deployed
BH> routers tend to kick any packets with options to the slow (software)
BH> forwarding path since the options might require the router to take
BH> special action. Perhaps its possible to change that behavior with a
BH> software upgrade that offers a configurable to ignore
BH> timestamp options in favor of keeping IP packets with options in the
BH> fast path.
> Operators have been very leery of unrecognised or new options for
> many years - in fact my own proposal to solve the R&A problem using
> IPv4 options was shot down on those grounds at IETF 29.
Indeed - 13 years ago you were on the case:
Most people felt that AEIOU would work and could, with effort,
be developed into a viable stop-gap solution. There was one
significant technical issue, the impact of option analysis on
local router performance.
It is pointed out that it is dangerous to assume that new
options will survive passage across the Internet; Rob Ullman
has done some investigation on what routers and hosts do to
After this discussion, Brian is not inclined to propose it as an
''active proposal.'' No mandate for a working group is
perceived, but it is worth keeping the discussion alive for
anybody interested (send mail to Brian Carpenter if this is
you). Deering noted that AEIOU should go into the same status
as as EIP: honored, revered, unimplemented.
Unless there is consensus that today's installed base of BGP and
internal network routers would handle IPv4 packets with a new option
header with the same ease and speed as ordinary IPv4 packets, I
propose that the option-header aspects of Bill's IP-Via proposal
also be "honored, revered and unimplemented".
So it is back to the drawing board with IP-in-IP, UDP or perhaps GRE
encapsulation. However, while I need to think about it a lot more,
I still like Bill's ideas about ITR behaviour in fragmenting packets
initially, and being able to assume a 1280 MTU in the path to the
ETR. Modifying SYN packets sounds good in some ways, but involves
deep packet inspection for lots of short packets (a good DoS target
too), and I think it is rather oppressive to have routers messing
with the contents of host's attempts to initiate communications.
to unsubscribe send a message to email@example.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg