Subject: RE: [NSIS] framework discussion

From: [email-masked]
Date: Wed, 23 Oct 2002 08:38:08 +0200

Hi Robert, Melinda,

Please see inline.

Sven.

"Hancock, Robert" <[email-masked]>@ietf.org on 21/10/2002
23:01:48

Sent by:  [email-masked]

To:   Melinda Shore <[email-masked]>, Sven VAN DEN
      BOSCH/BE/ALCATEL@ALCATEL
cc:   [email-masked]
Subject:  RE: [NSIS] framework discussion

hi melinda,

[snip]
> > [sven] I think there would be merit in having a
> > separate discovery phase (which does not have to be
> > per-flow).
>
> [melinda] This working group is very focused on QoS.  There are other
> applications for which the protocol will be used, and for
> some of those protocols topology is an important issue (if
> not the defining issue).  Examples include firewall/NAT
> traversal and tunnel endpoint discovery/communication.
> Indeed, any NSIS protocol which is expected to be able to
> talk to NATs and traverse them intelligently is going to
> have to concern itself with topology.  Accretion of
> topological information and returning it to the NSIS
> initiator to sort through and build appropriate messages
> is not going to be as effective, I would argue, as the
> current RSVP model where each node has information about
> adjacent hops and the message's success is not dependent on
> someone having knowledge of the entire end-to-end path.  At
> a very minimum it's going to need adjacent hope information,
> anyway.
>
> Melinda
>

[robert] actually, i'm not clear that there's any disagreement here.

as i understand it, all discussions involving the term 'discovery' are
about peer (next-NSIS-hop) discovery, not complete-path-discovery - i.e.
essentially the same as what the RSVP PATH mechanism does. i've certainly
never seen an explicit suggestion that all this information should get sent
back to the NI.

[Sven] I have the same understanding as you have (just peer discovery, not
path/NI discovery). If this resolves the issue that would be great.

have i been deluding myself?

cheers,

robert h.

========================================================================================

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

(See attached file: RMRL-Disclaimer.txt)

---

From: Melinda Shore <[email-masked]>
Date: Thu, 24 Oct 2002 08:37:49 -0400

> path/NI discovery). If this resolves the issue that would be great.

Routing problems tend to be very difficult, and in the
context of this protocol I'm unclear on what it means to
talk about peer discovery without also talking about path
discovery.  Peer relationships *by themselves* really aren't
very meaningful.

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