Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i dentifier

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 4 Nov 2002 19:20:38 -0000

hi all,

I confess being somewhat in a dilemma about this one. Please excuse the following somewhat discursive email.

On the one hand, I think there is (fairly) widespread consensus that an independent reservation identifier is needed to support certain seamless mobility functions. For example, Mike Thomas' draft includes in 1.2.5:

"... this draft makes the wild and perhaps unfounded
   assumption that the ISSLL working group will step up to allowing RSVP
   to use a session identifier in addition to the normal 5-tuple to
   identify a reservation. Given the round trip implications, the author
   cannot see how seamless mobility with RSVP reservations can be
   achieved if this assumption is false."

What is unclear is 
(a) whether the improvements over plain resignalling from scratch is worth it
(b) especially given that supporting such an identifier is hard.

But in any case, if the role of this identifier is supporting mobility scenarios, then we already have a requirement for that (5.8.1, "Allow efficient XXX re-establishment after handover"). If a separate identifier is the only way to meet that, we'll get it anyway. Incidentally, if we delete 'efficient' in 5.8.1 the requirement becomes unambiguous and entirely vacuous, since you can always resignal from scratch.

In that sense, we don't need 5.4.3....

On the other hand, we have (I think) a general goal to develop something that can be used for applications and in scenarios we haven't thought of yet, which leads to certain goals about modularity, clean interfaces with other protocols/functions, and so on. Being able to refer to a reservation independently of the flow identification could come into that category of Good Things (like, for example, structuring things as two layers/levels...). But does that mean we need it in the requirements document? It depends what you want to use the requirements document for (which actually isn't clear to me at the moment).

My instinctual preference would be to keep it as a should.

Cheers,

Robert H.

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: 04 November 2002 17:54
> To: [email-masked]; [email-masked]
> Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of 
> reservation
> identifier
> 
> 
> 
>   *> 
>   *> 
>   *> Req-Draft: Open Issue 2: Independence of reservation identifier
>   *> ----------------------------------------------------
>   *> 
>   *> - see thread on NSIS and mobility
>   *> - is the req needed?
>   *> - is it needed for a general NSIS base protocol? Or is 
> it application 
>   *> dependent?
>   *> 
>   *> 5.4.3 Independence of reservation identifier
>   *> 
>   *> A reservation identifier MUST be independent of the flow 
> identifier (flow 
> 
> Actually, only trouble I have with this statement is capitalizing
> MUST.  By its very definition, a reservation identifier is independent
> of the flow identifier (otherwise, we wouldn't call it a reservation
> identifier, we would call it a flow identifier, right?) Since the
> independence is by definition, not de jure, there is no place for MUST
> here -- there is no requirement.  The requirement (should it be agreed
> upon), woudd simply be that the protocol MUST support a reservation
> identifier.
> 
> HINT: The best list of requirements is the shortest list, not the
> longest list.
> 
> Bob Braden
> 
>   *> end-points). Various scenarios in the mobility area require this 
>   *> independence because flows resulting from handoff might 
> have changed 
>   *> end-points etc. but still have the same service 
> requirement. Also several 
>   *> proxy-based signaling methods profit from such as independence.
>   *> 
>   *> 
>   *> --------------------------------------
>   *> Dr. Marcus Brunner
>   *> Network Laboratories
>   *> NEC Europe Ltd.
>   *> 
>   *> E-Mail: [email-masked]
>   *> WWW:    http://www.ccrle.nec.de/
>   *> Phone: +49 (0) 6221 905 11 29
>   *> personal home page: http://www.brubers.org/marcus
>   *> 
>   *> 
>   *> _______________________________________________
>   *> nsis mailing list
>   *> [email-masked]
>   *> https://www1.ietf.org/mailman/listinfo/nsis
>   *> 
> _______________________________________________
> 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: Bob Braden <[email-masked]>
Date: Mon, 4 Nov 2002 19:58:31 GMT

*> 
  *> On the one hand, I think there is (fairly) widespread consensus that an independent reservation identifier is needed to support certain seamless mobility functions. For example, Mike Thomas' draft includes in 1.2.5:

Robert,

"Widespread consensus" does not always mean it's true ;-).  Ten years
ago there were countless papers and publications citing the "widespread
consensus" that TCP could never be made to operate faster than a megabit
per second, since TCP was too "heavyweight" a protocol.  This of course
turned out to be nonsense. 

  *> 
  *> "... this draft makes the wild and perhaps unfounded
  *>    assumption that the ISSLL working group will step up to allowing RSVP
  *>    to use a session identifier in addition to the normal 5-tuple to
  *>    identify a reservation. Given the round trip implications, the author
  *>    cannot see how seamless mobility with RSVP reservations can be
  *>    achieved if this assumption is false."
  *> 
  *> What is unclear is 
  *> (a) whether the improvements over plain resignalling from scratch is worth it

Yes...

  *> (b) especially given that supporting such an identifier is hard.
  *> 

I am puzzled about what is hard about it.  It seems pretty straightforward.
Is there a one or two-sentence explanation of why it is hard?

