Subject: [NSIS] QoS NSLP: RSN + tear down

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 10 Jan 2007 14:13:34 +0200 (EET)

Hi all,

I now have the QoS NSLP spec updated with the recent comments. One issue 
remains, that I'd like a confirmation before sending out to you for review 
v. "13-pre2".

Issue: RSN + tear down

We have earlier decided that RSNs would not be interpreted when tearing 
down a reservation. However, we actually need to interpret them, otherwise 
the path change mechanism currently specified will not work (see my 
previous email about the mobility work today).

Thus, I propose that when a node receives a tearing RESERVE, it MUST 
interpret and compare the RSN in the message to the stored RSN. 

1. If the RSN values match, the QNE MUST perform the tear down and send 
   out a tearing RESERVE with the RSN object.

2. If the received RSN is greater than the stored RSN, the QNE MUST 
   perform the tear down, and send out a tearing RESERVE with the received 
   greater RSN value.

3. If the received RSN is less than the stored RSN, the QNE MUST silently 
   drop the tearing RESERVE, and not perform any tear down, nor send out 
   any tearing RESERVE.

Jukka

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

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 15 Jan 2007 10:34:10 +0100

Hi Jukka,

The proposed text sounds good to me.

   Martin

---

From: Roland Bless <[email-masked]>
Date: Tue, 16 Jan 2007 10:55:54 +0100

Hi Jukka,

> previous email about the mobility work today).

Ok, we overlooked that. I guess that you are right in this respect.
What about the RSN-1 hack in section 3.2.11.2. (the last sentence seems
to be messed up somehow: "This in the peer from which it was receiving
RESERVE messages.")?

>    drop the tearing RESERVE, and not perform any tear down, nor send out 

Ok, sounds fine to me, too.

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 17 Jan 2007 18:03:29 +0200 (EET)

Hi Roland, all,

My only small concern is with how to update the RSN numbers. As I put in 
an earlier email with the example of mobility with the QoS NSLP, the main 
point is that the reservation on the _new_ path must have a higher RSN 
than the old path, which is to be torn down.

The NSLP draft currently has the same point, but goes a bit further, in 
that the reservation on the new path has an RSN that is greater by two 
compared to the old RSN, and the tear-down is also one higher than the 
old.

I think it is enough that the new reservation is simply with a higher RSN 
value than the RSN used for the existing reservation.

However, we have another problem here. I will reply using my previous 
email with the network scenario.

Jukka