Subject: [NSIS] commentson on draft-ietf-nsis-req-03.txt

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 5 Jul 2002 09:23:52 +0200

Dear Marcus

Please receive some comments on version 3 of the requirements draft:
draft-ietf-nsis-req-03.txt

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

Comment_1: general:
There are many requirements that are affected by the fact that NSIS will have 
to concentrate mainly on the in-band (in-path case).
What should we do with them? maybe list them as optional and to be done in the future?
---------------------------------------------------------------------------------------

Comment_2: Section 2: Terminology: (page 6):

I propose to use the terms given in draft-hancock-nsis-fw-00.txt regarding
NSIS Initiator (instead of QoS Initiator), NSIS Forwarder (instead of QoS Controller)
and NSIS Responder. This applies also for other additional terms that are 
included into draft-hancock-nsis-fw-00.txt and are not included into the requirements
draft.
----------------------------------------------------------------------------------------

Comment_3: Section 3: Problem statement and scope (Page 9):

Please remove or signifficantly modify bullet 2:
"We see the network at the level of domains/subdomains rather 
than individual routers ...... Aggregation can also take place at subdomain boundaries."

The reasonsof asking this are:
    * not each domain but any router that implements a QoS controller or QoS initiator 
       can use NSIS signaling;
   * It  is contradictory with bullet 4  (of the same section) that mentions:
       " Each router on the data path implements a QoS controller and QoS initiator."

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

Comment_4: Section 4.1: Assumptions and exclusions (Page 11):

Bullet 6:
Please change the text:
"NSIS assumes to operate with networks using standard ("normal") L3 routing"

INTO 

"NSIS assumes to operate with networks using standard ("normal") L3 routing 
as described in RFC 2993."
----------------------------------------------------------------------------------------

Comment_5: Section 4.2: Assumptions and exclusions (Page 11):
Issue 3: Please add a sentance after:
"Specific mechanisms for QoS provisioning withis a domain/subdomain are not considered."

As follows:
"Specific mechanisms for QoS provisioning withis a domain/subdomain are not considered.
However,  NSIS can be used for signaling within a domain/subdomain."

----------------------------------------------------------------------------------------
Comment_6: Section 5.8 General (Page 20):

Many of the security requirements mention that the signaling protocol must provide means 
to provide security.  I would prefer to mention somewhere, maybe in the introduction of section 5.8 
that:
"The NSIS protcol must provide means to provide security, but it is not mandatory that all nodes
that use NSIS signalling will have to apply these means for security."
----------------------------------------------------------------------------------------

Comment_7: Section 5.10.5: Interworking with seamless handoff protocols:

Mention that this interworking should not duplicate functionality.
----------------------------------------------------------------------------------------

Comment_8: Open Issue 2: page 44:
I prefer:
"should be optimized for sender initiated"

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

Comment_9: Regarding open Issues 53, 59, 65 and 72  I propose that Sven
and myself try to propose some text that solves all these issues:
Sven do you agree?

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

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

---

From: [email-masked]
Date: Fri, 5 Jul 2002 10:59:10 +0200

Hi John, Georgios,

I am not sure if we can split the requirements without pre-supposing a
solution. Ideally, the requirements should cover the problem space
(signaling for resources) without doing that. I think we already had a
similar discussion once when we talked about 'parts of the network'. The
feedback we got at the meeting was that we should not restrict the
requirements to a particular architecture. Some offline discussion resulted
in keeping the requirements listed as they were in order to avoid
duplication and left the possibility open to add a section indicating in
which case they would apply. As an alternative to such an additional
section, I think it would be perfectly OK for a particular solution to
state that it is not affected by or inherently fulfills some of the
requirements. Would you feel any of these to be an appropriate solution in
this case as well?

Sven.

[email-masked]@ietf.org on 05/07/2002 10:31:48

Sent by:  [email-masked]

To:   <[email-masked]>, <[email-masked]>
cc:   <[email-masked]>
Subject:  RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt

Hi Georgios,

> to be done in the future?

I think that we need to seperate off-path requirements from the main
document. In my opinion, these are non-requirements for the current
charter.  I would support moving these into an appendix,
which discusses off-path signaling.

> I propose to use the terms given in draft-hancock-nsis-fw-00.txt
> regarding NSIS Initiator (instead of QoS Initiator), NSIS Forwarder
> (instead of QoS Controller) and NSIS Responder. This applies also
> for other additional terms that are
> included into draft-hancock-nsis-fw-00.txt and are not
> included into the requirements draft.

I support this, but I think we should have some WG discussion on
this.

>     * not each domain but any router that implements a QoS
> controller or QoS initiator can use NSIS signaling;

