Subject: RE: [NSIS] QoS NSLP: summary object

From: "Shivanajay Marwaha" <[email-masked]>
Date: Mon, 4 Dec 2006 13:12:12 +0800

Dear Jukka, 

I have some comment on your email sent sometime ago. 

Regarding your second point on tearing down several sessions in one NSLP tearing RESERVE message (Summary_TEAR), I've some queries regarding:-

- Is the Summary_TEAR only for one hop (hop-by-hop)? Or, is it meant for multiple hops over a region (for example a Tunnel) as well? 

- Secondly, just to be in sync, what is the criteria for Summary_TEAR? As I understand, if multiple TEAR are received simultaneously at a QNE, they can be combined into a Summary_TEAR (if their next-hop is same). Kindly clarify.

- Lastly, does a QNE wait before forwarding a TEAR in order to generate a Summary_TEAR? For example, if there exists a delay in arrival of multiple TEAR messages propogating on the same path, the Summary_TEAR may not be generated, unless the QNE waits.

Thanks and regards,
Shiv  

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: Friday, November 10, 2006 4:39 AM
> To: [email-masked]
> Subject: [NSIS] QoS NSLP: summary object
> 
> 
> Based on John's request, here is recap of the summary object 
> mentioned today. After Roland's comment on the mic, there are 
> actually two use
> cases:
> 
> 1. Allow a QNE to refresh several sessions in one NSLP 
> refreshing RESERVE message. 
> 
> 2. Allow a ANE to tear down several sessions in one NSLP 
> tearing RESERVE message.
> 
> Both of these save bytes and processing compared to doing it 
> independently for each session. They can be implemented 
> outside GIST by keeping track of the SII_HANDLE provided by 
> GIST (however, you can only know the handle after you have 
> received a message from the per, e.g., a RESPONSE). If a QNE 
> has sessions whose next peer has the same SII_HANDLE, it can 
> use a new SESSION_LIST where it indicates SID+RSN pairs of 
> sessions it wants to refresh or tear down. The receiving QNE, 
> in case of unknown SID, will reply with a RESPONSE carrying 
> the same object to indicate which session references where 
> not understood. If a confirmation was requested from the QNR 
> for a tear, and it must send an individual RESPONSE for each 
> terminated session, as usual - the summary refresh could hit 
> a QNR with multiple sessions being terminated.
> 
> We would like to add this to the NSLP spec. Any comments, 
> arguments, feedback? I'll wait for a week, then add this 
> unless I hear arguments against.
> 
> Jukka
> 
> _______________________________________________
> 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: Jukka MJ Manner <[email-masked]>
Date: Mon, 4 Dec 2006 09:19:43 +0200 (EET)

Hi Shiv,

On Mon, 4 Dec 2006, Shivanajay Marwaha wrote:

> - Is the Summary_TEAR only for one hop (hop-by-hop)? Or, is it meant for 
>   multiple hops over a region (for example a Tunnel) as well?

Sending a Summary tear is only for one hop, you can't force all nodes to 
send summary tear msgs. A QNE receiving a tear may decide by itself, 
whether to send also a summary tear, or individual tear msgs.

> 
> - Secondly, just to be in sync, what is the criteria for Summary_TEAR? 
>   As I understand, if multiple TEAR are received simultaneously at a 
>   QNE, they can be combined into a Summary_TEAR (if their next-hop is 
>   same). Kindly clarify.

That is a configuration and policy issue. We can't mandate to use some 
heuristics and always send a summary tear. It is a beneficial optimization 
for certain situations.

> 
> - Lastly, does a QNE wait before forwarding a TEAR in order to generate 
>   a Summary_TEAR? For example, if there exists a delay in arrival of 
>   multiple TEAR messages propogating on the same path, the Summary_TEAR 
>   may not be generated, unless the QNE waits.

I don't want to specify how one should implement a QNE and summary tear. 
The spec only allows this functionality.

Jukka