[RRG] Re: TRRP-Via - option header vs. encapsulation

[Robin Whittle <rw@firstpr.com.au>]

Hi Bill,

I think your new proposal:

   http://bill.herrin.us/network/trrp-via02.html

looks very promising.  I haven't looked at the IPv6 section yet.

I think "next best preference ITR" should be "next best preference ETR".

I don't understand this:

  "If an ETR is unreachable, the via-tagged packet will follow the
   default route and fall back into an ITR."

Can you explain this more fully?

I think the first major requirement:

  ITRs and ETRs located so that there is always at least an 1280
  byte MTU on all routers between them.

is practical.

I am not so sure about this one, at least for Ivip:

  No filtering of ICMP destination unreachable messages between
  wherever the ITR and ETR are located.

because I want ITR functions to be able to be performed in sending
hosts, and I want ITRs and ETRs to be potentially quite deep in the
networks, not just at border routers.

By the way, I found a good explanation of how ICMP filtering can
screw up PMTUD:

  http://www.netheaven.com/pmtu.html


I want to think about TRRP-Via02 lot more, but I can imagine
adapting it to Ivip, by removing the second and subsequent lower
priority mapping options.

TRRP-Via and TRRP-Via02 are like Ivip in that the Source Address
(SA) of the packet when travelling between ITR and ETR is the same
SA as of the sending host.  All other approaches have the SA being
that of the ITR.

Your proposal doesn't have any means by which an aggrieved router
could find out which ITR sent the packet to it in error - as with
the current Ivip proposal.  I considered using UDP encapsulation so
I could include the ITRs address in the UDP data to solve this problem.

I could restructure your proposal (for IPv4 at least) to use and
encapsulation header rather than the modified original header plus
an option header.  This would be much the same as Ivip.  However, I
think your proposals about the ITR:

  Automatically assuming a shorter (say 1280) MTU and therefore
  fragmenting the packet before sending it to the ETR.

  Sending ICMP destination unreachable messages to the sending
  host in order to get it to send subsequent packets short
  enough not to need fragmentation.  (I am unclear as to whether
  one or the other or both of the above would be used.)

  Trying to find a higher MTU later, assuming there is more
  traffic to this ETR.

  Modifying Syn packets to make TCP run with short enough
  packets that they won't need to be fragmented to fit inside 1280.

are really interesting and probably practical.  So I will think
about adopting them into Ivip, either with an encapsulation header
as Ivip currently uses or with your new option header arrangement.

If I use your option header arrangement, I wouldn't need any list of
"been there" addresses, since there is no concept in Ivip of an ETR
acting like an ITR, to look up the mapping and to send the packet to
some other ETR according to second priority mapping information
(there is only one mapping option in Ivip) if the first ETR can't
reach the destination host.

If the option header I am thinking of for Ivip just included the
destination address of the ETR (4 bytes) and the 4 bytes which
precede it (the first 4 bytes of the option header), this is 8 bytes
- 12 bytes shorter than IP-in-IP encapsulation as Ivip currently uses.

If I added 4 bytes to carry the ITR's address, this would make it 16
bytes, which is 4 bytes shorter than plain IP-in-IP (which doesn't
have the ITR address, as I use it in Ivip) and a lot shorter than
using UDP encapsulation, as I previously proposed to carry the ITR
address.

Is there any reason to think that routers in general - BGP and
internal routers - will be upset by an option header, specifically a
new kind of option header as you suggest?

  - Robin


--
to unsubscribe send a message to rrg-request@psg.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