The MPLS WG Archive

[Guy Davies <Guy.Davies@telindusk.net>]

Hi Dave and Mike,

There are certainly implementations out there which will not permit you to
use anything other than an interface on a directly connected network when
describing strictly routed LSPs.  When you think about it, this makes sense
because the point of a strictly routed LSP is that you describe each hop
(without the possibility of any other hops being introduced).  If you
specify the loopback (or, indeed, any other non-ingress interface of the
next LSR) then each LSR would have to resort to using it's routing table to
select the path to the next hop and that introduces the possibility of other
LSRs being traversed between the two supposedly adjacent LSRs.

So, to make my ramblings short...  to me, it makes no sense to use any
address other than that of the ingress interface of each LSR on the path
when using strict explicit routing of LSPs.

Regards,

Guy

> -----Original Message-----
> From: David Charlap [mailto:david.charlap@marconi.com]
> Sent: Tuesday, August 29, 2000 4:19 PM
> To: mpls@UU.NET
> Subject: Re: RSVP Explicit_Route object question
> 
> 
> "Michael H. O'Meara" wrote:
> > 
> > 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.
> 
> 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
> 
This e-mail and any attachments may contain privileged, confidential and/or
copyright information and is for the sole use of the intended addressee. If
you are not the named recipient, please notify the sender immediately and do
not disclose the contents to another person, use it for any purpose, or
store or copy the information in any medium.This message is subject to and
does not create or vary any contractual relationship between Telindus K-NET
Ltd and you.