Subject: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.txt

From: [email-masked]
Date: Tue, 03 Apr 2007 15:50:02 -0400

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 Signalling Transport
	Author(s)	: H. Schulzrinne, R. Hancock
	Filename	: draft-ietf-nsis-ntlp-13.txt
	Pages		: 177
	Date		: 2007-4-3
	
This document specifies protocol stacks for the routing and transport
   of per-flow signalling 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
   Signalling Transport (GIST), which provides a common service for
   diverse signalling applications.  GIST does not handle signalling
   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 Signalling" framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-13.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-13.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-13.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

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 4 Apr 2007 00:31:45 +0200

Dear all,

We are starting an extended WGLC for GIST. The WGLC starts on April  
4th and will run for *three* weeks.

Everybody of the NSIS WG should review GIST once again, especially  
all **implementers** and **NSLP authors**.

Thank you and looking forward to your reviews and comments

   Martin

Anfang der weitergeleiteten E-Mail:

> Von: <[email-masked]>
> Datum: 3. April 2007 21:50:02 MESZ
> An: <[email-masked]>
> Kopie: <[email-masked]>
> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-ntlp-13.txt
>

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Apr 2007 10:55:41 +0200

I would like to raise a warning from my side regarding this WG last 
call. Unless I actually see a number of persons stating that they have 
read the document in this version I will refuse to process into a second 
AD review. There need to be clear consensus from the WG that this is 
what you want and that it doesn't contain any serious errors.

Please remember that unless you actually get GIST published all your 
work on NSLPs will be for nothing. And unless you actually help ensure 
that the document really is ready this time for publication the whole WG 
effort can be terminated. I need to convince a number of ADs that you 
actually taken serious looking on the problems raised and are agreeing 
on how to resolve them.

Magnus Westerlund
Your AD

Martin Stiemerling skrev:
> Dear all,
> 
> We are starting an extended WGLC for GIST. The WGLC starts on April 4th 
> and will run for *three* weeks.
> 
> Everybody of the NSIS WG should review GIST once again, especially all 
> **implementers** and **NSLP authors**.
> 
> ------------------------------------------------------------------------
> 
> FILE DELETED
> ------------
> 
> Warning!
> 
> The attached file draft-ietf-nsis-ntlp-13.URL has not been delivered.
> The reason is due to that the filter FILE FILTER= unnamed: *.url is in effect.
> 
> 
> Ericsson Group IT
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 18 Apr 2007 11:37:22 +0200

Dear all,

This is a friendly reminder for the currently running WGLC for GIST.

Apparently, there have not been much reviews and/or comments on GIST.  
I interpret this as *nobody* has read the document. Consider also  
Magnus' email response to the original WGLC!

In any case, I would like to encourage all WG memmbers and especially  
*all* implementers and NSLP authors to review GIST and to send their  
comments to the list.

It is even good to send something along the lines "yes, I have read  
the document and it is fine with me."

Thanks and looking forward to your reviews,

   Martin

Am 04.04.2007 um 00:31 schrieb Martin Stiemerling:

>> <ATT966628.TXT>
>> <draft-ietf-nsis-ntlp-13_URL.DEFANGED-0>
>> <ATT966629.txt>
>
>
>

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 19 Apr 2007 14:35:49 +0300 (EEST)

Dear all,

I have reviewed the GIST spec and have no major concerns. A couple of 
small nits and editorial things are mentioned below.

Yet, in a separate email I have suggested the addition of "Peering data" 
that could be used by NSLPs to give more details for the peering decision 
when receiving a QUERY. This is an important function I would like to be 
enabled. I can provide e.g. text for a small subsection that identifies 
the issue, shows the solution and discusses its implications on the NSLP 
layer.

The nits:

- It is sometimes difficult to follow, what is meant by "flow" in the 
  document. Mostly it seems to be used for data flows, but sometimes it 
  seems it is used in signaling flows, or left otherwise unspecified. A 
  couple examples: p.20 6.A "for that flow" (what flow?), p.22 "Section 
  4.2 describes the per-flow and" (what flow?).

  SUGGESTION: add "data" in front of "flow" where the text really talks 
  about the data flow being signaled for.

- p.7: Would the use of DTLS be counted as "C-mode" or "D-mode"?

