Subject: RE: [NSIS] How to handle unknown MRMs

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 25 Aug 2005 13:44:58 +0100

Hi Henning,

this is a good question. i think there are several components 
to the right answer (what follows is basically me thinking
aloud, but the short answer is that your analysis is correct).

1. GIST was always designed (using the same techniques as RSVP,
in fact), to work OK in regions where there were no GIST nodes
at all. Query messages can always be forwarded at the IP layer
provided the destination IP address can be forwarded to. It's
not as good as doing a proper analysis of the MRM and deciding
exactly what to do with the message, but it's better than nothing
(and MRM designers should be prepared to cope with this scenario).

2. If a Query message actually arrives at a node which will become
a GIST peers (i.e. it has the right NSLP which wants to take part
in the signalling session and so on), then in some senses the
receiving GIST node doesn't *need* to understand the MRM at all.
It just needs to be able to use it as a table index and pass it
up to the NSLP. (Actually this is a slightly extreme view, and
I wouldn't expect a GIST implementation to be able to receive
unknown MRMs. But there is an asymmetry between the level of support
required in the sender and the receiver.)

3. Fundamentally, I think it is necessary for NSLPs to fix which
MRM they use. (In practice this should not be an issue, but it
probably needs to be written down.) Then the only case where a
node doesn't understand an MRM is where is doesn't support the
NSLP either, in which case forwarding the message as though one
were totally NSIS-unaware is the right thing to do; if the message
cannot be forwarded (e.g. because it's reached the destination
in the encapsulation) then we already have an error message for
that circumstance.

cheers,

robert h.

ps. recorded at 
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue66

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Henning Peters
> Sent: 23 August 2005 14:35
> To: [email-masked]
> Subject: [NSIS] How to handle unknown MRMs
> 
> 
> Hello WG, hello Robert,
> 
> today we discussed the new loose-end MRM and asked ourselves how GIST
> shall behave in general when it is about to handle an MRM 
> that might be
> specified in a future RFC and is yet unknown to a GIST 
> implementation that
> relies on current RFCs. We didn't find a part in the spec that clearly
> defines how an implementation shall handle unknown MRMs.
> 
> Our view is to treat those MRMs with the same behavior as if 
> the NSLP is
> unknown, that means: relaying without modification of the message or
> without setup up of any state. Otherwise future MRMs might 
> get blocked and
> can't be deployed in a proper way if an old implementation is 
> on the path.
> 
> Is this assumption correct?
> 
> Christian Dickmann & Henning Peters
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Christian Dickmann" <[email-masked]>
Date: Fri, 26 Aug 2005 16:26:20 +0200

Hi Robert,

> required in the sender and the receiver.)

This is really an extreme view, but certainly it is somehow right.
The problem is the 3-way handshake. The first problem would be the
D-Flag in the Response. If you do not consider the MRI in the GIST
layer, then you can not send a valid Response. So the 3-way handshake
won't be completed and so the NSLP might never be triggered. 
Even if the 3-way handshake works, we get new problems. Lets say, that
GIST established a MRS using an MRM that it does not understand.
The NSLP payload is passed to an NSLP that understands the MRM (that is
already strange). The NSLP wants to forward the message downstream 
and so uses the API to send the message. As you said, sending is a
different issue. Sending means, that you can read the MRI to find the
destination IP address. The message is stuck and to make everything worse,
we already got a MRS with the upstream peer.

I think that in practice, a GIST node not supporting a MRM should not try
to participate in a signaling session using that MRM. In addition, every
NSLP should state which MRMs it supports. So the GIST node should only 
consider Queries with a MRM supported by the GIST implementation _and_ the 
NSLP (implementation, but specification as well). 

Did I miss something?

Christian