Subject: [MBONED] AMT - new message proposed

From: "Tony Ballardie" <[email-masked]>
Date: Tue, 30 Sep 2008 10:18:23 +0100

This was originally sent to the AMT mailist list last night but it was 
considered more appropriate for mboned.

There was some concern expressed on the AMT list about proposing changes

at this stage when AMT is in wg last call (apparently has been for some
time). 
But there was also concern expressed that *not* including key changes to
the 
spec at the earliest opportunity has little value.

I've made a slight correction to my posting last night, included here:

Tony
----------

I've been involved with testing the UT Dallas Gateway implementation 
and Cisco's Relay implementation over the past week or so.

A number of things have come to light which require more detailed /
tighter 
specification. I'll try and detail these later in a separate e-mail.

Tests have exposed an anomalous condition whereby the Relay and Gateway 
become out of sync; the Relay expires the tunnel but the G/w does not. 
This can probably be corrected by a clearer definition of tunnel expiry 
timeouts and what messages refresh them at what intervals. But there
still
may be situations where a Relay receives a Gateway message
"unexpectedly"
and there are other scenarios, described below, that need further 
consideration. 

To cater for these scenarios I'm proposing the introduction of a new
message
type: RESET. 

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type=0x7  |   Len |  IPV  |    Reason     |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Response Nonce (bounced by Relay)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Alternate Relay IP address #1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       ..............                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Alternate Relay IP address #n                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type: message type 0x7 RESET
Len: length of this message in 32-bit words
IPV: IP version of any addresses being carried
Reason: codes tbc
Response Nonce: Nonce from the Gateway's message that triggered this
Reset 
Alternate IP address: IP address of alternate Relay

It essentially works like this:

The Reset is only ever issued by the Relay.

It's sent when the Relay receives any message *other than a Discover*
but 
the Relay has no tunnel to the said G/w. In this situation something has

clearly gone wrong. 

The G/w keeps track of the Nonces on outstanding messages sent to a 
particular Relay.If a Reset is returned which includes any of those 
outstanding Nonces the G/w immediately tears down its tunnel with that 
Relay and re-Discovers. 

There's also the situation where, for policy reasons, or strict tunnel
limits, 
the Relay refuses a G/w Discover...

If the Relay has reached its tunnel limit, the Relay should withdraw the

anycast prefix [suggested by Dino@cisco]. There could be a transient
state 
where the Discover arrives but it's not quite withdrawn the prefix yet. 
In this case the Reset "reason" code should indicate that. In response
the 
G/w would wait 1-2 secs before re-Discovering rather than re-Discovering

immediately.

Policy might dicate only certain IP addresses can set up a tunnel. In
this 
case the Relay should respond to non-authorized Gateways with a Reset
with 
at least 1 alternate Relay IP address (configured). This means the Relay

has to accept (if it doesn't already) Discovers not targeted at the
Relay 
anycast address.

Could we find consensus for this?

Tony
_______________________________________________
MBONED mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mboned