- p.15: s/which are nothing/which have nothing/

- Section 3.10: A figure would help understand the example

- p.28: s/match, the GIST/match, GIST/

- p.28, S4.3.1, last paragraph: A node receives a packet with a hop count 
  of zero, but I think this would be a special error case. Why would the 
  previous GIST hop send a message out with a hop count of zero, since it 
  knows the message will be discarded by the recipient?

- p.30 "GIST MUST verify that it is not the direct destination of an 
  outgoing message...": don't get the meaning of this sentence. A node is 
  sending a packet to itself, internally?

- p.38: s/a abstract/an abstract/

- p.42, S4.4.4: You could make the timer description clearer, e.g., 
  separate it from the main body of the paragraph, e.g., a formulae, and 
  could also add some examples.

- p.47, Section 5 could have a short introduction

- p.47: why MUST the objects be carried in the proposed order? It would 
  put this as a SHOULD. At least the QoS NSLP says "SHOULD" for this.

- p.47: s/the MRI SID/the MRI, SiD/

- p.48, middle of page: The Confirm echos something, yet, the information 
  is something the querying node included in the first place. Can this 
  information change as it comes back from the responding node? I would 
  rephrase this to "The Confirm MUST include the MRI and SID, and echo the 
  Responder-Cookie if the Response carried one."

- p.54: I would make the magic number clearly visible, and even mention 
  earlier in the document. Now one has to be very careful to find the 
  value of the magic number.

- p.55: "If the MRM defines the use of RAO, the sender MUST include it by 
  default." This latter "by default" sounds wierd. Is it needed at all, 
  isn't "MUST include it." enough?

- p.55: "Note that all MRMs require S=1 for at least some retransmissions, 
  so ICMP errors related to fragmentation will be seen at the Querying 
  node". Could you elaborate a bit on this? Didn't quite get it.

- p.56: "within the networ which"

- p.60: "except that that the"

- p.63, S.5.7.1: The discussion about the stack proposal object would need 
  an example, a figure, to illustrate how the object is composed.

- p.63: What is "SCD" the acronym? Stack-Configuration-Data? First time it 
  is used in the text body.

- S.5.7 in general: should there be a section about using UDP as the MA 
  transport protocol? This is not really presented anywhere.

- p.85: s/to a change the opposite/to a change in the opposite/

Jukka

---

From: Lars Eggert <[email-masked]>
Date: Thu, 19 Apr 2007 17:47:05 +0300

> the issue, shows the solution and discusses its implications on the  

One of the points that came up during the IESG evaluation was that  
GIST was already very complex, and other ADs were questioning whether  
all the features were really needed or if it could even be understood  
and implemented.

I think Magnus and me got the point across that a generic signaling  
framework comes with a certain level of complexity, but if the next  
revision that hits the IESG adds more features - esp. ones that  
apparently
aren't required for any existing NSLP - that probably would send a  
very wrong message.

The WG needs to really think carefully about this.

Lars

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 19 Apr 2007 16:32:03 +0100

hi all,

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: 19 April 2007 15:47
> To: ext Jukka MJ Manner
> Cc: nsis
> Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt
> 
> > that could be used by NSLPs to give more details for the peering 
> > decision when receiving a QUERY. This is an important 
> function I would 
> > like to be enabled. I can provide e.g. text for a small subsection 
> > that identifies the issue, shows the solution and discusses its 
> > implications on the NSLP layer.
> 
> One of the points that came up during the IESG evaluation was 
> that GIST was already very complex, and other ADs were 
> questioning whether all the features were really needed or if 
> it could even be understood and implemented.
> 
> I think Magnus and me got the point across that a generic 
> signaling framework comes with a certain level of complexity, 
> but if the next revision that hits the IESG adds more 
> features - esp. ones that apparently aren't required for any 
> existing NSLP - that probably would send a very wrong message.
> 

there are a couple of points here.

1. for this particular case of early peering data, I believe that
the functionality necessary is already in the spec (has been since
version 7) and is used by the QoS-NSLP among others. I don't believe
anything extra is needed but I'll explain why in a separate mail.

2. as a more general point, if people spot functionality or text
that they feel is unecessary (for whatever reason) then that would
be fine to highlight during the WGLC process. The list of things
that have been added recently can be found in the change history
(E.1 and E.2), and it would be good to focus here particularly
if the additions seem worthwhile. some highlights:

