The draft-ietf-isis-link-attr defines a couple flags whose
interactions with loop-free alternates should probably be described.
The relevant text is:
"Local Protection Available (0x01). When set, this indicates that the
link is protected by means of some local protection mechanism (e.g
Link excluded from local protection path (0x02). When set, this link
SHOULD not be included in any computation of a repair path by any
other router in the routing area. The triggers for setting up this
bit are out of the scope of this document.
Such link characteristics has several applications such as
constrained shortest path computation for a Traffic Engineering Label
Switched (TE LSP) path or the triggering of specific actions in the
context of IS-IS SPF computation.
Local maintenance required (0x04). When set, this indicates that the
link will be put out of service and will consequently be shortly
unavailable. The set of actions triggered by other nodes is out of
the scope of this document. An example of the usage of this bit is
provided in [GR-SHUT]. "
The LFA draft currently discusses not using as an alternate next-hop
links which have a maximum cost (or reverse cost). I am proposing
that alternate next-hop links that have either the "link excluded from
local protection path" or the "local maintenance required" should be
I would like opinions on what the appropriate behavior is in
relationship to the "local protection available" flag. This depends
both on how the flag might be used and the complexity of
determining with LFAs that a link is fully protected. I believe the
original intent of the flag is really for use with RSVP-TE bypass
tunnels, so that a head-end can more easily plan a path that will be
fully link-protected. I would propose that the existence of IPFRR
alternates should not cause this flag to be set.
Please send all opinions. I'd like to respin the draft with this
clarified before the next IETF.
Rtgwg mailing list