Subject: [NSIS] Questions on QoS NSLP draft

From: Bernd Schloer <[email-masked]>
Date: Fri, 15 Sep 2006 17:22:41 +0200

Hi,

I have a few questions on the QoS NSLP draft.

A RESPONSE is sent to a QUERY containing an RII object. The INFO
object is mandatory. Which value does it contain, when no error
situation occured?

A refresh along the path contains a RII object. When do I send
refreshes peer to peer and when refreshes along the path? Are only
refreshes with a RII object answered by a RESPONSE?

When no reservation state is installed at a QNE, does it make
sense to process a RESERVE with set T-Flag and forward it?

A RESPONSE usually contains a RII object that the quering node
does not forward it further along the path. A NOTIFY which is
sent in response of a RESERVE with set Q-Flag could be sent
further along the path by the quering node, if the QNI didn't
request reduced refreshes but a QNE did. Would a RESPONSE make
sense here?

Bernd

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

---

From: David Palma <[email-masked]>
Date: Fri, 15 Sep 2006 17:05:25 +0100

Hi Bernd et al.

Please see in line.

> object is mandatory. Which value does it contain, when no error

Maybe a QoS Specific error code.

> refreshes with a RII object answered by a RESPONSE?

In the introduction we see:

	"...The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 [RFC2205], and uses soft-state peer-to-peer refresh messages as the primary state management mechanism (i.e., state installation/refresh is performed between pairs of adjacent NSLP nodes, rather than in an end-to-end fashion along the complete signaling path)..."

and in section 4.3.4 we can read:

	"...This peer-to-peer refreshing (as opposed to the QNI initiating a refresh which travels all the way to the QNR) allows QNEs to choose refresh intervals..."

With this I mean that peer to peer refreshing is much more useful and I don't see where should we use refreshes along the path. About the second question I would say yes.

> sense to process a RESERVE with set T-Flag and forward it?

I think so because this might happen due to some re-routing and we still 
want to tear down the old branches.

> request reduced refreshes but a QNE did. Would a RESPONSE make

I think that the NOTIFY message should be sent only to the immediate 
upstream peer, much like the RESPONSE sent to the ACK flag on the last 
version of the draft. With this we only answer the upstream node that 
really asked for the reduced refresh.

Regards,

David Palma

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 15 Sep 2006 19:11:00 +0300 (EEST)

Hi, some answers below.

Jukka

> object is mandatory. Which value does it contain, when no error

Section 5.1.3.6: Class 0x02, error code 0x01

> refreshes with a RII object answered by a RESPONSE?

RII is only used in special cases when you might want a refreshto go all 
the way, the default refresh is p2p.

> sense to process a RESERVE with set T-Flag and forward it?

Say your router rebooted, and lost the state. Just after reboot, it gets a 
tear for a session it was supposed to have. Thus, it should just forward 
the message further downstrea, otherwise the reservations will not be 
removed on other nodes downstream.

> request reduced refreshes but a QNE did. Would a RESPONSE make

The NOTIFY includes an INFO_SPEC that tells the result of the request. It
should be sent to the immediate peer from where the RESERVE came, which
does not forward it further.

---

From: Ruud Klaver <[email-masked]>
Date: Sun, 24 Sep 2006 16:34:25 +0200

Hello,

> removed on other nodes downstream.

In this case what should the RSN be in the tearing RESERVE that is
passed on to the downstream peer?

-- 
Best regards,
 Ruud Klaver                     mailto:[email-masked]

---

From: Bernd Schloer <[email-masked]>
Date: Sun, 24 Sep 2006 17:04:46 +0200

Dear Ruud Klaver,

section 5.3.1 says if the Epoch Identifier is different to the stored
one then the reservation has to be seen as an update. The stored RSN
and Epoch Identifier need to be exchanged to the received ones.

In case the router rebooted the RSN can be e.g. 0 and the QNE has
to store it as RSN from the upstream peer.

Bernd