Subject: RE: [IPTEL] ITAD Topology

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 25 Feb 2001 20:22:06 -0500

I'm inclined to agree with Dave, and that the simplest and cleanest solution
is to allow UPDATE to contain ReachableRoutes, WithdrawnRoutes, or
ITADTopology, and specify which other attributes need to be present based on
which of the above three are there.

I definitely do not want to add a new message type, since I think this will
require too many changes in other places in the document. Similarly, I do
not want to use UPDATE as a keepalive, since this would require very
pervasive changes throughout the document.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Dave Walker [mailto:[email-masked]]
> Sent: Friday, February 16, 2001 11:23 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [IPTEL] ITAD Topology
> 
> 
> Here's a bit of discussion mostly on option 1 (without 
> actually endorsing
> either option).
> 
> The draft already describes zero length Withdrawn and Reachable Route
> attributes.  I didn't see anything in the draft about it, but there
> should be an explanation of what to do if both have length zero.  If 
> this is allowed, I'd expect that the other mandatory attributes (NHS, 
> AdPath, and RoutedPath) would also have length zero (not described in
> the draft).  If at least one of the Route attributes must 
> have non-zero
> length, then a) it's an error if both are zero, and b) the other 
> mandatory attributes must not have length zero.
> 
> My next question is why are these attributes mandatory in the first
> place?  My feeling about the UPDATE message is that it's basically 
> used to convey a description of changes in an LS's view of 
> the network.
> This may include adding routes, and/or deleting routes, and/or 
> changes in topology.  Is it of great benefit to include zero length
> attributes if there's nothing to say?  Shouldn't the rule for these
> attributes be something like: "if you have a ReachableRoute, then you
> must also include NHS and the Path attributes"?  If this were 
> the case,
> then UPDATE could be used for ITAD Topology without including other
> (currently mandatory) attributes which aren't applicable.  Further
> degenerating this idea, the KEEPALIVE could be replaced by an UPDATE
> that contains nothing at all.
> 
> 
> Dave Walker
> SS8 Networks
> Ottawa, Canada
> 
> 
> "Hussein F. Salama" wrote:
> > 
> > I got a comment from a developer who doesn't like the use of the
> > ITAD-Topology attribute in the UPDATE message. They strongly believe
> > that we should define a new message dedicated to topology flooding,
> > because many times an LS would like to update the the 
> topology without
> > having new ReachableRoutes or WithdrawnRoutes to advertise. And in
> > link-state protocols, there are usually separate message 
> for advertising
> > the topology and others for advertising the routes.
> > 
> > I can think of the following choices:
> > 1. Define a new message for ITAD-Topology
> > 2. Keep the attribute as it is today and specify how to fill in the
> > mandatory arttributes (ReachableRoutes, WithdrawnRoutes, LocalPref,
> > AdvertisementPath, ...) if there';s nothing to put in them.
> > 3. Do nothing (may be give some guidelines in the BCP draft)
> > 
> > I think the #1 is the right thing to do. What do you think?
> > 
> > Hussein
> > 
> > --
> > Hussein F. Salama
> > Cisco Systems
> > Mail Stop SJC-21/3, 170 W. Tasman Drive, San Jose, CA 95134
> > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147
> 
> _______________________________________________
> IPTEL mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel