Subject: BFD for Multi Topology IS-IS

From: "Pudiyapura, Ajeer" <[email-masked]>
Date: Fri, 10 Mar 2006 16:00:42 -0800

>From the Single-Hop draft (BFD for IPv4 and IPv6 (Single Hop)
draft-ietf-bfd-v4v6-1hop-04.txt) section 7.3:

   Therefore, when a BFD session transitions from Up to Down, action

   SHOULD be taken in the routing protocol to signal the lack of

   connectivity for the data protocol (IPv4 or IPv6) over which BFD is

   running.  If only one data protocol is being advertised in the

   routing protocol Hello, or if multiple protocols are being advertised

   but the protocols must share a common topology, a Hello protocol

   timeout SHOULD be emulated for the associated OSPF neighbors and/or

   IS-IS adjacencies.

   If multiple data protocols are advertised in the routing protocol

   Hello, and the routing protocol supports different topologies for

   each data protocol, the failing data protocol SHOULD no longer be

   advertised in Hello packets in order to signal a lack of connectivity

   for that protocol.

Talking from an MT-IS-IS context where both IPv4-unicast and
IPv6-unicast topologies are enabled (see second paragraph above) on the
link:

1. Why do we require IS-IS to convey the lack of connectivity to the
neighbor? Doesn't BFD on the neighboring router detect it as well (much
faster)?

2. Which field in the IIH is implied here? NLPID or MTID TLV?

3. Why do we need to modify these fields, which advertise the
configuration and capabilities supported on the link, when a neighbor
state changes?

4. Doesn't changing these fields in our Hello packet affect all
neighbors on the shared link?

5. Isn't it sufficient to just emulate receiving a Hello from the
neighbor without the corresponding NLPID and MTIDs, which would cause
only the failed protocol to re-route around the neighbor, without
affecting anything else?

Thanks

-Ajeer Pudiyapura

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================