Subject: [NSIS] MRI issue

From: "Thanh Tra LUU" <[email-masked]>
Date: Tue, 4 Oct 2005 11:48:59 +0200

Hi,

I look at the MRI definition in the GIST protocol. Even though it's clear
that MRI is used as a guide for GIST nodes to route signaling messages. Two
example of MRM are stated in the draft NTLP version 8 for predictive routing
and NAT address revervation.

The problem i see is why MRI must be at the NTLP level while GIST is only
responsible for transporting signaling messages hop by hop. The MRI is
something at NSLP signaling application level. I don't see any benefit of
using MRM without NSLP in two foregoing examples. Moreover, because of the
problems of compatibilty, it's difficult for GIST to define new MRI.

I agree that in the case of RSVP, and only in this case MRM has a meaning.
Thus, i think it's better if GIST only sends signaling message along the
data path, sending directly or using an IP router alert option. Other
routing information will be defined at the NSLP layer.

nary

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 27, 2005 9:50 PM
Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-08.txt

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Next Steps in Signaling Working Group of
the IETF.
>
> Title : GIST:  General Internet Signaling Transport
> Author(s) : H. Schulzrinne, R. Hancock
> Filename : draft-ietf-nsis-ntlp-08.txt
> Pages : 126
> Date : 2005-9-27
>
> This document specifies protocol stacks for the routing and transport
>    of per-flow signaling messages along the path taken by that flow
>    through the network.  The design uses existing transport and security
>    protocols under a common messaging layer, the General Internet
>    Signaling Transport (GIST), which provides a universal service for
>    diverse signaling applications.  GIST does not handle signaling
>    application state itself, but manages its own internal state and the
>    configuration of the underlying transport and security protocols to
>    enable the transfer of messages in both directions along the flow
>    path.  The combination of GIST and the lower layer transport and
>    security protocols provides a solution for the base protocol
>    component of the "Next Steps in Signaling" framework.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-08.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the
message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-nsis-ntlp-08.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-ietf-nsis-ntlp-08.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

----------------------------------------------------------------------------
----

> _______________________________________________
> 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: "Thanh Tra LUU" <[email-masked]>
Date: Wed, 5 Oct 2005 12:14:52 +0200

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.
- NSLP can ask GISP to transport a message hop by hop (with RAO) or directly
to a specific node.
- 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. without NSLP, GIST cannot decide how MRI is changed in your examples.
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".

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.