Bob

  *> But in any case, if the role of this identifier is supporting mobility scenarios, then we already have a requirement for that (5.8.1, "Allow efficient XXX re-establishment after handover"). If a separate identifier is the only way to meet that, we'll get it anyway. Incidentally, if we delete 'efficient' in 5.8.1 the requirement becomes unambiguous and entirely vacuous, since you can always resignal from scratch.
  *> 
  *> In that sense, we don't need 5.4.3....
  *> 
  *> On the other hand, we have (I think) a general goal to develop something that can be used for applications and in scenarios we haven't thought of yet, which leads to certain goals about modularity, clean interfaces with other protocols/functions, and so on. Being able to refer to a reservation independently of the flow identification could come into that category of Good Things (like, for example, structuring things as two layers/levels...). But does that mean we need it in the requirements document? It depends what you want to use the requirements document for (which actually isn't clear to me at the moment).
  *> 
  *> My instinctual preference would be to keep it as a should.
  *> 
  *> Cheers,
  *> 
  *> Robert H.
  *> 
  *> > -----Original Message-----
  *> > From: Bob Braden [mailto:[email-masked]]
  *> > Sent: 04 November 2002 17:54
  *> > To: [email-masked]; [email-masked]
  *> > Subject: Re: [NSIS] Req-Draft: Open Issue 2: Independence of 
  *> > reservation
  *> > identifier
  *> > 
  *> > 
  *> > 
  *> >   *> 
  *> >   *> 
  *> >   *> Req-Draft: Open Issue 2: Independence of reservation identifier
  *> >   *> ----------------------------------------------------
  *> >   *> 
  *> >   *> - see thread on NSIS and mobility
  *> >   *> - is the req needed?
  *> >   *> - is it needed for a general NSIS base protocol? Or is 
  *> > it application 
  *> >   *> dependent?
  *> >   *> 
  *> >   *> 5.4.3 Independence of reservation identifier
  *> >   *> 
  *> >   *> A reservation identifier MUST be independent of the flow 
  *> > identifier (flow 
  *> > 
  *> > Actually, only trouble I have with this statement is capitalizing
  *> > MUST.  By its very definition, a reservation identifier is independent
  *> > of the flow identifier (otherwise, we wouldn't call it a reservation
  *> > identifier, we would call it a flow identifier, right?) Since the
  *> > independence is by definition, not de jure, there is no place for MUST
  *> > here -- there is no requirement.  The requirement (should it be agreed
  *> > upon), woudd simply be that the protocol MUST support a reservation
  *> > identifier.
  *> > 
  *> > HINT: The best list of requirements is the shortest list, not the
  *> > longest list.
  *> > 
  *> > Bob Braden
  *> > 
  *> >   *> end-points). Various scenarios in the mobility area require this 
  *> >   *> independence because flows resulting from handoff might 
  *> > have changed 
  *> >   *> end-points etc. but still have the same service 
  *> > requirement. Also several 
  *> >   *> proxy-based signaling methods profit from such as independence.
  *> >   *> 
  *> >   *> 
  *> >   *> --------------------------------------
  *> >   *> Dr. Marcus Brunner
  *> >   *> Network Laboratories
  *> >   *> NEC Europe Ltd.
  *> >   *> 
  *> >   *> E-Mail: [email-masked]
  *> >   *> WWW:    http://www.ccrle.nec.de/
  *> >   *> Phone: +49 (0) 6221 905 11 29
  *> >   *> personal home page: http://www.brubers.org/marcus
  *> >   *> 
  *> >   *> 
  *> >   *> _______________________________________________
  *> >   *> nsis mailing list
  *> >   *> [email-masked]
  *> >   *> https://www1.ietf.org/mailman/listinfo/nsis
  *> >   *> 
  *> > _______________________________________________
  *> > 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: "Geib, Ruediger" <[email-masked]>
Date: Tue, 5 Nov 2002 09:49:12 +0100

Hi John,

I'd like to to keep a reservation ID as a requirement and 
I prefer to look at it as a "must" (no capitals). Two 
issues: it may save signaling load if you refresh by using 
reservation IDs instead of flow IDs. That may be 
intersting on wireless interfaces, but not only there. 
The other argument I see is aggregation. I'm aware of 
RFC 3175 and I regard the aggregation 
mechanism designed there as smart but non trivial. A 
reservation ID may be useful in this context.

I've twice used "may" here. It would be great if could 
decide on the strength of requirement (must, should, may) 
after we checked some real world designs and a proof of 
concept.

Regards, Rüdiger

> > Bob Bradeb wrote:
> > MUST.  By its very definition, a reservation identifier is 
> > independent of the flow identifier (otherwise, we wouldn't call 
> > it a reservation identifier, we would call it a flow identifier, 
> > right?) Since the independence is by definition, not de jure, 
> > there is no place for MUST here -- there is no requirement.  
> > The requirement (should it be agreed
> > upon), would simply be that the protocol MUST support a reservation
> > identifier.
> > 

