The MPLS WG Archive

[Dimitry Haskin <dhaskin@nexabit.com>]

Dan,

Let me suggest the following text:

"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,
session is defined as the set of label switched packets with
a particular destination, tunnel id, and extended tunnel id."

>From functional viewpoint the original text unnecessary narrows the scope of
the session with the implications related to the number of label switched
paths that can constitute a session as well as LSP merging capabilities. If
not for this implications, which I believe are quite consequential to the
RSVP-TE applicability, I would not raise the issue.

BTW, the RSVP-TE support of multipoint-to-point and split-path sessions as
well as related path merging could be a good topic for the RSVP-TE
applicability draft to help clear some haze around these issues.

Regards,
 Dimitry

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


> -----Original Message-----
> From: Daniel Awduche [mailto:awduche@UU.NET]
> Sent: Tuesday, April 18, 2000 4:09 PM
> To: Dimitry Haskin
> Cc: mpls@UU.NET; Daniel Awduche
> Subject: Re: FW: I-D
> ACTION:draft-ietf-mpls-rsvp-tunnel-applicability-01.txt
> 
> 
> 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
> 
> 
> On Mon, Apr 10, 2000 at 03:05:04PM -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. 
> >  
> > 
> --------------------------------------------------------------
> -------- 
> > Dimitry Haskin 
> > Lucent Technologies Internetworking Systems 
> >  
>