The MPLS WG Archive

[Daniel Awduche <awduche@UU.NET>]

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 
>