> John Loughney wrote:
> I think I agree.  It actually also sounds very much like a protocol
> specific issue.  Is the issue really that we would like to 
> have seperation between a reservation & a flow?  Perhaps this is 
> one requirement we can drop.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 5 Nov 2002 09:51:29 +0100

Robert,

> The hard point is the security aspect, since so far as I can 
> tell, (in general) any random node in the Internet could pop 
> up and say "I want to modify reservation XXX 'cos it's really 
> mine", and it would be hard to decide whether it wasn't just 
> the real node having moved. All it has to do is get it's 
> signalling message to intersect the existing path for that 
> reservation id. 

Do you want to say that flow Id's provide better security?

Regards, Rüdiger

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 5 Nov 2002 09:04:49 -0000

yes, after a fashion.

see e.g. http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg01993.html

it's not cryptographic security, of course.

robert h.

> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: 05 November 2002 08:51
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of 
> reservation
> i dentifier
> 
> 
> Robert,
>

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 5 Nov 2002 12:09:40 +0100

Hi Robert

There might be other situations than supporting mobility scenarios,
where you might need independence of the reservation identifier.
For example, think about SCTP which supports multiple source and
destination addresses, i.e., the SCTP Multi-Homing Feature (see 
ftp://ftp.rfc-editor.org/in-notes/rfc3286.txt)

Best Regards,
Georgios

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: maandag 4 november 2002 20:21
To: Bob Braden; [email-masked]; [email-masked]
Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation
i dentifier

hi all,

What is unclear is 

Cheers,

Robert H.

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 5 Nov 2002 12:02:28 -0000

hi Georgios,

Nice example (also comes up in the v6 flow label draft). Rudi has mentioned reservation bundling/aggregation. I am sure there are others (as well as mobility of course).

So that would come into my second category of motivation (see "on the other hand" below): we see several examples of how it can be useful to refer to a reservation independently of the specific flow it is associated with; therefore, it should (SHOULD? MUST? may) be a basic protocol capability (in that it will support applications we haven't even thought of yet).

On the *other* other hand, how much is there a danger of this being a clever feature whose main role is as a source of arguments unless its use is really carefully defined at the outset? (For comparison, I'll just mention 'site local addresses'...)

Cheers,

Robert H.

> From: Georgios Karagiannis (ELN)
> [mailto:[email-masked]]
> Sent: 05 November 2002 11:10
> To: Hancock, Robert
> Cc: [email-masked]
> I confess being somewhat in a dilemma about this one. Please 
> excuse the following somewhat discursive email.
> 
> On the one hand, I think there is (fairly) widespread 
> consensus that an independent reservation identifier is 
> needed to support certain seamless mobility functions. For 
> example, Mike Thomas' draft includes in 1.2.5:
> 
> But in any case, if the role of this identifier is supporting 
> mobility scenarios, then we already have a requirement for 
> that (5.8.1, "Allow efficient XXX re-establishment after 
> handover"). If a separate identifier is the only way to meet 
> that, we'll get it anyway. Incidentally, if we delete 
> 'efficient' in 5.8.1 the requirement becomes unambiguous and 
> entirely vacuous, since you can always resignal from scratch.
> 
> On the other hand, we have (I think) a general goal to 
> develop something that can be used for applications and in 
> scenarios we haven't thought of yet, which leads to certain 
> goals about modularity, clean interfaces with other 
> protocols/functions, and so on. Being able to refer to a 
> reservation independently of the flow identification could 
> come into that category of Good Things (like, for example, 
> structuring things as two layers/levels...). But does that 
> mean we need it in the requirements document? It depends what 
> you want to use the requirements document for (which actually 
> isn't clear to me at the moment).
> 
> independent

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 5 Nov 2002 14:23:22 +0100

The thread you refer to is about mobility and addresses. 
What's the relation to a reservation ID?

Regards, Rüdiger

> yes, after a fashion.
> 
> see e.g. 
> http://www1.ietf.org/mail-archive/working-groups/nsis/current/
msg01993.html

robert h.

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 5 Nov 2002 13:46:48 -0000

Hi,

well, the question as i understood it was: isn't using a flow id (=, in framework terminology, some address fields/ports and so on) just as insecure as a reservation identifier?

answer: no, because the behaviour of the network ties the flow id (non-cryptographically) to the relevant parties (flow endpoints) - which is what the referred-to message asserts - whereas the reservation id (to be useful) is independent of any such constraint or guarantee. 

or did i misunderstand the question?

cheers,

robert h.

> Sent: 05 November 2002 13:23
> To: Hancock, Robert
> Cc: [email-masked]

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 5 Nov 2002 13:50:50 -0000

Marcus,

> So reformulating the requirement into "An NSIS protocol MUST 
> support a 
> reservation identifer" would solve the first one. The reservation 
> identifier then can be the same as the flow id or can be 
> something else.

with this interpretation, wouldn't the requirement then be entirely vacuous? i suppose it would rule out reservations which didn't refer to _any_ flows.

i think you would have to include the force of Bob's second sentence ("By its very definition, a reservation identifier is independent of the flow identifier (otherwise, we wouldn't call it a reservation identifier, we would call it a flow identifier, right?)") somewhere. Maybe your terminology section...

cheers,

robert h.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 5 Nov 2002 16:11:01 +0100

Robert

> well, the question as i understood it was: isn't using a flow 
> id (=, in framework terminology, some address fields/ports 
> and so on) just as insecure as a reservation identifier?

You got my question.

> answer: no, because the behaviour of the network ties the 
> flow id (non-cryptographically) to the relevant parties (flow 
> endpoints) - which is what the referred-to message asserts - 
> whereas the reservation id (to be useful) is independent of 
> any such constraint or guarantee. 

The reservation ID is visible on signaling application level. 
I'd expect a signaling node to save state, including the 
relevant flow information. So the flow context is 
re-established by means of the reservation ID. Then the 
signaling node has the same information as with a flow ID, 
doesn't it?

Changing IP addresses obviously require signaling of a 
new flow ID.

I think the signaling load may be reduced by a reservation ID. 
You trade that for an additional soft state entry in the router
(the reservation ID).

I didn't explain the above prior to this message. I don't 
think this is less secure than repeating the flow ID on 
signaling application level.

Regards, Rüdiger

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 5 Nov 2002 16:10:36 -0000

Hi,

OK, we have 2 aspects of the word secure:

1. privacy of signalling information (your emphasis). here, there is basically no difference between the reservation and flow ids.
2. ability to avoid someone stealing the reservation (my emphasis). here, there is a difference, of a 'soft' sort.

Is that the basic point?

Cheers,

Robert H.

> Sent: 05 November 2002 15:11
> To: Hancock, Robert
> Cc: [email-masked]

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 6 Nov 2002 08:45:31 +0100

> 2. ability to avoid someone stealing the reservation (my 
> emphasis). here, there is a difference, of a 'soft' sort.

That's what I'm interested in too.

Regards, Rüdiger

---

From: [email-masked]
Date: Wed, 6 Nov 2002 09:51:24 +0200

Hi all,

So, we have the following needs:

1) Potential confidentiality of data
2) Protection against DoS attacks
3) Ensuring reservation ownership 
   (this is applicable for QoS, NAT / firewall traversal)

I'd suggest that 

1) is a MUST at the application signaling layer
2) is a MUST in a general sense
3) is a MUST in a general sense

John

> From: ext Geib, Ruediger [mailto:[email-masked]]
> Sent: 06 November, 2002 09:46
> To: [email-masked]
> Cc: [email-masked]

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 6 Nov 2002 09:13:42 +0100

Hi John,

"SHOULD" is ok. "To be considered" sounds a bit too weak.

Regards, Rüdiger

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 8:58 AM
> To: Geib, Rüdiger
> Cc: [email-masked]
> Hi Rüdiger,
> I think the concept is a good one, but I somehow feel funny
> that it would be a 'requirement' - perhaps it could listed
> as a SHOULD or 'SHOULD be considered' - would that work?
> 
> John
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 6 Nov 2002 09:22:29 +0100

Hello John,

sorry for giving an ambiguous reply. The first "SHOULD" 
(i.e. not "SHOULD be considered") is what I prefer.

Regards, Rüdiger

> SHOULD or SHOULD be considered were my suggestions.  Either are
> OK with me.
> 
> John
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 7 Nov 2002 22:36:41 -0000

Hi,

A comment on scope/layering of this reservation identifier thing (if it ever exists):
 
>   *> So reformulating the requirement into "An NSIS protocol 
> MUST support a 
>   *> reservation identifer" would solve the first one. 
> 
> OK, although I would say "MUST be able to support".
> 
> BTW, a reservation identifier is presumably a multi-hop 
> thing, so in my
> 2-level model it is a creature of ULSP, i.e., it is carried in an
> SAPU.  That's good, because non-QoS signaling applications probably
> don't have any reservations to identify.

I think we need to work through this.

1. As Marcus has said, we are signalling to set up something, and that something is what we want to identify to be able to manipulate - it doesn't matter if it's QoS (and called a reservation) or something else.

The v6 flow label draft calls this something 'flow state' so this identifier could be a "flow state id". Would that be a better term?

2. My feeling is that this XXX-id would be useful for general signalling applications (i.e. if you use the signalling application in a mobile enviroment, efficiently moving the state is something you want to do anyway). Also, providing the facility might be tricky, and might require subtle interworking with other protocols (e.g. mobility ones). 

In that case, it be better to provide it as a generic service rather than solving the problem for each signalling application.

3. So, wouldn't one want it within the NTLP (lower layer)?
4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has these generic facilities?

Cheers,

Robert H.

---

From: Bob Braden <[email-masked]>
Date: Thu, 7 Nov 2002 22:49:12 GMT

