Subject: [NSIS] SII-Handle

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

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