Subject: RE: FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt

From: Dimitry Haskin <[email-masked]>
Date: Tue, 11 Apr 2000 13:55:24 -0400

> 
> Dimitry Haskin wrote:
> > 
> > The last paragraph on Page 3:
> > 
> > ...  To be definite, in the original RSVP protocol [3], a session
> > was defined as a data flow with a particular destination and
> > transport layer protocol.  In the RSVP-TE specification, however, a
> > session is implicitly defined as the set of packets that 
> are assigned
> > the same MPLS label value at the originating node of an LSP-tunnel.
> > 
> > 
> > I believe there is an issue with the RSVP-TE session 
> definition in the
> > above statement.  To my reading, nowhere the RSVP-TE draft  implies
> > that a set of packets have to be assigned the same MPLS label at the
> > originating node in order to constitute a session. (If my reading is
> > incorrect, then I've an issue with the RSVP-TE spec.) Moreover,
> > Section 2.5 (Rerouting LSP Tunnels) of the RSVP-TE 
> specification seems
> > to clearly imply that multiple LSPs can belong to a single session.
> > Another example where multiple LSPs belonging to the same 
> RSVP session
> > can originate at the same note is a load sharing multipath tunnel
> > between ingress and egress LSRs.  In summary, this at the 
> first glance
> > an insignificant matter has significant implementation implications.
> 
> I think you may have found a bug in this draft.
> 
> Under RSVP, whether MPLS or not, a session is defined as the set of
> paths that share a common destination.  The difference is that with
> MPLS, a destination is defined as the tunnel endpoint 
> address, tunnel ID
> and extended tunnel ID.  (Instead of the destination address, protocol
> and port of non-MPLS RSVP.)
> 
> This is explicitly spelled out in the new definition of the SESSION
> object.  See draft-ietf-mpls-rsvp-lsp-tunnel-05.txt, section 
> 4.6.1.  It
> is further spelled out in the reroute rules (section 2.5) - 
> which could
> not work if the two tunnels were in different sessions.  The reroute
> algorithm depends on the fact that two tunnels (the original 
> and the new
> one) will have different labels - otherwise the two tunnels could not
> coexist during between the time of the second tunnel's 
> creation and the
> first's destruction.
> 
> It should further be noted that labels are not assigned until after
> reservations are made.  They are propagated in the Resv message. 
> Therefore, any definition of session that depends on labels is
> meaningless, since sessions are created during Path message 
> processing.
> 
> BTW, this bug is also reflected in the
> draft-ietf-mpls-rsvp-lsp-tunnel-05.txt document.  In section 2.1, it
> defines "session" and "flow" to be synonymous.  This must be 
> incorrect, because during the reroute processing, two flows share a common
> session.  More accurately, a session is defined as one or more flows to
> a common destination (as described by the SESSION object), however,
> normal MPLS operation will only have one flow per session, 
> except during tunnel rerouting.

As I've mentioned, another important example of such an arrangement is a
session that utilizes multiple MPLS paths for load sharing purposes. Such
paths can merge at some downstream LSR. LSP merging decision is more
straightforward and is in line with the classical RSVP if LSPs that can be
merged are identified with the same session object.

While on the merging topic, I believe the following statement on Page 43 in
RSVP-TE spec is to be revisited:

          0x02  Merging permitted

                This flag permits transit routers to merge this session
                with other RSVP sessions for the purpose of reducing
                resource overhead on downstream transit routers, thereby
                providing better network scalability.

I would think that the intention was to permit merging of LSPs that belong
to the same session as opposed to merging LSPs from different sessions.
I've difficulties to see how merging of sessions is achieved within the RSVP
framework. 

> -- David

---

From: "Abes, Andi" <[email-masked]>
Date: Thu, 13 Apr 2000 16:04:39 -0400

David,

Now I understand your objections - 
the wording in the sections you qouted is not 
clear enough about what is a session, a flow and how
they relate to labels.
Ok - to that I agree.

But to say it's a bug in the draft - that's taking 
it a little too far.

A little analysis of the objects involved and the 
processing rules for RSVP along with the text will
bring you to the right conclusions.

I completly agree that making the draft more explicit
as to what is permissible and possible with the 
defined objects would be very useful.

And, if the draft is taking the "reader-freindly" path -
there are quite a few more issues that need clarification
and updating:

1. Diff serv over MPLS.
2. Label stacks and implications on distributing them with RSVP 
   (the LDP world has pretty well define rules for 
    Trageted sessions and it's implications)
3. Some usage scenarios and examples would be great.

Andi.

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Thursday, April 13, 2000 3:10 PM
> To: [email-masked]
> Subject: Re: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.txt
> 
> 
> "Abes, Andi" wrote:
> > 
> > David,
> > 
> > The following are quoted from rsvp-tunnel-05, sections 3.1 and 3.2
> > It's the description of the Path and RESV messages -
> > the parts that apply to sender specification.
> > Both messages contain a session object as well (qouted from 4.6.1)
> 	...
> 
> I never said that they didn't contain SESSION objects.  Of course they
> must - otherwise you don't know what tunnels the messages apply to.
> 
> > So what does this mean:
> > 
> > In a path message, an LSP is identified by:
> >   a. the session it belongs to -
> >         IPv4 egress address + tunnel ID + extendend TunnelID.
> >   b. A sender template -
> >         the ingress address + LSP ID (unique for the sender).
> 
> Yes.  SESSION and SENDER_TEMPLATE.  As with straight RSVP.
> 
> > In a reserve message an LSP is identified by:
> >   a. The session - same as path.
> >   b. the filter spec, which is exactly the same as the 
> sender_template
> 
> Again, exactly as in straight RSVP.
> 
> > So back to the original questions and issues:
> > 
> > 1. For LSP's to be belong to the same session they need
> >    to share the same egress point and tunnel ID.
> >    If the exteneded tunnel ID is set to the Ingress IP address, only
> >    LSP's originating at the same ingress could ever belong to the
> >    same session.
> 
> Yes.
> 
> > 2. For multiple LSP's to share resources, they need to:
> >    a. belong to the same session (see above)
> >    b. The egress router needs to assign SE style to the session.
> 
> Yes.
> 
> > Do you agree with the statements above ?
> 
> Yes.
> 
> > In light of these statements, do you still believe there
> > is a bug in the rsvp-tunnel draft ?
> 
> Yes.  What you've described is correct.  But section 2.1 of
> draft-ietf-mpls-rsvp-lsp-tunnel-05.txt describes something else:
> 
>    According to [1], "RSVP defines a 'session' to be a data 
> flow with a
>    particular destination and transport-layer protocol." However, when
>    RSVP and MPLS are combined, a flow or session can be defined with
>    greater flexibility and generality.  The ingress node of an LSP can
>    use a variety of means to determine which packets are assigned a
>    particular label.  Once a label is assigned to a set of 
> packets, the
>    label effectively defines the "flow" through the LSP.  We refer to
>    such an LSP as an "LSP tunnel" because the traffic through it is
>    opaque to intermediate nodes along the label switched path.
> 
> Here, the draft implies that there is no difference between and LSP, a
> flow and a session.  This is completely untrue.
> 
> Multiple data flows can go through a single LSP - the ingress router
> will determine which flows go into which LSPs, based on whatever
> administrative policies are in place (including, but not limited to
> destination address, diffserv bits, or layer-4 information)
> 
> Additionally, multiple LSPs can be defined for a single 
> session.  These
> LSPs may share resources (when used in make-before-break rerouting or
> creating redundant failoer paths) or they might maintain distinct
> reservations (possibly for defining multiple parallel LSPs for
> prioritizing traffic.)
> 
>    New RSVP SESSION objects, called LSP_TUNNEL_IPv4 and 
> LSP_TUNNEL_IPv6
>    have been defined to support the LSP tunnel feature.  The semantics
>    of these objects, from the perspective of a node along the label
>    switched path, is that traffic belonging to the LSP tunnel is
>    identified solely on the basis of packets arriving from the PHOP or
>    "previous hop" (see [1]) with the particular label 
> value(s) assigned
>    by this node to upstream senders to the session.  In fact, the
>    IPv4(v6) that appears in the object name only denotes that the
>    destination address is an IPv4(v6) address.  When we refer to these
>    objects generically, we use the term LSP_TUNNEL Session.
> 
> Again, this is inaccurate.  A tunnel is not defined by 
> packets sharing a
> common label.  An LSP is a set of packets sharing a common label.  A
> tunnel (or session) is a collection of one or more LSPs to a common
> destination (sharing a common tunnel ID.)
> 
> It is perfectly possible for multiple LSPs (meaning packets with
> different labels) to all belong to a single tunnel.
> 
> On the data plane, the distinction doesn't matter.  The switch just
> looks at the label, updates the label (push, pop, swap, etc) and
> forwards the packet.
> 
> But on the control plane - at least with RSVP - the distinction is
> important.  Tunnels (or sessions) can not share resources with each
> other.  LSPs within a single tunnel, however, may or may not share
> resources, depending on the reservation style sent out by the tunnel
> endpoint (egress) router.
> 
> It is important to note that a label can not be used to 
> identify an LSP
> during LSP setup.  Labels are only assigned during Resv message
> processing - which happens towards the end of the setup.  In other
> words, labels are purely data-plane entities and don't 
> identify anything
> until after RSVP (or LDP, I assume) sets up the LSP.
> 
> -- David
>

---

From: Dimitry Haskin <[email-masked]>
Date: Thu, 13 Apr 2000 16:12:21 -0400

A small but not insignificant correction.

> >    LSP's originating at the same ingress could ever belong to the

There is nothing to prevent nor it is an error for LSPs originating at
different ingress nodes to share the same extended tunnel ID even if this ID
happen to be set to an address of one of the ingress nodes.

Dimitry

---

From: "Abes, Andi" <[email-masked]>
Date: Thu, 13 Apr 2000 16:15:53 -0400

Dimitry,

Yes, you're right - 
it will probably work - but it will defeat the purpose 
of the extended ID.

Andi.

> From: Dimitry Haskin [mailto:[email-masked]]
> Sent: Thursday, April 13, 2000 4:12 PM
> To: David Charlap; [email-masked]
> Cc: Abes, Andi
> Subject: RE: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.t xt
> 
>

---

From: Dimitry Haskin <[email-masked]>
Date: Thu, 13 Apr 2000 16:27:12 -0400

> it will probably work - but it will defeat the purpose 
No, it will not if used judiciously by cooperating nodes.

---

From: "Abes, Andi" <[email-masked]>
Date: Thu, 13 Apr 2000 16:41:19 -0400

What is the advantage of doing this,
as opposed to simply using different Tunnel ID's
and setting the extended tunnel ID to 0 
(as the spec suggests) ?

Andi.

> Sent: Thursday, April 13, 2000 4:27 PM
> To: Abes, Andi; Dimitry Haskin; David Charlap; [email-masked]
> Subject: RE: FW: I-D

---

From: Dimitry Haskin <[email-masked]>
Date: Thu, 13 Apr 2000 17:00:07 -0400

> and setting the extended tunnel ID to 0 

I assume you meant to write 'the same Tunnel ID'. The advantage is that you
can confine the session scope to a set of cooperating nodes without risking
that a node outside of the set can assign the same session object to its
RSVP session. 

Dimitry

---

From: "Abes, Andi" <[email-masked]>
Date: Thu, 13 Apr 2000 17:08:44 -0400

Dimmitry,

No, I did mean different Tunnel ID's.

Lets say that there are LSR's Ra Rb Rc and Rd.

The goal we are trying to achieve, if I understand 
you correctly, is to have some LSP's from Ra and Rb
going to Rd share resources among themselves, 
but not with LSP's from Rc going to the same place.

The way I would configure this is:
- Ra and Rb use a session defined by Egress = Rd 
  tunnel = T1
- Rc use a session defined by Egress = Rd and 
  tunnel = T2.

In all sessions, the extended ID is set to 0,
such that if you choose to share its resources
you only need to configure the new ingress to use
the same tunnel ID.

According to your suggestion - how would you configure
these routers ?

Andi.

In any case, it might be good to take this offline
so we don't generate too much traffic on the list.

Andi.

> Sent: Thursday, April 13, 2000 5:00 PM
> To: Abes, Andi; [email-masked]
> Subject: RE: FW: I-D

---

From: Eric Gray <[email-masked]>
Date: Thu, 13 Apr 2000 21:10:59 -0700

David,

	Hello.  Please see below.

You wrote:
> 
> Eric Gray wrote:
> >
> >         One is that the session object is defined such that the last
> > four bytes of the extended tunnel ID is defined to be an IP address of
> > the tunnel ingress.
> 
> Not quite "defined".  It's a recommended behavior:
> 
>       Extended Tunnel ID
> 
>          A 32-bit identifier used in the SESSION that remains constant
>          over the life of the tunnel.  Normally set to all zeros.
>          Ingress nodes that wish to narrow the scope of a SESSION to the
>          ingress-egress pair may place their IPv4 address here as a
>          globally unique identifier.
> 
> Note that it says "may" and not "must".
> 
> In other words, as long as two senders don't pick the same triple of
> tunnel endpoint address, tunnel ID and extended tunnel ID, any value is
> perfectly good.

This is an interesting interpretation.  Possibly it 
is a common one.  When I read it, however, I see it
stating that there is a "normal" value and another
(set) of alternative values that "may" be used.  It
would be strange to have a "normal" value and other
disimilar - values that "must" be used.

Perhaps I misunderstand.

However, this should be more than a casual suggestion.
Otherwise, a lazy (or, perhaps, insane) implementer
might ignore the recommendation and use a counter
to generate the extended portion of the ID.  A loose
interpretation of the text you quote might lead one
to think that it is only recommended that the ID may
be globally unique.

> 
> The decision to use source IP addresses is simply a good idea, because
> you know that it will be unique.  But there are other ways of
> guaranteeing uniqueness as well - including operator assignment and (for
> the insane) a network-wide ID server.

It's also more than a good idea, because of the KISS
principle.  Operator assignment is pretty far from a
guarantee of uniqueness.

I guess - if we cannot come up with an alternative -
it might be okay to put this gun in the customer's
hand.  But it's not much better than okay.

> 
> > This is done explicitly to provide a globally unique tunnel identifier
> > which MUST then be under the control of the owner of that IP address.
> 
> I don't get that from the reading.  From what I can tell, any value that
> can be used as a globally unique tunnel identifier may be used.
> Administrators may choose to use values other than ingress IP addresses
> if they so desire.

Huh?  The text very exactly states that the IPv4 
address will provide a globally unique identifier.

> 
> >         The second is that it should be an error.  Since the extended
> > tunnel ID is defined the way that it is, allowing any LSR to use the
> > address of another LSR - even one that is not necessarily particularly
> > local - is allowing forgery.
> 
> Ummmm....  I don't think the extended tunnel ID is intended to be used
> as a security measure.  Its intent seems to be merely to prevent a
> popular egress node from using up all of its 64K tunnel IDs.

I am not much of a security expert, but I seem to
recall that security is obtained more as a result
of avoiding the creation of opportunities than as 
a result of addition of security measures.

In this particular case, it might be necessary in
some networks to prevent someone's being able to
forge a tunnel ID - precisely because it gives
them the opportunity to usurp a share of network
resources they are not entitled to.

> 
> > The fact that enforcement of the definition of the extended tunnel ID
> > MIGHT be hard to do should not be taken to mean that nobody will do
> > it - or that anybody doing so is wrong.
> 
> You assume that the definition is a requirement instead of a
> recommendation.  I don't get that impression from my reading of the
> draft.

Put it this way.  Even if it is only a good idea,
then we need a really good reason to ignore it.
Bearing in mind that options are not necessarily
a good thing (putting it mildly), why look for
ways to interpret new options into a specification?

--
Eric Gray

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 14 Apr 2000 10:35:23 -0400

Eric,

An LSR using an address of another LSR as the extended tunnel ID is as much
forgery as me driving my wife's car is a crime. If there is consent and a
purpose, it is perfectly legal and even useful.

----------------------------------------------------------------------
Dimitry Haskin
Lucent Technologies Internetworking Systems

> From: Eric Gray [mailto:[email-masked]]
> Sent: Thursday, April 13, 2000 6:30 PM
> To: 'Dimitry Haskin'; David Charlap; [email-masked]
> Cc: Abes, Andi
> Subject: RE: FW: I-D
> 	I think this is wrong for a couple of reasons.
> 
> 	One is that the session object is defined such
> that the last four bytes of the extended tunnel ID is
> defined to be an IP address of the tunnel ingress.  
> This is done explicitly to provide a globally unique
> tunnel identifier which MUST then be under the control
> of the owner of that IP address.
> 
> 	The second is that it should be an error.  Since
> the extended tunnel ID is defined the way that it is,
> allowing any LSR to use the address of another LSR -
> even one that is not necessarily particularly local -
> is allowing forgery.  The fact that enforcement of
> the definition of the extended tunnel ID MIGHT be hard
> to do should not be taken to mean that nobody will do
> Sent: Thursday, April 13, 2000 1:12 PM

---

From: "Abes, Andi" <[email-masked]>
Date: Fri, 14 Apr 2000 11:44:10 -0400

> Sent: Friday, April 14, 2000 10:35 AM
> To: Eric Gray; [email-masked]
> Subject: RE: FW: I-D

---

From: Eric Gray <[email-masked]>
Date: Fri, 14 Apr 2000 09:03:44 -0700

Dimitry,

	Speaking as one who has used an analogy
before, this one is a bit of a stretch.  But
let's take it for a stroll.

	What I am saying is that - should you get
pulled over in your wife's car - you should not
be surprised when you are detained pending a
verification that you have permission from the
owner of the vehicle.  A police officer would
absolutely be within his/her rights to insist
on performing such a check.

	After that, it might not seem so useful.

--
Eric Gray

-----Original Message-----
From: Dimitry Haskin [mailto:[email-masked]]
Sent: Friday, April 14, 2000 7:35 AM
To: Eric Gray; [email-masked]
Subject: RE: FW: I-D

Eric,

---

From: "Abes, Andi" <[email-masked]>
Date: Fri, 14 Apr 2000 12:05:43 -0400

(sorry for the previous mail - too quick on 
the trigger)...

Ok, 
 many "hidden" intentions were assigned to the 
extended tunnel ID.
It might be usefull to make an attempt and clarify 
what is it usefull for.

The following was sent in private email.

Do my assumptions make any sense ?

Andi.

-----Original Message-----
From: Abes, Andi 
Sent: Thursday, April 13, 2000 6:00 PM
To: 'Dimitry Haskin'; Abes, Andi
Subject: RE: FW: I-D

Could be, but I'm not copletly sure about that.
I think there are many issues about corssing administrative
domains.

I might be wrong here, but bare with me.
Basically the Egress makes the decission on what style to 
use for a session, and the ingress has very little say in it.

Yes, there's the "might-reroute" session attribute. There's also
the "merging-permitted" - which I didn't really understand.

Other that those 2 flags, which are very limited info, and 
considered recomendation only, the ingress has very 
little avenues to express its will.

The extened tunnel ID, in my mind, is to allow the 
ingress the capability to disallow any type of sharing.

The rational being:
The "network" will attempt to reduce resource utilization
as much as possible - merge what ever it can - so the 
ingress doesn't realy need to ask for it.
But... The ingress might want to allow an LSP to receive 
prefered treatment, and explicitly dis-allow any type 
of resource sharing. This would be accomplished using
the extended ID.

> Sent: Thursday, April 13, 2000 5:47 PM
> To: Abes, Andi
> Subject: RE: FW: I-D
> Andi,
> If all sessions that terminate at the same egress are 
> configured by the same
> administrative entity there is no need for the extended 
> tunnel ID in the
> Session object. My understanding is that the extended tunnel 
> ID was intended
> to allow initiation of RSVP sessions in different 
> administrations without
> necessity of close cooperation in identifying the sessions.
> 
> > From: Abes, Andi [mailto:[email-masked]]
> > Sent: Thursday, April 13, 2000 5:36 PM
> > To: Dimitry Haskin
> > Subject: RE: FW: I-D
> > Ok,
> > so what's to prevent Rc chosing the same value
> > as Ra for the extended ID ?
> > 
> > My understanding was that the Tunnel ID is not "picked"
> > by either Ra Rb or Rc - it has to be administratively 
> > assigned.
> > The Tunnel ID has very important implications on the way
> > that LSP's are going to be treated (can they be merged / shared 
> > and the likes).
> > In our system - we are going to allow the user control over it.
> > 
> > 
> > Andi.
> > 
> >

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 14 Apr 2000 13:58:50 -0400

Eric,
> on performing such a check.
If such a check is possible I've no problem with that. It could be a plain
nuisance in some neighborly communities but ok.. It still does not mean that
it is necessarily illegal or that it does not serve any purpose driving
someone's car.

Back to reality, draft-swallow-rsvp-bypass-label-00.txt provides an example
of different ingress nodes using the same session objects including the
extended tunnel id for association of backup LSPs with LSPs being backed up.

Dimitry

---

From: "Abes, Andi" <[email-masked]>
Date: Fri, 14 Apr 2000 14:44:52 -0400

Back to reality, draft-swallow-rsvp-bypass-label-00.txt
> provides an example

Dimitry,

I was looking for the refrence you gave, but the only
thing I found was an example discussing using different IP addresses
in the sender_template, not in the session.

(end of section 3.1)

   We therefore propose that backup tunnels be identified as follows.
   The SESSION object and the LSP_ID are copied from the LSP tunnel
   being backed up.  The IPv4 tunnel sender address is set to an address
   of the PLR node.  If the head-end of a tunnel is also acting as the
   PLR, it must choose an IP address different from the one used in the
   SENDER_TEMPLATE of the original LSP tunnel.

Did you mean something else ?

Andi.

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 14 Apr 2000 15:09:18 -0400

> in the sender_template, not in the session.
Isn't it the point?

> Did you mean something else ?
No, this is it.

---

From: "Abes, Andi" <[email-masked]>
Date: Fri, 14 Apr 2000 16:05:02 -0400

Dimitry,

If I understand your point -
An ingress can choose a seemingly randon value to 
put in the SESSION object's extended Tunnel ID.

Then, no - this is not the point.
The bypass draft suggest using exactly the same SESSION
object - including the extended Tunnel ID, but 
using a different IP address in the SENDER_TEMPLATE -
meaning - 
creating a new sender in the same session for the backup
tunnel, but the original and the backup tunnels all
belong to the same SESSION.

If you think about it - at points in the network
where the backup and original happen to co-exist -
no "double-booking" will occcur, since the resources
can be shared among different senders in the same tunnel.

If the SESSION object were modifed in any way, like
changing the extended tunnel ID - this would not work -
and resources would have to be reserved for both the original
and backup tunnel.

Andi.

> Sent: Friday, April 14, 2000 3:09 PM
> To: Abes, Andi; Dimitry Haskin; Eric Gray
> Cc: [email-masked]
> Subject: RE: FW: I-D

---

From: "Abes, Andi" <[email-masked]>
Date: Fri, 14 Apr 2000 17:23:06 -0400

Dimitry,

But in this case the initiator of the backup tunnel
is not an igress LSR for the LSP, if you make that 
argument - than each transit LSR would have to replace
the SESSION object.

Andi.

> Sent: Friday, April 14, 2000 4:33 PM
> To: Abes, Andi
> Subject: RE: FW: I-D
> I believe the contention was if the same address could be used as an
> extended tunnel id by different LSRs. So the point was that it could. 
> 
> > Sent: Friday, April 14, 2000 4:05 PM
> > To: Dimitry Haskin; Abes, Andi; Eric Gray
> > Cc: [email-masked]
> > Subject: RE: FW: I-D

---

From: Dimitry Haskin <[email-masked]>
Date: Tue, 25 Apr 2000 10:21:35 -0400

Dan,

Your corrected version of the text is fine.

Thanks

> From: Daniel Awduche [mailto:[email-masked]]
> Sent: Tuesday, April 25, 2000 2:33 AM
> To: Dimitry Haskin
> Cc: [email-masked]; Daniel Awduche
> Subject: Re: FW: I-D
> Thanks or the note. See additional comments inline...
> 
> On Wed, Apr 19, 2000 at 10:52:03AM -0400, Dimitry Haskin wrote:
> > Dan,
> > 
> > Let me suggest the following text:
> > 
> > "To be definite, in the original RSVP protocol [3], a session 
> > transport layer protocol.  In the RSVP-TE specification, however,
> > session is defined as the set of label switched packets with
> > a particular destination, tunnel id, and extended tunnel id."
> 
> This is a good try, but it conveys an incorrect impression
> that the parameters of the RSVP-TE SESSION object (tunnel end 
> point address, tunnel id, and extended tunnel id) are in fact 
> attributes of the label switched packets. That is, it
> confuses the semantics of the RSVP-TE signaling messages that
> instantiate a session with the attributes of the packets 
> that comprise the session.
> 
> Nonetheless, you did have a valid point in your original
> email, in that you discerned that the wording of the 
> applicability draft did not express the fact that a session 
> may result in more than one LSP. With this mind, 
> here's a corrected version of the second sentence which 
> accommodates your input.
> 
> "In the RSVP-TE specification, however, a session is defined 
> as the set of label switched packets that are instantiated
> by RSVP-TE messages containing particular values of the
> SESSION object parameters (Tunnel-End-Point-Address, 
> Tunnel-Id, and Extended-Tunnel-Id)."
> 
> Let's converge on these rhetorical aspects and move on
> to other issues... 
> 
> George/Lou feel free to step in if a more concise description 
> is needed.
> 
> Cheers,
> /Dan
>