Subject: RE: [NSIS] SII-Handle

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 8 Sep 2005 17:22:31 +0100

Hi Roland,

I can't answer for the QoS-NSLP. However, I've done some
revision of the route change detection section, and as a
result there are a couple of changes in other parts of
the API which answer your first point:

- NetworkNotification gets invoked when routing state is
first established (or re-established);

- the SII-Handle is provided when this happens.

So, the NSLP knows the SII-Handle of its peer with which
it has established routing state, and knows when it changes.

cheers,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Roland Bless
> Sent: 08 September 2005 17:12
> To: [email-masked]
> Subject: [NSIS] SII-Handle
> 
> 
> Hi,
> 
> some questions about the SII-Handle:
> as far as I understood the GIST spec, an NSLP may use he
> SII-Handle (which has only local significance, i.e. in the
> same node) to explicitly refer to message routing state
> (and, thus peer/GIST next hop). The SII-Handle is not transferred
> between the nodes but along the API between GIST/NSLP.
> Currently, SII-Handle is communicated to NSLP via the
> RecvMEssage() primitive of the API.
> In this case GIST will provide the SII-Handle for the routing
> state in the outgoing direction to the peer who just
> sent the message, right?
> 
> * Shouldn't there be a way to notify NSLP of a
>   new or changed SII-handle? So, if I use a SendMessage()
>   primitive to send a message downstream, but I'll get no
>   NSLP response message back (so I don't get a RecvMessage()
>   for a response from my downstream peer), how will NSLP get
>   knowledge of the SII-handle (for the downstream peer)?
>   Or is it indeed sufficient if you only get the SII-Handle
>   when you receive something from your neighbor?
> 
> * the QoS NSLP draft-07 seems to confuse the SII handle
>   with something similar like a peer identity. While the
>   definition in the GIST draft is consistent, I strongly
>   recommend that the current definition within QoS NSLP should
>   be removed: IMHO it doesn't make any sense to require
>   a length of at least 128 bit and the SII handle is *not*
>   chosen by the QoS NSLP but by the GIST implementation.
>   A 32-bit value would usually be sufficient since NSLP/GIST
>   can address 2^32 different next hops in this case.
> 
> Regards,
>  Roland
> 
> _______________________________________________
> 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: Roland Bless <[email-masked]>
Date: Thu, 08 Sep 2005 21:57:36 +0200

> it has established routing state, and knows when it changes.

This sounds good to me...

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Thu, 08 Sep 2005 22:43:10 +0200

Hi Robert,

Two additional questions:
- Is it true that an SII-Handle references exactly
  a particular next hop in one direction, either up- or downstream
  (and not both peers at once)?
- sec 4.2.1 says:
  The information for a given key consists of two items: the routing
  state to reach the upstream and the downstream peer, with respect to
  the MRI in each case.

I'm not sure whether the above statement is correct since the
up/down flag is now contained in the MRI.
I think that a key (MRI,SID,NSLPID) references
routing state to exactly only one peer (either up or downstream,
depending on the MRI D flag). If I'm right the above statement
should be corrected since it says an entry consists of two items.

Regards,
 Roland