Subject: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt

From: Allison Mankin <[email-masked]>
Date: Sun, 08 Jun 2003 23:29:52 -0700

Marcus, John and WG,

Here are my AD Review comments on the NSIS requirements.  Overall
it is a good document.  I have a few problems on charter, technical
or clarity points.  Discussion welcome.

Allison

-------- 
   However, QoS is not the only field where signaling 
   is used in the Internet. Others might be the use for middlebox 
   communication [RFC3234]. 

It would be helpful to clarify the manner in which signaling would be
used for middlebox communication (in one sentence) - this is so terse, that
only if a reader has been in the working group would they understand the
sentence.

Suggestion:  "Signaling might also be used as a communication protocol
to set up the state in middleboxes."

-------- 

   There are several areas related to networking aspects which are 
   incomplete, for example, interaction with host and site multi-
   homing, use of anycast services, and so on. These issues should be 
   considered in any future analysis work. 

Incomplete in the sense of requirements analysis?  This paragraph suggests
a different kind of analysis.  Also anycast in particular seems very unlikely 
to be a significant element in signaling requirements analysis - it seems 
like it should not be mentioned in the same sentence with a common issue 
like multihoming.  

Suggestion:  "This document does not cover requirements in relation to some
networking areas, in particular, interaction with host and site multihoming.
We leave these for future analysis. "

-------- 

NSIS Initiator - needs to say, in parallel with the NSIS Responder, 
it interacts with applications  (Definition does not say so).

-------- 
3. Something that terminates the signaling path, the NSIS Responder.

   The NSIS responder might be in an end-system or within other
   equipment. The distinguishing feature of the NSIS Initiator is that
                                                     ^^^^^^^^^
   it responds to requests at the end of a signaling path.

Typo? s/Initiator/Responder/

-------- 
   The host to first 
   router part includes all the layer 2 technologies to access to the 
   Internet.

Consider a home network with a wireless router and a DSL router accessing
the Internet.  The topology definition is less crisp than host to *first*
router.  I suggest you add a sentence after this one:  "This part of the
division is especially informal and may incorporate several access segments."
-------- 

5.2.2 NSIS MUST support path-coupled and SHOULD NOT exclude path-
     decoupled signaling.  

SHOULD NOT is very strong, given that the WG is not chartered to work on
this technology.

The language needs to be "MAY support path-decoupled signaling." 

-------- 

5.3.2 Automatic release of state after failure SHOULD be possible 
    
   When the NSIS Initiator goes down, the state it requested in the 
   network SHOULD be released, since it will no longer be necessary. 

An important feature of RSVP was its soft-state character, in part to
ensure that critical resources in the net were not fate-shared for too long.
Given this is about release after _failure_, these SHOULDs should be MUSTs,
if not going so far as to preserve the soft-state architecture.  Comments?

-------- 

5.4.3 State MUST be addressed independent of flow identification 
    
   Addressing or identifying state MUST be independent of the flow 
   identifier (flow end-points, topological addresses). Various 
   scenarios in the mobility area require this independence because 
   flows resulting from handoff might have changed end-points etc. but 
   still have the same service requirement. Also several proxy-based 
   signaling methods profit from such independence. 

Add to the last sentence "though these are not chartered work items for
NSIS".

This is a tough requirement since it has to be globally unique.  It may
turn out to be best met by the NI's authentication token, requiring an
early integration of authentication design into the protocol.  No request
to change this, but just noting how hard this is - WG is _sure_
the mobility requirements are really so important?

-------- 

5.4.1 Mutability information on parameters SHOULD be possible 
    
   It SHOULD be possible for the NSIS initiator to control the 
   mutability of the signaled information. This prevents them from 
   being changed in a non-recoverable way. The NSIS initiator SHOULD be 
   able to control what is requested end to end, without the request 
   being gradually mutated as it passes through a sequence of domains. 
   This implies that in case of changes made on the parameters, the 
   original requested ones must still be available.  
    
   Note that we do not require anything about particular parameters 
   being changed.  
    
   Additionally, note that the provider of the particular requested 
   services can still influence the provisioning but in the signaling 
   message the request should stay the same. 

The requirement is not expressed well.  Do you mean "It SHOULD be
possible to have nodes modify parameters to interact with the
signaling message, while still retaining an intact copy of the
original form of the signaling message"?  

This requirement seems like it would vary a great deal depending on what
the signaling application was, and as it is written here it is very close
to a protocol design rather than a requirement.  Could you omit
it from this document?

