The MPLS WG Archive

["Peter Ashwood-Smith" <petera@nortelnetworks.com>]

Title: RE: draft-ietf-mpls-te-feed-01.txt

Hmmm,
 
     You are right it is confusing. I must have not had enough coffee that morning. Let me see if I can clarify it for you.

The point I was trying to make is that there are performance advantages to keeping the feedback values in order. For example if my feedback list for the path A->B->C->D looks like this:

(A,B,Stuff1) (B,C,Stuff2) (C,D,Stuff3) 

      Then I can possibly walk the list and my database structure simultaneously without having to start the search from the root of some search tree every time. For example after applying the (A,B,Stuf1) value to the database, when you apply (B,C,Stuff2) to the database, you already have your pointers to 'B" so the search is presumably much faster.

     On the other hand, if the feedback came in the order:

(A,B,Stuff1) (C,D,Stuff3) (B,C,Stuff2)

      Then I have to look from scratch for each link in the database without being able to take advantage of where I previously was. Obviously that's going to be slower in many implementations.

      Now, I could have written the draft  to specify the vector as (A,Stuff)(B,Stuff)(C,Stuff) and REQUIRED them to be sorted but that would have made it impossible to skip feedback for certain links.

      Hope this helps and sorry my wordy description confused you.

     Cheers,
 
     Peter Ashwood-Smith

P.S. please, I don't want 20 emails saying not to apply the feedback data to the topology database ... I simply said database, its up to you where you store the data as long as you use it for interim route computations but don't re-flood it,  I'm happy.

-----Original Message-----
From:   Bui, Khanh [SMTP:kbui@netplane.com]
Sent:   Monday, November 06, 2000 3:34 PM
To:     mpls@UU.NET
Subject:        draft-ietf-mpls-te-feed-01.txt

Hello,

Would someone please clarify the recommended order of
the feedback TLVs included in a CR-LDP message as quoted
from section 2 "Adding feedback TLVs to CR-LDP":

"Two new TLVs are optionally added to the CR-LDP mapping,
notification, and withdraw messages. There may be an arbitrary
number of these TLV in any order or position in the message.
It is recommended that they be placed such that they can be
read and applied to override the topology database by scanning
the message forwards and walking the topology database from
the point where the last link feedback TLV left off."

Specifically, what does the phrase "where the last link
feedback TLV left off" mean ?

Thanks,
Khanh