Subject: RE: Explicit Loose Path Computation

From: LE ROUX Jean-Louis FTRD/DAC/LAN <[email-masked]>
Date: Wed, 16 Jan 2002 09:36:08 +0100

Are you sure David that there is no real need for loose nodes ?

To my mind loose routes may be relevant in case of multi-area, or multi AS
TE.

The head-end LSR calculates a route that is stirctely explicited in it's
area, because it has a complete topology, and loosely explicited in other
areas, because it has only some recheability information provided by border
routers.

Each border router receving a Path message loosely routed, determines the
strict path in it's area.

JL

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: mercredi 16 janvier 2002 00:36
To: [email-masked]
Subject: Re: Explicit Loose Path Computation

Snigdho Bardalai wrote:
> 
> I wanted to find out if anybody has come across an
> algorithm to compute an explicit loose path.

IMO, it seems rather pointless.  If you have enough routing information
available to automatically compute an ERO, why wouldn't you want to
compute a strict ERO?

IMO, loose EROs are best used only by manual-creation, where a human
operator can specify certain key nodes, knowing that the topology of the
intervening nodes may change over time.  But any software that
auto-generates these EROs should also be capable of dynamically
recomputing those EROs as the topology changes, meaning that there is no
real need for loose nodes.

At least this is my opinion.

-- David

---

From: [email-masked]
Date: Wed, 16 Jan 2002 09:59:49 +0100

Let's explore this a little bit further.

In my opinion, the proposal for loosely specified parts in the explicit
route (the ABRs probably) makes sense if:
- the ABR of the computing area has more than one ABR alternative in the
destination area
- the computing node knows about the path between the possible ABR pairs
- the computing node knows about the path following the ABR in the
destination area
After all, why would you change the ABR selection if it wasn't to find a
more optimal path? I think the above scenario requires signalling between
the computing node and one or more ABRs. In this case, couldn't we assume
that not only the computing node, but also the explicit route (segment) is
passed?
I agree, however, that it may be interesting to be able to set up more
optimal multi-area LSPs without the need for communication between
computing nodes or specifying the complete explicit route at the ingress.
In draft-vdbosch-tewg-multiarea-branch-te-00.txt, a proposal is made to
send several path setup messages in parallel and letting the egress decide
on the actual path that is taken. This does not require specifying the
complete explicit route at the ingress. It allows the specification of any
path segment, and it can find the most optimal path through the network. It
achieves this at the cost of extra signalling during LSP setup.

Sven.

"LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
on 16/01/2002 09:36:08

  To:          "'David Charlap'" <[email-masked]>, 
               "'Snigdho Bardalai'" <[email-masked]>     
                                                              
  cc:          [email-masked](bcc: Sven VAN DEN                  
               BOSCH/BE/ALCATEL)                              

  Subject      RE: Explicit Loose Path Computation            
  :                                                           

JL

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: mercredi 16 janvier 2002 00:36
To: [email-masked]
Subject: Re: Explicit Loose Path Computation

-- David

---

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 16 Jan 2002 12:14:26 -0500

Snigdho:

-> My question may have been a little confusing -
-> actually the algorithm should generate an explicit
-> path based on loose route constraint specification.

  One simple solution (though not efficient)

  Take pairs of adjacent EROs from source to destination.
  That is, if A,B,C,D are EROs then take (A,B) as the
  source and destination pair and recursively iterate 
  path computation engine for (B,C), (C,D) etc...

  Finally combine all EROs - what you get is (one of the)
  best matched between A(source) and D(destination).

  lemma: divide and conquer.
  note: take care of accumulative constraints.

--Venkata Naidu

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 16 Jan 2002 14:28:02 -0500

I think there is more operational reasons to constrict an ERO path based on
certain
Loose, or Strict nodes (hops). The scenarios would be too numerous to
mention. Enough
to say that it is used beyond just optimizing TE multi-area algorithms being
proposed
in IETF.

>> "In draft-vdbosch-tewg-multiarea-branch-te-00.txt, a proposal is made to
>> achieves this at the cost of extra signalling during LSP setup."
>>

I also believe that CSPF is a more efficient way to compute an ERO that is
constraint
than by using a complex signalling mechanism and finding the ERO Constraint
path.

Ben
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 4:00 AM
To: LE ROUX Jean-Louis FTRD/DAC/LAN
Cc: 'David Charlap'; 'Snigdho Bardalai'; [email-masked]
Subject: RE: Explicit Loose Path Computation

Sven.

                                                              

                                                              

JL

-----Original Message-----
From: David Charlap [mailto:[email-masked]]
Sent: mercredi 16 janvier 2002 00:36
To: [email-masked]
Subject: Re: Explicit Loose Path Computation

-- David

---

From: [email-masked]
Date: Thu, 17 Jan 2002 08:55:00 +0100

Ben,

Thanks for your comment. Would you care to expand on this a little bit?

>>than by using a complex signalling mechanism and finding the ERO
Constraint

What do you propose to do:
a. use CSPF per area and rely on reachability info to select intermediate
hops
b. use CSPF per area but explicitly specify some hops (maybe the ABRs in
the case of interarea TE). In this case how do you know which ones to
specify?
c. use CSPF and signal "remote" path segments to the computing node that
assembles them to the complete path. This would also require some sort of
(possibly complex) signalling

Sven.