Subject: RE: [NSIS] MRI issue

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 6 Oct 2005 11:28:18 +0100

Hi Nary,

I'm still not really following. Please see below:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thanh Tra LUU
> Sent: 05 October 2005 11:15
> To: [email-masked]
> Subject: Re: [NSIS] MRI issue
> 
> 
> hi,
> 
> in fact, the arguments are as follows:
> - the flow id can be changed anytime, because of mobility or 
> other reasons > (e.g. NAT). For this reason, session id is defined.

True, but I'm not sure I see the relevance.

> - NSLP can ask GISP to transport a message hop by hop (with 
> RAO) or directly to a specific node.

Partly true: the NSLP can ask GIST to transport a message along a
flow path to the next/previous node. Whether RAO mechanisms are
used is up to GIST. The NSLP *cannot* ask GIST to transport a message
to a specific node *unless* it is a node which it has previously 
received a message from.

> - there is no meaning in two cases you give as examples if a 
> GIST node does not support NSLP. A message must goes up to NSLP and
again 
> goes down to GIST. 

True (well, at least the second sentence...) if the message is about
that
NSLP.

> without NSLP, GIST cannot decide how MRI is changed in 
> your examples.

GIST never changes the MRI. It only uses the MRI to decide how to
route messages. (NATs can change the MRI. It is an implementation
issue whether this goes through the code that implements the
NATFW NSLP, or some other code which manages binding tables in the
NAT which is coordinated with the NATFW NSLP.)

> otherwise, GIST must be capable of communicating with NAT/FW 
> ALG to know the
> change of IP address even without NSLP. i don't know weather 
> this is a good
> idea or not.
> 
> thus, i think MRI should be only as flow id as before. i'm afraid GIST
> becomes too "heavy".

The functionality is needed in any case. The question is how it is
structured within the specification. 

What MRI do you think the NATFW NSLP should use for the REA message?

robert h.

> 
> nary
> 
> 
> 
> ----- Original Message ----- 
> From: "Hancock, Robert" <[email-masked]>
> To: "Thanh Tra LUU" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, October 04, 2005 4:04 PM
> Subject: RE: [NSIS] MRI issue
> 
> 
> Hi Nary,
> 
> At the moment, I'm not quite sure that I follow the details of
> your argument or what you are proposing.
> 
> - if you want to send messages along the data path, the definition
> of MRM 0 and the MRI format for it are required at the GIST level.
> Otherwise it has no way to know what path to send data along. There
> are several aspects of message routing which are all interrelated,
> and it makes sense to describe them together.
> 
> - for the NAT reservation case, we think it is clear that since
> there is *no* existing flow path to send messages along, a different
> MRM *must* be defined. And indeed, many of the other aspects of
> message routing are also changed in this case. but the rest of
> GIST operation is not changed.
> 
> - the MRI is used *both* at the GIST and NSLP level. The NSLP has
> to describe how it wants the messages to be routed, and GIST has
> to do the routing.
> 
> - there is discussion in the draft (end of 3.3 and 4.3.4) which
> I think shows why there is no practical barrier to deploying new
> MRMs if they are actually required.
> 
> As a side comment, I don't think anyone expects new MRMs to be
> defined very often.
> 
> Does this answer your concerns?
> 
> robert h.
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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