*> 
  *> I think we need to work through this.
  *> 
  *> 1. As Marcus has said, we are signalling to set up something, and that something is what we want to identify to be able to manipulate - it doesn't matter if it's QoS (and called a reservation) or something else.
  *> 
  *> The v6 flow label draft calls this something 'flow state' so this identifier could be a "flow state id". Would that be a better term?
  *> 
  *> 2. My feeling is that this XXX-id would be useful for general signalling applications (i.e. if you use the signalling application in a mobile enviroment, efficiently moving the state is something you want to do anyway). Also, providing the facility might be tricky, and might require subtle interworking with other protocols (e.g. mobility ones). 
  *> 
  *> In that case, it be better to provide it as a generic service rather than solving the problem for each signalling application.
  *> 
  *> 3. So, wouldn't one want it within the NTLP (lower layer)?
  *> 4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has these generic facilities?
  *> 
  *> Cheers,
  *> 
  *> Robert H.

Robert,

The architectural principle in CSTP is that it operates hop/hop.
This turns out to capture a lot of generic functionality, which is
its benefit.  That does not mean that all generic functionality belongs
in CSTP, particularly generic E2E functionality.

So I can see several alternatives:

(1) Overload CSTP (I mean overload in the technical sense, not the
	pejorative sense) by putting any important generic
	functionality in CSTP.  This effectively gives the CSTP level a
	second major architectural task, in addition to handling
	hop/hop transport.  The effect on the spec would be to add
	calls to the API for the library of generic functionsI.

	Note that my latest draft suggests doing exactly this for the
	interface to routing, which is probably of importance to both
	levels.  However, I think that is a somewhat different case,
	since routing is really a hop/hop issue although it has to
	be available to the ULSP.

(2) Create some additional structure in the upper level, for example a
	library of common generic functions.

I suggest that (2) is architecturally preferable, for the following
reason.  We may expect that over time additional generic functions will
be defined and some will be modified, as the IETF develops different
ULSPs.  But you really don't want to decouple these changes from the
API to the CSTP, which you want to be as stable as possible.

Hope this helps,

Bob Braden

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Nov 2002 11:18:01 +0100

Bob,

I support your view on the issue. 

Regards, Rüdiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 8 Nov 2002 11:45:43 +0100

Hello Hannes,

comments are in line. Re-ordered things a little, 
important stuff first.

Regards, Rüdiger

> > Rüdiger:
> > I think the care-of address will do. As I've explained
> > in another message, I'd expect signaling with complete
> > flow ID should the latter change. That will solve the
> > mobility problem.

> [hannes] i am not sure to which mail you are referring. in 
> any case i have the strong feeling that you need to have
> some sort of session  / reservation
> identifier which is not subject to change. if you also want 
> to change this identifier then you need to update it 
> along the entire path. maybe i do not catch your point.

Rüdiger: 
Good point. Non ambiguos and not subject to change. It 
should be based on the home address then.

> > Rüdiger:
> > The above is valid for sender based reservations. Things
> > may look different for receiver based schemes like RSVP
> > in combination with mobility.

> [hannes] are you sure? both sender and receive can move. i 
> guess that there is still a need for analysis work.

Rüdiger:
I'll have to read Michael Thomas draft to get some better 
understanding. 

> > Rüdiger:
> > In general, I'd regard the so called "flow identifier" as the
> > largest possible reservation ID, no matter how it looks like.

> [hannes] my point of view is that the reservation (or 
> session) identifier should be something different 
> than the flow identifier. if this is not the
> case then no such separation is required.

Rüdiger: 
Yes. I wanted to point out that flow ID and 
reservation ID to some extent serve the same purpose. 
I however regard the reservation ID as a smarter 
solution - if it is well defined.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 10 Nov 2002 21:52:52 -0000

Bob,

> ULSPs.  But you really don't want to decouple these changes from the
[reh] did you want that  ^^^^^?
> API to the CSTP, which you want to be as stable as possible.
[reh] I see the reasoning here; the final answer to the question seems quite unclear to me at the moment.

(Part of the issue is the name: 'reservation id' should refer to something which an application wants shifted around, whereas we could also talk about maintaining a 'logical path' with this identifier, which took all upper layer state around with it. One question is whether the functionality of this identifier only needs support at specific application aware nodes, or whether e.g. in a mobile network it should be specially supported in an application-neutral way.)

I also noted your draft raises the question of whether we should develop a (using non-judgmental terminology) NTLP API, and I can see the value of that too. When do you think it would be the right time to start doing this?

Cheers,

Robert