-------- 

                                                       One of the 
   reasons is that the protocol handling should have a minimal impact 
   on interior (core) nodes. 

Suggest adding that NSIS MAY also have a feature allowing core nodes
to ignore it (though I hope it will be more elegant than RSVP's as
document in RFC 3175 :)

-------- 

5.7.5 Hop-by-hop security 
    
   Hop-by-Hop security SHOULD be supported. It is a well known and 
   proven concept in Quality-of-Service and other signaling protocols 
   that allows intermediate nodes that actively participate in the 
   protocol to modify the messages as it is required by processing 
   rules. Note that this requirement does not exclude end-to-end or 
   network-to-network security of a signaling message. End-to-end 
   security between the initiator and the responder may be used to 
   provide protection of non-mutable data fields. Network-to-network 
   security refers to the protection of messages over various hops but 
   not in an end-to-end manner i.e. protected over a particular network. 

Without minimum mandatory to implement channel security for the signaling, 
you can't be sure the other security features will be untampered with -
this needs to be a MUST implement (it's not a MUST use).  Suggest changing
the first sentence to "Channel security between signaling entities
MUST be implemented'?

-------- 

5.9.5 SHOULD interwork with seamless handoff protocols 

5.9.6 MAY interwork with non-traditional routing 
    
   NSIS assumes L3 routing, but networks, which do non-traditional 
   routing, should not break it. 

NSIS should not be complex and interworked in ways that make it less modular.
Both of these requirements are complications.  The first one, because it poses
a certain environment and particular protocols, would make NSIS less modular.
It is probably improved by changing SHOULD to MAY.  The second one may sound
worse than it is - does it mean NATs?  Suggest this might have meant:

5.9.6. MAY operate in varied routing environments

     NSIS assumes L3 routing, but it MAY be designed to operate in
     varied routing environments, such as those with L4 switches and NATs.

But if not, do explain...
-------- 

Scenarios -

's' as an abbreviation is not explained.

-------- 
10.2

The 3G Scenario is somewhat too specific to 3GPP and 3GPP2 still - IMS is
mentioned without being expanded or explained.  All the terms are specific.
Try to make it a bit more abstract - say it is an All-IP multimedia system.

-------- 
     This part of the wireless network has different 
     characteristics when compared to traditional IP networks: 
    
         1. The network supports a high proportion of real-time 
            traffic.  The majority of the traffic transported in the 
            wired part of the wireless network is speech, which is 
            very sensitive to delays and delay variation (jitter). 

Two things about IP networks - they carry whatever they carry, so
it's not out of tradition to be a voice IP network.  Second, speech in
Internet phones is quite a lot less sensitive to delays and jitter than
often thought, due to the many good engineering designs in playout and
speech cover that are known.  So this material places a context of more
difference on the environment than most general transport experts view
as necessary, seeing more continuum, while not disagreeing that signaling
and resource reservation are valuable.

So drop sentence 1, but leave the rest alone (I just wanted to make my point :)

-------- 

10.10  Application request end-to-end QoS path from the network 
    
   This is actually the easiest case, nevertheless might be most often 
   used in terms of number of users.

Few believe that ordinary applications signaling for QoS is an easy matter for
the network - RFCs 2961, 2996 and 3175 are all about mitigating the unscalability
of edge signaling.  Probably this would go better if you substitute the term
"conceptually simplest" for "easiest" and note that there are these issues with
scaling.  

    Additionally, we assume no mobility and standard devices. 

Note: the end system application and NSIS do not know about the 
distinction between 10.10 and the other scenarios :), unless NSIS is not 
a modular Internet protocol.

-------- 

QoS for Virtual Private Networks - section needs a number

IP-Sec -> IPSec

The discussion of NSIS in VPNs ignores the whole world of the PPVPN WG.  
Cite draft-ietf-ppvpn-framework-08.txt early on in the section (it is in the 
RFC-Editor Queue).  

Allison

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Jun 2003 13:33:09 -0700 (PDT)

> the mobility requirements are really so important?

Maybe I don't understand what you're concerned
about, but why should this be hard? Say I generate
a pseudo-random number, we'd only really have to
worry about the birthday paradox which is
mitigated by adding bits. We're talking about the
(NSIS) signaling traffic, right? This seems pretty
orthogonal to auth...

	      Mike

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 12 Jun 2003 00:01:13 +0200

Alison, John,

Here my comments and how I have addressed them. I am going to submit the 
changed version (-08) soon.

Marcus

> used for middlebox communication (in one sentence) - this is so terse,
> that only if a reader has been in the working group would they understand
> the sentence.
>

changed into "Signaling might also be used as a communication protocol to 
setup and maintain the state in middleboxes."

> a different kind of analysis.  Also anycast in particular seems very
> unlikely  to be a significant element in signaling requirements analysis
> - it seems  like it should not be mentioned in the same sentence with a
> common issue  like multihoming.
>
> Suggestion:  "This document does not cover requirements in relation to
> some networking areas, in particular, interaction with host and site
> multihoming. We leave these for future analysis. "
>

ok, change accepted

> Typo? s/Initiator/Responder/

done thanks

> division is especially informal and may incorporate several access

ok, added.

> The language needs to be "MAY support path-decoupled signaling."

Req changed to

5.2.2 NSIS MUST support path-coupled and MAY support path-decoupled 
signaling.

The path-coupled signaling mode MUST be supported. NSIS signaling messages 
are routed only through nodes (NEs) that are in the data path.

However, there is a set of scenarios, where signaling is not on the data 
path. Therefore, NSIS MAY support the path-decoupled signaling mode, where 
signaling messages are routed to nodes (NEs), which are not assumed to be 
on the data path, but which are aware of it.

> ensure that critical resources in the net were not fate-shared for too
> long. Given this is about release after _failure_, these SHOULDs should
> be MUSTs, if not going so far as to preserve the soft-state architecture.
> Comments?
>

Changed to

5.3.2 Automatic release of state after failure MUST be possible

When the NSIS Initiator goes down, the state it requested in the network 
SHOULD be released, since it will most likely no longer be necessary.

After detection of a failure in the network, any NSIS Forwarder/Initiator 
MUST be able to release state it is involved in. For example, this may 
require signaling of the "Release after Failure" message upstream as well 
as downstream, or soft state timing out.

The goal is to prevent stale state within the network and adds robustness 
to the operation of NSIS. So in other words, an NSIS signaling protocol or 
mechanisms MUST provide means for an NSIS entity to discover and remove 
local stale state.

Note that this might need to work together with a notification mechanism. 
Note as well, that transient failures in NSIS processing shouldn't 
necessarily have to cause all state to be released immediately.

> the mobility requirements are really so important?

ok added "though these are not chartered work items for NSIS"

I think the address of the state might be locally unique only (per node), 
but this is a design decision. And I think mobility is important but should 
not be the overruling factor.

> to a protocol design rather than a requirement.  Could you omit

You are right the part on keeping a copy is very design-specific, but as 
Robert pointed out in a different mail, the control of the change process 
should be under the control of the NSIS initiator.
So with this I have change it the following:

It is possible that nodes modify parameters of a signaling message. 
However, it SHOULD be possible for the NSIS Initiator to control the 
mutability of the signaled information. For example, the NSIS Initiator 
should be able to control what is requested end to end, without the request 
being gradually mutated as it passes through a sequence of nodes.

> to ignore it (though I hope it will be more elegant than RSVP's as

added the point to the paragraph on example methods

the req reads now

5.5.4 NSIS SHOULD allow to constrain load on devices

The NSIS architecture SHOULD give the ability to constrain the load (CPU 
load, memory space, signaling bandwidth consumption and signaling 
intensity) on devices where it is needed. One of the reasons is that the 
protocol handling should have a minimal impact on interior (core) nodes.

This can be achieved by many different methods. Examples include message 
aggregation, header compression, minimizing functionality, or ignoring 
signaling in core nodes. The framework may choose any method as long as the 
requirement is met.

> Without minimum mandatory to implement channel security for the
> signaling,  you can't be sure the other security features will be
> untampered with - this needs to be a MUST implement (it's not a MUST
> use).  Suggest changing the first sentence to "Channel security between
> signaling entities MUST be implemented'?
>

ok changed

> NSIS should not be complex and interworked in ways that make it less
> modular. Both of these requirements are complications.  The first one,
> because it poses a certain environment and particular protocols, would
> make NSIS less modular. It is probably improved by changing SHOULD to
> MAY.  The second one may sound worse than it is - does it mean NATs?
> Suggest this might have meant:
>

I don't see why this makes it less modular, nevertheless I followed Roberts 
proposal to use "work with" instead of "interwork"

5.9.5 SHOULD work with seamless handoff protocols

An NSIS protocol SHOULD work with seamless handoff protocols such as 
context transfer and candidate access router (CAR) discovery.

Concerning req 5.9.6
The req is not so much about that it is designed for other routing 
environments, but that it should not break in "non-traditional" 
environments.

Again I followed Robert and replace "interworking" ith "work with"

> 's' as an abbreviation is not explained.

yes, should be Fast state installation

> mentioned without being expanded or explained.  All the terms are
> specific. Try to make it a bit more abstract - say it is an All-IP
> multimedia system.

expanded the IMS, but being specific is on purpose it should be the 3GPP 
scenario. A less specific version has been complained about.

> So drop sentence 1, but leave the rest alone (I just wanted to make my

Actually, in this particular scenario it is very jitter sensitive, but this 
has nothing to do with IP phones and its playout, but with the design of 
current protocols running on top of IP here. I removed it anyway since it 
does not really add value.

> Few believe that ordinary applications signaling for QoS is an easy
> matter for the network - RFCs 2961, 2996 and 3175 are all about
> mitigating the unscalability of edge signaling.  Probably this would go
> better if you substitute the term "conceptually simplest" for "easiest"
> and note that there are these issues with scaling.
>
>

You are right, removed the sentence

> QoS for Virtual Private Networks - section needs a number

ok

> Cite draft-ietf-ppvpn-framework-08.txt early on in the section (it is in
> the  RFC-Editor Queue).
>

Ok added the reference.

Marcus

---

From: Allison Mankin <[email-masked]>
Date: Thu, 12 Jun 2003 21:41:22 -0700

> (NSIS) signaling traffic, right? This seems pretty

Globally unique means a reasonably quite pseudo-random number
(because it isn't good to have the resources id'd as someone else's)
or a value that is sure to be unique.

I'm not asking the document to take these ramblings in...just raising
thoughts.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Allison Mankin <[email-masked]>
Date: Thu, 12 Jun 2003 22:06:53 -0700

Marcus,

Thanks for the detailed responses.  It's all good, with just two 
worries left.

I asked for better clarification of Requirement 5.9.6 in my reply to
Robert Hancock - it still stands out that "non-traditional routing" is
vague and what form of robust behavior is required of NSIS in what
environment is really not stated by the text.

The other worry is the 3G scenario.  John Loughney's message expressed a
very good reason to make the scenario just a little more abstract, as I
suggested, when he wrote:

    the IETF is not 3GPP, and it may be
    seen as the IETF imposing its view upon 3GPP.  We should be
    careful not to imply that this is the way that the IETF or
    the NSIS WG thinks 3GPP should do things.

If the WG does not want to decrease the specificity of the details from
3GPP, then the text must make more disclaimers.  The opening of the
section should say that the scenario inserts NSIS in an environment that
resembles 3GPP, but that NSIS is not in 3GPP plans, and that design is
hypothetical.

The following language is not enough because it comes later, after the
reader may have become convinced of NSIS's integral role with the other 3GPP
components:

   The NSIS Forwarder is currently not part of the standard 3G wireless 
   architecture. However, to achieve end-to-end QoS a NSIS Forwarder is 
   needed such that the NSIS Initiators can request a QoS connection to 
   the IP network. 

Thanks,

Allison

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Jun 2003 15:04:54 -0400

> I'm not asking the document to take these ramblings in...just raising

The interim meeting slides have an 'analysis' of the collision 
probability for different random number lengths, which were 
significantly lower than any other reasonable failure probabilities and 
similar to the probability that Earth will be obliterated by a meteor, 
from my recollection.

I also believe that are no reasonable alternatives unless one assumes

1) every originator has a DNS name that is guaranteed to be unique and 
that it has easy access to (this isn't true without a working inverse 
mapping)

or

2) every originator has a globally unique IP address (clearly iffy)

or

3) we posit some global number handout algorithm system (maybe useful, 
but non-trivial; see multicast address assignment problem)

Henning

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 16 Jun 2003 12:08:13 +0200

Hi Allison

Regarding your comment on Section 5.7.5 about MUST implement and not a MUST
use.

Do you mean that the channel security between signaling entities
MUST be implemented, but this does not mean that it should be used?

Best Regards,
Georgios

----- Original Message -----
From: "Allison Mankin" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, June 09, 2003 8:29 AM
Subject: [NSIS] AD Review comments on draft-ietf-nsis-req-07.txt

> used for middlebox communication (in one sentence) - this is so terse,
that
> a different kind of analysis.  Also anycast in particular seems very
unlikely
> Suggestion:  "This document does not cover requirements in relation to
some
> ensure that critical resources in the net were not fate-shared for too
long.
> NSIS should not be complex and interworked in ways that make it less
modular.
> mentioned without being expanded or explained.  All the terms are
specific.
> Cite draft-ietf-ppvpn-framework-08.txt early on in the section (it is in
the