Re: thoughts on draft-bryant-shand-ipfrr-notvia-addresses-00.txt

[Alia Atlas <aatlas at avici.com>]

At 01:19 PM 4/28/2005, stefano previdi wrote:
> On Apr 28, 2005, at 3:43 PM, Alia Atlas wrote:
> > What I was considering was whether the router would need to advertise a 
> > 10/8 - which allows saving of 2 bytes per notvia address (top octet plus 
> > mask) by using a single summary address or whether the router might be 
> > able to advertise multiple summary addresses so, say, 10.1.1/24 and then 
> > 10.1.8/24 - which saves 4 bytes per notvia address - but adds the bits 
> > for identifying the summary address intended.
>
> well... at this stage it's more a deployment issue...
> but we certainly need to allow multiple summaries.

As long as we agree on the need to support multiple summaries (at the very 
least to allow the transition from one summary to another), then what type 
of issue we each think it is doesn't seem to matter much. :-)

> > I assume that you are thinking of ISIS & not OSPF?
>
> as far as I'm concerned... yes.

We do want a solution that works for both, so it's useful to catch the 
different assumptions.

> >  Regardless, for fast-reroute purposes, it is extremely desirable to 
> > know of the existence of parallel links.  Otherwise, there may be an 
> > alternate path that isn't computed simply because it uses a parallel 
> > link.   The same issue arises with RSVP-TE.  For instance, the parallel 
> > links may not share any SRLGs in common - which can make for quite a 
> > difference.
>
> yes, I was referring to IP-only networks. When TE is deployed
> such behavior is not used. Odf course we won't use it for ipfrr
> neither. It's maybe worth to mention this in some place...

As Mike pointed out, not reported parallel links isn't a problem until one 
starts to consider SRLGs (local or general).

> > I believe that it is important to consider a dynamic/automatic way of 
> > assigning addresses - and at the very least, it is needed to have a 
> > mechanism so that the same IP address means the same thing 
> > consistently!  If we don't have the latter, it'll be a bit of a nightmare 
> > to troubleshoot.
>
> I certainly agree with the last part of your statement but
> not the first part. Manual assignment of ip addresses is
> something that is being done from day one and I don't
> believe we have any strong need to make it dynamic. Of
> course, a dynamic assignment method that will be consistent
> across re-starts and predictable in its results is always
> a plus we can think of but at the current stage of ipfrr
> I don't see it as a must.

Consistency is the primary concern.  The next is simplicity of 
configuration, trouble-shooting and operation.  Manual assignment of 
addresses to interfaces could be good enough; perhaps the options are just 
implementation differences as to how the router derives a particular notvia 
address to use per interface.

> >  What about the memory required?  Is it the case that the data on the 
> > last "primary topology" SPF is stored & then used as the basis for each 
> > of the other incremental SPFs so that the amount of data stored doesn't 
> > grow substantially with the number of notvia addresses?
>
> this is one option. Note that in most of the cases each
> router stores anyway the data related to its last SPT so
> the not-via overhead may not _that_ significant...

Depends on the router of course, but also as Mike pointed out, the base 
topology used for the notvia computation also has to toss out those routers 
that aren't capable.

> Also, the way you store ip addresses and the way you update
> rib/fib will make the difference in terms of scaling and
> performance.

Isn't is always so?

Alia



_______________________________________________
Rtgwg mailing list
Rtgwg at ietf.org
https://www1.ietf.org/mailman/listinfo/rtgwg