Subject: Re: Evaluation of Gateway Location proposals

From: Jose Costa Requena <[email-masked]>
Date: Wed May 05 15:56:54 1999

Hi Hussein,

>You are talking here strictly about BGP for layer 3 routing. Even in
>this case, a single UPDATE message may contain multiple NLRI
>(destination prefixes) under the condition that they share the same
>attributes (NEXT_HOP, AS_PATH, ...) . TBGP uses the MP_REACH_NLRI
>attribute to advertise prefixes. Similar to BGP, the MP_REACH_NLRI
>contains a list of NLRIs which share the same attributes.
>
>The original BGP NEXT_HOP attribute will not be used in call routing.
>
>The above discussion brings up the question I had for some time: Does
>GLP/SCSP define a mechanism for explicitly withdrawing a route and
>removing it from the call routing databases?

The SCSP itself has a mechanism to notify the databases in the rest of DCSs 
forming the SG that the server has received a request from a client or User 
Agent to remove an entry from its cache or routing database.In this case, 
when the LS which contains the entry that is going to disappear and receive 
Cache State Update Solicit (CSUS) from other server, this LS will respond 
copying the CSAS from the CSUS and will set the N bit (described in the CSAS 
record specification). The N bit signifies that this CSAS Record is actually 
a Null record and this entry in the database does not exist any longer.

I wonder if is that the question that you were asking?
and I hope that I have clarified the idea.

Best regards.

Jose

Helsinki University of Technology
Laboratory of Telecommunications Technology
Jose Costa Requena
Research Scientist
Room: SG 227B
Tel: + 358 9 451 2475
email(internet): [email-masked]
http://keskus.tct.hut.fi/tutkimus/ipana/pers/jose.shtml

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Hussein F. Salama" <[email-masked]>
Date: Wed, 05 May 1999 16:01:49 -0700

Jose,

Thanks for the clarification.

> a Null record and this entry in the database does not exist any longer.

Assume server A advertises a record X to server B. Then, at some later
point in time, record X is deleted. Server B won't learn that record X
has seized to exist until it solicits an update from server A for that
record? This could be a very slow operation. How frequently should B
solicit updates from A, in order to minimize the probability of using
outdated or deleted records?

Advertising route withdrawals to a server which is multiple hops away
will be very slow using this mechanism. Let's say every server
periodically solicits updates every time interval t. It will take a
server, C, n*t time units, in the worst case, to learn that a record has
been withdrawn, where n is the number of hops between server C and the
server which has withdrawn the record. 

What's wrong with conventional routing logic: when a server detects a
change to the state of a record, it immediately triggers an unsolicited
update to its peers. When a peer receives the update, if it causes any
changes to that peer's records, it immediately triggers an update to the
peer's peers. And so on. Wouldn't that be faster?

The SCSP RFC says: "The "N" bit signifies that this CSAS Record is
actually a Null record.  This bit is only used in a CSAS Record
contained in a CSU Request/Reply which is sent in response to a CSUS
message." This means that an update advertising a record deletion must
be solicited. How about other changes to the attributes of an existing
record? Can they trigger an unsolicited update, CSU Request?

Hussein

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

---------