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

[mike shand <[e-mail]>]

Alia,
         Responses in line below.

At 07:39 06/11/2006, Alia Atlas wrote:
>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.

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


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

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.





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

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.



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

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.



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

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.


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

Yes.


>Alia


Thanks very much for a useful set of comments.

         Mike



>_______________________________________________
>rtgwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/rtgwg

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