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

From: mike shand <[email-masked]>
Date: Tue, 26 Apr 2005 15:35:00 +0100

At 15:07 25/03/2005 -0500, Alia Atlas wrote:

>Second is the list of downsides with the approach.  The main concern is 
>that the mechanism becomes too complex such that the trade-off between its 
>complexity and the full coverage is not desirable.
>1.      This requires a large number of additional IP addresses in the 
>IGP.  The same number of additional FECs is required to support LDP.

Yes, it does. In the simplest case of link and node protection, and 
ignoring LANs it requires 2 addresses per protected link. It is expected 
that these would come out of a "private" address space, and hence wouldn't 
consume real addresses. Indeed for security reasons it is preferable that 
they are private addresses.

I don't think this number is "too many". The question is how does this 
number increase when we add LANs and SRLGs.

>2.      Explicit tunnels are needed, which means that targeted LDP 
>sessions are necessary to have this support LDP traffic.

Yes. In the case of node protection we could also using Naiming's scheme of 
next-next hop LDP advertisement.

>  This is a particular concern for multi-homed prefixes; I'll describe my 
> concerns on this later.

Yes. This is a concern for LDP. I don't like the idea of targeted LDP 
sessions. Two possibilities come to mind

a) each node with an attached MHP distributes an additional label for that 
prefix which has the semantics that when you pop that address you MUST 
forward the underlying IP packet "directly".

b) an alternative which doesn't require additional labels, but DOES require 
a new "well known" label with the above semantics.

Neither are very attractive, but perhaps more attractive than the directed 
LDP sessions.

>3.      Substantial IGP changes are required to handle the additional 
>Notvia addresses.

Substantial is perhaps a bit strong. We need to advertise the not-via 
address and its association. For IS-IS its pretty straightforward. OSPF, by 
its very nature, may be a little more tricky.

>4.      A more complex algorithm is required to make the computation feasible.

Yes.

>5.      The management of the Notvia addresses & of the tunnels can create 
>longer time periods where protection isn't available for a part of the 
>network (the new link or node, etc.).

I don't think the tunnels add to the time at all. They are after all just 
FIB entries. Distributing the notvia addresses for a new node/link will 
occur at the same time as distributing the information about the link/node 
in the first place. I don't think it significantly increases the delay.

There is of course the time it takes to recompute notvia routes, but we 
think this will be well under a second.

These aspects certainly need thinking about, but they don't seem to pose 
insurmountable issues.

>Third, there are a number of issues that I feel need considerable 
>discussion to try and resolve.  I will try to go through each in turn and 
>explain what I think the various aspects of each are.  Each of these 
>issues has the possibility to resolve in such a way that the Notvia 
>Addresses approach becomes overly complex.

Yes. That is a temptation we need to resist!

>1.      Notvia Addresses:  The first issue is how the Notvia addresses are 
>allocated, distributed and withdrawn.  An initial idea of Stewart & Mike 
>is that these addresses are not global addresses (i.e. are 10.x.x.x or 
>such) and are configured in blocks on each router so that the router can 
>manage the bindings itself.

That seems the most reasonable thing to do.

>a.      The routing extensions to the IGP will have to associate a network 
>resource (node or link) that an address should be Notvia.  This is 
>probably straightforward.

Yes, As I said above.

>b.      It is desirable to have some dampening on the withdrawal of Notvia 
>addresses to minimize thrashing.

The allocation of notvia addresses to links certainly shouldn't be changed 
as a result of not "needing" the notvia address when the object with which 
it is associated goes away. It should also get back the same notvia address 
when it comes back. But I don't think there are any particular issues 
associated with them disappearing and reappearing in the LSPs.

Do you have any specific issues in mind?

>c.      If configured in blocks, it would be extremely desirable to have 
>the same Notvia address mean the same thing through multiple reboots, 
>etc.  It'd be good to have some means of consistent association.  This is 
>for easy manageability.

Yes, definitely.

>d.      When a new link or neighbor comes up, there will be a longer 
>period of time when an alternate isn't available because the Notvia 
>address hasn't been advertised yet.  These periods without protection need 
>to be clearly understood and minimized.

Yes. I'm not convinced there is a particular problem here, but it does need 
thinking through carefully.

>e.      There may be scalability concerns based on the number of Notvia 
>addresses and LDP FECs required.  For instance, as described in the draft, 
>it is basically the number of uni-directional links in the topology.  This 
>is ignoring the extras for broadcast links.  To fully & certainly provide 
>SRLG protection if at all feasible, would require that each router 
>advertise a Notvia address for every uni-directional link into every 
>neighbor of that router.  This would result in K*L additional addresses, 
>where K is the average number of neighbors & L is the number of 
>uni-directional links in the topology.

Yes. This is a major concern, and we need to devise ways of solving SRLGs 
etc. which minimize the potential proliferation of addresses.
We need to get the right tradeoff here between optimal solutions and 
complexity.

>2.      Insufficiently diverse topology:  It is possible that a network 
>topology cannot provide an alternate that suffices for link, node and SRLG 
>protection.  It isn't clear to me how to compute a "best-available" 
>alternate using this approach.  For instance, if one can get link 
>protection, but not node protection, how would that be determined, 
>computed and assigned?  This becomes much more of a concern for SRLG 
>protection & for topologies where failures have already occurred and the 
>network has converged for those & needs protection in the event of an 
>additional failure.

Clearly it is always possible to create a topology which contains single 
points of failure and is inherently irreparable. This is part of the 
tradeoff we need to address when thinking about SRLGs, since taking a 
simple but pessimistic approach to SRLG can result in this sort of failure. 
This seems to be a property of the problem rather than any particular solution.

>3.      Failure Diagnosis versus Pessimism:  As written, the draft 
>discusses the idea of doing failure diagnosis using BFD.  As Stewart, Mike 
>& I have discussed, this isn't possible for SRLG failures, although it is 
>possible for broadcast links.

Yes, and this relates to (2) above.

>a.      I am concerned about adding the failure diagnosis.  This is yet 
>another level of complexity for implementation.  It also has ramifications 
>for the forwarding plane, because of the need to store multiple alternates 
>to use & have multiple states to check to decide what to use.

Yes. It would be nice not to have to do it, but that is back to the 
tradeoff above.

>b.      An example of a concern with the BFD diagnosis is that all 
>interfaces on a node that has failed are not certain to fail exactly 
>simultaneously or even within a sub-50ms bounded window.  It is entirely 
>possible that BFD sessions are terminated on different line-cards, that 
>detect the router failure at slightly different times and stop forwarding 
>traffic, therefore, at slightly different times.

Yes. There is the possibility of misdiagnosis in this case if the second 
failure occurs too long after the first. I suppose this then looks like two 
separate failures. Clearly an unreliable diagnosis is probably worse than 
no diagnosis at all. We need to get some handle on how realistic or not 
this scenario is.

>c.      The other approach is to pessimistically eliminate all routers 
>connected to the broadcast link as well as the broadcast link; this may 
>not provide an alternate.

Yes. While simple, it runs into the problem of being a single (albeit 
large) point of failure. Its the same trade-off as above.

>   It also needs to be thought through what issues might exist if the 
> topologies used for the SPF vary slightly for each router that is on the 
> broadcast link, since each will, as described, not prune itself out when 
> doing the computation; of course, there could be an approach where the 
> same topology can be used everywhere.

I'm not really sure what you mean here.

>  It isn't clear to me what Notvia addresses would be needed to express 
> "don't go through this pseudo-node or any nodes attached to it"; I don't 
> think that it is simply the Notvia address for avoiding a particular node.

No, it would need a specific notvia address bound to the LAN interface.

>4.      Multi-homed Prefixes:  I am quite concerned about the mechanisms 
>suggested in the draft.
>a.      First, I really do not like the idea of having separate forwarding 
>for "local" prefixes that come out of a tunnel.  What is a local 
>prefix?  For instance, does this mean that an ABR has to forward traffic 
>different depending on which area traffic from the tunnel has come 
>from?  I am concerned about how this would scale; maybe only 2 FIBs are 
>needed (one for backbone & one for other), but it may be worse to handle 
>AS external routes.  I know that Stewart, Mike, Joel, Albert and I had 
>discussed/agreed to put this idea out of scope  at least for the moment.

Clearly the problem needs solving, especially since prefixes which are 
multihomed are frequently the most important prefixes (which is WHY they 
are multihomed in the first place).

>b.      I am quite concerned about having tunnels to the advertisers of 
>the prefixes.
>i.      There needs to be a mechanism to determine whether the advertiser 
>of a prefix will forward the packet in a loop-free fashion to avoid the 
>failure point.  The separate forwarding for "local" prefixes avoided the 
>need for this determination, but at more substantial cost.

There seem to be two aspects to this.

a) we need the ability to get the packet to the "second-best" attachment 
point for the prefix without it being "sucked back" to the failure. This in 
general requires a tunnel, except for the cases where a neighbor of the 
node detecting the failure has an LFA to the second best attachment point. 
Clearly this could be used in preference to a tunnel where available, but 
at the expense of additional complexity. However this is really just an 
extension of the general principle that we should use "basic" (i.e. LFA) 
repair to cream off traffic which doesn't NEED to be tunnelled.

b) we need (in a very limited number of cases), the ability to force the 
packet to the locally attached prefix. This only occurs where the local 
cost is high compared to the cost back to the failed attachment point. But 
when we DO need it, the use of a tunnel is a convenient means of signalling 
this. I'm not sure how else to do it, other than using a label.

Of course ONE "solution" would be to REQUIRE the costs to be set sensibly :-)

>ii.     To support LDP, every tunnel requires a targeted LDP session.  If 
>multi-homed prefixes are common, then this becomes a full mesh for 
>LDP.  That isn't acceptable.

Agreed.

>  Of course, multi-homed prefixes may be much more infrequent for LDP than 
> for IP; for example, there is no reason to advertise a separate FEC for 
> the subnet of a link.  However, multi-homed prefixes are a concern for 
> LDP for at least the inter-area, AS External, and BGP routes.
>iii.    If traffic is encapsulated to a node's regular address, because 
>that traffic is destined to a prefix advertised by the node, how does the 
>receiving node know to remove the encapsulation and forward the packet 
>inside  all in the fast path?  Is this a just a question of different 
>handling based on the header type inside the outer encapsulation (for GRE)?

Yes.

>iv.     Perhaps these issues could be handled by determining a 
>next-next-hop that avoids the failure to reach an appropriate 
>advertiser.   Of course, this is a different set/type of computation.

Could you explain that suggestion please?

>5.      SRLGs and Broadcast Links:  There seem to be a number of possible 
>ways to handle SRLGs and broadcast links, each of which provides a 
>different trade-off in terms of  coverage, computation, and extra Notvia 
>addresses.

Yes.

>   There are basically 4 approaches at this point.
>a.      First, In order to compute a notvia alternate that avoids a link, 
>the primary neighbor, and all SRLGs that the link is part of, it is 
>necessary to have a separate topology and associated SPF computation for 
>each link that is a member of an SRLG or a broadcast link.   This requires 
>also a substantially larger number of Notvia addresses and the 
>corresponding mechanisms to determine how and when to allocate and 
>de-allocate them.

.. and could potentially result in a combinatorial explosion if we weren't 
very careful.

>b.      Second, one could use a topology that removed the primary neighbor 
>and see whether SRLG protection can be obtained either along S's path or 
>along any path of a neighbor of S that is also loop-free.

Could you explain that a bit more please?

>c.      Third, when a Notvia address indicates to avoid a node, one could 
>remove not merely the node & the uni-directional links to and from that 
>node, but also any other links that are in a common SRLG with any of the 
>links to or from the removed node.  This is pessimistic  but allows some 
>SRLG protection without increased computation or Notvia addresses.

Yes. This is nice and simple, but as you have pointed out above, could 
easily result in an inability to find a viable repair.

>d.      Fourth, one could simply track the SRLGs encountered along the 
>Notvia path; this just reports whether the alternate provides SRLG 
>protection without any effort to obtain it.

Yes. Interesting. I wonder how useful this would be.

>6.      Implementability:  Clearly, the draft describes the basic idea for 
>Notvia addresses, but there are a fair number of implementation/protocol 
>decisions that need to be made before this can become anything more than 
>an interesting idea.

Sure. There are quite a few design decisions and tradeoffs as indicated 
above that need tieing down.

>7.      There is a definite need to describe the convergence case 
>better.   This is how the transition from using the alternate to the 
>network being converged happens, such that the alternate remains functional.
>a.      For instance, if the node E fails, then the Notvia address E_!S 
>will no longer be advertised.  If S was getting link protection (because 
>that was all that was possible, for instance) by tunneling traffic to 
>E_!S, it is important that this traffic be properly discarded when E's 
>addresses go away.   This implies that there needs to be a default 
>blackhole for Notvia addresses.

I don't quite understand your concern here. If E goes away and S is sending 
to E_!S, then the neighbors of E will drop the packets because we don't 
repair a notvia address.

Or are you concerned that after convergence, there will be nodes which 
don't even have a forwarding entry for E_!S. By this time I don't think 
that S (or anyone else) should still be using that address, but even if it 
were, the absence of a forwarding entry would (SHOULD) cause the packet to 
be dropped. Is this all you are saying?

>b.      Another example is when node E fails, the next-next-hop B must 
>continue to advertise the Notvia address B_!E until the network converges 
>so that S can continue to tunnel traffic to B_!E as the alternate.

Yes. Our view was that no changes would be made to notvia advertisement or 
more specifically notvia FIB entries until after convergence is over. Of 
course there is an issue as to how you tell when that has happened, but the 
timers associated with loop free convergence probably give a good indication.

>c.      It is possible to get a micro-forwarding loop affecting a Notvia 
>address as a result of a less severe failure than anticipated.  For 
>instance, consider the following topology.
>              [D]
>               |
>           1   |
>      [E]-----[F]-\
>       |       |   \ 10
>     1 |R    1 |R   \
>       |   5   |     \
>      [S]-----[H]----[I]
>                  2
>
>      Link S->E and Link H->F are in SRLG R
>
>When node E fails, if I converges before H, there will be a loop affecting 
>the Notvia address being used to reach F without going through any of Link 
>S->E, E or SRLG R.

We discussed this privately, and I still don't see how loops could arrise 
even if the notvia FIB were recomputed before normal convergence is 
complete. But I think it is better to delay the notvia FIB changes anyway.

>d.      How do exceptions work?  Particularly in regards to an IP-in-IP 
>encapsulation such as GRE, it doesn't seem like MTU exceeded cases can be 
>handled cleanly  either by use of DF or by doing IP fragmentation and then 
>the reassembly at the end of the tunnel.  This seems like a problem for 
>all ICMP packets; how could a source understand the header inside for a 
>TTL expired, for instance.

I'll leave this for Stewart (tunnel) Bryant!

>e.      For IP-in-IP tunnels, another concern is flow diversity.  The IP 
>source and destination addresses are used to determine a flow; this flow 
>identification may then be used for a variety of purposes, including 
>ECMP.  By putting all the traffic to a variety of destinations inside the 
>same header, the ability to take advantage of flow diversity appears to 
>have disappeared.   This could possibly be solved by putting the original 
>source address into the encapsulating header?  Are there other approaches?

and this.

>Hopefully, this will spark some discussion on the issues.

Let's hope so

         Mike

>Alia
>
>
>
>_______________________________________________
>Rtgwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
Rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Apr 2005 22:56:32 -0400

Mike,

At 10:35 AM 4/26/2005, mike shand wrote:
>>that the mechanism becomes too complex such that the trade-off between 
>>its complexity and the full coverage is not desirable.

It would be useful to hear some additional opinions on the impact of adding 
a large number of addresses.  The other question is what is the boundary 
when it becomes a serious concern.

>Yes. In the case of node protection we could also using Naiming's scheme 
>of next-next hop LDP advertisement.

True - but I'd want to think about the implications in terms of additional 
communication & periods of instability/inaccuracy of knowledge.    It also 
doesn't handle the multi-homed prefix case for the case when the path isn't 
via the next-next-hop.

>b) an alternative which doesn't require additional labels, but DOES 
>require a new "well known" label with the above semantics.
>

Both of these presume the ability to route based on the nested addresses of 
the packet.  In general, I don't think that this is a valid 
assumption.  Consider, for instance, the case of a BGP-free core.  Traffic 
is directed towards an ASBR in a different area (that is multi-homed to the 
one being considered).  In that case, the ABR may not have the BGP routes 
to be able to correctly forward the packet based on its IP address.  There 
are also a number of scenarios where what is underneath the top LDP label 
is another MPLs label & not routable at all.

>address and its association. For IS-IS its pretty straightforward. OSPF, 
>by its very nature, may be a little more tricky.

More substantial than a few bits :-)  The main issue here is just the 
interop and migration concerns.

>>5.      The management of the Notvia addresses & of the tunnels can 
>>create longer time periods where protection isn't available for a part of 
>>the network (the new link or node, etc.).
>

I agree that they're not insurmountable - but just require consideration.

>Yes. That is a temptation we need to resist!

It's frequently a coverage versus complexity trade-off, where each decision 
is along the slippery slope - alas!

>>b.      It is desirable to have some dampening on the withdrawal of 
>>Notvia addresses to minimize thrashing.
>
>it is associated goes away. It should also get back the same notvia 
>address when it comes back. But I don't think there are any particular 
>issues associated with them disappearing and reappearing in the LSPs.
>

Only keeping the notvia addresses around until after the network has 
converged...  If the notvia address is withdrawn with the link that's 
failed, then traffic may still be using that alternate.

>>etc.  It'd be good to have some means of consistent association.  This is 

For the case where the notvia address is for a neighbor, it's not always 
that straightforward - unless one ends up advertising multiple notvia 
addresses for the same neighbor, depending on the number of parallel 
links.  This is mostly engineering, I think.

>>address hasn't been advertised yet.  These periods without protection 
>>need to be clearly understood and minimized.
>
>Yes. I'm not convinced there is a particular problem here, but it does 
>need thinking through carefully.

Agreed.

>>addresses and LDP FECs required.  For instance, as described in the 
>>draft, it is basically the number of uni-directional links in the 
>>topology.  This is ignoring the extras for broadcast links.  To fully & 
>>certainly provide SRLG protection if at all feasible, would require that 
>>each router advertise a Notvia address for every uni-directional link 
>>into every neighbor of that router.  This would result in K*L additional 
>>addresses, where K is the average number of neighbors & L is the number 
>>of uni-directional links in the topology.
>

Agreed.  We need to understand the impact of additional addresses to know 
the complexity cost of that versus the reduced coverage of selecting a less 
complete approach to broadcast link and SRLG protection.

>>topology cannot provide an alternate that suffices for link, node and 
>>SRLG protection.  It isn't clear to me how to compute a "best-available" 
>simple but pessimistic approach to SRLG can result in this sort of 
>failure. This seems to be a property of the problem rather than any 
>particular solution.

Let me try to explain this a bit better.  Say there's a topology that, for 
a particular next-hop & next-next-hop, can only provide an alternate that 
gives link and node protection but not SRLG protection.  Now, how does the 
notvia addresses method compute an alternate?  If the method is pruning the 
topology of the relevant link, node & SRLGs, no alternate will be 
found.  However, it was possible to compute & use an alternate that gives 
the link & node protection.  The similar case can easily occur with link & 
node protection.  Say S has two parallel links to E; if the first fails, S 
could use the other to get link protection  - but there is no 
node-protecting alternate.  How does S determine this?  What is the 
fall-back strategy in the case that no "full-protection" alternate is 
available?

>>discusses the idea of doing failure diagnosis using BFD.  As Stewart, 
>>Mike & I have discussed, this isn't possible for SRLG failures, although 
>>it is possible for broadcast links.
>
>>another level of complexity for implementation.  It also has 
>>ramifications for the forwarding plane, because of the need to store 
>>multiple alternates to use & have multiple states to check to decide what 
>>to use.
>

Complexity vs. coverage?  I'm very fond, unsurprisingly, of options that 
don't require hardware changes... so I judge that the complexity is rather 
high to support this one - as well as more error-prone (see comment on 
unreliable diagnosis).

>failure occurs too long after the first. I suppose this then looks like 
>two separate failures. Clearly an unreliable diagnosis is probably worse 
>than no diagnosis at all. We need to get some handle on how realistic or 
>not this scenario is.

Well, I think it is exceedingly realistic :-)
For a non-power related failure, routers with separate forwarding & control 
planes may take varying amounts of time for the line-cards to all realize 
that the route controller is down.

>large) point of failure. Its the same trade-off as above.

Don't they all reduce to that?

>I'm not really sure what you mean here.

Let me try and explain it a bit.  Perhaps I'm missing something.   In the 
case where a notvia topology results in pruning the router doing the 
computation, what forms the root of the SPT?   Say routers A, B and C are 
all connected to a broadcast link X and want to compute a notvia X address 
as described in (c) by pruning the pseudo-node related to X as well as A, 
B, and C.   Now, router A prunes the pseudo-node, A, B and C from the 
topology; what does A use as the root?  IF A only prunes the pseudo-node, B 
and C to compute notvia X, B only prunes the pseudo-node, A, and C, and C 
only prunes the pseudo-node, A and B,  and all other routers prune the 
pseudo-node, A, B, and C, can there be any issues with a consistently 
computed & non-looping path for notvia X?

I think it may not be an issue - b/c once the traffic leaves A, B or C, it 
will never return - but it at least needs some thought, since this is a bit 
different from what's traditionally been done.

>No, it would need a specific notvia address bound to the LAN interface.

Agree

>>a.      First, I really do not like the idea of having separate 
>>forwarding for "local" prefixes that come out of a tunnel.  What is a 
>>local prefix?  For instance, does this mean that an ABR has to forward 
>>traffic different depending on which area traffic from the tunnel has 
>>come from?  I am concerned about how this would scale; maybe only 2 FIBs 
>>are needed (one for backbone & one for other), but it may be worse to 
>>handle AS external routes.  I know that Stewart, Mike, Joel, Albert and I 
>>had discussed/agreed to put this idea out of scope  at least for the moment.
>

inconvenient that!

>point for the prefix without it being "sucked back" to the failure. This 
>in general requires a tunnel, except for the cases where a neighbor of the 

Yes - though the tunnels bring out the LDP issues with targeted sessions - 
of course.

>when we DO need it, the use of a tunnel is a convenient means of 
>signalling this. I'm not sure how else to do it, other than using a label.
>

I like that one :-)  but you knew I would!  We may need to define what that 
means better or have a way of determining that it is the case.

>>  Of course, multi-homed prefixes may be much more infrequent for LDP 
>> than for IP; for example, there is no reason to advertise a separate FEC 
>> for the subnet of a link.  However, multi-homed prefixes are a concern 
>> for LDP for at least the inter-area, AS External, and BGP routes.

OK.  The traffic wouldn't be directed up to the control plane because it 
was GRE encapsulated??  And had a special header type for this 
purpose?  Certainly I can see something like this working with an LDP LSP, 
b/c the label would just get it to that router & then be popped & the 
packet forwarded based on what's underneath.

>Could you explain that suggestion please?

Well, if there is a neighbor's neighbor whose path to the multi-homed 
prefix doesn't go through the failure & this can be determined, then the 
traffic could be tunneled to that neighbor's neighbor & then normally 
forwarded from there.

Basically, if one knows the SPT from each neighbor's neighbor & can reach 
all of those neighbor's neighbors without going through the failure, then 
it might provide an alternate.  The issue there is first that the path to a 
neighbor's neighbor might go via the failed element & not have an 
appropriate notvia  & second the effort of computing and considering the 
different SPTs.

Does that make more sense?

>>each link that is a member of an SRLG or a broadcast link.   This 
>>requires also a substantially larger number of Notvia addresses and the 

I do think of this as having the highest potential to be the "too 
complicated & run-away" scenario.

>>b.      Second, one could use a topology that removed the primary 
>>neighbor and see whether SRLG protection can be obtained either along S's 
>>path or along any path of a neighbor of S that is also loop-free.
>

This is the concept of looking for a loop-free neighbor to the notvia 
address whose path there happens to give SRLG protection.  We'd discussed 
this one the last day at IETF.

>easily result in an inability to find a viable repair.

At the risk of additional complication, one could have it configurable as 
to the specific handling of SRLGs.  For instance, most link/node/SRLG would 
be handled with a single notvia per node  - and then there could be 
configured specific links that required their own notvia.   Of course, that 
adds substantial extra complexity.  Is it necessary?

>Yes. Interesting. I wonder how useful this would be.

Well, it could feedback to a network design at least - to give an 
indication of coverage.  Also, not all SRLGs have the same likelihood to 
fail.  So, if avoiding all doesn't work, perhaps one can avoid the most 
risky ones - and then report the protection against the failures of the 
others.

This is part of my concern/question about what notvia alternate is computed 
if the best protection isn't possible.

>>6.      Implementability:  Clearly, the draft describes the basic idea 
>>for Notvia addresses, but there are a fair number of 
>>implementation/protocol decisions that need to be made before this can 
>>become anything more than an interesting idea.
>
>I don't quite understand your concern here. If E goes away and S is 
>sending to E_!S, then the neighbors of E will drop the packets because we 
>don't repair a notvia address.

I'm thinking of this as the more specific prefix goes away.   Without a 
specific blackhole for the group of prefixes, why wouldn't the packets take 
that instead?  I.e., if the notvia address is 10.1.1.1 and there's a 
default route for 10.1/16  (or for 0.0.0.0/0), then the packet would pick 
up the latter when the notvia address is removed.

>don't even have a forwarding entry forE_!S. By this time I don't think 

I was also worrying about the above in reference to the notvia 
addresses.  While it is possible to say that changes to notvia 
addresses  shouldn't be installed until after the network has otherwise 
converged, that sort of detail needs to be clarified.

>course there is an issue as to how you tell when that has happened, but 
>the timers associated with loop free convergence probably give a good 
>indication.

Conceptually, I agree.  Having a primary topology to forward the traffic on 
while the backup one reconverges helps.

>>When node E fails, if I converges before H, there will be a loop 
>>affecting the Notvia address being used to reach F without going through 
>>any of Link S->E, E or SRLG R.
>

Just for clarity (hopefully),  before the failure, H computes the path for 
F_!E, the address of F's that is notvia E, to go via I and then to 
F.  After the failure of E, if H installs the changed notvia address F_!E 
the path is directly to F, b/c node E no longer has SRLG R associated with 
any of E's up links.

>>handled cleanly  either by use of DF or by doing IP fragmentation and 
>>then the reassembly at the end of the tunnel.  This seems like a problem 
>>for all ICMP packets; how could a source understand the header inside for 
>>a TTL expired, for instance.
>

For LDP, there are mechanisms (layer violations though they are) to handle 
exceptions generating ICMP packets.

>>source address into the encapsulating header?  Are there other approaches?

Again, for an LDP tunnel, many routers can look under the label and 
consider the IP packet inside for flow identification.

Alia

---

From: stefano previdi <[email-masked]>
Date: Wed, 27 Apr 2005 11:49:27 +0200

Alia, Mike,

just one comment on not-via addresses...

On Apr 27, 2005, at 4:56 AM, Alia Atlas wrote:

>>> Second is the list of downsides with the approach.  The main concern 
>>> is that the mechanism becomes too complex such that the trade-off 
>>> between its complexity and the full coverage is not desirable.
>>> 1.      This requires a large number of additional IP addresses in 
>>> the IGP.  The same number of additional FECs is required to support 
>>> LDP.
>>
>> ignoring LANs it requires 2 addresses per protected link. It is 
>> expected that these would come out of a "private" address space, and 
>> hence wouldn't consume real addresses. Indeed for security reasons it 
>> is preferable that they are private addresses.
>>
>> I don't think this number is "too many". The question is how does 
>> this number increase when we add LANs and SRLGs.
>
> It would be useful to hear some additional opinions on the impact of 
> adding a large number of addresses.  The other question is what is the 
> boundary when it becomes a serious concern.

I believe there are ways of implicitly advertise these
addresses (i.e.: the router advertises a kind of a summary
from which the interface not-via addresses are derived).
For example, a router receiving an LSP/LSA will do:

- check if the originator has ipfrr enabled on one
   or more interfaces (capability TLV ?)
- the originator advertised a summary not-via address
   (new not-via summary address TLV ?)
- check what are the originator neighbors for which
   protection has been enabled and derive which not-via
   address has to be used for which neighbor (neighbor
   subTLV with a few bits identifier correlated to the
   not-via address to use)

In this case the igp won't suffer much from these
additional addresses and I believe we have most of the
bits we need to do that...

s.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 27 Apr 2005 15:51:19 +0100

First of all I largely agree with Mike's email,
but then that's not going to surprise anyone :)

Alia Atlas wrote:

>>> the IGP.  The same number of additional FECs is required to support LDP.
>>
>>

Also to understand whether the issue is the number of addresses per se
or the inflation of the routing protocol message size.

>> Yes. In the case of node protection we could also using Naiming's 
>> scheme of next-next hop LDP advertisement.
> 
> 
> True - but I'd want to think about the implications in terms of 
> additional communication & periods of instability/inaccuracy of 
> knowledge.    It also doesn't handle the multi-homed prefix case for the 
> case when the path isn't via the next-next-hop.
> 

OK. I think that we need to work on some state transition description
to make sure that all the bases are covered, and that we have
a common view of the states.

The complexity of MHP is really the complexity of MHP per se, rather
than the complexity of NV.

We have four options:

1) Restrict the reach of the repair to max two hops and
maybe use Naiming's LDP extension.
2) Tunnel the packet (using NV, PQ or whatever) and learn the label
at the far end.
3) Tunnel the packet and then strip all labels and do an IP lookup.
4) Figure out some other method of delivering the packet n hops away
in the base topology (such as n-hop u-turn).

Each of these approaches seems to have it's issues, and it's
a question of picking the least unpalatable.

> 
>>>  This is a particular concern for multi-homed prefixes; I'll describe 
>>> my concerns on this later.
>>
>>
>> a) each node with an attached MHP distributes an additional label for 
>> that prefix which has the semantics that when you pop that address you 
>> MUST forward the underlying IP packet "directly".
>>
>> Neither are very attractive, but perhaps more attractive than the 
>> directed LDP sessions.
> 
> 
> Both of these presume the ability to route based on the nested addresses 
> of the packet.  In general, I don't think that this is a valid 
> assumption.  Consider, for instance, the case of a BGP-free core.  
> Traffic is directed towards an ASBR in a different area (that is 
> multi-homed to the one being considered).  In that case, the ABR may not 
> have the BGP routes to be able to correctly forward the packet based on 
> its IP address.  There are also a number of scenarios where what is 
> underneath the top LDP label is another MPLs label & not routable at all.

In which case we either have to:

a) Run the directed LDP session
b) Give up
c) Think of something else.

A for else might be domain wide labels, but I remember the last
time that was proposed in MPLS WG:)

Are there any other for-else's that are better?

>> address and its association. For IS-IS its pretty straightforward. 
>> OSPF, by its very nature, may be a little more tricky.
> 
> 

I don't understand. The IGP will flood the TLV's we have in mind.
Non-NV routers will be excluded from base. Could you expand?

>>> create longer time periods where protection isn't available for a 
>>> part of the network (the new link or node, etc.).
>>
>>
>> I don't think the tunnels add to the time at all. They are after all 
>> just FIB entries. Distributing the notvia addresses for a new 
>> node/link will occur at the same time as distributing the information 
>> about the link/node in the first place. I don't think it significantly 
>> increases the delay.
>>
>> There is of course the time it takes to recompute notvia routes, but 
>> we think this will be well under a second.
>>
>> These aspects certainly need thinking about, but they don't seem to 
>> pose insurmountable issues.
> 
> 
>>> discussion to try and resolve.  I will try to go through each in turn 
>>> and explain what I think the various aspects of each are.  Each of 
>>> these issues has the possibility to resolve in such a way that the 
>>> Notvia Addresses approach becomes overly complex.
>>
>>
> It's frequently a coverage versus complexity trade-off, where each 
> decision is along the slippery slope - alas!
> 
>> The allocation of notvia addresses to links certainly shouldn't be 
>> changed as a result of not "needing" the notvia address when the 
>> object with which it is associated goes away. It should also get back 
>> the same notvia address when it comes back. But I don't think there 
>> are any particular issues associated with them disappearing and 
>> reappearing in the LSPs.
>>

Since we are going to use controlled rather than uncontrolled
convergence we can include managing the NV entries in the FIB.
You are right to point out that we have not described how to do this.

> 
>>> c.      If configured in blocks, it would be extremely desirable to 
>>> have the same Notvia address mean the same thing through multiple 
>>> reboots, etc.  It'd be good to have some means of consistent 
>>> association.  This is for easy manageability.
>>
>>
>> Yes, definitely.
> 
> 
>>> e.      There may be scalability concerns based on the number of 
>>> Notvia addresses and LDP FECs required.  For instance, as described 
>>> in the draft, it is basically the number of uni-directional links in 
>>> the topology.  This is ignoring the extras for broadcast links.  To 
>>> fully & certainly provide SRLG protection if at all feasible, would 
>>> require that each router advertise a Notvia address for every 
>>> uni-directional link into every neighbor of that router.  This would 
>>> result in K*L additional addresses, where K is the average number of 
>>> neighbors & L is the number of uni-directional links in the topology.
>>
>>
>> Yes. This is a major concern, and we need to devise ways of solving 
>> SRLGs etc. which minimize the potential proliferation of addresses.
> Agreed.  We need to understand the impact of additional addresses to 
> know the complexity cost of that versus the reduced coverage of 
> selecting a less complete approach to broadcast link and SRLG protection.
> 
>>> 2.      Insufficiently diverse topology:  It is possible that a 
>>> network topology cannot provide an alternate that suffices for link, 
>>> node and SRLG protection.  It isn't clear to me how to compute a 
>>> "best-available" alternate using this approach.  For instance, if one 
>>> can get link protection, but not node protection, how would that be 
>>> determined, computed and assigned?  This becomes much more of a 
>>> concern for SRLG protection & for topologies where failures have 
>>> already occurred and the network has converged for those & needs 
>>> protection in the event of an additional failure.
>>
>>
>> Clearly it is always possible to create a topology which contains 
>> single points of failure and is inherently irreparable. This is part 
>> of the tradeoff we need to address when thinking about SRLGs, since 
>> taking a simple but pessimistic approach to SRLG can result in this 
>> sort of failure. This seems to be a property of the problem rather 
>> than any particular solution.
> 
> 
> Let me try to explain this a bit better.  Say there's a topology that, 
> for a particular next-hop & next-next-hop, can only provide an alternate 
> that gives link and node protection but not SRLG protection.  Now, how 
> does the notvia addresses method compute an alternate?  If the method is 
> pruning the topology of the relevant link, node & SRLGs, no alternate 
> will be found.  However, it was possible to compute & use an alternate 
> that gives the link & node protection.  

I need to think about this.

> The similar case can easily 
> occur with link & node protection.  Say S has two parallel links to E; 
> if the first fails, S could use the other to get link protection  - but 
> there is no node-protecting alternate.  How does S determine this?  What 
> is the fall-back strategy in the case that no "full-protection" 
> alternate is available?

In this case

S fails E, and computes the NV paths to its neighbors.
If any or all of these are unreachable it uses a link
repair to E_!S to reach them as described in Section 4.2
of the draft. If E_!S does not exist as in the case above,
S then looks to see if the parallel link exists.

Of course in the absence of SRLG, this topology contains
a SPF for node protection and will always be expected to have
limited repair coverage.

You are correct that this all needs describing in detail.

>>> Mike & I have discussed, this isn't possible for SRLG failures, 
>>> although it is possible for broadcast links.
>>
>>
>>> a.      I am concerned about adding the failure diagnosis.  This is 
>>> yet another level of complexity for implementation.  It also has 
>>> multiple alternates to use & have multiple states to check to decide 
>>> what to use.
>>
>>
> don't require hardware changes... so I judge that the complexity is 
> rather high to support this one - as well as more error-prone (see 
> comment on unreliable diagnosis).
> 
>>> simultaneously or even within a sub-50ms bounded window.  It is 
>>> entirely possible that BFD sessions are terminated on different 
>>> line-cards, that detect the router failure at slightly different 
>>> times and stop forwarding traffic, therefore, at slightly different 
>>> times.
>>
>>
>> Yes. There is the possibility of misdiagnosis in this case if the 
>> second failure occurs too long after the first. I suppose this then 
>> looks like two separate failures. Clearly an unreliable diagnosis is 
>> probably worse than no diagnosis at all. We need to get some handle on 
>> how realistic or not this scenario is.
> 
> 
> For a non-power related failure, routers with separate forwarding & 
> control planes may take varying amounts of time for the line-cards to 
> all realize that the route controller is down.

Well maybe for power-failures as well :)

The pathology of this sort of failure is highly implementation dependent.
Say BFD was running on the LC, but the switch fabric was down.
You could end up with the neighbors thinking that the router was still
up, but it was non-functional. Eventually routing would notice the
absence of routing hellos, unless of course, these had also been
delegated :) Perhaps we need to run BFD to the neighbor's neighbors
on the direct path?

The problem is that we rapidly get on a complexity spiral that
becomes intractable.

We clearly to write down a set of project scoping rules for the
types of failure that we will and will not deal with.

> 
>>> c.      The other approach is to pessimistically eliminate all 
>>> routers connected to the broadcast link as well as the broadcast 
>>> link; this may not provide an alternate.
>>
>>
>>> topologies used for the SPF vary slightly for each router that is on 
>>> the broadcast link, since each will, as described, not prune itself 
>>> out when doing the computation; of course, there could be an approach 
>>> where the same topology can be used everywhere.
>>
>>
> Let me try and explain it a bit.  Perhaps I'm missing something.   In 
> the case where a notvia topology results in pruning the router doing the 
> computation, what forms the root of the SPT?   Say routers A, B and C 
> are all connected to a broadcast link X and want to compute a notvia X 
> address as described in (c) by pruning the pseudo-node related to X as 
> well as A, B, and C.   Now, router A prunes the pseudo-node, A, B and C 
> from the topology; what does A use as the root?  IF A only prunes the 
> pseudo-node, B and C to compute notvia X, B only prunes the pseudo-node, 
> A, and C, and C only prunes the pseudo-node, A and B,  and all other 
> routers prune the pseudo-node, A, B, and C, can there be any issues with 
> a consistently computed & non-looping path for notvia X?
> 
> I think it may not be an issue - b/c once the traffic leaves A, B or C, 
> it will never return - but it at least needs some thought, since this is 
> a bit different from what's traditionally been done.

Agreed, we need to write down the algorithm and subject it to review.
> 
>>>  It isn't clear to me what Notvia addresses would be needed to 
>>> express "don't go through this pseudo-node or any nodes attached to 
>>> it"; I don't think that it is simply the Notvia address for avoiding 
>>> a particular node.
>>
>>
>>> 4.      Multi-homed Prefixes:  I am quite concerned about the 
>>> mechanisms suggested in the draft.
>>> local prefix?  For instance, does this mean that an ABR has to 
>>> forward traffic different depending on which area traffic from the 
>>> tunnel has come from?  I am concerned about how this would scale; 
>>> maybe only 2 FIBs are needed (one for backbone & one for other), but 
>>> it may be worse to handle AS external routes.  I know that Stewart, 
>>> Mike, Joel, Albert and I had discussed/agreed to put this idea out of 
>>> scope  at least for the moment.
>>
>>
>> multihomed are frequently the most important prefixes (which is WHY 
>> they are multihomed in the first place).
> 
> 
> inconvenient that!
> 
>>> b.      I am quite concerned about having tunnels to the advertisers 
>>> of the prefixes.
>>> i.      There needs to be a mechanism to determine whether the 
>>> advertiser of a prefix will forward the packet in a loop-free fashion 
>>> to avoid the failure point.  The separate forwarding for "local" 
>>> prefixes avoided the need for this determination, but at more 
>>> substantial cost.
>>
>>
>> a) we need the ability to get the packet to the "second-best" 
>> attachment point for the prefix without it being "sucked back" to the 
>> failure. This in general requires a tunnel, except for the cases where 
>> a neighbor of the node detecting the failure has an LFA to the second 
>> best attachment point. Clearly this could be used in preference to a 
>> tunnel where available, but at the expense of additional complexity. 
>> However this is really just an extension of the general principle that 
>> we should use "basic" (i.e. LFA) repair to cream off traffic which 
>> doesn't NEED to be tunnelled.
> 
> 
> Yes - though the tunnels bring out the LDP issues with targeted sessions 
> - of course.
> 
>> b) we need (in a very limited number of cases), the ability to force 
>> the packet to the locally attached prefix. This only occurs where the 
>> local cost is high compared to the cost back to the failed attachment 
>> point. But when we DO need it, the use of a tunnel is a convenient 
>> means of signalling this. I'm not sure how else to do it, other than 
>> using a label.
>>
> I like that one :-)  but you knew I would!  We may need to define what 
> that means better or have a way of determining that it is the case.
> 
>>> ii.     To support LDP, every tunnel requires a targeted LDP 
>>> session.  If multi-homed prefixes are common, then this becomes a 
>>> full mesh for LDP.  That isn't acceptable.
>>
>>
>> Agreed.
>>
>>> than for IP; for example, there is no reason to advertise a separate 
>>> FEC for the subnet of a link.  However, multi-homed prefixes are a 
>>> concern for LDP for at least the inter-area, AS External, and BGP 
>>> routes.
>>> iii.    If traffic is encapsulated to a node's regular address, 
>>> because that traffic is destined to a prefix advertised by the node, 
>>> how does the receiving node know to remove the encapsulation and 
>>> forward the packet inside  all in the fast path?  Is this a just a 
>>> question of different handling based on the header type inside the 
>>> outer encapsulation (for GRE)?
>>
>>
>> Yes.
> 
> 
> was GRE encapsulated??  

GRE always pops the header at the tunnel endpoint. That is how it
works!

> And had a special header type for this purpose?  
> Certainly I can see something like this working with an LDP LSP, b/c the 
> label would just get it to that router & then be popped & the packet 
> forwarded based on what's underneath.
> 

Perhaps an MPLS label of some sort the way we thought of doing directed
forwarding and the way that Mark Townsley proposed doing IP VPN?

> traffic could be tunneled to that neighbor's neighbor & then normally 

Yes, but you only get two hop reachability. Perhaps you do this,
and then do directed LDP for the remaining (perhaps 2%) of cases.
The problem I have with this is the added complexity.

> 
> Basically, if one knows the SPT from each neighbor's neighbor & can 
> reach all of those neighbor's neighbors without going through the 
> failure, then it might provide an alternate.  The issue there is first 
> that the path to a neighbor's neighbor might go via the failed element & 
> not have an appropriate notvia  & second the effort of computing and 
> considering the different SPTs.
> 

Yes.

> 
>>> 5.      SRLGs and Broadcast Links:  There seem to be a number of 
>>> possible ways to handle SRLGs and broadcast links, each of which 
>>> provides a different trade-off in terms of  coverage, computation, 
>>> and extra Notvia addresses.
>>
>>
>> Yes.
>>
>>> a.      First, In order to compute a notvia alternate that avoids a 
>>> link, the primary neighbor, and all SRLGs that the link is part of, 
>>> it is necessary to have a separate topology and associated SPF 
>>> computation for each link that is a member of an SRLG or a broadcast 
>>> link.   This requires also a substantially larger number of Notvia 
>>> addresses and the corresponding mechanisms to determine how and when 
>>> to allocate and de-allocate them.
>>
>>
>> .. and could potentially result in a combinatorial explosion if we 
>> weren't very careful.
> 
> 
>>> neighbor and see whether SRLG protection can be obtained either along 
>>> S's path or along any path of a neighbor of S that is also loop-free.
>>
>>
> address whose path there happens to give SRLG protection.  We'd 
> discussed this one the last day at IETF.
> 
>>> c.      Third, when a Notvia address indicates to avoid a node, one 
>>> could remove not merely the node & the uni-directional links to and 
>>> from that node, but also any other links that are in a common SRLG 
>>> with any of the links to or from the removed node.  This is 
>>> pessimistic  but allows some SRLG protection without increased 
>>> computation or Notvia addresses.
>>
>>
> At the risk of additional complication, one could have it configurable 
> as to the specific handling of SRLGs.  For instance, most link/node/SRLG 
> would be handled with a single notvia per node  - and then there could 
> be configured specific links that required their own notvia.   Of 
> course, that adds substantial extra complexity.  Is it necessary?
> 
>>> d.      Fourth, one could simply track the SRLGs encountered along 
>>> the Notvia path; this just reports whether the alternate provides 
>>> SRLG protection without any effort to obtain it.
>>
>>
> This is part of my concern/question about what notvia alternate is 
> computed if the best protection isn't possible.
> 
>>> 6.      Implementability:  Clearly, the draft describes the basic 
>>> idea for Notvia addresses, but there are a fair number of 
>>> implementation/protocol decisions that need to be made before this 
>>> can become anything more than an interesting idea.
>>
>>
>> Sure. There are quite a few design decisions and tradeoffs as 
>> indicated above that need tieing down.
>>
>>> a.      For instance, if the node E fails, then the Notvia address 
>>> E_!S will no longer be advertised.  If S was getting link protection 
>>> (because that was all that was possible, for instance) by tunneling 
>>> traffic to E_!S, it is important that this traffic be properly 
>>> discarded when E's addresses go away.   This implies that there needs 
>>> to be a default blackhole for Notvia addresses.
>>
>>
>> sending to E_!S, then the neighbors of E will drop the packets because 
>> we don't repair a notvia address.
> 
> 
> specific blackhole for the group of prefixes, why wouldn't the packets 
> take that instead?  I.e., if the notvia address is 10.1.1.1 and there's 
> a default route for 10.1/16  (or for 0.0.0.0/0), then the packet would 
> pick up the latter when the notvia address is removed.

Yes, you are quite right. We need a NV black hole.

>> that S (or anyone else) should still be using that address, but even 
>> if it were, the absence of a forwarding entry would (SHOULD) cause the 
>> packet to be dropped. Is this all you are saying?
> 
> 
>>> b.      Another example is when node E fails, the next-next-hop B 
>>> must continue to advertise the Notvia address B_!E until the network 
>>> converges so that S can continue to tunnel traffic to B_!E as the 
>>> alternate.
>>
>>
>> Yes. Our view was that no changes would be made to notvia 
>> advertisement or more specifically notvia FIB entries until after 
>> convergence is over. Of course there is an issue as to how you tell 
>> when that has happened, but the timers associated with loop free 
>> convergence probably give a good indication.
> 
> 
> Conceptually, I agree.  Having a primary topology to forward the traffic 
> on while the backup one reconverges helps.
> 
>>> c.      It is possible to get a micro-forwarding loop affecting a 
>>> Notvia address as a result of a less severe failure than 
>>> anticipated.  For instance, consider the following topology.
>>>              [D]
>>>               |
>>>           1   |
>>>      [E]-----[F]-\
>>>       |       |   \ 10
>>>     1 |R    1 |R   \
>>>       |   5   |     \
>>>      [S]-----[H]----[I]
>>>                  2
>>>
>>> affecting the Notvia address being used to reach F without going 
>>> through any of Link S->E, E or SRLG R.
>>
>>
>> We discussed this privately, and I still don't see how loops could 
>> arrise even if the notvia FIB were recomputed before normal 
>> convergence is complete. But I think it is better to delay the notvia 
>> FIB changes anyway.
> 
> 
> Just for clarity (hopefully),  before the failure, H computes the path 
> for F_!E, the address of F's that is notvia E, to go via I and then to 
> F.  After the failure of E, if H installs the changed notvia address 
> F_!E the path is directly to F, b/c node E no longer has SRLG R 
> associated with any of E's up links.
> 

I think that the core issue here is the case of a failure during the
reconvergence of the repair topology. Is that in scope?

>>> d.      How do exceptions work?  Particularly in regards to an 
>>> IP-in-IP encapsulation such as GRE, it doesn't seem like MTU exceeded 
>>> cases can be handled cleanly  either by use of DF or by doing IP 
>>> fragmentation and then the reassembly at the end of the tunnel.  This 
>>> seems like a problem for all ICMP packets; how could a source 
>>> understand the header inside for a TTL expired, for instance.
>>
>>
> For LDP, there are mechanisms (layer violations though they are) to 
> handle exceptions generating ICMP packets.

The interesting question is who needs to know of the MTU problem?

If you tell the host, then by the time it adjusts it's MTU the
network will likely have reconverged anyway.

However if you tell repairing router (which is what will happen
with a tunnels packet), it can alarm and let the network
administrators know that there is problem with IPFRR config.

For this to work, the MTU at the edges needs to be lower than the
MTU in the core.

> 
>>> e.      For IP-in-IP tunnels, another concern is flow diversity.  The 
>>> IP source and destination addresses are used to determine a flow; 
>>> this flow identification may then be used for a variety of purposes, 
>>> including ECMP.  By putting all the traffic to a variety of 
>>> destinations inside the same header, the ability to take advantage of 
>>> flow diversity appears to have disappeared.   This could possibly be 
>>> solved by putting the original source address into the encapsulating 
>>> header?  Are there other approaches?
>>
>>
>> and this.
> 
> 

I was going to say:

Given that basic cuts in before NV, I think that the only case where
this is a problem is when you have a router with max ECMP = say 2 which
selects two from more than two, and the next hop on one of them fails.
This is surely a corner case?

Then Mike pointed out that we had said that we would use ECMP in the
draft, and yes there is a problem. Again we need to think about the
implications, because it's not clear what we should do.

- Stewart

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Apr 2005 11:00:28 -0400

Stefano,

If I understand correctly, you are suggesting that the advertising of the 
addresses could be a starting address (for the block) and then each 
neighbor sub-TLV could give an index within that block?  Of course, that 
introduces the constraint that the notvia addresses given by a particular 
router have to be contiguous - and brings up issues when the block size 
needs to increase.  It sounds a lot like the label distribution mechanism 
used in RFC 2547.

Another question (somewhat related) would be how to handle a neighbor 
connected by multiple parallel links.   Logically, one only needs a single 
notvia address for the neighbor - but one doesn't want the one used to be 
dependent on which of the parallel links came up first.  This argues that 
there may be multiple notvia addresses advertised for a particular neighbor 
- for the parallel links case.

Any extensions would want to handle this as well, I think.

Alia

At 05:49 AM 4/27/2005, stefano previdi wrote:
>>>that these would come out of a "private" address space, and hence 
>>>wouldn't consume real addresses. Indeed for security reasons it is 
>>>preferable that they are private addresses.
>>>

---

From: stefano previdi <[email-masked]>
Date: Wed, 27 Apr 2005 18:04:51 +0200

Alia,

On Apr 27, 2005, at 5:00 PM, Alia Atlas wrote:

> Stefano,
>
> If I understand correctly, you are suggesting that the advertising of 
> the addresses could be a starting address (for the block) and then 
> each neighbor sub-TLV could give an index within that block?

Not exactly. I was suggesting that each router will
advertise a kind of not-via summary address in addition
to the host part of it on its neighbor TLVs.

Example: Router X advertises 10.1.1/24 as the summary
not-via address and then, for each of its neighbor on its
LSP, router X will add following subTLVs:

	neighbor A, not-via-host-address: 1
	neighbor B, not-via-host-address: 5
	neighbor C, not-via-host-address: 20
	...

so, any other router in the area, when receiving router X
LSP, can derive that router X not-via addresses will be:

	Neighbor-A: 10.1.1.1/32
	Neighbor-B: 10.1.1.5/32
	Neighbor-C: 10.1.1.20/32

And nothing prevents router Y to advertise the _same_
summary but with different host addresses.

>  Of course, that introduces the constraint that the notvia addresses 
> given by a particular router have to be contiguous

I don't think so.

>  - and brings up issues when the block size needs to increase.  It 
> sounds a lot like the label distribution mechanism used in RFC 2547.

I still believe these addresses will likely be taken from
the private address space so the issue is more how to
reduce the effective information you advertise rather than
the address space you're going to use (10/8 will just work
fine).

> connected by multiple parallel links.   Logically, one only needs a 
> single notvia address for the neighbor - but one doesn't want the one 
> used to be dependent on which of the parallel links came up first.  
> This argues that there may be multiple notvia addresses advertised for 
> a particular neighbor - for the parallel links case.

in this case I believe the router will do ipfrr among ECMP
members so we need an address in case both link fails.

s.

>>>>> Second is the list of downsides with the approach.  The main 
>>>>> concern is that the mechanism becomes too complex such that the 
>>>>> trade-off between its complexity and the full coverage is not 
>>>>> desirable.
>>>> expected that these would come out of a "private" address space, 
>>>> and hence wouldn't consume real addresses. Indeed for security 
>>>> reasons it is preferable that they are private addresses.
>>>>
>>> adding a large number of addresses.  The other question is what is 
>>> the boundary when it becomes a serious concern.
>>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Apr 2005 13:55:25 -0400

>but then that's not going to surprise anyone :)

Simply shocking :-)

>or the inflation of the routing protocol message size.

Sure.  We need to understand clearly the potential issues causing the 
constraints.

>maybe use Naiming's LDP extension.

yes - maybe it's good enough?  It'd be good to get the multi-homed prefixes 
considered in the network topology & simulations so we can see.

>2) Tunnel the packet (using NV, PQ or whatever) and learn the label

In the general worst-case, doesn't scale.  How realistic that worst-case 
isn't as clear.

>3) Tunnel the packet and then strip all labels and do an IP lookup.

Not really an option - assuming we want to have things like pseudo-wires 
running under the LDP :-)

>in the base topology (such as n-hop u-turn).

Possible, but it does get uglier to compute.

Agree

>a) Run the directed LDP session

See above for my thoughts on the options.

>b) Give up

nope - too stubborn :-)

>time that was proposed in MPLS WG:)

sure, but we're seeing upstream label distribution being proposed again too :-)
It is true that anything else seems likely to require some change/addition 
to the MPLS semantics - and that would be more challenging to consider.

>Non-NV routers will be excluded from base. Could you expand?

Oh, this is just the more general worry of getting interoperability without 
very clear specification.  I've nothing specific here yet - just a 
background concern that it be thought about.

I do agree that excluding those routers that don't advertise the capability 
takes care of a large section of the issues.

>>>changed as a result of not "needing" the notvia address when the object 
>>>with which it is associated goes away. It should also get back the same 
>>>notvia address when it comes back. But I don't think there are any 
>>>particular issues associated with them disappearing and reappearing in 
>>>the LSPs.
>>>

What are you defining as controlled convergence?  Is this the wait until 
the network's done otherwise & then do the notvia addresses?  That'll work 
- but it's a bit different from the general controlled convergence for the 
primary topology.

>>>>SRLG protection.  It isn't clear to me how to compute a 
>>>>determined, computed and assigned?  This becomes much more of a concern 
>>>>for SRLG protection & for topologies where failures have already 
>>>>occurred and the network has converged for those & needs protection in 
>>>>the event of an additional failure.
>>>
>>>
>>The similar case can easily occur with link & node protection.  Say S has 
>>two parallel links to E; if the first fails, S could use the other to get 
>>link protection  - but there is no node-protecting alternate.  How does S 
>>determine this?  What is the fall-back strategy in the case that no 
>>"full-protection" alternate is available?
>
>In this case
>

Thanks.  This helps clarify the behavior when the link is pt-to-pt.

For the broadcast link case, I can see  greater difficulties - because it 
looks like a local SRLG  to a large extent.  Any thoughts there?

>You are correct that this all needs describing in detail.

That's what revisions are for :-)

>>>>line-cards, that detect the router failure at slightly different times 
>>>>and stop forwarding traffic, therefore, at slightly different times.
>>>
>>>
>>control planes may take varying amounts of time for the line-cards to all 
>>realize that the route controller is down.
>

This is a large part of what I see to be the problem with thinking of BFD 
as being a mechanism for detecting router failure.  Perhaps there are those 
with more BFD experience who can point out how it could work?

To my mind, either the BFD session is running on the line-card, in which 
case one can possibly imagine it being implemented in a scalable way such 
that packets are sent out at least every 5-10ms, such that a failure could 
be detected within 20ms & then repaired in the remaining 30ms, or the BFD 
session isn't running on the line-card, in which case generating packets 
every 5-10ms per interface reliably seems a bit of a stretch.

It seems to me to get the desired speed for failure detection that BFD 
would need to be done on the line-card & preferably in hardware.  This 
makes BFD good for detecting link failures, but not so much for detecting 
router failures.

As for the line-card being up, but the switch fabric down, I'd hope that 
the router internals would have a way of detecting that & bringing the 
line-card down when appropriate.  That's internal implementation anyhow.

BFD to neighbor's neighbor would at least validate the forwarding path all 
the way to that neighbor's neighbor - but it gives a larger number of BFD 
sessions & there is also the difficulty of interpreting the failure back to 
the affected routes.  For instance, what about the case where the 
downstream neighbor may (or may not?) ECMP to two of its neighbors.  If the 
BFD session to one of those goes down, does S do repair?

>The problem is that we rapidly get on a complexity spiral that

This is why I really do not like the idea of trying to do failure diagnosis 
via BFD.  I don't think it is realistic to believe that router failure can 
be identified as such by BFD within 20-30ms.

>types of failure that we will and will not deal with.

I don't think the issue here is the type of failure that is being handled - 
that is determined by the avoidance of the alternate.  The question here is 
the ability to diagnosis failure types on the fly.

>>all connected to a broadcast link X and want to compute a notvia X 

The more I think about it, the more comfortable I am - but as we've agreed, 
it needs clear description & thought about the differences & their 
implications.

>>>> concern for LDP for at least the inter-area, AS External, and BGP routes.
>>>>that traffic is destined to a prefix advertised by the node, how does 
>>>>the receiving node know to remove the encapsulation and forward the 
>>>>packet inside  all in the fast path?  Is this a just a question of 
>>>>different handling based on the header type inside the outer 
>>>>encapsulation (for GRE)?
>>>
>>>
>>>Yes.
>>

OK.  Thanks.  I'm (obviously) not that familiar with GRE.

>forwarding and the way that Mark Townsley proposed doing IP VPN?

Could you explain more?  I'm not sure what you're picturing the label being 
used for.

>The problem I have with this is the added complexity.

Yes, it would require additional computation & anytime you have two ways to 
do something, it gets more complicated.   On the other hand, a 
(potentially) full mesh of LDP sessions isn't simple either!

If the frequency of multi-homed prefixes that can't be protected via this 
is small - and the network design to gain protection isn't too complicated 
to understand, then it'd help.  For, say, the inter-area case, a typical 
cross-hatch connection probably works fine.

>>>>will no longer be advertised.  If S was getting link protection 
>>take that instead?  I.e., if the notvia address is 10.1.1.1 and there's a 

I think this is just a detail to be written down then.

>>>arrise even if the notvia FIB were recomputed before normal convergence 
>>>is complete. But I think it is better to delay the notvia FIB changes anyway.
>>
>>the path is directly to F, b/c node E no longer has SRLG R associated 
>>with any of E's up links.
>

??  No, I think this is the issue of whether the repair topology 
reconverges at the same time as the primary topology or it is delayed.  If 
it is at the same time, the problem above happens.  I think we're all 
agreed that delaying the repair topology convergence until the primary 
topology convergence is complete is the way to go.

>>>>encapsulation such as GRE, it doesn't seem like MTU exceeded cases can 
>>>>be handled cleanly  either by use of DF or by doing IP fragmentation 
>>>>and then the reassembly at the end of the tunnel.  This seems like a 
>>>>problem for all ICMP packets; how could a source understand the header 
>>>>inside for a TTL expired, for instance.
>>>
>>>

It depends on how long the network is taking to get off the 
alternates.   That could be 10s or so - so there's a chance the host will 
be able to adjust its MTU usefully.

>administrators know that there is problem with IPFRR config.

But why does the ICMP packet need to travel back to the repairing 
router?  Why couldn't the router which sees an MTU exceeded addressed to a 
notvia address let the network administrators know?

>For this to work, the MTU at the edges needs to be lower than the

Sure.  My  concern isn't so much for the MTU exceeded case as for the TTL 
expired case.  That's a common network debugging tool - and we'd want it to 
continue to work during repair.

>>>>IP source and destination addresses are used to determine a flow; this 
>>>>flow identification may then be used for a variety of purposes, 

If the paths for notvia addresses can be ECMP, then it becomes a 
concern.   Now, maybe it isn't necessary for those to be ECMP - or that 
likely.  But maybe it could be solved by pulling the real source IP address 
in the encapsulating packet header?

Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Apr 2005 16:52:58 -0400

Stefano,

At 12:04 PM 4/27/2005, stefano previdi wrote:
>>neighbor sub-TLV could give an index within that block?
>

OK.  This seems like it could be a useful way of reducing the actual bits 
advertised.  It does seem to me that it might be useful/desirable for a 
router to be able to advertise multiple summary addresses.

>the address space you're going to use (10/8 will just work

True, but needing to use 10/8 would dictate the effective information 
required.  The ability to use multiple summaries could be useful to reduce 
this further.

I guess a question is whether this is the point of concern with the 
additional quantity of notvia addresses, such that it deserves substantial 
optimization.

>>This argues that there may be multiple notvia addresses advertised for a 
>>particular neighbor - for the parallel links case.
>

I don't think so.  Consider that S is connected to E via a link & E is 
connected to F via two links.  Now, F will advertise at least one F_!E 
notvia address that S can use if its link to E fails (for traffic whose 
next-next-hop is F).  The question is how does F decide what address to use 
to mean F_!E.  It doesn't seem desirable (to me) to have the specific 
address used to vary - based on which link to E came up first or 
such.  Therefore, I'd assume that there could be multiple notvia addresses 
that mean F_!E.

Do you see a cleaner way to do this & still ensure consistent use of 
addresses through reboots, link state changes, etc?

Alia

---

From: stefano previdi <[email-masked]>
Date: Thu, 28 Apr 2005 14:54:46 +0200

On Apr 27, 2005, at 10:52 PM, Alia Atlas wrote:

>>> If I understand correctly, you are suggesting that the advertising 
>>> of the addresses could be a starting address (for the block) and 
>>> then each neighbor sub-TLV could give an index within that block?
>>
> OK.  This seems like it could be a useful way of reducing the actual 
> bits advertised.  It does seem to me that it might be useful/desirable 
> for a router to be able to advertise multiple summary addresses.

