Subject: [NSIS] I-D Action:draft-ietf-nsis-ext-02.txt

From: [email-masked]
Date: Mon, 9 Mar 2009 11:45:01 -0700 (PDT)

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           : Using and Extending the NSIS Protocol Family
	Author(s)       : J. Manner, et al.
	Filename        : draft-ietf-nsis-ext-02.txt
	Pages           : 26
	Date            : 2009-03-09

This document gives an overview of the Next Steps in Signaling (NSIS)
framework and protocol suite created by the NSIS working group during
the period 2001-2009 together with suggestions on how the industry
can make use of the new protocols, and how the community can exploit
the extensibility of both the framework and existing protocols to
address future signaling needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ext-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 10 Mar 2009 18:43:56 +0100

Just a quick comment: I would envision an update of the extensibility 
document could consider potential use for off-path signaling, especially 
in the GIST section.
Xiaoming

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Mar 2009 20:08:43 +0200

This version of the document addresses my comments. Thanks for the quick
update, Elwyn.  

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>[email-masked]
>Sent: 09 March, 2009 20:45
>To: [email-masked]
>Cc: [email-masked]
>Subject: I-D Action:draft-ietf-nsis-ext-02.txt 
>
>This document gives an overview of the Next Steps in Signaling 
>(NSIS) framework and protocol suite created by the NSIS 
>working group during the period 2001-2009 together with 
>suggestions on how the industry can make use of the new 
>protocols, and how the community can exploit the extensibility 
>of both the framework and existing protocols to address future 
>signaling needs.
>
>Below is the data which will enable a MIME compliant mail 
>reader implementation to automatically retrieve the ASCII 
>version of the Internet-Draft.
>

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 10 Mar 2009 18:25:07 +0000

Xiaoming Fu wrote:
> document could consider potential use for off-path signaling, 
> especially in the GIST section.
> Xiaoming
Hi.

Thanks for the input.

How much of a discussion would you think we should have? We have had 
considerable discussion of the possibilities of off-path signaling at 
least among the authors of the NATFW NSLP, but it would be a major 
change to how GIST works.

I think we could make a 'passing mention' but going into too much detail 
is probably out of scope. The question is how elastic is extensibility?

Regards,
Elwyn

---

From: Teemu Huovila <[email-masked]>
Date: Wed, 11 Mar 2009 14:43:10 +0200 (EET)

Hello

I have read the -02 ext-draft. Predominantly it looks good to me. Only a 
couple of small issues and a bunch of possible typos caught my eye.

The first issue is with the use of "MRMs" on page 6. The the abbreviation 
MRM (or even the concept of different message routing methods) is not 
explained anywhere earlier in the text. My suggestion is that, either 
remove the "MRMs" and use rest of the bullet as is, or somehow change it 
so that Message Routing Method is spelled out. Perhaps something like:

"Initial focus on path-coupled signaling: GIST transports messages towards 
an identified unicast data flow destination based on the signaling 
application request. This is called the Path Coupled Message Routing 
Method (PC MRM). The framework also supports a "Loose-End" message routing 
method (i.e. LE MRM) used to discover GIST nodes with particular 
properties in the direction of a given address, for example the NAT/FW 
NSLP uses this method to discover a NAT along the upstream data path. GIST 
does not directly support path-decoupled signaling, e.g., QoS signaling to 
a bandwidth broker or other off-path resource manager."

The second issue I have is with almost the whole section 8.6. The section 
does point out many central issues in NSLP design and implementation, but 
it is extremely vague. Many complicated concepts are only briefly 
mentioned or hinted at. Some of the more vague points might cause more 
confusion, than shed light. Finding a suitable level of abstraction for 
the descriptions is admittedly very difficult. To create any new, more 
than trivial, NSLP, I think one would have to understand large parts of 
the GIST spec, like the API, the MRMs, the MRI and flow identification and 
GIST peering.

I would change at least the third to last bullet, e.g. "Source IP address: 
...". It could say something more like:

