Subject: FW: I-D ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.txt

From: Dimitry Haskin <[email-masked]>
Date: Mon, 10 Apr 2000 15:05:04 -0400

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. 
 
---------------------------------------------------------------------- 
Dimitry Haskin 
Lucent Technologies Internetworking Systems

---

From: David Charlap <[email-masked]>
Date: Tue, 11 Apr 2000 11:33:35 -0400

Dimitry Haskin wrote:
> 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.

-- David

---

From: Daniel Awduche <[email-masked]>
Date: Tue, 18 Apr 2000 16:08:41 -0400

Dimitry,

Thank you for the comments. Apologies for the late
response...

Yes, it's perhaps best to replace the term "session" 
with "flow"  in the text under reference, to eliminate
the terminological nit which you identified. Please let 
me know if this addresses your concerns.

From a functional viewpoint, this is of course inconsequential.

Regards,
/Dan