yes, but of course the idea being to reduce the amount
of data each router has to flood, advertising multiple
summary addresses may end up in limiting the gain...

> required.  The ability to use multiple summaries could be useful to 
> reduce this further.
>
> additional quantity of notvia addresses, such that it deserves 
> substantial optimization.

well, I believe that adding a few thousands of ip address
to the igp may not be a big concern for now but still it's
worth to have an optimized scheme.

>>> Another question (somewhat related) would be how to handle a 
>>> neighbor connected by multiple parallel links.   Logically, one only 
>>> needs a single notvia address for the neighbor - but one doesn't 
>>> want the one used to be dependent on which of the parallel links 
>>> came up first.
>>> This argues that there may be multiple notvia addresses advertised 
>>> for a particular neighbor - for the parallel links case.
>>
> notvia address that S can use if its link to E fails (for traffic 
> whose next-next-hop is F).  The question is how does F decide what 
> address to use to mean F_!E.  It doesn't seem desirable (to me) to 
> have the specific address used to vary - based on which link to E came 
> up first or such.  Therefore, I'd assume that there could be multiple 
> notvia addresses that mean F_!E.

I know a few implementations that do not advertise parallel
links between routers. So in your example E and F will just
advertise a single adjacency in between themselves (the one
with the lowest metric). So, the rest of the area will just
not know the existence of parallel links.

> addresses through reboots, link state changes, etc?

I originally thought that the concern we may have is on the
volume of the additional data the igp has to flood. So my
suggestion was a way to reduce the amount of data that each
router will have to advertise, but I wasn't thinking about
a dynamic/automatic way of assigning addresses.

Having said that, we have also to consider that each router
will have to collect and derive all this information from
its lsdb and store it somewhere for the purpose of the
not-via SPFs computations... but of course this is more an
implementation issue.

s.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 Apr 2005 09:43:53 -0400

>summary addresses may end up in limiting the gain...

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.

>worth to have an optimized scheme.

Sure.  It's just a question of how complicated is reasonable.

>>next-next-hop is F).  The question is how does F decide what address to 
>>use to mean F_!E.  It doesn't seem desirable (to me) to have the specific 
>>such.  Therefore, I'd assume that there could be multiple notvia 
>>addresses that mean F_!E.
>

I assume that you are thinking of ISIS & not OSPF?  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.

>a dynamic/automatic way of assigning addresses.

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.

Now, the exact mechanisms for ensuring that consistency don't need to be 
specified, but the implications of such mechanisms into the protocol 
extensions, such that the mechanisms are feasible do.  Thus, the 
possibility of using multiple notvia addresses per neighbor.

>not-via SPFs computations... but of course this is more an

Oh yes - and even more than just storing the info from the LSDB for the 
computation is the need to store the data for the incremental SPF 
topologies.  Actually, that one may be worth investigating a bit.  Mike & 
Stewart have said what the computation time is like using incremental SPFs 
to handle the notvia addresses.  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?

Alia

---

From: mike shand <[email-masked]>
Date: Thu, 28 Apr 2005 15:06:15 +0100

At 09:43 28/04/2005 -0400, Alia Atlas wrote:
>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 
>>>use to mean F_!E.  It doesn't seem desirable (to me) to have the 
>>>specific address used to vary - based on which link to E came up first 
>>>or such.  Therefore, I'd assume that there could be multiple notvia 

In the absence of SRLG then I don't think it matters because only the node 
local to the parallel link needs to know that it is actually parallel, and 
of course it does. However, in the SRLG case, it is certainly important if 
you have a paralell links which are members of different SRLGs. But I think 
to advertise the SRLG membership we would need to advertise both links 
anyway, which is what TE does (in IS-IS anyway).

>to handle the notvia addresses.  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?

Yes. You compute the "primary topology", which in its simplest form would 
just be the result of your normal SPF, but for interoperability reasons 
would probably be the normal topology minus any routers which can't do 
not-via. (this could be done as an incremental from the normal SPF topology 
if you like, but the gain is not going to be that great). Then for each 
"object" that you need to disable to compute its notvia addresses, you run 
an incremental from that primary topology. So, apart from some additional 
data structures  to allow you to run the incremental while preserving the 
primary topology for the next incremental, there is no additional memory 
requirement.

There is plenty of scope here for trading off memory against processing of 
course, but that is up to the individual implementation.

         Mike

---

From: stefano previdi <[email-masked]>
Date: Thu, 28 Apr 2005 19:19:51 +0200

On Apr 28, 2005, at 3:43 PM, Alia Atlas wrote:

>>> bits advertised.  It does seem to me that it might be 
>>> useful/desirable for a router to be able to advertise multiple 
>>> summary addresses.
>>
> 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.

>>> True, but needing to use 10/8 would dictate the effective 
>>> information required.  The ability to use multiple summaries could 
>>> be useful to reduce this further.
>>>
>>> I don't think so.  Consider that S is connected to E via a link & E 
>>> is connected to F via two links.  Now, F will advertise at least one 
>>> F_!E notvia address that S can use if its link to E fails (for 
>>> traffic whose next-next-hop is F).  The question is how does F 
>>> decide what address to use to mean F_!E.  It doesn't seem desirable 
>>> (to me) to have the specific address used to vary - based on which 
>>> link to E came up first or such.  Therefore, I'd assume that there 
>>> could be multiple notvia addresses that mean F_!E.
>>
> I assume that you are thinking of ISIS & not OSPF?

as far as I'm concerned... yes.

>  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...

> 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.

> Now, the exact mechanisms for ensuring that consistency don't need to 
> be specified, but the implications of such mechanisms into the 
> protocol extensions, such that the mechanisms are feasible do.  Thus, 
> the possibility of using multiple notvia addresses per neighbor.
>
> Oh yes - and even more than just storing the info from the LSDB for 
> the computation is the need to store the data for the incremental SPF 
> topologies.  Actually, that one may be worth investigating a bit.  
> Mike & Stewart have said what the computation time is like using 
> incremental SPFs to handle the notvia addresses.

yes...

>  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...

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

s.

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 Apr 2005 15:08:15 -0400

At 10:06 AM 4/28/2005, mike shand wrote:
>>with RSVP-TE.  For instance, the parallel links may not share any SRLGs 
>>in common - which can make for quite a difference.
>
>you have a paralell links which are members of different SRLGs. But I 
>think to advertise the SRLG membership we would need to advertise both 
>links anyway, which is what TE does (in IS-IS anyway).

I agree that it doesn't matter except in the SRLG cases.

>>Stewart have said what the computation time is like using incremental 
>>SPFs to handle the notvia addresses.  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?
>
>not-via. (this could be done as an incremental from the normal SPF 
>topology if you like, but the gain is not going to be that great). Then 
>for each "object" that you need to disable to compute its notvia 
>addresses, you run an incremental from that primary topology. So, apart 
>from some additional data structures  to allow you to run the incremental 
>while preserving the primary topology for the next incremental, there is 
>no additional memory requirement.
>

That's about what I expected and seems quite reasonable.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 Apr 2005 17:30:56 -0400

At 01:19 PM 4/28/2005, stefano previdi wrote:
>>10.1.8/24 - which saves 4 bytes per notvia address - but adds the bits 
>>for identifying the summary address intended.
>

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. :-)

>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.

>> 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.
>

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

>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.

>> 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?
>

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.

>rib/fib will make the difference in terms of scaling and

Isn't is always so?

Alia

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 Apr 2005 10:14:25 +0100

> 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.
> 

I think so. Whilst I think that we need a manual address assignment
mode, I am sure that we will also need a block assignment mode.
The config should then try hard to allocate the same address across
reboots, but I do not think that it needs to be perfect. Any tool
that needs to know which address was allocated to which interface
could look in the link state DB.

Stewart

---

From: Alia Atlas <[email-masked]>
Date: Fri, 29 Apr 2005 13:38:52 -0400

At 05:14 AM 4/29/2005, Stewart Bryant wrote:
>>just implementation differences as to how the router derives a particular 
>>notvia address to use per interface.
>

I am more concerned about the notvia addresses changing meaning as 
interfaces go up and down.  That would be an issue.  Tools are fine - but 
would all need to be augmented to do such understanding - and human 
operators may make assumptions - such as that the meaning/presence/use of 
an IP address doesn't dynamically change.

Alia

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 Apr 2005 22:30:36 +0100

Alia Atlas wrote:

> interfaces go up and down.  That would be an issue.  

I agree, we need to find a way to make them sticky.

Stewart

> Tools are fine - 
> but would all need to be augmented to do such understanding - and human 
> operators may make assumptions - such as that the meaning/presence/use 
> of an IP address doesn't dynamically change.
> 
> Alia
> 
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 29 Apr 2005 20:18:45 -0400

>I agree, we need to find a way to make them sticky.

I think that an aspect of this is that there can be multiple notvia 
addresses advertised by the same router to avoid the same resource.

Anyhow, I think we've got agreement here.  Want to pick the next issue to 
discuss? :-)

Alia