Subject: [NSIS] "sessions" and discovery

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Oct 2002 09:41:23 -0400

I think that these are two of the most fundamental questions
that this working group needs to resolve, and while there's
been a suggestion to send the requirements draft through WG
last call both of these questions, along with some other
basic questions (like addressing) are still open.

Frankly, I think that this is something that RSVP got very,
very right and that it might be difficult to improve on it.
In the framework draft it says that NSIS Entity discovery is
not to be included in an NSIS protocol, and in the CASP
draft discovery is a separate process.  What concerns me is
that 1) it leads to a lack of robustness, and 2) it
increases the number of messages required to accomplish a
given task.  Rerunning the discovery process every time
route moves or a node goes down seems to me to be far less
desirable than having discovery be implicit in the state
maintenance mechanism.

Using a stand-alone discovery process becomes more
attractive when you have persistent, (hopefully) durable
connections between NEs.  While I understand that the use of
persistent connections for QoS signaling *might* have better
scaling properties (although I'm not convinced of it), by
rerunning the discovery protocol and then introducing round
trips between entities it makes the system slower to respond
to changes in the network, increases the amount of local
traffic (between NEs), and *requires* an external discovery
process.  My preference would be to look for ways to
aggregate/multiplex messages over a protocol that looks more
like RSVP than it would to create persistent sessions among
NEs.

There have been arguments for creating a stand-alone
RSVP-like discovery protocol that doesn't actually convey
requests or install state, and that's certainly what TED
does.  I would argue that a correctly designed RSVPv2 could
do that very easily and is almost certainly preferable to
separate discovery/state processes.

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 17 Oct 2002 23:50:52 +0100

hi melinda,

<framework hat on>
a quick clarification:

> not to be included in an NSIS protocol

if you're referring to the statement at the very end of section 4.2, the key word there is 'potentially'. 

the framework doesn't exclude the basic NSIS protocol working out for itself where to send messages (even doing to implicitly, i.e. operating in end-to-end addressing mode). the framework leaves open the option that there might be additional/complementary approaches, which would be seen as being handled by other protocols which supported NSIS. [one example might be a wireless node being told by DHCP that all its traffic was going to arrive via a single router which it could then request resources from.]

in other words, the framework doesn't say "you have to separate message transport from discovery". if you think this is unclear, we can fix it.

<framework hat off>

cheers,

robert h.

> Melinda
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: [email-masked]
Date: Fri, 18 Oct 2002 08:20:07 +0300

Hi Robert,

> in other words, the framework doesn't say "you have to 
> separate message transport from discovery". if you think this 
> is unclear, we can fix it.

Perhaps it would be good to clarify it.

John