Subject: RE: RSVP-TE--RRO

From: Arumugam R <[email-masked]>
Date: Thu, 28 Sep 2000 21:20:05 +0530

Thanks for the comments. Also added the inline comments.

-----Original Message-----
From:	David Charlap [SMTP:[email-masked]]
Sent:	Thursday, September 28, 2000 8:39 PM
To:	[email-masked]
Subject:	Re: RSVP-TE--RRO

Arumugam R wrote:
> 
> How can a single Resv message used for reserving multiple senders?.

Please reread RFC 2205.  It's explained in great detail.

> In Rsvp-Lsp point of view, the TE tunnel should be an unique one in
> the entire domain.

And if every sender specifies a different session, this is exactly what
you'll get.

But RSVP also allows multiple senders to send to the same session.  A
receiver that gets Path messages from two different senders in the same
session, it may send out a single Resv message for both of them.

Remember: A session only specifies an endpoint (egress router, tunnel
ID, and extended tunnel ID).  And there can be multiple senders can be
on the same ingress router (differentiated by the LSP ID)

[$$] If the Same Ingress Router (Behaving Like multiple senders) establishes 
multiple Sessions ( TE tunnels) with the Egress Router, then all the sessions 
will be having different Tunnel Id isn't.
      Between Ingress and Egress there can be a number of tunnels established based 
on policy considerations, depending on the traffic parameters required for each 
of them. But each tunnel should have an unique reservation along all the nodes 
between the Ingress and Egress, which can be achieved only by an unique Tunnel Id.
     Only during the reroute condition the Ingress of tunnel assigns a different LSP-ID 
for avoiding double counting of resources. All other occasions the nodes 
maintain reservations only based on the unique Tunnel Id, Egress Address pair I suppose.
Please correct me if I am wrong.    .

> Since the draft does not deal with multicasting applications, the
> above following discussion holds good only for SE style( that too
> during rerouting ) and not for FF style.

Multiple senders in one session can and will happen for a short time
during a make-before-break operation.  It can also happen during some
kinds of failures.

During this time, when there are more than one sender for a single
session, the next-hop routers can (and probably should) send out a
single Resv message for all the senders in the session.

-- David

---

From: David Charlap <[email-masked]>
Date: Thu, 28 Sep 2000 12:26:01 -0400

Arumugam R wrote:
> 
> [$$] If the Same Ingress Router (Behaving Like multiple senders)
> establishes multiple Sessions ( TE tunnels) with the Egress Router,
> then all the sessions will be having different Tunnel Id isn't.

Correct.  Under normal conditions, every LSP will be using a separate
session.

> Between Ingress and Egress there can be a number of tunnels
> established based on policy considerations, depending on the traffic
> parameters required for each of them. But each tunnel should have an
> unique reservation along all the nodes between the Ingress and Egress,
> which can be achieved only by an unique Tunnel Id.

Unique tunnel ID and extended tunnel ID.  Otherwise, it is hard to
prevent two different ingress routers from choosing the same tunnel ID.

Another possibility, which is not as good, is to let all the LSPs remain
in the same session (same tunnel ID and extended tunnel ID), and make
FF-style reservations.  But this should not be attempted, because an
ingress router can not force the egress router to choose a particular
reservation style.

(I only mention the second possibility to point out that unique
non-shared reservations don't _have_ to be achieved through multiple
sessions, although that is the best way to do it.)

> Only during the reroute condition the Ingress of tunnel assigns a
> different LSP-ID for avoiding double counting of resources.

It's not to avoid double-counting.  It's to prevent the LSP from going
down during a reroute.

Make-before-break can't work if the LSP ID doesn't change.  Transit
routers will end up applying the PathTear message to the new route
instead of to the old one.

If the ingress router simly changes the ERO without doing make-before-
break at all, similar problems will arise.  Routers that are no longer
on this LSP's route will eventually timeout and send PathTear messages
downstream - which will cause the LSP (on its new route) to get torn
from the point where the two routes merge to the egress router.

> All other occasions the nodes maintain reservations only based on the
> unique Tunnel Id, Egress Address pair I suppose.
> Please correct me if I am wrong.

This is the expectation.

I don't think it would violate the MPLS drafts if two senders would
deliberately try to establish paths in the same session (perhaps by
using the all-zeros value of extended tunnel ID).  If the egress router
uses FF-style reservation, or if the reservation is for best-effort, or
if the ingress routers don't care about sharing resources with each
other, then everything should operate normally.

Note that this is not really multicast.  Multiple unicast LSPs are still
being established, and each one still gets its own labels.  The only
difference between this and multiple sessions (from the data-plane
perspective) is if SE-style reservations are used - in which case,
resources will be shared between these LSPs wherever they have links in
common.

The main reason that this scenario probably won't be used by anybody is
because resource sharing between LSPs (outside of make-before-break) is
not something peole want.  And SE style reservations are going to be
used, in order to facilitate efficient make-before-break handling.

-- David