- the authorisation model (mainly 4.4.2) and TLS name checking
rules (5.7.3.1)
- recommendations on evolvability of D-mode (3.2)
- details on IP option handling (5.3.2)
- guidance on overload protection (mainly 8.4)
- multipath handling (7.1.4)

in particular, for the last two it would be good to know if
people find the text helpful or not (since it is mainly 
informative). Related to the multipath handling discussion is
the question of whether GIST should have an explicit routing
state removal functionality, which strikes me as a case of
premature optimisation compared to what is already possible in
the protocol, but which some people have asked for in general
terms in the past.

At the moment I am unaware of any outstanding specific 'feature 
XXX could be removed' suggestions (there have only ever been 
very few) but that does not mean that some could not be made.

r.

---

From: <[email-masked]>
Date: Thu, 19 Apr 2007 11:54:28 -0500

I strongly support Lars on this.  I do not thing we should be
considering additional
features at this point. I think we need to get this complete and if
there are any
additional features which are needed, we should address them after we
have some 
deployment experience.

John 

>From: ext Lars Eggert [mailto:[email-masked]] 
>Sent: 19 April, 2007 07:47
>To: ext Jukka MJ Manner
>Cc: nsis
>> decision when receiving a QUERY. This is an important function I
would 
>but if the next revision that hits the IESG adds more features 
>- esp. ones that apparently aren't required for any existing 
>NSLP - that probably would send a very wrong message.
>

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 20 Apr 2007 10:05:39 +0300 (EEST)

Hi Lars (& John),

GIST already does this. It sends the NSLP ID and MRI as "peering data", 
every time unprotected. NSLPs must be aware of that, especially if privacy 
is an issue. Tracking NSLP+MRI combinations, you can track a user and his 
signaling in the network.

The proposal on the table is to allow more information besides the above 
two data items. This data is up to the NSLPs, and has the same concerns as 
the NSLP ID and MRI currently. This affects only the GIST API.

We are working on two new NSLPs. At least of the NSLPs would really need 
this additional peering data. Otherwise the whole NSLP gets really, and 
unnecessary, complex. We will release the spec of this NSLP as soon as it 
is sensible to propose new work items in NSIS.

We are working on our own GIST implementation, and it will be providing 
the enhanced API as discussed above.

Regards,
Jukka

On Thu, 19 Apr 2007, Lars Eggert wrote:

> One of the points that came up during the IESG evaluation was that GIST was
> already very complex, and other ADs were questioning whether all the features
> were really needed or if it could even be understood and implemented.
> 
> I think Magnus and me got the point across that a generic signaling framework
> comes with a certain level of complexity, but if the next revision that hits
> the IESG adds more features - esp. ones that apparently
> aren't required for any existing NSLP - that probably would send a very wrong
> message.
>

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 20 Apr 2007 11:36:03 +0300 (EEST)

Hi,
a few comments below.

Jukka

On Thu, 19 Apr 2007, Hancock, Robert wrote:

> DTLS requires the establishment of state between the endpoints, 
> and so is (clearly?) C-mode. 

Ok. :)

> if it was a broken implementation ;-)
> Are you suggesting we should have a different error code?

A GIST implementation should never send a packet out with a hop count of 
zero, that was my point. Not the error code itself. But a node may anyway 
do as you wrote, just in case the previous hop is misbehaving.

> could you make a suggestion? (which part of the timer description,
> etc.)

   "the refresh of existing ones.  A suitable value is 

               2 * routing states / rate limit (pkts/s)
               
   which leaves a factor of two headroom for new routing state creation 
   and Query retransmissions."

   Then you could 1-2 examples. (I don't really get this timer value, but 
   maybe it's just me)

> i've made this change (but to me, the meaning is still the same).

Yes, the meaning is quite similar, but somehow more logical to me, at 
least. :)

> would a skeleton box diagram in 5.3.1 be a good solution?

For example, yes.

> no, because you are allowed not to include it (see the remainder
> of the same paragraph). Suggested rephrasing?

So, is this then a "SHOULD", since you can do otherwise, if you have a 
good reason for it.

