Subject: [NSIS] framework discussion

From: [email-masked]
Date: Mon, 21 Oct 2002 11:20:43 +0200

Hi all,

I have tried to make an overview of some of the issues that have been
brought up during the flurry of e-mails that we have seen over the past
couple of days. I have reacted to some of them. Please correct me if my
impression of the ongoing discussion is not correct or indeed if you have
comments on my reaction.

Cheers,
Sven.

Path-coupled/de-coupled issue
=========================
- There still seems to be a terminology concern. For me coupled is OK but I
wouldn't want to make an issue of it.
- I saw this statement, that seemed to receive some support from various
parties.
"I think that we can leave hooks in for the off-path signaling, but I hope
we don't drive protocol work to accomplish it.  I would prefer to get the
basic on-path signaling work well stablized before developing off-path
signaling."
I agree with this statement, but I think that it does not directly lead to
the conclusion that all path-decoupled issues should be removed from
requirements and framework (in fact, I see it as contradictory: how can you
leave hooks for something that you do not otherwise describe in any of the
documents). The WG has clearly decided to focus on an path-coupled solution
first. For me, combining this with the above statement means:
    * a separation in the requirements documents stating what would be
needed extra for path-decoupled signalling
    * a discussion of the most important issues related to path-decoupled
signalling as is present in some form in the framework document
    * a focus of proposed solutions to describe how they solve the
path-coupled issue
- I saw this statement
"Making an overtly simple example.  If A wants to signal B, on-path means
he signals to B.  Off path means he signals to C."
With the risk of being nitpicky, I think the fundamental thing here is that
A doesn't care where he/she is siganlling as long as he gets the required
reservations to B. If this can be achieved by signalling to C, that should
be fine for him/her.

Peer relationship between NSIS entities
===============================
Several issues were raised regarding the peer relationship between  NEs. I
think the issues raised were
- loss of self-healing properties
- slow down reconfiguration
- persistent connections
- addressing
I believe that the advantages lie in the aggregation of operations (that
you can now do per entity pair instead of per-flow). I don't think that it
would necessarily lead to slower response times since it is not precluded
to keep state about neighbours that can potentially be used for backup.

Discovery
========
I agree with the remark that the current specification does not call for a
separate discovery protocol. I think there would be merit in having a
separate discovery phase (which does not have to be per-flow). At this
point, whether this is implemented as a separate protocol or as a set of
specific messages or parameters in the protocol seems a secondary issue.

Layer split
========
I was under the impression that the two-layer approach with transport and
signalling was agreed by the majority of the group. The framework currently
uses Service Description, NSIS Control Layer and Generic Signaling
Transport  Protocol. With that terminology, I think the requirement would
apply to the combination of the NSIS Control Layer and the Generic
Signaling Transport Protocol. Any QoS related aspects would need to go in
the Service Description part. Apart from a client layer specification in
the CASP proposal, I have not seen a lot on this (which makes sense since
it would not be the focus of NSIS). However, in a complete architecture, a
discussion on this aspect would be very useful.

End-to-end
=========
I didn't quite understand this statement from Melinda:
"That's not to say that I think this is not IETF work - I do think it is.
I just don't think that it could reasonably fit into an end-to-end
signaling protocol.  As it happens, there is a diagram in the framework
document of how it could be done by NSIS working in conjunction with
another protocol, and that's Figure 8."
The diagram in my opinion does not refer to any other protocol than NSIS. I
don't see what the figure shows NSIS could do together with another
protocol and what this protocol would be.

For discussion
===========
- sender- vs receiver-initiated
- multicast

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

---

From: Melinda Shore <[email-masked]>
Date: Mon, 21 Oct 2002 08:21:37 -0400

> first. 

Actually, the WG was told to focus on a path-coupled
solution.  It is still unclear to me that the signaling
protocol used for on-path signaling is the same one that
should be used for off-path signaling - you should use a
protocol that's appropriate for the architecture, it seems
to me.  If an off-path signaling protocol can be done easily
or inexpensively with the same protocol that's being used
for on-path signaling that's great, but it it would be
difficult, perverse, or unnecessarily complex we'd be better
off looking for a more appropriate approach.  I've used
screwdrivers as hammers but frankly I would have been better
off using a hammer.

> I think there would be merit in having a
> separate discovery phase (which does not have to be
> per-flow). 

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