Subject: [NSIS] How to handle unknown MRMs

From: "Henning Peters" <[email-masked]>
Date: Tue, 23 Aug 2005 15:34:56 +0200 (CEST)

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 30 Aug 2005 17:24:04 +0100

hi christian,

i think we're in agreement. the key point is that NSLPs 
specifications will define the set of valid MRMs to use, in
which case any GIST node hosting an NSLP can also be 
required to understand the MRMs of that NSLP. (Probably
something about this needs to go in the extensibility
draft.) GIST nodes which don't understand an MRM should
be able to bypass the message without processing the MRI 
object in it.

the only subtlety is the case where a message arrives at
a GIST node where is *cannot* be bypassed, which would only
be the case if the GIST node was at the IP destination address
of the Query packet. But in that case, the error response
is sent based on the NLI object, and there is no need to 
create any routing state or understand the MRI at all.
(You would probably want to include the MRI in the error
message, however.)

robert h.

> -----Original Message-----
> From: Christian Dickmann [mailto:[email-masked]] 
> Sent: 26 August 2005 15:26
> To: Hancock, Robert; [email-masked]
> Subject: RE: [NSIS] How to handle unknown MRMs
> 
> 
> Hi Robert,
> 
> > 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.)
> 
> 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
> 
> 
>