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

From: Dimitry Haskin <[email-masked]>
Date: Wed, 19 Apr 2000 10:52:03 -0400

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:[email-masked]]
> Sent: Tuesday, April 18, 2000 4:09 PM
> To: Dimitry Haskin
> Cc: [email-masked]; 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 
> >  
>

---

From: Daniel Awduche <[email-masked]>
Date: Tue, 25 Apr 2000 02:32:56 -0400

Dimitry,

Thanks or the note. See additional comments inline...

> 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