Subject: [NSIS] Layer split issues

From: Michael Thomas <[email-masked]>
Date: Tue, 3 Dec 2002 16:52:34 -0800 (PST)

So, I'm still trying to make it back to some
reasonable semblance of "caught up", and I have to
say that this desire for a new decoupling of
transport/application leaves me pretty quizzical
as to why the current set of affairs with RSVP are
so broken that we need to open Pandora's Box here.

As I said in the meeting, I think that we should
be pretty prejudiced toward not fixing things that
aren't absolutely, positively broken. What we
don't want to be facilitating here is a Second
System Syndrome Crack House. RSVP already has a
division of labor of sorts, re transport. What's
the fatal problem here again?

	  Mike

Hancock, Robert writes:
 > Dear all,
 > 
 > Following the NSIS session in Atlanta, I'd like to stimulate further discussion (and maybe agreement??) on some of the issues around where the NTLP/NSLP boundary should actually go.
 > 
 > It seems to me there are 
 > 1) some options on which there is some agreement
 > 2) some options on which there is some disagreement
 > 3) some options we haven't really discussed yet or at least not properly.
 > 
 > This email is an attempt to summarise (1) (i.e. find out whether I have read the mood right). Separate emails will cover some of the topics under (2). 
 > 
 > [I think (3) includes some real headaches (e.g. mobility handling/reservation identifiers, security attributes, coupled/decoupled aspects) which can reasonably be postponed before (1) and (2) are clearer.]
 > 
 > Message Types
 > =============
 > 
 > I think we can make a working assumption that the NTLP basically provides a capability like 'send data', without associating that data with creating a reservation, querying something, releasing resources, or whatever. The 'send data' message can go with or against the data flow, and only goes between NTLP peers.
 > 
 > Is this valid? [There may be different variants of 'send data' depending on whether the NTLP can do state management stuff, I'm not prejudging that here.]
 > 
 > [NB. There are potentially confusing comments within the framework about how much the NTLP and NSLP could be coupled/not properly independent layers. This is a historical overhang from when we used to think that the NTLP would have a richer message set. If the NTLP has only a very simple message set, these issues would go away.]
 > 
 > Path Management
 > ===============
 > 
 > What was discussed/not objected in the framework session was (roughly) the assertion that the NTLP processing at each NSIS entity should include getting to the next NTLP peer, and that the NTLP should detect and maybe do something about path changes ("do something" may just be "tell the NSLP it's happened".)
 > 
 > Left to its own devices, the NTLP would then implicitly construct the whole path (although I would content this shouldn't be described as giving the NTLP end to end capabilities). But the NSLP at any node is free to interfere however it wants anyway.
 > 
 > I like this because it puts a large number of hard but signalling application independent, transport and lower layer issues inside the NTLP where they can be solved once. But I think there may be other views as well. Arguments?
 > 
 > Sender/Receiver Issues
 > ======================
 > 
 > The proposal (actually in an individual submission) is that, in so far as the NTLP has 'directionality':
 > a) it only needs the functionality to get to the next NTLP peer in the sender-->receiver direction (might be called 'sender oriented')
 > b) by default, it should be able to send its 'data' messages either direction, but as an optimisation, some signalling applications might only ask to send them sender-->receiver.
 > 
 > However, we shouldn't make any restrictions on how (i.e. from which end) any NSLP should trigger the signalling process, request/authorise something, or whatever. In other words, NI and NR are NSLP concepts.
 > 
 > I haven't heard counter-proposals, but the assumption is partly contingent on the path management assumption (so I'm asking).
 > 
 > 
 > 
 > Is this a reasonable starting point?
 > 
 > Cheers,
 > 
 > Robert H.
 > 
 > (Later, under (2), we get to state management and flow identification, where there are clearly interesting divergences of view.)
 > _______________________________________________
 > nsis mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/nsis
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Melinda Shore <[email-masked]>
Date: Tue, 03 Dec 2002 20:04:50 -0500

> and I have to

I don't know how far out on a limb we need to go, but I do
think that it's pretty clear that in RSVP, QoS in general
and intserv in particular are more closely intertwined with
the protocol itself than they need to be, particularly in
the form of mandatory data elements.  There may be stuff
around the namespace if it does become a more general
signaling protocol; one of the unfortunate things about
Diameter, for example, is that the flatness of the namespace
makes adding new applications a little unwieldy.  I'd be
happy, frankly, with just getting some of that stuff cleaned
up, but other people have raised specific issues about a
need for reliable delivery, etc., and I hope they can be
more explicit about why they feel it's necessary.

Melinda