Subject: RE: [NSIS] framework discussion

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 24 Oct 2002 16:41:05 +0100

hi melinda,

ok:
<framework hat>
i thought it was obvious, but if you asked me to point at the precise place in the framework where it said so i would struggle.

so, i suggest we add a short statement in the 'basic assumptions' section (3.3.1) which says something about all the routing information being managed in the basic NSIS protocol (not visible to applications, anyway), and messages being routed peer-by-peer. we can point to some later subsections for more details (which i think are there, it's just the basic starting point that's missing).

would that be a step in the right direction?
</framework hat>

robert

ps. i also owe you responses on your other more detailed framework comments, but just recently i've been trying to get my head round the sender/receiver question which seems to be one of the primary headaches.

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: 24 October 2002 16:20
> To: Hancock, Robert
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] framework discussion 
> 
> 
> > if you change your phrase "each node has information about
> > adjacent hops" --> something about an NSIS entity talking
> > to its peer, i think we're saying the same thing, and no
> > one's suggesting the approach indicated in the first part
> > of your sentence.
> 
> I'm not sure that we are talking about the same thing.  I do
> think that this needs to be clarified in both documents so
> that we have a simple description of what's intended.  I've
> seen quite a few proposals, both in midcom and in discussion
> of off-path QoS signaling, that place IP-layer route
> information in the application, so when you say that
> "obviously (?) we are talking about finding the appropriate
> peer within the context of talking about a particular flow"
> it is actually not that obvious (although in an ideal world
> it would be).
> 
> Melinda
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Bob Braden <[email-masked]>
Date: Thu, 24 Oct 2002 17:09:33 GMT

Melinda,

I apologize for reading the NSIS email sporadically; I have not had
time to catch up.  I will go back and read your reply.

Bob

---

From: Bob Braden <[email-masked]>
Date: Thu, 24 Oct 2002 17:34:48 GMT

*> 
  *> See my answer to Robert.  I think we may be having some
  *> terminological problems,

Melinda,

Yup.  Looking broadly at the recent discussions, I would suggest that
we should generally unqualified words like "path" and "discovery".

Thus, I think we can all agree that "neighbor discovery" and "path
discovery" are two different issues with different requirements (and
probably different mechanisms.)  I think I hear some saying that
*neighbor discovery* might need a separate phase while others say (as I
implied in the 2-level document) that neighbor discovery will generally
happen without any additional packet exchanges.  I hear you saying the
the RVSP scheme of *path discovery* works very well (which *I*
certainly won't disagree with ;-)).

Does this make sense?

Bob

---

From: [email-masked]
Date: Fri, 25 Oct 2002 12:49:50 +0300

Hi Melinda, Sven and/or Bob,

> > Hmmm. I believe that Sven was using the term "peer" for what we
> > in the Internet world customarily call a "neighbor".  Neighbor
> > discovery is pretty fundamental to many routing protocols, 
> right?  And
> > I believe it will be fundamental to a signaling protocol.  (See my
> > earlier message about "session").  Perhaps we are talking about
> > different things here, or am I just misunderstanding?
> 
> See my answer to Robert.  I think we may be having some
> terminological problems, plus I was responding to Sven's
> comment that we need peer discovery but not path/NI
> discovery.  It seems to me that we need both.  It may (or
> may not!) be useful to think about policy-based routing when
> sorting this through.

Please suggest text to go into the Framework document.  rather
than discussing the need for terminology, let's get some resolution.

thanks,
John

---

From: [email-masked]
Date: Fri, 25 Oct 2002 12:49:54 +0300

Hi Bob,

> certainly won't disagree with ;-)).

So, I propose that we add 'Neighbor Discover' (perhaps prefix it with NSIS,
so we don't confuse it with IPv6 Neighbor Discovery) & 'Path Discovery'
to the framework & requirements (if needed there) and use these.

John