Subject: [NSIS] Working Group Requirements document

From: [email-masked]
Date: Mon, 4 Feb 2002 10:23:38 +0200

Hi all,

There have several requests that the following document be made
a working group document:

http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt

After discussing with our Area Directors, we have asked Marcus Brunner
to edit the Signaling Requirements draft, with the above draft
forming the basis of initial draft. 

I would like to see if there is interest within the working group to
have a conference call in order to help progress the work on this draft.

best regards,
John

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

---

From: David Partain <[email-masked]>
Date: Mon, 04 Feb 2002 15:55:22 +0100

Hi all,

> have a conference call in order to help progress the work on this draft.

There certainly is interest on my part.

Cheers,

dlp

---

From: "Lars.Westberg" <[email-masked]>
Date: Mon, 04 Feb 2002 18:11:18 +0100

I am interested to partizipate in the telephone conference.

Regards Lasse

---

From: "Ki Young Jung" <[email-masked]>
Date: Tue, 5 Feb 2002 03:08:32 +0900

Hi, all.
First, sorry for my poor English.

Indeed, I can't fully follow the mailing list, but I have some thinking
related with the
draft  http://search.ietf.org/internet-drafts/draft-brunner-nsis-req-00.txt.

> 3.4. Scenario 4: QoS reservations/negotiation from access to core
>     network

>   The scenario includes the signaling between access networks and core
>   networks in order to setup and change reservations together with
>   potential negotiation.

>   The issues to be solved in this scenario are different from previous
>   ones. The entity of reservation is most likely an aggregate, and the
>   time scales of reservations might be different (long living
>   reservations of aggregates, rarer re-negotiation). However, the
>   specification of the traffic, a particular QoS is guaranteed for,
>   needs to be changed. E.g., in case additional flows are added to the
>   aggregate, the traffic specification of the flow needs to be added
>   if it is not already included in the aggregates specification.

Actually, I think that if we mentioned about the mobility with the
aggregated flow, we should consider the dynamic resource allocation.
If a flow (or MT) leave from old aggregated flow or enter into new
aggregated flow, nothing will be requred to do, I think. But some flows
(MTs) are behave like that, re-provisioning signaling is needed to allocate
some additional resource or to release some extra resources as like the
draft. Also, it is another situation that some source terminals belonging a
aggregated flow are stop the packet transmission for a long time.
The signaling packet like this one should follows the path of a aggregated
flow, of course.

I hope to talk about this situation like above one within this mailing list.
And if I miss something, please forgive my ignorance and let me know.

Regards.

----------------------------------------------------
Ki Young Jung ([email-masked])
Information and Communications University(ICU)
Broadband Network Laboratory (http://bnlab.icu.ac.kr)
58-4 Hwaam-dong, Yusong-gu, Taejon, 305-732, KOREA
Tel)+82-42-866-6182, 016-370-1751 Fax)+82-42-866-6110

---

From: Tricci So <[email-masked]>
Date: Mon, 04 Feb 2002 21:19:05 -0800

Hi John et al,

Sorry for taking me so long to plug into the NSIS mailing list discussion.
It is not easy to keep up with the IETF work when there are other
responsibilities within the company.

Anyway, I truly appreciate all the hard work that been done to put together
the NSIS requirements draft.  I have quicky read through it.  It is very
comprehensive.  However, I do have some requests on the current format and
contents........

1. Although information is good, but too much information sometimes will
digress the real intent of the document.  May I suggest to move the service
application scenarios to the appendix since it seems to be the common
approach for most of the IETF draft.  So that audience can focus on the
scope and requirements discussions.

2. Is the QoS Initiator MUST always interact directly with QoS Controller?
I hope not that this is NOT the intent.

3. In term of the organization of the requirements, as it has been suggested
in section 4.2 that NSIS signaling could run end-to-end, end-to-edge,
edge-to-edge or network-to-network.  I am wondering that if the requirements
can be organized in such a way as
- general requirements
- end-to-edge signaling requirements for certain service applications -
edge-to-edge signaling requirements
- network-to-network signaling requirements

I thought that it may help to make the document more readable since there
are a lot of detailed requirements group together in a single section.   It
is easier to identify which requirement is applicable to which part of the
network.

4. Also, since the goal is to re-use existing protocols as much as possible,
I thought it may be a good idea to create a table of how certain existing
signaling protocol satisfies the given set of requirements in each of the
segment listed above.  By doing this exercise, it is much easier to examine
what are missing in the current signaling protocols.

B.T.W. The comparison can be resided in the appendix as well.

Truly thank you for such a great work.  I will also like to participate in
the conference call if one is available.

Cheers,
Tricci

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 05 Feb 2002 14:51:45 +0100

Tricci,

--On Monday, February 04, 2002 9:19 PM -0800 Tricci So 
<[email-masked]> wrote:

> Anyway, I truly appreciate all the hard work that been done to put
> together the NSIS requirements draft.  I have quicky read through it.  It
> is very comprehensive.  However, I do have some requests on the current
> format and contents........
>
> digress the real intent of the document.  May I suggest to move the
> service application scenarios to the appendix since it seems to be the
> common approach for most of the IETF draft.  So that audience can focus
> on the scope and requirements discussions.
>

IMO the need to be rewritten a bit to more cover use cases as sugested by 
somebody else on the list.

> 3. In term of the organization of the requirements, as it has been
> suggested in section 4.2 that NSIS signaling could run end-to-end,
> end-to-edge, edge-to-edge or network-to-network.  I am wondering that if
> the requirements can be organized in such a way as
> - general requirements
> are a lot of detailed requirements group together in a single section.
> It is easier to identify which requirement is applicable to which part of
> the network.
>

Other opinions? We tried to group them contextwise not where in the network 
they apply.

> 4. Also, since the goal is to re-use existing protocols as much as
> possible, I thought it may be a good idea to create a table of how
> certain existing signaling protocol satisfies the given set of
> requirements in each of the segment listed above.  By doing this
> exercise, it is much easier to examine what are missing in the current
> signaling protocols.
>

I think this needs to be done at a later stage, when deciding how to go on.

> the conference call if one is available.

Welcome, thanks for you help.

Marcus

>> have a conference call in order to help progress the work on this draft.

--------------------------------------
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: [email-masked]
Date: Tue, 05 Feb 2002 19:17:34 +0100

> have a conference call in order to help progress the work on this draft.

John,

I am also interested in participating in the conference call.

Best regards,

-- 
Alban Couturier