|Subject:||updates to draft-ietf-rtgwg-ipfrr-spec-base|
|Date:||Fri, 27 Jul 2007 12:28:29 -0400|
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.
_______________________________________________ rtgwg mailing list [email protected] https://www1.ietf.org/mailman/listinfo/rtgwg
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Draft rtgwg minutes for July 24, 2007 meeting, John G. Scudder|
|Previous by Thread:||Draft rtgwg minutes for July 24, 2007 meeting, John G. Scudder|
|Indexes:||[Date] [Thread] [Top] [All Lists]|