Subject: a few comments/questions on draft-bryant-shand-ipfrr-notvia-addresses-03.txt

From: "Alia Atlas" <[email-masked]>
Date: Sun, 5 Nov 2006 23:39:14 -0800

I have a few comments and a question on the draft.

1) In Section 4.3, the draft says:

"It may be that the cost of reaching X using local delivery from
   the alternate router is greater than the cost of reaching X via
   P. Under those circumstances, the alternate router would normally
   forward to X via P, which would cause the IPFRR repair to loop.
   To prevent the repair from looping the alternate router must
   locally deliver a packet received via a repair encapsulation.
   This may be specified by using a special address with the above
   semantics. Note that only one such address is required per node."

Could I suggest modifying the first sentence to be "...from the
alternate router (i.e.  Z)..." to clarify that this is a concern
for avoiding loops for both?  Otherwise, b/c of the previous
paragraph, it sounds like this applies to only Y and not to Z...

Am I correct that you mean this to apply to Z and not Y?  If it were Y,
the address used is a not-via address - which would imply that all
not-via addresses would require local delivery.

Could you better define local delivery in the draft?  Is this a
requirement for an additional, separate forwarding table that is
populated only by prefixes advertised by the router and which is
entered into on decapsulation based upon the outer address?

2)    The semantics of the not-via address Ps changes from simply "P
   not-via the link S-P" to be "P not-via the link S-P or any other link
   with which S-P shares an SRLG"

>From all earlier discussion, Ps means "P not-via the node S" and not
"P not-via the link S-P".  If S is sending the packet encapsulated to
Ps, then this avoids it coming back to S, but it could still go
through a broadcast link connecting P,S and another node X.

3)  In Section 7, the draft suggests a router signal if it has an
LFA-protected link.  However. that is derived info that is dependent
upon (potentially) the entire LSDB.  The idea of the optimization is
appealing, but have you thought about the ramifications of advertising
this derived information?  What happens if the info is old?  What
about issues from many routers reissuing their LSA/LSP on a single
topology change?

4)  The discussion of interactions with LANs is quite good and clear.
It would be nice if the draft specifically stated the behavior to use
- or at the very least specified in a clear section which not-via addresses a
router should advertise and what elements should be pruned for each
such case.

5)  In the next version, a discussion of the routing extensions
required would be very useful.

Alia

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

---

From: mike shand <[email-masked]>
Date: Tue, 14 Nov 2006 12:09:44 +0000

Alia,
         Responses in line below.

>not-via addresses would require local delivery.

You may need this for both Z and Y. In the case of Z, S encaps the 
packet to Z'.
In the case of Y, S first encaps the packet to Bp, then B decaps it 
and re-encaps it to Y'.

So perhaps the first sentence should read

"...from the alternate router (i.e. Z or Y)..."

>entered into on decapsulation based upon the outer address?

What is required is that in the (somewhat unusual) case where the 
cost of delivery to the "local" X is greater than the cost to the X 
attached to P,
we ensure that the packet is sent to the local X, and not back to P 
(which would cause a loop).

We originally thought that we could trigger this simply on the fact 
that the packet had arrived in a tunnel, but this seems somewhat too 
global, and so we
proposed a special address to indicate this. It could equally well be 
indicated by some key information in the GRE header or some such. I 
don't really care what the exact mechanism is, and if one way is easy 
than another, we should choose the easiest.

But yes, the requirement is that for a packet arriving so flagged, it 
should be forwarded via a "special" forwarding table. Note that in 
most cases, of course, the content of this would be identical to the 
normal forwarding. I imagine it will be a rare occurrence for the 
cost actually to be greater, but we need to deal with that case to 
avoid the loop.

>through a broadcast link connecting P,S and another node X.

Yes. The SRLG section was developed from link protection, in which 
case the statement would be correct, but since we prefer node 
protection for the normal case (using the node protecting not-via 
address to provide "link" repair for the case where the node is a 
single point of failure), then those semantics should be used throughout.

The combination of SRLG with broadcast links needs some careful 
thought to determine exactly what properties it should have. Not-via 
is flexible enough to give almost any properties we want, but we need 
to decide on ONE such set.

>about issues from many routers reissuing their LSA/LSP on a single

Yes. It is arguable whether the advantages of the optimization 
outweigh the potential extra churn, etc.
While in some topologies the gain can be substantial, on average it 
probably only gives a reduction by a factor of 2 or 3.
Clearly there are "pathological" topologies (large rings etc.) where 
it gives no gain at all, and others (fully meshed) where the 
effective "gain" is infinite.

On the subject of stale information. If you have already run your 
not-via computation when some new protection information arrives, 
then if you had already done the computation for this, and the new 
information said you didn't need to, then you just wasted some time, 
but no harm done. If you had previously omitted something on the 
basis of the existing information, and the new information implies 
you need to include it, then you would have to re-run that part of 
the not-via computation.

>router should advertise and what elements should be pruned for each

Yes. I would really like to make a decision as to what level of 
complexity is appropriate for LAN repair. Any opinions from the WG 
would be useful in this context.

>required would be very useful.

Yes.

>Alia

Thanks very much for a useful set of comments.

         Mike