Subject: RE: [NSIS] Layer split issues

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 4 Dec 2002 11:27:51 +0100

Hi Melinda

>> 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.

I agree with you, we should just simplify RSVPv1 as much as possible,
i.e., use only the transport related features,
and try to see if it can be used as a NTLP.

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

---

From: [email-masked]
Date: Wed, 4 Dec 2002 12:37:40 +0100

Hi Robert, all,

I have included some comments inline.

Cheers,
Sven.

"Hancock, Robert" <[email-masked]>@ietf.org on 28/11/2002
14:42:40

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  [NSIS] Layer split issues

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.]

[Sven] I agree that the NTLP message types should be restricted to send
data.

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".)

[Sven] It is clear that the NTLP should have the functionality to get to
the next NTLP peer. This is required to support opaque handling of NSLP (I
believe 'selective nodes' is used elsewhere to indicate this
functionality). What I would like to get to the bottom of is what exactly
will happen with route changes. Detecting and notifying them is the minimum
we need.

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.

[Sven] I am not sure I completely follow you here. Why does the NTLP node
need to (implicitly or explicitly) construct the whole path if its scope is
restricted to the next hop? I am also not sure what you mean with 'the NSLP
is free to interfere'.

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')

[Sven] The underlying reason here, I believe is the assumption that the
backwards direction, if required will be taken care of by means of
installed (reverse) state. There are other ways of doing it (record route
is an example) which do not require keeping state. I think it is important
that these are not excluded in the discussion.

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.

[Sven] Can you give an example where this would matter for the NTLP?

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.

[Sven] Agreed. Or in other words, UNI/NNI distinction is irrelevant in the
NTLP context.

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 4 Dec 2002 13:04:33 -0000

hi sven,

some comments on your comments.

[snip]
> Path Management

[reh] i think having the ability to notify an NSLP is included, and to detect at least local routing changes. i think there are some path changes better detected in the signalling application (but this is a bizarre idea i am still thinking about).
mobility handling was in my category (3) ("too hard at the moment" box)

> restricted to the next hop? I am also not sure what you mean 

[reh] what i mean is
*) first NTLP sends it to the next
*) it knows the next will send it to the next
*) and so on till it gets to the end
 - and lo! the originating signalling application just passed a message to the NTLP and has good reason to believe it got all the way, even if there were no signalling application instances in the middle of the network helping it along.

what i mean by 'interfere' is that a signalling application might eat a message at an interior node and do something which made it wrong for the NTLP to forward it directly (e.g. it might put it and its flow inside an aggregate).

> where they can be solved once. But I think there may be other views as

[reh] i agree with you, but your comment is actually relevant to the next point (b). What (a) is trying to say (badly) is that the NTLP is only required to find downstream, not upstream peers (which is good, because we only know how to do the downstream case). 

> [Sven] Can you give an example where this would matter for the NTLP?

[reh] 
1. to answer your route-recording point: i agree this is a reasonable mechanism to contemplate, and is not excluded here. all it says is that the state OR recorded-route data is kept internally to the NTLP, and the signalling application doesn't care how it's done.
2. where would it matter? if you had a resource management application which only required sender-->receiver messages (I'm sure you can think of one), the NTLP could forget about all the backwards routing stuff and be simpler.

cheers,

robert h.

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 4 Dec 2002 13:10:02 -0000

Hi Georgios, Melinda, all,

> and try to see if it can be used as a NTLP.

To be clear: are we assuming that when people say 'RSVP' or 'RSVPv1' transport features they include RFC2961? I certainly hope so. (That is, I feel we need to be able to support at least equivalent transport functionality to RFC2961, even if it is not mandated in all circumstances. Presumably, these features were not added to RSVP without a good reason - i.e. genuine need. [maybe it would be profitable for the analysis document to explain why!])

Cheers,

Robert H.

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 4 Dec 2002 16:43:35 +0100

Hi Robert 

Which features of RFC2961 do you consider as transport features?

Best regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: woensdag 4 december 2002 14:10
To: [email-masked]
Subject: RE: [NSIS] Layer split issues 

Cheers,

Robert H.

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 4 Dec 2002 16:28:59 -0000

hi georgios,

i would say most of them, certainly message bundling and retransmission backoff and probably message identification. (i'm not sure about the summary refresh since i'm not sure about whether state management is a transport function, although i'm preparing to write something separate on this anyway.)

which parts would you say were signalling application specific?

cheers,

r.

> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 04 December 2002 15:44
> To: Hancock, Robert; [email-masked]'
> To be clear: are we assuming that when people say 'RSVP' or 
> 'RSVPv1' transport features they include RFC2961? I certainly 
> hope so. (That is, I feel we need to be able to support at 
> least equivalent transport functionality to RFC2961, even if 
> it is not mandated in all circumstances. Presumably, these 
> features were not added to RSVP without a good reason - i.e. 
> genuine need. [maybe it would be profitable for the analysis 
> document to explain why!])
> 
> Cheers,
> 
> Robert H.