Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier

From: "Freytsis, Ilya" <[email-masked]>
Date: Fri, 8 Nov 2002 09:42:46 -0500

My comments in-line

Regards,
Ilya

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: Thursday, November 07, 2002 5:37 PM
To: Bob Braden; [email-masked]; [email-masked]
Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i
dentifier

Hi,

A comment on scope/layering of this reservation identifier thing (if it ever
exists):

>   *> So reformulating the requirement into "An NSIS protocol
> MUST support a
>   *> reservation identifer" would solve the first one.
>
> OK, although I would say "MUST be able to support".
>
> BTW, a reservation identifier is presumably a multi-hop
> thing, so in my
> 2-level model it is a creature of ULSP, i.e., it is carried in an
> SAPU.  That's good, because non-QoS signaling applications probably
> don't have any reservations to identify.

I think we need to work through this.

1. As Marcus has said, we are signalling to set up something, and that
something is what we want to identify to be able to manipulate - it doesn't
matter if it's QoS (and called a reservation) or something else.
[IF] That is right to the point. I just want to add that that something is
separate from the flow but used by the flow. The main value of the
reservation ID in my mind is to enable referencing that something
independently from any other characteristics of the flow.

The v6 flow label draft calls this something 'flow state' so this identifier
could be a "flow state id". Would that be a better term?
[IF] I don't think. See the argument above.
2. My feeling is that this XXX-id would be useful for general signalling
applications (i.e. if you use the signalling application in a mobile
enviroment, efficiently moving the state is something you want to do
anyway). Also, providing the facility might be tricky, and might require
subtle interworking with other protocols (e.g. mobility ones).

In that case, it be better to provide it as a generic service rather than
solving the problem for each signalling application.
[IF] Agreed.
3. So, wouldn't one want it within the NTLP (lower layer)?
[IF] Absolutely.
4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has
these generic facilities?
[IF] I think it is good way to move forward.
Cheers,

Robert H.
_______________________________________________
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: Nguyen Thi Mai Trang <[email-masked]>
Date: Fri, 08 Nov 2002 16:24:42 +0100

Hello,

In the draft-ietf-nsis-req-05.txt, the definition of sender-/receiver initiated
signaling protocol (page 4) is not clear for me. In fact, the word "inititated"
means "initiate the signaling process" or "initiate the reservation"? Are the
"sender" and "receiver" considered over the data stream?

I take RSVP for example:

For a data stream from A to B (source = A, destination = B), A initiates the
signaling process by sending PATH message. B initiates the reservation process
by sending RESV message.

In comparison with sender-initiated definition in the draft, B initiates the
reservation, then RSVP is receiver-initiated signaling protocol. In comparison
with sender-initiated definition in the draft, A initiates the signaling, then
RSVP is sender-initiated signaling protocol. Therefore, RSVP is both sender- and
receiver-initiated protocol !???

Another question, what does "the triggering instance" means in the sentence
"However, the triggering instance is not specified" ?

Thanks for any clarification,
Mai Trang

---

From: MATSUURA Nobuaki <[email-masked]>
Date: Mon, 11 Nov 2002 18:13:12 +0900

Hello Mai Trang,

According to the definition in the draft, RSVP seems to be both
sender- and receiver-initiated signaling protocol, as you said.
I think that there should be a receiver-initiated signaling protocol,
in which a receiver initiates the "signaling".

(FYI... may be relevant)
http://www.ietf.org/internet-drafts/draft-matsuura-reverse-lsp-01.txt

Regards,

 Nobuaki