Subject: Re: Determining the Ingress IP address in an RSVP session

From: George Swallow <[email-masked]>
Date: Thu, 10 May 2001 12:56:41 -0400

Eric, Guangzhi -

We've had a terminology problem with tunnels all along.  The way I
think about it is a tunnel is the desire to have a path from a source
to destination.  When that desire is frustrated we say the 'tunnel is
down' or no path extists for this tunnel.  A tunnel is *normally*
mapped one to one to an LSP.  The notable exceptions to this are in
the case of a reroute operation or a fast-reroute.

The scope of the SE style reservation is to the Session.  In order to
limit a session to a single tunnel, we extended the session object to
include the extended tunnel ID.  We also renamed the Port field to
tunnel_ID.  This creates a means of allowing multiple LSPs to
share a session, (and bandwidth using the SE style).

The sender_template contains the sender and the LSP_ID.  This creates
a means of allowing reroute operations.

On initial setup any Path message creating an LSP for a tunnel should
have The destination field of the session object set to the
destination of the tunnel and the source in the sender to the
ingress.  As the draft says, the extended tunnel_ID is normally zero.
This derives from one vendor's hope that they could avoid LDP
altogether and that merging destination based trees would be the
dominant use of RSVP lsps.  Our implementation always fills it in.

The way I've modeled fast reroute is as follows.

The node making the repair (Point of local repair or PLR for short)
creates an lsp from itself to the destination for this purpose.
This lsp may merge with the original lsp somewhere prior to the
destination but need not.  (Note that if the PLR is the penultimate
node it cannot.)  It uniquely identifies that LSP by using its own
address in the sender object.  But this only works if the
extended_tunnel ID is in use.  (A point that I need to add to my
reroute draft).

So in practive if the extended tunnel ID is non-zero, use that as the
identifier of the ingress.  If it is zero use the sender.

Also note that for GMPLS some folks are considering doing away with
the requirement that PATH messages are addressed to the destination.
In GMPLS, having non-RSVP routers in the path won't work so the reason
for addressing to the destination is gone.  Also it is possible to
have loss of neighbor connectivity in the control plane while the data
plane is just fine.  So being able to directly address these without
having to do IPinIP would be useful.  Don't know if this will actually
happen, but relying on the Source/Dest address in the IP header of the
Path message may not be a good choice in the long run.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Guangzhi Li <[email-masked]>
Date: Thu, 10 May 2001 15:03:08 -0400

George:

Thanks. So the conclusion could be:

(1) In order to  support destination rooted tree lsps, the SESSION field
of extended ID must be zero.
(2) In order to support fast reroute, the SESSION field of extended ID
must be used (non zero).

Then you can not have both. But both are legal based on RSVP-TE. It is
vendor's choice for implementation. But should be ready to accept both.
Right ?

Now  sender_template. Is it legal to put sender_template address different
from extended ID when extended ID is non-zero? In your example of fast
reroute,
Is it legal to put PLR address in the sender_template ? if not, then which
one ?

Thanks,

-- Guangzhi

---

From: George Swallow <[email-masked]>
Date: Thu, 10 May 2001 15:32:07 -0400

Guangzhi -

> of extended ID must be zero.

Yes.

> (2) In order to support fast reroute, the SESSION field of extended ID

Only if you care about sharing the bandwidth.  If you're just doing a
best effort service then the restriction isn't necessary.

> vendor's choice for implementation. But should be ready to accept both.

Again only if you're worried about bandwidth.

> from extended ID when extended ID is non-zero? In your example of fast

Yes.

> Is it legal to put PLR address in the sender_template ? if not, then which

Yes.

,,,George

---

From: Guangzhi Li <[email-masked]>
Date: Thu, 10 May 2001 17:07:13 -0400

George:

I think your answer solves a lot of questions posted in this mailing list.
Thanks,

-- Guangzhi