> if S=0, and a message is too big to be forwarded, the node
> with the constrained link will generate an ICMP "too big" message
> but send it to the source address in the IP header (which is 
> not the source of the signalling message). So this ICMP message
> is probably wasted. However, eventually one of these packets will
> be sent with S=1 which means that the ICMP message will be addressed
> to the signalling node. the point is not that the S flag setting
> changes the way the ICMP message is generated, but that the value
> of the S-flag tells you whether the message is going to go somewhere
> useful.

Right. This would be good to include in the spec.

> could we refer to Appendix D (which is a fairly complete example).

Ok.

> see p52 ;-)

But not in the _body text_, just in a list item's title

> probably not; while it is theoretically possible to negotiate
> UDP (if someone defines an MA-Protocol option for it), in 
> practice we would not allow it (because there is no congestion
> control provided with it). So I would not emphasise this possibility.

So, if I am a mobile node, then I always have to use TCP over the wireless 
link? Sounds "interesting". If an edge (access) router is the default 
router for, say, 10'000 mobile nodes, then there are at least as many 
TCP-states. With UDP, you could have a single port and use DTLS or IPsec. 
With mobile nodes coming and going, you would have more than that number 
of TCP states, e.g., the states for closing TCP connections.

Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 20 Apr 2007 11:41:11 +0300 (EEST)

Hi Rob,

> control provided with it). So I would not emphasise this possibility.

Reading again Section 3.2, it specifically talks about using D-mode on the 
edges of the network. Yet, the spec does not present how to use it with 
the MA in Section 5.7. I think there is a bit of a mismatch.

Jukka

---

From: "Vitor Bernardo" <[email-masked]>
Date: Fri, 20 Apr 2007 11:40:54 +0100

Hi all,

You can find UoC comments to the GIST first 3 chapters.

We are going to continue the review process to check any other issues that
could be improved.

*GIST v13 – UoC Review*

*[Page 4]*

*1.* Introduction
* *

Each of these different uses of signalling is referred to as a
signaling application.

Ø  What is a signaling application?

* *

GIST path-coupled signalling does not directly support multicast flows but
could be extended to do so, especially in environments where the multicast
replication points can be made GIST capable.

Ø  After reading this statement, I think that isn't clear for reader if GIST
is multicast or not.

*[Page 5]*

(…)

Instead, GIST manages its own internal state and the configuration of
the underlying transport and security protocols to ensure the transfer
of signalling messages on behalf of signalling applications in both
directions along the flow path.

* *

Ø  What's the objective of GIST?

Ø  After reading the first paragraphs of introduction this point isn't
clear…

*[Page 9]*

*3.* Design Overview

*3.1.* Overall Design Approach

*3rd paragraph:*

Ø  Text talks about "easy" message… and the "difficult" message? Probably
"easy" it's not the best word.

* *

*[Page 11]*

  It is possible to mix these two modes along a path.  This allows,
for example, the use of D-mode at the edges of the network and C-mode
in the core of the network.  Such combinations may make operation more
   efficient for mobile endpoints, while allowing *multiplexing* of
signalling messages across shared security associations and transport
connections between core routers.  The setup for these protocols
imposes an initialisation cost for the use of C-mode, but in the long
term this cost can be shared over all signalling sessions between
peers; once the transport layer state exists, retransmission
algorithms can operate much more aggressively than would be possible
in a pure D-mode design.

Ø  Multiplexing ??? What do you mean multiplexing? It's not clear here.

* *

*[Page 12]*

   *Predictive Routing*:  Here, the intent is to signal along a path
that the data flow may follow in the future.  Possible cases are pre-
installation of state on the backup path that would be used in the
event of a link failure, and predictive installation of state on the
path that will be used after a mobile node handover.

   *NAT Address Reservations*:  This applies to the case where a node
behind a NAT wishes to reserve an address at which it can be reached
by a sender on the other side.  This requires a message to be sent
outbound from what will be the flow receiver although no reverse
routing state for the flow yet exists.

Ø  This is well written, but I believe that this is a concept that is too
early in the document to be well understood.

*[Page 14]*

*3.4 *GIST Messages

Ø  What is and how works the 3 way handshake? What does each GIST message
type represents? MA-Hello?! What is this message?

o    Maybe a figure could help the understanding. Something like the current
Figure 4, but simpler.

o   Table with a small description of message types

*[Page 18]*

