Subject: RE: [Isis-wg] Question on the usage of ISH and P2PIIH

From: Micah Bartell <[email-masked]>
Date: Wed, 13 Feb 2002 14:34:35 -0600

Alright....I went back and did a rehash of your doco and mine.  Integrated 
parts and made sure I got Dave's last comments addressed.

At this point 10589:2001 is not a formal IS, so I would rather just 
reference 10589:1992 and RFC 1195.

I would rather see a quick synopsis of what is required to be compliant 
than an explanation of the various implementations.  If you follow the BP 
for IIH and ISH handling, you will be compliant with all of the 
implementations.

I think the point here is to identify where the issue is, RFC 1195 section 
5.1 and 10589 Section 8.2.4.  Why it says what it does, when we do not need 
to strictly adhere, and in what manner we do not need to adhere.

/mpb

               IS-IS Adjacency Establishment in IP Only Environments
                      <draft-ietf-isis-ipadj-00.txt>

1. Status of this Document

    This document is an Internet-Draft and is in full conformance with all
    provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering Task
    Force (IETF), its areas, and its working groups. Note that other groups
    may also distribute working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsolete by other documents at any
    time. It is inappropriate to use Internet-Drafts as reference material
    or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

2. Abstract

    This document describes a modification to the IS-IS protocol in IP Only
    environments for adjacency establishment over Point to Point circuits.
    The IS-IS protocol is specified in [2], with extensions for supporting
    IPv4 specified in [1].

    This draft describes a modification to the IS-IS protocol, which will
    allow an IS-IS adjacency to be established over Point to Point circuits
    without the use of an Intermediate System Hello PDU (ISH).

3. Introduction

    The IS-IS protocol as defined in [2] was intended for use with the
    Connectionless Network Service (CLNS).  The extensible nature of IS-IS
    enabled IS-IS to be extended to provide multiprotocol support in an
    integrated routing protocol, Integrated IS-IS, as defined in [1].
    Integrated IS-IS now supports reachability information for CLNS, IPv4,
    and IPv6.

    The original intent of [1] was to provide a routing protocol capable
    of handling both CLNS and IPv4 reachability information.  The need to
    support CLNS reachability information required that an ISH be issued
    to detect End Systems (ES) and initiate the formation of an ES-IS
    adjacency.

    For this reason section 5.1 of [1] states:

    "On point-to-point links, the exchange of ISO 9542 ISHs (intermediate
    system Hellos) is used to initialize the link, and to allow each
    router to know if there is a router on the other end of the link,
    before IS-IS Hellos are exchanged.  All routers implementing IS-IS
    (whether IP-only, OSI-only, or dual), if they have any interfaces on
    point-to-point links, must therefore be able to transmit ISO 9542
    ISHs on their point-to-point links."

    Section 5.1 of [1] re-enforces the need to comply with section 8.2.4
    of [2].  This requirement was defined when the industry mindset was
    that of dual environments being the general case.  The general case
    has instead shifted to IP Only environments.

    In an IP Only environment, there is no need to issue an ISH PDU over a
    Point to Point circuit because there are no End Systems with which to
    form an ES-IS adjacency.  [2] requires that an ISH be received in order
    to issue an IIH PDU.

4. Best Common Practice

    An IP Only implementation has no need to issue an ISH PDU as described in
    section 8.2.4 of [2].  An IP Only implementation MAY issue an IIH PDU
    when a Point to Point circuit transitions into an "Up" state to
    initiate the formation of an IS-IS adjacency.  An IP Only implementation
    SHOULD accept an IIH to initialize an adjacency regardless of an ISH
    having been issued.  The IIH PDU SHOULD still be issued in conformance
    with section 8.2.4 of [2] with the exception of the requirement for
    reception of an ISH PDU.

    An implementation that supports the forwarding of CLNS PDU's MUST act in
    full accordance with section 8.2.4 of [2] when CLNS functionality is
    enabled, including the initial issuance of an ISH PDU.

5. Security Considerations

    This document raises no new security issues for IS-IS.

6. References

    [1] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual
    Environments" RFC 1195, December 1990

    [2] ISO, "Intermediate System to Intermediate System Intra-
    Domain Routeing Exchange Protocol for use in Conjunction with the
    Protocol for Providing the Connectionless-mode Network Service (ISO
    8473)", ISO/IEC 10589:1992

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Wed, 13 Feb 2002 16:14:23 -0500