I don't see your point.  If we are signaling for some 'NSIS
resource' - does each router on the path suply this resource,
is it aggregated or not?  We are not designing a specific
host to router, or router to router protocol; in my opinion
we are doing something a bit broader.  However, what we do
may be applicable to this.

> "NSIS assumes to operate with networks using standard
> ("normal") L3 routing  as described in RFC 2993."

I am perplexed at this reference - 2993 is "Architectural Implications
of NAT" - what does this have to do with NSIS?

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 8 Jul 2002 10:52:08 +0200

Hi John

Please see some remarks in line
(moreover please note that I meant RFC2992 and 

> to be done in the future?

[john] I think that we need to seperate off-path requirements from the main 
[john] document. In my opinion, these are non-requirements for the current 
[john] charter.  I would support moving these into an appendix,
[john] which discusses off-path signaling.

[georgios] Agree! However, I am open also to other solutions

> included into the requirements draft.

[john] I support this, but I think we should have some WG discussion on 
this.
[georgios] agree!
 
> controller and QoS initiator."

[john] I don't see your point.  If we are signaling for some 'NSIS
[john] resource' - does each router on the path suply this resource,
[john] is it aggregated or not?  We are not designing a specific
[john] host to router, or router to router protocol; in my opinion
[john] we are doing something a bit broader.  However, what we do
[john] may be applicable to this.

[georgios] good point! What about changing bullet 2 in Section 3 as follows
(adding a paragraph at the end of bullet 2):

"2. We see the network at the level of domains/subdomains rather than 
   individual routers (except in the special case that the domain 
   contains one link). Domains are assumed to be administrative 
   entities, so security requirements apply to the signaling between 
   them. Subdomains are introduced to allow the fact a given QoS 
   provisioning mechanism may only be used within a part of a domain, 
   typically for a particular subnetwork technology boundary. 
   Aggregation can also take place at subdomain boundaries. 
   However, each router on the data path may implement a QoS 
   controller and/or QoS initiator and therefore, any router
   on the data path may use the NSIS signalling."

> ("normal") L3 routing"

[john] I am perplexed at this reference - 2993 is "Architectural Implications 
[john] of NAT" - what does this have to do with NSIS?

[georgios] I am very sorry, I meant RFC2992,"Analysis of an Equal-Cost 
[georgios] Multi-Path Algorithm", located at:
http://www.ietf.org/rfc/rfc2992.txt?number=2992

Best Regards,
Georgios

---

From: [email-masked]
Date: Wed, 10 Jul 2002 14:50:16 +0300

Hi Marcus & Georgios,

> > In my opinion, the main requirements that are affected by the
> > in-path and out of path discussions are:
> >
> > * Requirement 5.2.2:
> > "No constraint of the QoS signaling Controllers to be in the data path"
> > You could remove this requirement!
> 
> The requierment is already very weak and just says "No 
> constraint". Could you live with it if we even make it a SHOULD?

I think we could leave this requirement loose & then over-rule it,
if needed, in the framework document.

> > * Requirement 5.7.2:
> > "Flexibility in the placement of the QoS initiator"
> > In my opinion the way of how the network initiated reservations
> > are explained ion this section, are mainly out of path.
> > Please remove the sentence that describes network initiated 
> reservations.
> 
> This has nothing to do with on/off path. Removing this means no proxies, no 
> Acess Router initated signaling (even if they are on path)
> I vote for leaving it.

I agree with Marcus.  It is not saying on- or off-path.

> > * Requirement 5.7.3:
> > "Flexibility in the initiation of re-negotiation (QoS change requests)"
> > In my opinion the way of how the network initiated reservations
> > are explained ion this section, are mainly out of path.
> > Please remove the sentence that describes network initiated 
> reservations.
> 
> The same here as with the previous req.

I don't see the problem with this requirement.

John

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 10 Jul 2002 16:48:55 +0200

Hi Marcus

Please see my remarks in line!

> Hi Marcus

[marcus] The requierment is already very weak and just says "No constraint". Could 
you live with it if we even make it a SHOULD?

[georgios] what I meant is to emphasize in a stronger sense that the 
QoS signaling Controllers should be in the data path, for example this 
requirement could become:

"The NSIS Forwarders and NSIS Initiators should be located in the data path.
However, there might be optional situations where this is not required."

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

> Please remove the sentence that describes network initiated reservations.

[marcus] This has nothing to do with on/off path. Removing this means no proxies, no 
Acess Router initated signaling (even if they are on path)
I vote for leaving it.

[georgios] Okay, what about changing the text:
"But also network-initiated reservations are required in various scenarios such as 
PSTN gateways, some VPNs, mobility."

Into:
"But also network-initiated reservations are required in various scenarios such as 
PSTN gateways, some VPNs, mobility. Note however, that the NSIS Initiator should be located
in the data path (see Requirement 5.2.2)."

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

> Please remove the sentence that describes network initiated reservations.

[marcus] The same here as with the previous req.

[georgios] Okay, what about changing the text:
"But also network-initiated re-negotiations is required in cases, where the 
network is not able to further guarantee resources etc."

Into:

"But also network-initiated re-negotiations is required in cases, where the 
network is not able to further guarantee resources etc. Note however, that the NSIS Initiator 
should be located in the data path (see Requirement 5.2.2)."

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 11 Jul 2002 00:04:29 +0100

hi all,

a question:

how precisely does the body of the requirements text have to track the w.g. charter? if the charter were (hypothetically) to be extended at a later date to include (just as an example) off path signalling, would we want to update the requirements RFC just to reflect that?

a suggestion:

what about adding a section near the start explaining that any subsequent work we do is constrained by these requirements and the current charter, and then in particular explaining the initial restriction to on-path signalling and the reasoning behind it. i would have thought we could leave the rest of the document as it is.

[Note: such a section could also define just what the on-path restriction actually was. I've seen at least 4 different incompatible views on that.]

cheers,

robert h.

> -----Original Message-----
> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 10 July 2002 15:49
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 11 Jul 2002 18:44:58 +0100

hi marcus,

i've added a few refinements. we get up to 8 questions in all.

some answers may be obvious to some people, but I don't think any are obvious  to everyone.

robert h.

> From: Marcus Brunner [mailto:[email-masked]]
> Sent: 11 July 2002 15:02
> To: [email-masked]; Hancock, Robert;
> [email-masked]
> Cc: [email-masked]
> >> [Note: such a section could also define just what the on-path
> >> restriction actually was. I've seen at least 4 different
> >> incompatible views on that.]
> >
> > Want to provide a summary of the 4 views?
> 
> Ok, I give it a try
> 
> 1) exclusive on path
> The NSIS initiator and NSIS receiver are the data receiver and sender
> 
> 2) proxy on path
> The NSIS initiator is some where on the data path but not at 
> the sending 
> nor receiving side (only part of the data path is covered by 
> signaling)
> 
> 3) IP-hop-by-IP-hop
> The signaling message travels IP-hop-by-IP-hop. Where the 
> hops are chosen 
> by  the destination addr
3a) The signaling message travels IP-hop-by-IP-hop, but the hop can be chosen on any fields in the IP header (of data packet) or flow definition (in NSIS aware router), e.g. DSCP and so on. Can be used to handle some load sharing/traffic engineering issues, but not across NSIS-unaware clouds.

