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

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 8 Jul 2002 11:06:22 +0200

Hi Marcus
Please see my remarks in line:

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

[marcus] I still don't see what problem people have with off-path signaling (and I 
[marcus] would call tunneling off-path as well). If the working group agrees to 
[marcus] remove some of the req fine, let me know which ones.

[georgios] well we do not have to remove them, but we have to emphasise that 
[georgios] they are very optional. John propsed to move thaem in an appendix.
[georgios] If you want I can make a list with them.

>
>> 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.
>
> [john] I support this, but I think we should have some WG discussion on
> [john] this.

[marcus] Yes, sure, but I can a that point in time not rely on a personal 
[marcus] submission. And the terms showed up first in the req draft. I agree that 
[marcus] there are good reasons to change them, but we need consensus on that.
[georgios] agree, we should have a consensus on that!

>> 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."
>
[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.
[marcus]I don't understand georgios point but I think we need to modify section 3 
[marcus] anyway (or even remove it, because most of the stuff is framework related.

[georgios] What about the last proposal that I sent as reply to John's e-mail.

>> 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."
>
[john]> I am perplexed at this reference - 2993 is "Architectural Implications
[john]> of NAT" - what does this have to do with NSIS?

[marcus] Here I don't want to include any reference, The fuzzyness is on purpose.

[marcus] If you start talking about NATs this might be an issue for NSIS, whether 
[marcus] NSIS must work over NATs or not or don't care.

[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

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

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 08 Jul 2002 12:04:28 +0200

Georgios,

Yes, please make a list and post it to the list. We can discuss it.
Evenso, myself and John (if I understood him right) think the req are not 
containing any point which are off-path specific. But corr4ect me if you 
find some.

Marcus

--On Montag, 8. Juli 2002 11:06 +0200 "Georgios Karagiannis (ELN)" 
<[email-masked]> wrote:

> [marcus] I still don't see what problem people have with off-path
> signaling (and I  [marcus] would call tunneling off-path as well). If the
> working group agrees to  [marcus] remove some of the req fine, let me
> know which ones.
>
> [georgios] well we do not have to remove them, but we have to emphasise
> that  [georgios] they are very optional. John propsed to move thaem in an
> appendix. [georgios] If you want I can make a list with them.
>
>>
> [marcus] submission. And the terms showed up first in the req draft. I
> agree that  [marcus] there are good reasons to change them, but we need
> consensus on that. [georgios] agree, we should have a consensus on that!
>
>
> [marcus]I don't understand georgios point but I think we need to modify
> section 3  [marcus] anyway (or even remove it, because most of the stuff
> is framework related.
>
> [john]> I am perplexed at this reference - 2993 is "Architectural
> Implications [john]> of NAT" - what does this have to do with NSIS?
>
> [marcus] If you start talking about NATs this might be an issue for NSIS,
> whether  [marcus] NSIS must work over NATs or not or don't care.
>

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