*3.10 *Example of Operation

Ø  Maybe a figure of "example of operation" could help to explain it better!

Ø  There is a cross-reference for a figure in section 2 but it would be
better to have a new one here to ease the reading.

-- 
BR,
Vitor Bernardo

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 20 Apr 2007 16:17:14 +0200

Hi all,

Thanks for all getting their reviews done and/or discuss open items.

The WGLC is extended for one week, as discussions have started late  
and to give further opportunities for reviews.

Thus, the WGLC runs now until **May 2nd**!

Thanks,

   Martin

Anfang der weitergeleiteten E-Mail:

> Von: Martin Stiemerling <[email-masked]>
> Datum: 18. April 2007 11:37:22 MESZ
> An: nsis <[email-masked]>
> Betreff: [NSIS] Reminder: WGLC for draft-ietf-nsis-ntlp-13.txt
>
> Dear all,
>
> Apparently, there have not been much reviews and/or comments on  
> GIST. I interpret this as *nobody* has read the document. Consider  
> also Magnus' email response to the original WGLC!
>
> In any case, I would like to encourage all WG memmbers and  
> especially *all* implementers and NSLP authors to review GIST and  
> to send their comments to the list.
>
>> We are starting an extended WGLC for GIST. The WGLC starts on  
>> April 4th and will run for *three* weeks.
>>

[email-masked]
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
London W3 6BL | Registered in England 2832014

---

From: <[email-masked]>
Date: Fri, 20 Apr 2007 10:55:08 -0500

Just to add to Martin's mail.  We need people to state that they have read the latest draft and they either agree or disagree with the current draft. We need to have strong consensus on this before sending it back to the IESG.  If we have only a few mails, the IESG will assume there is no interest in promoting GIST as an Internet Standard.
 
John

________________________________

From: ext Martin Stiemerling [mailto:[email-masked]]
Sent: Fri 4/20/2007 5:17 PM
To: nsis
Subject: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt 

Hi all, 

The WGLC is extended for one week, as discussions have started late and to give further opportunities for reviews. 

Thanks,

  Martin

	Dear all,

	Apparently, there have not been much reviews and/or comments on GIST. I interpret this as *nobody* has read the document. Consider also Magnus' email response to the original WGLC!

	In any case, I would like to encourage all WG memmbers and especially *all* implementers and NSLP authors to review GIST and to send their comments to the list.

	It is even good to send something along the lines "yes, I have read the document and it is fine with me."

	  Martin

		Dear all,

		We are starting an extended WGLC for GIST. The WGLC starts on April 4th and will run for *three* weeks.

		Everybody of the NSIS WG should review GIST once again, especially all **implementers** and **NSLP authors**.

		  Martin

			

			Send a message to:
			[email-masked].
			In the body type:

[email-masked]
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Roland Bless <[email-masked]>
Date: Mon, 23 Apr 2007 13:03:19 +0200

Hi Martin,

Martin Stiemerling wrote:
> The WGLC is extended for one week, as discussions have started late and
> to give further opportunities for reviews. 

Ok, great. Since we are updating our implementation to draft v13
we will give feedback soon.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Tue, 24 Apr 2007 16:05:46 +0300 (EEST)

On Thu, 19 Apr 2007, Hancock, Robert wrote:

> well, there are some sensible restrictions. For example, we would
> probably want the NSLP-Data object at the end (to avoid having
> to parse through it looking for GIST objects); the forwarding 
> decision in the bypass case (4.3.4) likes the MRI at the start
> without having to pull apart the whole message, and the NTO has
> to be at the start if it is present. Rather than try to pin 
> down exactly what was necessary, it seemed easier just to MUST
> the specific order.

Hi Rob,

Thinking again about this, if I want to define a new TLV object into GIST 
and put it somewhere before the NSLP-Data with the AB flags set to "AB=10 
(forward)", am I allowed to change the order of objects? If GIST mandates 
a certain order, then all future extension headers must be put after the 
NSLP-Data, which may be problematic.

Therefore, I would still propose that GIST gives an order for the objects 
and uses the word "SHOULD". IMO, this is anyway enough per RFC2119:

"SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

Jukka

---

From: Lauri J T Liuhto <[email-masked]>
Date: Tue, 24 Apr 2007 16:38:28 +0300