> 
> 4) NSIS-hop-by-NSIS-hop
> The signaling message follows NSIS hops, where intermediate 
> IP hops are not 
> visited. The NSIS hop has to choose the next hop, here the 
> data path migh 
> follow a different path for a shsort segment.
[to clarify?] the ends of the NSIS hop are on the data path, but the middle may not be. the message is explicitly addressed to the next NSIS hop.

> 
> 5) in advance reservation in hand-over cases
> If a new access router has been chosen, where a mobile will 
> newly connect 
> to and a reservation should be done in advance, the data 
> flows still on the 
> old path. At the point in time data is flowing along the new 
> path (after 
> handoff) the reservation has already been setup.

6) i've seen some claim that if a node sets up a tunnel (obviously with a known endpoint) and then signals for the tunnel, and also sends data and signalling through the tunnel, this is 'morally equivalent' to off-path, in the sense that you're no longer relying on the routing system to recover from any non-end-system failures.

7) even if some messages are sent traditionally on-path as per (3) [like RSVP PATH], are other messages allowed to go off path and not be routed NSIS-hop by NSIS-hop [e.g. acknowledgements, error notifications]? or should everything go on-path?

> 
> Marcus
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
> 
>

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 12 Jul 2002 10:25:19 +0200

Hi Robert

I have a remark on one of your statements (statement (7)):

[Robert] (7) even if some messages are sent traditionally on-path as 
per (3) [like RSVP PATH], are other messages allowed to go off 
path and not be routed NSIS-hop by NSIS-hop [e.g. acknowledgements, 
error notifications]? or should everything go on-path?

[georgios] this is very much related to backward routing issues.
In a sender initiated approach it should be allowed that 
the acknowledgements and error notification messages are
sent to specific NSIS Forwarders (QoS Controllers) 
or NSIS Initiators (QoS Initiators)  
directly, without using backward routing (in RSVP terms
without using the PHOP option).

Best Regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: Thursday, July 11, 2002 7:45 PM
To: [email-masked]'; [email-masked];

hi marcus,

robert h.