At 03:34 PM 2/13/2002, Micah Bartell wrote:
>Alright....I went back and did a rehash of your doco and mine.  Integrated parts and made sure I got Dave's last comments addressed.
>
>At this point 10589:2001 is not a formal IS, so I would rather just reference 10589:1992 and RFC 1195.
>
>I would rather see a quick synopsis of what is required to be compliant than an explanation of the various implementations.  If you follow the BP for IIH and ISH handling, you will be compliant with all of the implementations.
>
>I think the point here is to identify where the issue is, RFC 1195 section 5.1 and 10589 Section 8.2.4.  Why it says what it does, when we do not need to strictly adhere, and in what manner we do not need to adhere.
>
>/mpb
>
>
>
>   of handling both CLNS and IPv4 reachability information.

>                                                             The need to

Not quite.  You don't send an ISH to detect an ES.  You send an ISH so
that the ES knows you're a router (if it is an ES) and the *ES* forms
an ES-IS adjacency.  I would revise this to say,

     To support the possibility of a CLNS ES attached on a PTP link,
     ISs are required to send ISH PDUs, and are not to send IIH PDUs
     before receiving an ISH from the peer.

>   of [2].

See note below about TC1.

>This requirement was defined when the industry mindset was

I don't think we need to talk about mindset, and there are members of
this list who consider dual environments very important.  All you need
is to begin the next sentence with "However,".

>   form an ES-IS adjacency.

>[2] requires that an ISH be received in order
>   to issue an IIH PDU.

This is inaccurate unless you specify [2] as including TC1.
10589:1992 says, in 8.2.3 (renumbered by TC1 as 8.2.4)

  The IIH PDU shall be sent when:  a) the circuit is first enabled.

It would be more accurate to say that [2] allows sending the IIH first, but
this was a mistake that was corrected in [3], and is now being allowed
again in certain circumstances.

[3] ISO, "Intermediate System to Intermediate System Intra-
   Domain Routeing Exchange Protocol for use in Conjunction with the
   Protocol for Providing the Connectionless-mode Network Service (ISO
   8473) Technical Corrigendum 1", ISO/IEC 10589:1992 TC1, May 1993.

Plus, you would need to change [2] in text below to [3].

>   enabled, including the initial issuance of an ISH PDU.

An implementation that supports CLNP should be allowed to send an IIH
after receiving one, but this is not permitted by [3].  After receiving
the IIH, we know that the neighbor is clearly an IS, so there is no
need to wait for an ESH or ISH.

I would say:

    An implementation that does not support attachments to CLNP End
    Systems via PTP links MAY send an IIH without waiting for an ISH,
    and MAY omit sending an ISH.

    An implementation that does support attachments to CLNP End
    Systems via PTP links MUST send an ISH when a PTP circuit is
    established, and MAY send an IIH after receiving an IIH on the
    link.

---

From: Micah Bartell <[email-masked]>
Date: Wed, 13 Feb 2002 17:20:04 -0600

Folks,

Alright, I think we are almost in agreement now....any further thoughts?  I 
took advantage of this draft to point out that 10589 does allow an IIH to 
be sent in response to an IIH even without an ISH, as it is a bit hidden in 
section 8.2.5.2 in the state tables.  I also made the point that if CLNS ES 
attachment is supported by the IS over p-t-p circuits, they must continue 
to conform to 8.2.3 ( 10589/TC1 ).

/mpb

2. Abstract

3. The History of the ISH

    The original intent of [1] was to provide a routing protocol capable
    of handling both CLNS and IPv4 reachability information.  To support
    the possibility of a CLNS ES attached on a point to point link, ISs
    are required to send ISH PDUs, and are not to send IIH PDUs before
    receiving an ISH from the peer.

    For this reason section 5.1 [1] states:

    Section 5.1 [1] re-enforces the need to comply with section 8.2.4
    [3].  However, in an IP Only environment, there is no need to issue
    an ISH PDU over a Point to Point circuit because there are no End
    Systems with which to form an ES-IS adjacency.

4. Best Common Practice

    An IP Only implementation has no need to issue an ISH PDU as described in
    section 8.2.4 of [3].  An IP Only implementation MAY issue an IIH PDU
    when a Point to Point circuit transitions into an "Up" state to initiate
    the formation of an IS-IS adjacency.  The IIH PDU SHOULD still be issued
    in conformance with section 8.2.4 [3] with the exception of the
    requirement for reception of an ISH PDU.  An IIH PDU MAY be issued in
    response to the receipt of an IIH PDU in accordance with section 
8.2.5.2 [3].

    A multiprotocol IS that supports the attachment of CLNS ESs over Point
    to Point circuits MUST act in accordance with section 8.2.2 [3] when
    CLNS functionality is enabled.

6. References