[email protected]
[Top] [All Lists]

Re: a few comments/questions on draft-bryant-shand-ipfrr-notvia-addresse

Subject: Re: a few comments/questions on draft-bryant-shand-ipfrr-notvia-addresses-03.txt
From: mike shand
Date: Tue, 14 Nov 2006 12:09:44 +0000
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
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

<Prev in Thread] Current Thread [Next in Thread>