Hi all.

 Just got through the GIST specification. I think it is mostly quite
 good and clear, but I also have some comments/questions about it.

 1) 

    In a recent thread on the list we have had a discussion about
    NSLPs sending data within queries (relating to conditional
    peering). I've had some problems trying to understand the peering
    process with all the details relating to it.

    I think that Section 3 or 4 should clearly state what requirements
    there are to include NSLP data into queries. In the second last
    paragraph of page 74, Section 6.2, it is said quite clearly, but I
    was a bit lost before found it there:

    (Section 6.2 p. 74): 

    "The NSLP data MAY be carried in the Query if local policy and the
     transfer attributes allow it, otherwise it MUST be queued locally
     pending MA establishment."

 2) 

    I was (and still am, at least a bit) quite confused when trying to
    understand the processing of Gist hop count. For example, in
    Section 4.3.1 (last paragraph) it is said: 
    
    "Immediately after reception, the GIST hop count is checked.  Any
    message with a GIST hop count of zero MUST be rejected with a "Hop
    Limit Exceeded" error message (Appendix A.4.4.2).  Otherwise, the
    GIST hop count MUST be decremented by one."

    What exactly is meant with 'reception'? Does this mean that when a
    GIST aware node receives a GIST message, the GIST hop count is
    decremented every time, even if the message is not processed at
    the node but just instantly forwarded? (for example; the message
    is a Query, and the node is not running the NSLP in the question)

    What if we have a following scenario: 

      GN1    ------------------>   GN2      ------------------>  GN3
    NSLP a    Query(NSLPID:a)  (no NSLP a)    Forwards query   NSLP a

    In Section 4.3.2, bullet 2, it is said:
    "2.  The signalling application does not wish to set up state with the
       Querying node and become its peer.
       ...
       these diagnostics to be meaningful, any GIST node forwarding a
       Query MUST NOT modify it except in the NSLP payload; in
       particular, it MUST NOT modify any GIST payloads or their order.
       An implementation MAY choose to achieve this by retaining the
       original message, rather than reconstructing it from some parsed
       internal representation."

    Is the GIST hop count decremented?
  
    I think that Section 4.3.4 tries to clarify (also) this case, but
    I find the bullets 2 and 3 a bit unclear:
      
      "2.  A Q-mode encapsulated message contains an RAO value which
           is relevant to NSIS but not to the specific node, but the
           IP layer is unable to recognise whether it needs to be
           passed to GIST for further processing or whether the packet
           should be forwarded just like a normal IP datagram.
  
       3.  A Q-mode encapsulated message contains an RAO value which
           is relevant to the node, but the specific signalling
           application for the NSLPID in the message is not processed
           there."

    (2) What does '[RAO value] relevant to NSIS but not to the
        specific node' mean?
  
       and

    (3) Is this the case when an NSLP refuses to peer? If it is, then
        the Section title ("Nodes not Hosting the NSLP") is a bit
        confusing. If this is meant for something else, then I think
        I'm lost :)
    
 3) 

   In Section 5.3.1.  Normal Encapsulation

   "...The payload MUST always begin with a 32 bit magic number with
   value 0x4e04 bda5 in network byte order;..."

   -> "...The UDP payload MUST..." ?

 Best Regards,
 Lauri

---

From: Luís Cordeiro <[email-masked]>
Date: Tue, 24 Apr 2007 17:55:41 +0100

Hi Robert and all,

Based on a review made by Michel Diaz we send you some more comments
about the first 3 chapters of the draft:

[Page 4]

Introduction,
second paragraph

The path-coupled signalling definition is not clear. It should be
given an not path-coupled example.

[Page 8]

Requirements,
message routing definition

Before define the Message Routing there should be explained it's
difference with "normal" routing.

[Page
11]

Section
3.2, last paragraph

This paragraph is quite difficult to understand: in the first
line,
what does transport mean, and at the end: it is GIST that makes the
decision, as the application gives the requirements.

[Page 15]

Section
3.6, first paragraph

The probe concept is not clear in this context.

[Page
17]

Section
3.7, last paragraph

This paragraph is not clear.

Hope this can help.

BR,

Luís Cordeiro

Vitor Bernardo wrote:

Hi all,

We are going to continue the review process to check any other issues
that could be improved.

