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

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 8 Jul 2002 15:02:58 +0200

Hi Marcus

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!

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

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

Best regards,
Georgios

-----Original Message-----
From: Marcus Brunner [mailto:[email-masked]]
Sent: Monday, July 08, 2002 12:04 PM
To: Georgios Karagiannis (ELN); [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] commentson on draft-ietf-nsis-req-03.txt

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:

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

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

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

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 10 Jul 2002 11:04:14 +0200

Georgios,

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

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

> Please remove the sentence that describes network initiated reservations.

The same here as with the previous req.

Marcus