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

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

Hi Bill,

I wrote in a previous message why concerns about BGP routers'
ability to quickly handle packets with option headers, or at least
novel option headers, seems to make your TRRP-Via proposal impractical.


RW>   "If an ETR is unreachable, the via-tagged packet will follow the
RW>    default route and fall back into an ITR."
RW>
RW> Can you explain this more fully?
> 
> TRRP works by removing all but a few thousand "globally routable"
> prefixes from the BGP table. The ETR's IP addresses are selected from
> these globally routable prefixes. So if you change ISPs you keep your
> CIDR block but get a new ETR address.

Wouldn't that mean there are only "a few thousand" ISP border
routers in the Net?   Perhaps you mean tens of thousands or a
hundred thousand or so.


> Any destination which is not in the globally routable space follows a
> default route which leads to the nearest ITR. There it is encapsulated
> (or in Via's case tagged) with an ETR as its destination address.
> 
> If the Via tagged packet reaches a router in the network which has no
> route in the table corresponding to that ETR then the packet will
> follow the default route and end up back at an ITR. That means the ETR
> is unreachable so the ITR should try the next one.

OK - thanks for this explanation.  I need to reread your TRRP
proposal in its various pages - maybe this was clearly explained there.


>> 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.
> 
> It was actually no filtering of echo request/response messages and
> destination unreachable messages between the ITR and ETR. This is
> because an ITR trying to discover a larger path MTU to the ETR will
> assume the ETR is dead if it can't get a sensible response to a ping.

OK.

> That requirement can be removed but the price is that the Via ITR will
> have no way to independently determine that an ETR is unavailable.
> It'd have to rely solely on the DNS route server.

At one point, I recall you wrote that TRRP is like Ivip, and unlike
LISP and eFIT-APT, in that it does not integrate multihoming service
restoration into the protocol or the ITR functionality.

I reflected this in the comparison chart:

  http://psg.com/lists/rrg/2007/msg00291.html

This business of ITRs having a list of options for which ETR to use,
and ETRs acting like ITRs if they can't send packets to the
destination host makes me think that TRRP does in fact have a lot of
multihoming service restoration functionality built into it.

With Ivip, it is up to the end-user - manually or more likely with
their own multihoming monitoring system - to quickly update the
mapping database so all the ITRs are tunneling packets to the
correct ETR.


Thanks for your account of the trouble caused by sites filtering
ICMP messages in a way which screws up PMTUD.


>> 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 considered adding that, but I'm not sure how much more useful to the
> aggreived router it is to know where the ITR was than it would be to
> know anything else about the other routers the packet passed through
> to get there.

I agree, in general, except for the case where the ITR is a
legitimate ITR which is malfunctioning.  It is vital that ITRs, at
least for Ivip, take themselves off-line (or if they are ITRDs, at
least stop advertising the relevant address blocks) if they are no
longer receiving mapping updates.

I considered this in:

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#rfc.section.14.1.2.3

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#rfc.section.14.1.2.7


To aid in debugging errant tunneling, which is errant due to the
end-user entering into the mapping database the IP address of
something other than the correct ETR, I proposed a centralised
search system for the current state and recent history of the entire
Ivip mapping database.

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#rfc.section.14.1.2.6


For instance, if some router (or host) gets a burst of tunnelled
packets, even for a second or two, the operator of that machine
needs to be able to find out who put that machine's IP address into
the Ivip mapping database.

 - 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