"MRI processing: It is sometimes challenging to find out at the NSLP, what 
the source IP address in the MRI should be, especially when a node has 
multiple interfaces. Moreover, the role of the source IP address may 
differ if the node processing an NSLP message is the source of the 
signaling flow, or an intermediate node on the signaling path. A node 
processing a received NSLP message also needs to take into account the MRI 
flow direction. So in many cases an NSLP application needs to be aware of 
its position and role on the signaling path and have some (,external to 
GIST,) means of finding out local IP addresses that are suitable for use 
in the signaling."

Thanks to Lauri and Nuutti for their help on the new text.

The other possible errors or typos are less important, so Ill just list 
them below:

Page 5, second paragraph: "This is achieved by routing signaling 
massages.." refers to multiple messages, but later in the sentence and 
paragraph a single message is described. I suggest using message or 
messages consistently throughout the paragraph.

Page 7, second line: "request also" --> "also request"

Page 8, third paragraph: "requested by the new MA." Should this be 
"requested by the new flow." or "required by the potential new MA."?

Page 8, last paragraph + page 9 first: The beginning of this paragraph is 
one extremely long sentence. It looks like it could benefit from being two 
or three separate ones. "Concerns were raised" clashes with "as well as 
discovery of", at least in my ear. Could it be written as:

"Late in the development of GIST serious concerns were raised in the IETF 
about the security risks and performance implications of extensive usage 
of the RAO [I-D.rahman-rtg-router-alert-dangerous]. It was also discovered 
that several existing implementations of RAO were inconsistent with the 
standards and would not support the NSIS usage."

Page 9, fourth paragraph: "NSIS state is held both at the signaling 
application layer and in the transport layer.." I would add "signaling" 
before "transport layer", since it is used before the "application". Then 
it becomes clearer, that the ntlp layer is the referred transport layer.

Page 10, last paragraph: should the "support of" bits be "support for"?

Page 12, fourth paragraph: "signalled" --> "signaled" (or change two other 
signaled in the document to signalled"?)

Page 16, second bullet: The DCCP draft is mentioned, but not the SCTP one. 
The SCTP draft is not even referenced in this document.

Page 17: is "interception scheme" the same as "interception class 
mechanism" or "interception mechanism". Could one expression be used 
consistently through the text describing interception schemes and classes?

Page 21, first paragraph: "Yet, on the other hand" --> "Yet" or "On the 
other hand"

Page 21, second bullet: "than can from GIST" --> "that can arrive from 
GIST"

Page 21, last bullet: "defines currently" --> "currently defines".

Page 22, bullet at top of page: "and prevent" --> "and to prevent"

Several places(page 6 and 15) in the text use the expression "in future". 
I am not certain, but should it not be "in the future" in these contexts?

br,
Teemu

-- 
Teemu Huovila

---

From: Roland Bless <[email-masked]>
Date: Wed, 11 Mar 2009 19:39:16 +0100

Hi Xiaomin,

> document could consider potential use for off-path signaling, especially

This should be already covered:
Section 8.2:

o  Use of different Message Routing Methods: currently only two
      message routing methods are supported (Path-coupled MRM and Loose-
      End MRM), but further MRMs may be defined in the future.  See
      Section 3.8.  One possible additional MRM under development is
      documented in [I-D.bless-nsis-est-mrm].

EST-MRM is effectively a path-decoupled MRM.

Section 8.3:

 Another current proposal
   seeks to extend the whole NSIS framework towards path-decoupled
   signaling and QoS reservations [I-D.cordeiro-nsis-hypath].

Or what is missing from your point of view?

Regards,
 Roland

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 13 Mar 2009 18:34:17 +0100

> EST-MRM is effectively a path-decoupled MRM.
maybe worth making it clearer: firstly tell what does a path-decoupled 
MRM basically mean, then possibly an example... (comparison: while 
talking about path-coupled and loosely-coupled ones there is some text)
Xiaoming