Subject: interactions of draft-ietf-isis-link-attr with LFAs

From: "Alia Atlas" <[email-masked]>
Date: Wed, 22 Feb 2006 14:37:03 -0800

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
   [FRR]).

   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
similarly avoided.

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.

Thanks,
Alia

_______________________________________________
Rtgwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg