Subject: RSVP Explicit_Route object question

From: "Michael H. O'Meara" <[email-masked]>
Date: Tue, 29 Aug 2000 10:53:03 -0400

LER_A ----- LSR_A ----- LSR_B ---- LER_B
-------------LSP/1 ----------------->

In the above topology, LER_A specifies a strict explicit route along
LSP/1. Can LER_A specify LSR_A's egress interface as it's first hop or,
does the RSVP-TE protocol require that the hop can only be either the
ingress interface or the routerId of LSR_A.

Thanks in advance,
 Mike

***************************
Michael O'Meara
Technician
MPLS Consortium	
InterOperability Lab
University of New Hampshire
***************************

---

From: David Charlap <[email-masked]>
Date: Tue, 29 Aug 2000 11:19:15 -0400

"Michael H. O'Meara" wrote:
> LSP/1. Can LER_A specify LSR_A's egress interface as it's first hop
> or, does the RSVP-TE protocol require that the hop can only be either
> the ingress interface or the routerId of LSR_A.

If you use a loose-hop in the explicit-route object, then there's
definitely no problem.  LER_A would look at the ERO and ask its routing
table "what's the next hop to get to the egress interface of LSR_A". 
The routing table will probably respond with "the ingress interface of
LSR_A".

As for whether this will work with a strict route or not, I'm not sure. 
My understanding of the draft is that it will.

If I'm wrong about this, hopefully someone will correct me here.

I've always understood the processing of an ERO with strict routes to be
something along the lines of:

	1: Strip all instances of your own addresses from the front of
           the list.

	2: The address that's now at the top of the list is your next-
           hop.  Use whatever means are necessary to find out if the
           switch owning this address (whether it's ingress, egress, or
           otherwise) is directly attached.  If so, send a Path to that
           switch, otherwise return PathErr.

So, for a topology like this:
                    ______
         /\        /\13      /\        /\
    ____/  \______/  \______/  \______/  \____
       5\1 /6    7\2 /8    9\3 /10  11\4 /12
         \/        \/        \/        \/

Where 1, 2, 3, and 4 are router IDs, 5-12 are interfaces along the path,
and 13 is an interface that's not on the path, all of these are
theoretically valid strict EROs:

	1, 2, 3, 4
	5, 7, 9, 11, 12
	5, 6, 7, 8, 9, 10, 11, 12
	5, 1, 6, 7, 2, 8, 9, 3, 10, 11, 4, 12
	6, 8, 9, 11, 4, 12

In all cases a switch will start by stripping off all of its own
addresses, and act based on whatever address is next.  When the next
switch receives the Path, it will do the same.

As a matter of fact, because of this, I think even this goofy ERO should
work, even though it is not actually describing the path the data will
follow:

	5, 13, 9, 11, 12

In this case, the first router strips off its own address (5) and does a
lookup for 13 - which is a neighbor address, since it's part of switch
2, which is directly attached.  When switch 2 gets the packet, it sees
13 as one of its own addresses and strips it, and does a lookup for the
next-hop address (9), and sends the Path there.  etc.

It all works because a transit router doesn't know (or doesn't have to
know) the topology of the network beyond its neighbors, and the first
thing a router does on receipt of an ERO is to strip its own addresses
off the front of it.

-- David