Subject: [Isis-wg] Protocols Supported TLV

From: "Ruth Civil" <[email-masked]>
Date: Wed, 18 Sep 2002 10:38:55 -0400

I would like to know what people think should be done with the
information received in the Protocols Supported TLV of an IIH, in the
way of compatibility checking.

I can think of 3 possibilities:

1. Nothing. 
E.g. If a neighbour sends you a Protocol Supported TLV indicating that
it only supports CLNP, and the receiving router is configured to only
support IP, you ignore the information in the PSupp TLV and bring up the
adjacency anyway.  (In which case, what was the point of sending the
PSupp TLV in the IIH in the first place ?)

2. You bring up the adjacency if there is an overlap. E.g, if the
neighbour advertises CLNP and IP in its PSupp TLV, but you support only
IP, you bring up the adjacency. If there is no overlap between the
supported protocols you don't bring up the adjacency.

3. You bring up the adjacency only if there is an exact match between
the protocols the neighbour advertises in its Psupp TLV and the
protocols you are configured to support, and don't bring it up
otherwise.

Any ideas/comments/opinions out there ?

Cheers,
	Ruth
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Wed, 18 Sep 2002 11:08:25 -0400

> way of compatibility checking.

Ruth -
	We hashed this out a few months ago when writing
http://ietf.org/internet-drafts/draft-ietf-isis-interoperable-01.txt

The document is still under revision, but this portion 
has settled down, and hasn't changed much recently.
The section from my current version is reproduced
below.  

One of the sticky points is what happens
with DIS election on a LAN - you can get into 
situations where not everyone can talk to the DIS,
or where you have dueling DISs.  It seems that 
discussion of this issue was left on the 
cutting room floor.  

Work on this draft is ongoing in sub mailing list of
this group.  Let me know if you'd like to help.  

- jeff parker
- axiowave networks

12. Non-homogeneous Protocol Networks

   RFC 1195 [2] assumes that every deployment of IS-IS routers will sup-
   port a homogeneous set of protocols. It anticipates OSI only, IP
   only, or dual OSI and IP routers. While it allows mixed areas with,
   for example, both pure IP and Dual IP and OSI routers, it allows only
   IP traffic in such domains, and OSI traffic only when pure OSI and
   Dual IP and OSI routers are present. Thus it provides only lowest
   common denominator routing.

   RFC 1195 [2] also requires the inclusion of the Protocol Supported
   TLV with code 129 in IIH and ISH PDUs and in LSP number Zero. IP
   capable routers MUST generate a Protocol Supported TLV, and MUST
   include the IP protocol as a supported protocol. A router that does
   not include the Protocols Supported TLV may be assumed to be a pure
   OSI router and can be interpreted as implicitly "advertising" support
   for the OSI protocol.

   The requirements of RFC 1195 [2] are ample if networks adhere to this
   restriction. However, the behavior of mixed networks that do not fol-
   low these guidelines is not well defined.

   The ITU-T requires that SONET/SDH equipment running the IS-IS proto-
   col must not form an adjacency with a neighbour unless they share at
   least one network layer protocol in common. Unless this feature is
   present in every IS in the SONET or SDH DCN network the network may
   not function correctly. Implementors MAY include this feature if they
   wish to ensure interoperability with SONET and SDH DCN networks.

   Definition of an interoperable strategy for resolving the problems
   that arise in non-homogeneous protocol remains incomplete. Members of
   the ITU are actively working on a proposal: see "Architecture and
   Specification of Data Communication Network", [9].