PS. FWIW the framework slot in Atlanta will probably concentrate on this 'inter-layer' issue. Please send opinions (that's a general invitation, by the way.)
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Bob Braden <[email-masked]>
Date: Sun, 10 Nov 2002 14:06:41 -0800 (PST)

*> > (2) Create some additional structure in the upper level, for example a
  *> > 	library of common generic functions.
  *> > 
  *> > I suggest that (2) is architecturally preferable, for the following
  *> > reason.  We may expect that over time additional generic 
  *> > functions will
  *> > be defined and some will be modified, as the IETF develops different
  *> > ULSPs.  But you really don't want to decouple these changes from the
  *> [reh] did you want that  ^^^^^?

Robert,

Ooops!  No, I didn't!!!  Thanks for catching that.

  *> > API to the CSTP, which you want to be as stable as possible.
  *> > 
  *> > Hope this helps,
  *> > 
  *> > Bob Braden
  *> > 
  *> [reh] I see the reasoning here; the final answer to the question seems quite unclear to me at the moment.
  *> 
  *> (Part of the issue is the name: 'reservation id' should refer to something which an application wants shifted around, whereas we could also talk about maintaining a 'logical path' with this identifier, which took all upper layer state 

Logical path?  I don't get how that relates to the real path that is determined
by IP routing.  Also, the reservation ID corresponds roughly to what RSVP
called a session, and it includes port information as well as path information.
I think we are talking about different abstractions.

around with it. One question is whether the functionality of this identifier o
nly needs support at specific application aware nodes, or whether e.g. in a mobile network it should be specially supported in an application-neutral way.)
  *> 
  *> I also noted your draft raises the question of whether we should develop a (using non-judgmental terminology) NTLP API, and I can see the value of that too. When do you think it would be the right time to start doing this?

As I indicated, I think this is a decision for the WG.  However, I can see
some advantage to first developing the 2-layer model using a generic
API; in this process the generic API will no doubt evolve.  Then when it
seems that the generic API has become stable, define a real API.
(However, the decision might be driven by market forces.)
 
Bob

  *> 
  *> Cheers,
  *> 
  *> Robert
  *> 
  *> PS. FWIW the framework slot in Atlanta will probably concentrate on this 'inter-layer' issue. Please send opinions (that's a general invitation, by the way.)
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: [email-masked]
Date: Tue, 12 Nov 2002 14:54:43 +0100

Hi Ilya, Bob, Robert, all,

There seem to be three options each with their pro's and con's:
- specific to each new NSLP: allows separate choice for each NSLP
- generic and a mandatory component of each NSLP: allows consistent choice
for all NSLP, useful for many applications
- generic in the NTLP
If I understand correctly, we are talking about an identifier that is
independent of IP addresses (they could be the flow id for QoS and should
go in the NTLP anyway) and cannot be guaranteed to be needed in all
applications. Given this, I think it would make sense to make it a
mandatory component of each NSLP specification (I am assuming that the
actual user of this id will be NSLP and therefore it would make more sense
to put it there). Maybe we could foresee a flag in the NTLP to indicate
that such an object is present?

Sven.

"Freytsis, Ilya" <[email-masked]>@ietf.org on 08/11/2002 15:42:46

Sent by:  [email-masked]

To:   "'Hancock, Robert'" <[email-masked]>, Bob Braden
      <[email-masked]>, [email-masked], [email-masked]
cc:
Subject:  RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i
       dentifier

My comments in-line

Regards,
Ilya

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: Thursday, November 07, 2002 5:37 PM
To: Bob Braden; [email-masked]; [email-masked]
Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i
dentifier

Hi,

A comment on scope/layering of this reservation identifier thing (if it
ever

1. As Marcus has said, we are signalling to set up something, and that
something is what we want to identify to be able to manipulate - it doesn't
matter if it's QoS (and called a reservation) or something else.
[IF] That is right to the point. I just want to add that that something is
separate from the flow but used by the flow. The main value of the
reservation ID in my mind is to enable referencing that something
independently from any other characteristics of the flow.

The v6 flow label draft calls this something 'flow state' so this
identifier
could be a "flow state id". Would that be a better term?
[IF] I don't think. See the argument above.
2. My feeling is that this XXX-id would be useful for general signalling
applications (i.e. if you use the signalling application in a mobile
enviroment, efficiently moving the state is something you want to do
anyway). Also, providing the facility might be tricky, and might require
subtle interworking with other protocols (e.g. mobility ones).

In that case, it be better to provide it as a generic service rather than
solving the problem for each signalling application.
[IF] Agreed.
3. So, wouldn't one want it within the NTLP (lower layer)?
[IF] Absolutely.
4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has
these generic facilities?
[IF] I think it is good way to move forward.
Cheers,

Robert H.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 12 Nov 2002 16:04:59 +0100

Hi Sven,

> independent of IP addresses 

As I've mentioned earlier, the reservation ID must be non-ambiguous within the Internet. Having a reservation ID based on a single IP address (e.g. sender IP address) and a reservation number would be a reasonable choice.

Should the design of the reservation ID be independant of IP addresses, a new regulated ID space may result to ensure non ambiguity within the Internet. I'd prefer protocols without reservation ID in this case.

Regards, Rüdiger

---

From: [email-masked]
Date: Tue, 12 Nov 2002 16:43:00 +0100

Hi Ruediger,

I have seen your point. First, I think we can assume that the
source/destination IP address will be present in NTLP or NSLP and that we
can combine that one plus the reservation number to the reservation ID.
Assuming that source/destination address are present in NTLP anyhow, this
would reduce the problem to a non-IP address dependent reservation number.
The other issue I have (I may have missed other people's comments) is that
with your proposal you cannot guarantee uniqueness in the presence of NAT.
Then, in principle, it would be possible to have the same ID twice (same IP
address(es) and same reservation number). The possibility would be reduced
if an end-point assembles an ID based on a local IP address and a
reservation ID and NTLP contains IP adresses (those would be translated
with NAT, the original one would remain) but even then I guess you cannot
completely guarantee uniqueness.
What do you think?
Sven.

"Geib, Ruediger" <[email-masked]> on 12/11/2002 16:04:59

To:   Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:   [email-masked]
Subject:  RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i
       dentifier

Hi Sven,

> independent of IP addresses

As I've mentioned earlier, the reservation ID must be non-ambiguous within
the Internet. Having a reservation ID based on a single IP address (e.g.
sender IP address) and a reservation number would be a reasonable choice.

Should the design of the reservation ID be independant of IP addresses, a
new regulated ID space may result to ensure non ambiguity within the
Internet. I'd prefer protocols without reservation ID in this case.

Regards, Rüdiger

---

From: Bob Braden <[email-masked]>
Date: Fri, 15 Nov 2002 19:36:26 GMT

*> If I understand correctly, we are talking about an identifier that is
  *> independent of IP addresses (they could be the flow id for QoS and should
  *> go in the NTLP anyway) and cannot be guaranteed to be needed in all

Sven,

?? I don't understand your argument for putting a "flow id for QoS" in the
NTLP/CSTP.  [I am not claiming there is no argument, mind you; depending
upon what you mean by "flow id", I might/might not agree.]

  *> applications. Given this, I think it would make sense to make it a
  *> mandatory component of each NSLP specification (I am assuming that the

I would argue against *any* mandatory component of NSLP specifications.
I think it is vital for future unforeseen applications of our framework
that the NSLP level be unrestricted.  It's fine to say, "If an NSLP/ULSP
needs this functionality, do it this way: ...", but not to mandate its
usage by all NSLPs/ULSPs.

  *> actual user of this id will be NSLP and therefore it would make more sense
  *> to put it there). Maybe we could foresee a flag in the NTLP to indicate
  *> that such an object is present?

If it is used in by an NSLP/ULSP, the object can be embedded in the
SAPU.  The "flag" could be embodied in the encoding used  for the
SAPU, e.g., it might be the presence of a strongly-typed object
as in RSVP v1.)

Bob Braden

  *> 
  *> Sven.
  *> 
  *> 
  *> 
  *> 
  *> 
  *> "Freytsis, Ilya" <[email-masked]>@ietf.org on 08/11/2002 15:42:46
  *> 
  *> Sent by:  [email-masked]
  *> 
  *> 
  *> To:   "'Hancock, Robert'" <[email-masked]>, Bob Braden
  *>       <[email-masked]>, [email-masked], [email-masked]
  *> cc:
  *> Subject:  RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i
  *>        dentifier
  *> 
  *> 
  *> My comments in-line
  *> 
  *> Regards,
  *> Ilya
  *> 
  *> -----Original Message-----
  *> From: Hancock, Robert [mailto:[email-masked]]
  *> Sent: Thursday, November 07, 2002 5:37 PM
  *> To: Bob Braden; [email-masked]; [email-masked]
  *> Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i
  *> dentifier
  *> 
  *> Hi,
  *> 
  *> A comment on scope/layering of this reservation identifier thing (if it
  *> ever
  *> exists):
  *> 
  *> >   *> So reformulating the requirement into "An NSIS protocol
  *> > MUST support a
  *> >   *> reservation identifer" would solve the first one.
  *> >
  *> > OK, although I would say "MUST be able to support".
  *> >
  *> > BTW, a reservation identifier is presumably a multi-hop
  *> > thing, so in my
  *> > 2-level model it is a creature of ULSP, i.e., it is carried in an
  *> > SAPU.  That's good, because non-QoS signaling applications probably
  *> > don't have any reservations to identify.
  *> 
  *> I think we need to work through this.
  *> 
  *> 1. As Marcus has said, we are signalling to set up something, and that
  *> something is what we want to identify to be able to manipulate - it doesn't
  *> matter if it's QoS (and called a reservation) or something else.
  *> [IF] That is right to the point. I just want to add that that something is
  *> separate from the flow but used by the flow. The main value of the
  *> reservation ID in my mind is to enable referencing that something
  *> independently from any other characteristics of the flow.
  *> 
  *> The v6 flow label draft calls this something 'flow state' so this
  *> identifier
  *> could be a "flow state id". Would that be a better term?
  *> [IF] I don't think. See the argument above.
  *> 2. My feeling is that this XXX-id would be useful for general signalling
  *> applications (i.e. if you use the signalling application in a mobile
  *> enviroment, efficiently moving the state is something you want to do
  *> anyway). Also, providing the facility might be tricky, and might require
  *> subtle interworking with other protocols (e.g. mobility ones).
  *> 
  *> In that case, it be better to provide it as a generic service rather than
  *> solving the problem for each signalling application.
  *> [IF] Agreed.
  *> 3. So, wouldn't one want it within the NTLP (lower layer)?
  *> [IF] Absolutely.
  *> 4. Or, should we be thinking of some kind of 'core' NSLP toolkit which has
  *> these generic facilities?
  *> [IF] I think it is good way to move forward.
  *> Cheers,
  *> 
  *> Robert H.
  *> _______________________________________________
  *> nsis mailing list
  *> [email-masked]
  *> https://www1.ietf.org/mailman/listinfo/nsis
  *> _______________________________________________
  *> 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: [email-masked]
Date: Sat, 16 Nov 2002 10:51:05 +0100

Bob,

Please see inline

Thanks,
Sven.

Bob Braden <[email-masked]>@ietf.org on 15/11/2002 20:36:26

To:   Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:   [email-masked], [email-masked], [email-masked]
Subject:  RE: [NSIS] Req-Draft: Open Issue 2: Independence of reservation i
       dentifier

  *> If I understand correctly, we are talking about an identifier that is
  *> independent of IP addresses (they could be the flow id for QoS and
should
  *> go in the NTLP anyway) and cannot be guaranteed to be needed in all

Sven,

[Sven] The point that was raised in the framework, I believe, was that it
would be useful to carry source and or destination address in NTLP (if they
are carried) for address translation purposes. If these are part of the
flow identifier they could be carried in NTLP. We were discussing about a
reservation identifier for NSLP, therefor my claim was that we could limit
that discussion to an IP address independent identifier since the address
dependent part would go in NTLP. I am not sure this is correct/useful but
that was the idea.

[Sven] I read in some other message of this or another thread: mandatory to
specify, not mandatory to use. I think this applies to this thing as well.
It then covers exactly what you say: "if you need it, do it this way". That
would make it optional to use, but if used with a unique specification.

  *> actual user of this id will be NSLP and therefore it would make more
sense
  *> to put it there). Maybe we could foresee a flag in the NTLP to
indicate
  *> that such an object is present?

[Sven] OK.

Sven.

Bob Braden

  *>
  *> Sven.
  *>
  *>
  *>
  *>
  *>
  *> "Freytsis, Ilya" <[email-masked]>@ietf.org on 08/11/2002
15:42:46
  *>
  *> Sent by:  [email-masked]
  *>
  *>
  *> To:   "'Hancock, Robert'" <[email-masked]>, Bob Braden
  *>       <[email-masked]>, [email-masked], [email-masked]
  *> cc:
  *> Subject:  RE: [NSIS] Req-Draft: Open Issue 2: Independence of
reservation i
  *>        dentifier
  *>
  *>
  *> My comments in-line
  *>
  *> Regards,
  *> Ilya
  *>
  *> -----Original Message-----
  *> From: Hancock, Robert [mailto:[email-masked]]
  *> Sent: Thursday, November 07, 2002 5:37 PM
  *> To: Bob Braden; [email-masked]; [email-masked]
  *> Subject: RE: [NSIS] Req-Draft: Open Issue 2: Independence of
reservation i
  *> dentifier
  *>
  *> Hi,
  *>
  *> A comment on scope/layering of this reservation identifier thing (if
it
  *> ever
  *> exists):
  *>
  *> >   *> So reformulating the requirement into "An NSIS protocol
  *> > MUST support a
  *> >   *> reservation identifer" would solve the first one.
  *> >
  *> > OK, although I would say "MUST be able to support".
  *> >
  *> > BTW, a reservation identifier is presumably a multi-hop
  *> > thing, so in my
  *> > 2-level model it is a creature of ULSP, i.e., it is carried in an
  *> > SAPU.  That's good, because non-QoS signaling applications probably
  *> > don't have any reservations to identify.
  *>
  *> I think we need to work through this.
  *>
  *> 1. As Marcus has said, we are signalling to set up something, and that
  *> something is what we want to identify to be able to manipulate - it
doesn't
  *> matter if it's QoS (and called a reservation) or something else.
  *> [IF] That is right to the point. I just want to add that that
something is
  *> separate from the flow but used by the flow. The main value of the
  *> reservation ID in my mind is to enable referencing that something
  *> independently from any other characteristics of the flow.
  *>
  *> The v6 flow label draft calls this something 'flow state' so this
  *> identifier
  *> could be a "flow state id". Would that be a better term?
  *> [IF] I don't think. See the argument above.
  *> 2. My feeling is that this XXX-id would be useful for general
signalling
  *> applications (i.e. if you use the signalling application in a mobile
  *> enviroment, efficiently moving the state is something you want to do
  *> anyway). Also, providing the facility might be tricky, and might
require
  *> subtle interworking with other protocols (e.g. mobility ones).
  *>
  *> In that case, it be better to provide it as a generic service rather
than
  *> solving the problem for each signalling application.
  *> [IF] Agreed.
  *> 3. So, wouldn't one want it within the NTLP (lower layer)?
  *> [IF] Absolutely.
  *> 4. Or, should we be thinking of some kind of 'core' NSLP toolkit which
has
  *> these generic facilities?
  *> [IF] I think it is good way to move forward.
  *> Cheers,
  *>
  *> Robert H.
  *> _______________________________________________
  *> nsis mailing list
  *> [email-masked]
  *> https://www1.ietf.org/mailman/listinfo/nsis
  *> _______________________________________________
  *> nsis mailing list
  *> [email-masked]
  *> https://www1.ietf.org/mailman/listinfo/nsis
  *>
  *>
  *>
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis