updates to draft-ietf-rtgwg-ipfrr-spec-base

After discussion with Stefano Previdi, Mike Shand, and Stewart Bryant, I
think that
we've agreed on the last couple outstanding details for the LFA draft.

Please send any comments on the draft or the below additions very soon,
since I'd
like to get the updated draft out very shortly (next week) so it'll be ready
for a last call.

So, to the changes between 07 & the upcoming 08

1) Changed back the MAY to a SHOULD NOT for setting the "local protection
available" flag
as a result of having LFAs.

    This had been changed to a MAY because having a bit indicate when a link
is protected by
    IPFRR is very useful for implementing Ordered FIB.  If the bit is set,
then the OFIB convergence
    can be used and otherwise not.  However, we concluded that the "local
protection available"
    flag that is currently defined should not be used for this purpose.  The
existing flag is used in
    the CSPF computation for RSVP-TE LSPs to determine what links have
bypass tunnels and
    ensure that the entire path does.  It is quite plausible that a network
will have both IPFRR and
    some non-zero number of RSVP-TE LSP that want to be protected with
RSVP-TE FRR.  Therefore,
    we concluded that a different additional "IP/LDP local protection
available" flag will be required.

    After some discussion, it was clear that there are a number of different
ways and reasons to
    decide when to set the new flag.  For instance, it could be set when
there is an LFA to the
    router at the end of the link, or to the link's far-end IP address, if
it is numbered.  Alternately,
    it could be set when a critical set of prefixes have LFAs or all
prefixes out that link/next-hop
    have LFAs.  The trade-offs and desired policy is really based upon OFIB
and not LFAs.  Because
    of this complexity and the desire not to tie the LFA draft to new ISIS &
OSPF drafts defining
    the new flag, we decided not to mention the new bit in the LFA draft.

    Instead, the OFIB draft will discuss the new flag and provide guidelines
on when it should be set.
    IPFRR is back to SHOULD NOT for setting the existing "local protection
available" flag.

2) From discussion, it's clear that there are implementations that use a
simplified approach that
doesn't give as good coverage, but may be easier to implement.  We wanted to
document this
and clarify the benefits and drawbacks of this.  Therefore, a new section (
3.6) is added with the
text below.   (The references to a Figure 4 and Section 6.1 are the same for
the 07 and 08 versions.)

"3.7.  A Simplification: Per-Next-Hop LFAs

   It is possible to simplify the computation and use of LFAs when
   solely link protection is desired by considering and computing only
   one link-protecting LFA for each next-hop connected to the router.
   All prefixes that use that next-hop as a primary will use the LFA
   computed for that next-hop as its LFA.

   Even a prefix with multiple primary next-hops will have each primary
   next-hop protected individually by the primary next-hop's associated
   LFA.  That associated LFA might or might not be another of the
   primary next-hops of the prefix.

   This simplification may reduce coverage in a network.  In addition to
   limiting protection for multi-homed prefixes (see Section 6.1), the
   computation per next-hop may also not find an LFA when one could be
   found for some of the prefixes that use that next-hop.

   For example, consider Figure 4 where S has 3 ECMP next-hops, E1, E2,
   and E3 to reach D. For the prefix D, E3 can give link protection for
   the next-hops E1 and E2; E1 and E2 can give link protection for the
   next-hops E3.  However, if one uses this simplification to compute
   LFAs for E1, E2 and E3 individually, there is no link-protecting LFA
   for E1.  E3 and E2 can protect each other.
"

Again, I would welcome any comments on these changes or anything else
in the draft.  I plan to submit an updated draft next week.

Thanks,
Alia