GIST v13 –
UoC Review

[Page 4]

1.
Introduction

Each of these different uses of signalling is referred to as a signaling application.

Ø
What is a signaling
application?

GIST
path-coupled signalling does not directly support multicast flows but
could be extended
to do so, especially in environments where the multicast replication
points can
be made GIST capable.

Ø
After reading this
statement, I
think that isn't clear for reader if GIST is multicast or not.

[Page 5]

(…)

Instead, GIST manages its own internal state and the configuration of the underlying transport and security protocols to ensure the transfer of signalling messages on behalf of signalling applications in both directions along the flow path.

Ø
What's the
objective of GIST?

Ø
After reading the
first paragraphs
of introduction this point isn't clear…

[Page 9]

3. Design
Overview

3.1.
Overall Design Approach

3rd paragraph:

Ø
Text talks about
"easy" message… and
the "difficult" message? Probably "easy" it's not the best word.

[Page 11]

It is possible to mix these two modes along a path.  This allows, for example, the use of D-mode at the edges of the network and C-mode in the core of the network.
Such combinations may make operation more    efficient for mobile endpoints, while allowing multiplexing of signalling messages across shared security associations and transport connections between core routers.
The setup for these protocols imposes an initialisation cost for the use of C-mode, but in the long term this cost can be shared over all signalling sessions between peers; once the transport layer state exists, retransmission algorithms can operate much more aggressively than would be possible in a pure D-mode design.

Ø
Multiplexing ???
What do you mean
multiplexing? It's not clear here.

[Page 12]

Predictive Routing:  Here, the intent is to signal along a path that the data flow may follow in the future.
Possible cases are pre- installation of state on the backup path that would be used in the event of a link failure, and predictive installation of state on the path that will be used after a mobile node handover.

NAT Address Reservations:  This applies to the case where a node behind a NAT wishes to reserve an address at which it can be reached by a sender on the other side.
This requires a message to be sent outbound from what will be the flow receiver although no reverse routing state for the flow yet exists.

Ø
This is well
written, but I believe
that this is a concept that is too early in the document to be well
understood.

[Page 14]

3.4 GIST
Messages

Ø
What is and how
works the 3 way
handshake? What does each GIST message type represents? MA-Hello?! What
is this
message?

o

Maybe
a figure could help the understanding.
Something like the current Figure 4, but simpler.

o

Table
with a small description of message types

[Page
18]

3.10 Example
of Operation

Ø
Maybe a figure of
"example of
operation" could help to explain it better!

Ø
There is a
cross-reference for a
figure in section 2 but it would be better to have a new one here to
ease the
reading.

--

BR,

Vitor Bernardo

On 4/12/07, Magnus Westerlund <[email-masked]>
wrote:

I
would like to raise a warning from my side regarding this WG last

that the document really is ready this time for publication the whole
WG

on how to resolve them.

Magnus Westerlund

Your AD

---

From: Roland Bless <[email-masked]>
Date: Fri, 27 Apr 2007 17:27:35 +0200

Hi Martin and all,

> Thus, the WGLC runs now until **May 2nd**!

What about input from the forthcoming Interop (from May 9th-11th)?
Comments from this event should probably also be catched in the WGLC...

Regards,
 Roland

---

From: "Robert Hancock" <[email-masked]>
Date: Fri, 27 Apr 2007 16:29:32 +0100

hi roland,

my plan has been to try to capture issues from the last call period
at least in the issue tracker, but not to push to the next stage
of the process until the interop is done and feedback incorporated.

robert h. 

> From: Roland Bless [mailto:[email-masked]] 
> Sent: 27 April 2007 16:28
> To: Martin Stiemerling
> Cc: nsis
> Subject: Re: [NSIS] Extending WGLC for draft-ietf-nsis-ntlp-13.txt
> 
> Hi Martin and all,
>

---

From: <[email-masked]>
Date: Fri, 27 Apr 2007 10:45:44 -0500

Roland,

We will consider input from the Interop, but the last call is for people
to look at the current document, after the changes coming from the IESG
review, and tell us if they are comfortable with the changes.

John 

>From: ext Roland Bless [mailto:[email-masked]] 
>Sent: 27 April, 2007 08:28
>To: Martin Stiemerling
>Cc: nsis