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

["Alia Atlas" <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/rtgwg