Subject: [NSIS] FW: list with all comments sent by me on list regarding requireme nts draft

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 11 Jul 2002 12:18:00 +0200

Hi 

Please receive the following e-mail, that 
includes some discussions that I have had together with Marcus on the 
requirements draft!

Best Regards,
Georgios

-----Original Message-----
From: Marcus Brunner [mailto:[email-masked]] 
Sent: Thursday, July 11, 2002 11:57 AM
To: Georgios Karagiannis (ELN)
Subject: Re: list with all comments sent by me on list regarding
requirements draft

Georgios,

I think the problem I still have is the definition of the data path/on-path 
etc. As Robert said I also see quite a number of different definitions. If 
data path is loosly defined I am able agree, if it defined very strict I am 
not.

See also some inline comments.

BTW, can you post this E-Mail? And thanks for the careful reading.

Marcus

--On Mittwoch, 10. Juli 2002 19:14 +0200 "Georgios Karagiannis (ELN)" 
<[email-masked]> wrote:

> Hi Marcus
>
> Here is a lsit of all comments that I provided until now regarding the
> requirements draft. I hope that you now agree with all of them!
>
>
> Best Regards,
> Georgios
> -------------------------------------------------------------------------
> -----------------------------------
>
> 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? The list is as follows:
>
> Change required in Requirement 5.2.2:
> "No constraint of the QoS signaling Controllers to be in the data path"
> Please chnage into:
> "The NSIS Forwarders and NSIS Initiators should be located in the data
> path. However, there might be optional situations where this is not
> required."
>
> Change required in Requirement 5.7.2:
> "Flexibility in the placement of the QoS initiator"
> Change the text from:
> "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)."
>
> Change required in requirement 5.7.3:
> "Flexibility in the initiation of re-negotiation (QoS change requests)"
> Please change the text from:
> "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)."
>
> Marcus do you agree?
> -------------------------------------------------------------------------
> -----------------------
>
>
>
>
> 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.
>
> NO discussion in the mailing list took place up to now!

I put it as a point for the IETF meeting.

> -------------------------------------------------------------------------
> ---------------
>
> 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."
>
>
>
> New proposal for modification:
>
> "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."
>
> Marcus do you agree?

I think I can agree on that.

> -------------------------------------------------------------------------
> ---------------
>
> 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 2992."
>
> Marcus do you agree?

No, actually, I would regard RFC 2992 not "normal". But we can think about 
whether NSIS need to be able to work with RFC 2992 type of routing.

>
> -------------------------------------------------------------------------
> ---------------
>
> 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."
>
> Marcus do you agree?

What do you understand with "be used for signaling within a domain"?
I think we even have a requirement saying that.

> -------------------------------------------------------------------------
> --------------- 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." Marcus do you agree?

Yes, I agree with that. Would you even regard security service-specific?

> -------------------------------------------------------------------------
> ---------------
>
> Comment_7: Section 5.10.5: Interworking with seamless handoff protocols:
>
> Mention that this interworking should not duplicate functionality.
>
> Marcus do you agree?

Wasn't it you that dropped that particulr requirement? But I can definitly 
mention that I can agree on that.

> -------------------------------------------------------------------------
> ---------------
>
> Comment_8: Open Issue 2: page 44:
> I prefer:
> "should be optimized for sender initiated"
> Marcus do you agree?

I put this again on the slide for Japan. But I tend to agree.

> ---------------------------------------------------------------------
>
> 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?
>
> Marcus do you agree?

Yes, I put this onto slides for Japan.

> -------------------------------------------------------------------------
> ----
>
>
> Comment_10:
> Due to the fact that the  Multi-level signaling has become
> a very important issue in NSIS, I would very much appreciate if we could
> add the following bullet into Section 5.1.3 "Modularity":
>
> "- multi-level NSIS signaling: the NSIS protocol should be able to
> be separated into more than one hierarchical levels. The hierarchical
> levels  are refering to protocol functionality levels."
>
> Marcus I think you mentioned that you agree!

I agree with what you try to say, but myself and also John disagreed with 
the wording multi-level signaling. But give me a try to change the text 
toward your thinking, then complain again if I have not met your 
expectations.

--------------------------------------
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

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