Subject: new drafts ...

From: Antoni Przygienda <[email-masked]>
Date: Sat, 21 Nov 1998 23:13:33 -0500

here go 3 things that got pushed out to internet-drafts. They may be
coming 
out after this IETF as well as the HMAC. However, FYI and hopefully we
can arrange
for slots
in the meetings to have a chat about those. Co-author lists may change
;-) 

1. snp, hello checksums 
2. 255+ adjacencies
3. ISIS in IP first proposal (please some comments on the ether encaps,
	seems 
        pretty heavy, on the other hand aligns well with the LLC/SNAP
world,
	it's 
        probably the first routed LLC frame encapsed in bridged LLC in
the
	world,
        actually ;-). As well, some people may see interoperability
issues
	right 
        away with the stuff. The general intention is to interoperate
with OSI 
        gear but to make IP encaps preference ...

                thanks 

                --- tony

Internet Engineering Task Force                            T. Przygienda
INTERNET DRAFT                                                 Bell Labs
                                                              1 Nov 1998

                       Optional Checksums in ISIS
                <draft-ietf-isis-wg-snp-checksum-00.txt>

Status of This Memo
   This document is an Internet Draft, and can be found as
   draft-ietf-isis-wg-snp-checksum-00.txt in any standard internet
   drafts repository.  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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''
   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Abstract
   This draft describes an optional extension to IS-IS [ISO90, Cal90a,
   Cal90b], used today by several ISPs for routing within their clouds.
   IS-IS is an interior gateway routing protocol developed originally
   by OSI and used with IP extensions as IGP. IS-IS originally doesn't
   provide CSNP adn PSNP checksums, relying on the underlying layers
   to verify the integrity of information provided.  Experience with
   the protocol shows that this precondition does not always hold and
   scenarios can be imagined that impact protocol functionality.  This
   document introduces a new optional TLV providing checksums.

1. Introduction
   IS-IS CSNPs and PSNPs and IIHs can be corrupted in case of faulty
   implementations of L2 hardware or lack of checksuming on a specific

   network technology.  As a particularly ugly case, corruption of

Przygienda et al.              Expires 1 May 1999               [Page 1]
^L
Internet Draft                 SNP Checksums                  1 Nov 1998

   length and/or TLV length fields may lead to generation of extensive
   numbers of "empty" LSPs in the receiving node.  Since we cannot rely
   on authentication as checksum mechanism, this document proposes an
   optional TLV to add checksums to the elements.

2. TLV Description
   The optional TLV MAY BE included in all CSNP, PSNP and IIH packets
   and an implementation that implements optional checksums MUST accept
   PDUs if they do NOT contain the optional checksum.  Implementations
   that receive optional checksum TLV and support it MUST discard the
   PDU if the checksum is incorrect.  An implementation that does NOT
   implement optional checksums MAY accept a PDU that contains the
   checksum TLV. An implementation that supports optional checksums and
   receives it within any other PDU than CSNP, PSNP or IIH MUST discard
   the PDU. Such an implementation MAY discard the PDU as well if more
   than one optional checksum TLVs are included within it.

3. Checksum Computation
   The checksum is a fletcher checksum computed according to iso 8473
   Annex C over the complete PDU.

4. Interaction with TLVs using PDU Data to Compute Signatures
   Since other TLVs could be introduced that use PDU data as input
   to a function that generates output to be included in the PDU,
   authentication being a straight-forward example thereof, it is
   important to specify the sequence at which the computation of
   different signatures takes place.  An implementation that implements
   optional checksums must generate the TLV and fill the TLV Checksum
   part with 0's.  After all other signatures have been computed, the
   checksum MUST BE filled in after all other signatures have been
   generated.  The implementation MAY choose to omit the optional
   checksum if it is aware that other signatures are included in the PDU
   that provide equivalent functionality.

5. TLV Format
                 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8
                +-----------------+-----------------+
                | TLV Type = 12   |  TLV Length     |
                +-----------------+-----------------+

Przygienda et al.              Expires 1 May 1999               [Page 2]
^L
Internet Draft                 SNP Checksums                  1 Nov 1998

                |   TLV Checksum (32 bits)          |
                |                                   |
                +-----------------------------------+

6. Acknowledgments
   Tony Li mentioned the original problem.  Somehow related problems
   with purging on LSP checksum errors have been observed by others
   before.

7. Security Consideration
   ISIS security applies to the work presented.  No specific security
   issues as to the new element are known.

References
   [Cal90a] R. Callon.  OSI ISIS Intradomain Routing Protocol.
            INTERNET-RFC, Internet Engineering Task Force, February
            1990.

   [Cal90b] R. Callon.  Use of OSI ISIS for Routing in TCP/IP and Dual
            Environments.  INTERNET-RFC, Internet Engineering Task
            Force, December 1990.

   [ISO90]  ISO.  Information Technology - Telecommunications and
            Information Exchange between Systems - Intermediate System
            to Intermediate System Routing Exchange Protocol for
            Use in Conjunction with the Protocol for Providing the
            Connectionless-Mode Network Service.  ISO, 1990.

Authors' Addresses

Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
[email-masked]

Przygienda et al.              Expires 1 May 1999               [Page 3]

Internet Engineering Task Force                            T. Przygienda
INTERNET DRAFT                                                 Bell Labs
                                                              1 Nov 1998

             Maintaining more than 255 adjacencies in IS-IS
                   <draft-ietf-isis-wg-255adj-00.txt>

Status of This Memo
   This document is an Internet Draft, and can be found as
   draft-ietf-isis-wg-255adj-00.txt in any standard internet drafts
   repository.  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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''
   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Abstract
   This draft describes an optional implementation technique within
   IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing
   within their clouds.  IS-IS is an interior gateway routing protocol
   developed originally by OSI and used with IP extensions as IGP.
   This draft describes how to effectively bypass the problem of 255
   circuits that IS-IS allows to maintain with minor violations of the
   specification that however does not prevent interoperability with
   existing implementations.

1. Introduction
   IS-IS reserves within its packets only one byte for a circuit ID
   and the specification requests it to be unique.  This ID is used in
   broadcast networks to identify a PNode.  They don't seem to serve any

Przygienda et al.              Expires 1 May 1999               [Page 1]
^L
Internet Draft           255+ Adjacencies in IS-IS            1 Nov 1998

   particular purpose on p2p networks except for some checking in hellos
   and tie-breaking in removal of excess adjacencies.

2. More than 255 adjacencies on p2p links
   For all p2p links within an Intermediate System, the same circuit ID
   can be chosen safely to interact with other Intermediate Systems.
   Even when two such systems are brought up on two ends of the link
   and both pick the same value, IS-IS specification does not preclude
   such a configuration.  In case of multiple parallel links between the
   systems the only obvious problem is the impact on tie-breaking in
   case of excessive adjacencies.  However, such a configuration cannot
   generate forwarding loops.

3. More than 255 adjacencies on broadcast links
   More trickier a case is the one in which an intermediate system has
   to form adjacencies on a broadcast medium.  The decisive insight
   is the fact that unique circuit ID on a broadcast medium is only
   needed in the case where the given intermediate system is assuming
   the role of the DIS for the LAN. As long as the intermediate system
   has not elected itself DIS, it can use a non-unique circuit ID (1).
   Therefore, it is enough to change circuit ID in all the packets
   transmitted to a unique one as soon as DIS election ran and the
   system must become DIS. Such behavior is basically indistinguishable
   from a node crashing and coming immediately back with a different
   circuit ID than the one used before the crash.  Implementation
   experience shows that it is unwise to tear down the adjacencies
   before changing circuit IDs since this can lead to ``ripple''-down
   behavior in DIS property on the broadcast media in case of all
   routers having the same preference.

3.1. Modification of the Behavior on Broadcast Media
   The exact modification of the behavior for broadcast links is
   given here.  It is a modification of chapter 8.4.5 of the original
   specification that states:

___________________________________________
1. it is important to realize that circuit ID is not a part of
   tie-breaking rules on DIS election

Przygienda et al.              Expires 1 May 1999               [Page 2]
^L
Internet Draft           255+ Adjacencies in IS-IS            1 Nov 1998

   When the broadcast circuit is enabled on an Intermediate system the
   IS shall perform the following actions.

    a) Commence sending IIH PDUs with the LAN ID field set to the
       concatenation of its own SystemID and its locally assigned one
       octet Local Circuit ID.

    b) ...  <omitted for clarity>

    c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and
       acquire adjacencies as appropriate.  Do not run the Designated
       Intermediate System election process.

    d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and/or
       the Level 2 Designated Intermediate System election process,
       depending on the Intermediate system type.  This shall be run
       subsequently whenever an IIH PDU is received or transmitted as
       described in 8.4.3.  (For these purposes, the transmission of the
       system's own IIH PDU is equivalent to receiving it).  If there
       has been no change to the information on which the election is
       performed since the last time it was run, the previous result can
       be assumed.  The relevant information is

        1) the set of Intermediate system adjacency states,

        2) the set of Intermediate System priorities (including this
           system's) and

        3) the existence (or otherwise) of at least one "Up" End system
           (not including Manual Adjacencies) or Intermediate system
           adjacency on the circuit.

   An Intermediate system shall not declare itself to be a LAN
   Designated Intermediate system of any type until it has at least one
   "Up" End system (not including Manual Adjacencies) or Intermediate
   system adjacency on the circuit.  (This prevents an Intermediate
   System which has a defective receiver and is incapable of receiving
   any PDUs from erroneously electing itself LAN Designated Intermediate
   System.)  The LAN ID field in the LAN IIH PDUs transmitted by this
   system shall be set to the value of the LAN ID reported in the LAN
   IIH PDU (for the appropriate level) received from the system which
   this system considers to be the Designated Intermediate System.  This
   value shall also be passed to the Update Process, as the pseudonode

Przygienda et al.              Expires 1 May 1999               [Page 3]
^L
Internet Draft           255+ Adjacencies in IS-IS            1 Nov 1998

   ID, to enable Link State PDUs to be issued for this system claiming
   connectivity to the pseudonode.  If this system, as a result of the
   Designated Intermediate System election process, considers itself to
   be designated Intermediate System, the LAN ID field shall be set to
   the concatenation of this system's own ID and the locally assigned
   one octet Local Circuit ID.

   One additional point has to be introduced:

    a) Commence sending IIH PDUs with the LAN ID field set to the
       concatenation of its own SystemID and a local non-zero, not
       necessarily unique circuit ID.

    b) ...  <omitted for clarity>

    c) Start listening for ISO 9542 ISH PDUs and ESH PDUs and
       acquire adjacencies as appropriate.  Do not run the Designated
       Intermediate System election process.

    d) After waiting ISISHelloTimer * 2 seconds, run the Level 1 and
       or the Level 2 Designated Intermediate System election process
       depending on the Intermediate system type.  If in any point in
       time the decision process determines the node to be DIS for this
       LAN:

        1) Commence sending IIH PDUs with the LAN ID field set to the
           concatenation of its own SystemID and a local unique circuit
           ID.

        2) go to step b.

       otherwise exhibit standard behavior.

4. Acknowledgments
   Some smart people probably thought about most of these things before
   and the p2p case may be documented in the best current practices for
   IS-IS in the Internet.

5. Security Consideration
   ISIS security applies to the work presented.  No specific security
   issues with the proposed solutions are known.

Przygienda et al.              Expires 1 May 1999               [Page 4]
^L
Internet Draft           255+ Adjacencies in IS-IS            1 Nov 1998

6. Intellectual Property Considerations

   Lucent may seek patent or other intellectual property protection
   for some or all of the technologies disclosed in this document.  If
   any standards arising from this document are or become protected
   by one or more patents assigned to Lucent, Lucent intends to
   disclose those patents and license them under openly specified and
   non-discriminatory terms.

References

   [Cal90a] R. Callon.  OSI ISIS Intradomain Routing Protocol.
            INTERNET-RFC, Internet Engineering Task Force, February
            1990.

   [Cal90b] R. Callon.  Use of OSI ISIS for Routing in TCP/IP and Dual
            Environments.  INTERNET-RFC, Internet Engineering Task
            Force, December 1990.

   [ISO90]  ISO.  Information Technology - Telecommunications and
            Information Exchange between Systems - Intermediate System
            to Intermediate System Routing Exchange Protocol for
            Use in Conjunction with the Protocol for Providing the
            Connectionless-Mode Network Service.  ISO, 1990.

Authors' Addresses

Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
[email-masked]

Przygienda et al.              Expires 1 May 1999               [Page 5]

Internet Engineering Task Force       A. Bansal, T. Przygienda, A. Patel
INTERNET DRAFT                                    Fore, Bell Labs/Lucent
                                                              1 Nov 1998

                            IS-IS over IPv4
                  <draft-ietf-isis-wg-over-ip-00.txt>

Status of This Memo
   This document is an Internet Draft, and can be found as
   draft-ietf-isis-wg-over-ip-00.txt in any standard internet drafts
   repository.  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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''
   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Abstract
   This draft describes an optional implementation technique within
   IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing
   within their clouds.  IS-IS is an interior gateway routing protocol
   developed originally by OSI and used with IP extensions as IGP. This
   draft describes how to encapsulate IS-IS packets in IPv4 [Pos81]
   format.  Such an encapsulation has many advantages, one of those
   being the possibility to run integrated IS-IS on anything that
   understands IPv4, including avian carriers [Wai90].

1. Introduction
   Encapsulation of IS-IS as defined in ISO 10589 [ISO90, Cal90a,
   Cal90b] uses directly over Link Layer protocols as opposed to IP
   routing protocols [Moy97] that are encapsulated over IP directly.

   By defining an encapulsation of IS-IS in IP, we save on special OSI

Bansal et al.                Expires 1 May 1999                 [Page 1]

Internet Draft                IS-IS over IPv4                 1 Nov 1998

   encapsulation on several media types.  Such an encapsulation would
   solve fragmentation problems of large LSPs and remove the necessity
   for OSI PPP extensions [Kat92] when IS-IS is run over negotiated
   PPP links.  Additionally, on certain media, such as p2p ATM links,
   no LLC/SNAP encapsulation is necessary to provide multi-protocol
   routing, allowing for gains in efficiency.

2. Encapsulation of IS-IS and ISO 9542 packets over IP
   IS-IS is encapsulated directly over the Internet Protocol's
   network layer.  IS-IS packets are therefore encapsulated by IP
   and local data-link headers.  Within this encapsulation, IS-IS
   packets are propagated as usual, however without the appropriate
   link-layer fields on point-to-point links and with a special internal
   encapsulation described in section 3 on broadcast media.

   IS-IS does not normally define a way to fragment its protocol
   packets, and depends on IP fragmentation when transmitting packets
   larger than the network MTU. If necessary, the length of IS-IS
   packets over IP can be up to 65,535 bytes (including the IP
   header).  The IS-IS packet types that are likely to be large (LSPs,
   CSNPs, PSNPs) can usually be split into several separate protocol
   packets, without loss of functionality.  This is recommended; IP
   fragmentation should be avoided whenever possible.  Using this
   reasoning, an attempt should be made to limit the sizes of IS-IS over
   IP packets sent over links to 1472 bytes including all media specific
   encapsulation unless Path MTU Discovery is being performed [MD90] or
   the router configuration allows for larger PDU sizes.
   The other important features of IS-IS in IP's IP encapsulation are:

    -  Use of IP multicast.  Some IS-IS in IP messages are multicast,
       when sent over broadcast networks.  Three distinct IP multicast
       addresses are used.  Packets sent to these multicast addresses
       should never be forwarded; they are meant to travel a single hop
       only.  To ensure that these packets will not travel multiple
       hops, their IP TTL must be set to 1.

          IPAllL1ISs

             OSI multicast value of this address was O1-80-C2-00-00-14.
             This multicast address has been assigned the IP address
             value 224.0.0.?  for IP encapsulated IS-IS. All routers
             running L1 IS-IS in IP should be prepared to receive
             packets sent to this address.  Hello packets are always

Bansal et al.                Expires 1 May 1999                 [Page 2]

Internet Draft                IS-IS over IPv4                 1 Nov 1998

             sent to this destination.  Also, certain IS-IS in IP
             protocol packets are sent to this address during the
             flooding procedure.

          IPAllL2ISs

             OSI multicast value of this address was O1-80-C2-00-00-15.
             This multicast address has been assigned the IP address
             value 224.0.0.?  for IP encapsulated IS-IS. All routers
             running L2 IS-IS in IP should be prepared to receive
             packets sent to this address.  Hello packets are always
             sent to this destination.  Also, certain IS-IS in IP
             protocol packets are sent to this address during the
             flooding procedure.

          IPAllIntermediateSystems

             OSI multicast value of this address was 09-00-2B-0O-00-05.
             This multicast address has been assigned the IP address
             value 224.0.0.?  for IP encapsulated IS-IS. All routers
             running IS-IS in IP should be prepared to receive packets
             sent to this address.  ISO 9542 is using this address.

    -  IS-IS in IP is IP protocol number ??.  This number has been
       requested with the Network Information Center.  IP protocol
       number assignments are documented in [RP94].

       Note:  For development purposes, IP Protocol number 9 (Private
       IGP protocol number) [RP94] will be used until an official number
       is granted.

    -  All IS-IS in IP routing protocol packets are sent using the
       normal service TOS value of binary 0000 defined in [Alm92].

    -  Routing protocol packets are sent with IP precedence set to
       Internetwork Control.  IS-IS in IP protocol packets should be
       given precedence over regular IP data traffic, in both sending
       and receiving.  Setting the IP precedence field in the IP
       header to Internetwork Control [Pos81] may help implement this
       objective.

Bansal et al.                Expires 1 May 1999                 [Page 3]

Internet Draft                IS-IS over IPv4                 1 Nov 1998

3. Internal Encapsulation

   On point-to-point links no MAC addresses are used by IS-IS. Therefore
   the Intradomain Routeing Protocol Discriminator or ISO 9542 Network
   Layer Protocol Identifier starts directly after the IP header.  For
   P2P link running over PPP, the Payload format will consist of PPP
   header, followed by the IP header and NLPID as indicated in the
   following figure:

       +------------+-----------+----------------+
       | PPP Header | IP Header | NLPID|ISIS PDU |
       +------------+-----------+----------------+

   For P2P ATM links using VC muxing, the payload format will not have
   to include a PPP header:

       +-------------+-----------+-----------------+
       | AAL5 Header | IP Header | NLPID|ISIS  PDU |
       +-------------+-----------+-----------------+

   In the case of broadcast media, MAC addresses are used for adjacency
   maintainance.  It would be rather painful to assume that an IS-IS
   implementation can have access to MAC headers, therefore when sending
   IS-IS encapsulated on broadcast networks an encapsulation header
   preeceds the Intradomain Routeing Protocol Discriminator.  It is
   essentially an LLC/SNAP [Hei93] encapsulation indicating bridged
   traffic with a contained routed OSI frame.  From the possible
   PIDs the one must be used that omits the LAN FCS since the IP
   PDU is already checksummed.  The following figure illustrates the
   encapsulation for 802.3 type PDUs.

Payload Format for Bridged Ethernet/802.3 PDUs

               +-------------------------------+
               |       LLC  0xAA-AA-03         |
               +-------------------------------+
               |        OUI 0x00-80-C2         |
               +-------------------------------+
               |         PID 0x00-07           |

Bansal et al.                Expires 1 May 1999                 [Page 4]

Internet Draft                IS-IS over IPv4                 1 Nov 1998

               +-------------------------------+
               |         PAD 0x00-00           |
               +-------------------------------+
               |    MAC destination address    |
               +-------------------------------+
               |    MAC source address         |
               +-------------------------------+
               |           Length              |
               +-------------------------------+
               |         LLC DSAP 0xFE         |
               +-------------------------------+
               |         LLC SSAP 0xFE         |
               +-------------------------------+
               |         LLC CNTL 0x03         |
               +-------------------------------+
               |             NLPI              |
               +-------------------------------+
               |                               |
               |   (remainder of ISO frame)    |
               |                               |
               +-------------------------------+

4. Interoperability with Devices without IP Encapsulation
   Normally, an interface will be configured to operate in either
   ISO or IS-IS in IP mode, for migration and interoperability with
   unknown/older devices a clear migration path is however preferable,
   as is controlled behavior in cases of misconfiguration.  To allow for
   operation in both modes, the following procedures are proposed in
   case an interface is configured to operate in both modes.

    -  in INIT all IS-IS and 9542 PDUs are sent and received in both
       encapsulations.

    -  in case any IP encapsulated frame has been received at any point
       in time on the interface, only IP encapsulated PDUs are sent and
       received on the interface.  No standard PDUs are received until
       the interface falls back into INIT.

    -  in case any traditionally encapsulated frame has been received
       in INIT, the interface starts to send traditionally encapsulated
       frames only with the exception that every 10th IIH is sent both
       in traditional as well as in IP encapsulation.  The interface

Bansal et al.                Expires 1 May 1999                 [Page 5]

Internet Draft                IS-IS over IPv4                 1 Nov 1998

       continues to receive both, the traditionally encapsulated frames
       as well as listen to IP encapsulated frames.  This ensures that
       the routers will try to ``climb up'' to IP encapsulation as the
       prefered mode of operation as soon as possible.

5. Acknowledgments
   The encapsulation description part has been "borrowed" from a
   well-known RFC [Moy97] with the author's consent.

6. Security Consideration
   ISIS security applies to the work presented.  No specific security
   issues with the proposed solutions are known.  Things like IPSec may
   influence the work in strange and unknown ways ;-)

References
   [Alm92]  P. Almquist.  Type of Service in the Internet Protocol
            Suite.  INTERNET-RFC, Internet Engineering Task Force, July
            1992.

   [Cal90a] R. Callon.  OSI ISIS Intradomain Routing Protocol.
            INTERNET-RFC, Internet Engineering Task Force, February
            1990.

   [Cal90b] R. Callon.  Use of OSI ISIS for Routing in TCP/IP and Dual
            Environments.  INTERNET-RFC, Internet Engineering Task
            Force, December 1990.

   [Hei93]  J. Heinanen.  Rfc 1483, Multiprotocol Encapsulation over ATM
            Adaptation Layer 5.  Internet Engineering Task Force, July
            1993.

   [ISO90]  ISO.  Information Technology - Telecommunications and
            Information Exchange between Systems - Intermediate System
            to Intermediate System Routing Exchange Protocol for
            Use in Conjunction with the Protocol for Providing the
            Connectionless-Mode Network Service.  ISO, 1990.

   [Kat92]  D. Katz.  Rfc 1377, The PPP OSI Network Layer Control
            Protocol (OSINLCP).  Internet Engineering Task Force,
            November 1992.

Bansal et al.                Expires 1 May 1999                 [Page 6]

Internet Draft                IS-IS over IPv4                 1 Nov 1998

   [MD90]   J. Mogul and S. Deering.  Rfc 1191, Path MTU Discovery.
            Internet Engineering Task Force, November 1990.

   [Moy97]  J. Moy.  OSPFv2, RFC 2178.  Internet Engineering Task Force,
            July 1997.

   [Pos81]  J. Postel.  Rfc 791, rfc Internet Protocol.  Internet
            Engineering Task Force, September 1981.

   [RP94]   J. Reynolds and J. Postel.  Rfc 1700, Assigned Numbers.
            Internet Engineering Task Force, October 1994.

   [Wai90]  D. Waitzman.  Rfc 1149, standard for the Transmission of
            IP Datagrams on Avian Carriers.  Internet Engineering Task
            Force, April 1990.

Authors' Addresses

Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
[email-masked]

Ajay Patel
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
[email-masked]

Atul Bansal
FORE Systems,
1595 Spring Hill Rd
Vienna, VA 22181
[email-masked]

Bansal et al.                Expires 1 May 1999                 [Page 7]

---

From: Mike Shand <[email-masked]>
Date: Mon, 23 Nov 1998 11:31:26 +0000

A few comments.

SNP Checksums
==============

1. I assume the 32 bits for the length of the checksum field is a typo, and
it should be 16 bits. (I'm not sure how to compute a 32 bit Fletcher
checksum).

2. We might as well make it clear that the length is always 2

3. I'm, not sure about the MAY discard a PDU containing more than one
checksum options. I guess there are two cases.
a) BOTH checksums compute OK. In that case a MAY is perhaps reasonable.
b) only ONE checksum computes OK. I would have thought that a MUST discard
was more appropriate there.

Since computing two (or more) checksums is an incredible pain, and cannot
possibly serve any purpose, I would just prohibit multiple checksums and
have a MUST discard for multiple copies.

4. Inclusion of the option makes parsing a little complex. Since you
mustn't do anything based on the contents of the PDU if the checksum turns
out to be false, you have to first parse the PDU looking for a checksum
option. If you find one, you then go back and rescan the PDU computing the
checksum, and if it is OK you finally go back and scan it a third time to
do the normal parse. I suppose you could combine the first two by
accumulating the fletcher checksum while looking for the option, on the off
chance that it was there. I guess this is all implementation details, but I
wonder if it would be helpful to mandate that the option appears first in
the PDU. I know this is dangerous since there *might* be something else
that we want to put first in the future. Perhaps a strong recomendation to
put it first would be OK.

5. The draft doesn't say what (if anything) is meant by an option which
contains all zeros. Since there is no need for optionality (you can always
omit the checksum option), it would seem prefereable to deem an all zeros
checksum to be corrupt.

Maintaining more than 255 adjacencies
==================================

1. The title is misleading. There is no problem maintaining more than 255
adjacencies. The issue is with more than 255 circuits. Similarly the titles
of sections 2 and 3 are misleading.

2. Reuse of a circuit ID within MaxAge of having previously used it on some
other circuit will potentially cause some slight confusion. The algorithm
will stabilise by reasserting the new pseudonode at a higher sequence
number, but there will be a small amount of unnecessary churn while this is
done. It *might* therefore be helpful to advise against such rapid re-use.

IS-IS over IPv4
==============

1. I've never liked incestuous routing protocols and this does nothing to
persuade me otherwise.

2. I'm concerned about the cuckoo like behaviour of the interoperability
rules. The presence of a pair of IS-IS over IPv4 routers on a LAN will make
them blind to any other OSI routers. There seems to be no way to gracefully
migrate a LAN to IP operation.

	Mike

---

From: Tony Li <[email-masked]>
Date: Mon, 23 Nov 1998 11:54:21 -0800 (PST)

|  4. Inclusion of the option makes parsing a little complex. Since you
|  mustn't do anything based on the contents of the PDU if the checksum turns
|  out to be false, you have to first parse the PDU looking for a checksum
|  option. If you find one, you then go back and rescan the PDU computing the
|  checksum, and if it is OK you finally go back and scan it a third time to
|  do the normal parse. I suppose you could combine the first two by
|  accumulating the fletcher checksum while looking for the option, on the off
|  chance that it was there. I guess this is all implementation details, but I
|  wonder if it would be helpful to mandate that the option appears first in
|  the PDU. I know this is dangerous since there *might* be something else
|  that we want to put first in the future. Perhaps a strong recomendation to
|  put it first would be OK.

Mike,

This turns out to not be a serious implementation difficulty.  You'll note
that the exact same problem exists with the authentication TLV.  The trick
is to store results from the first pass in temporary storage such that on a
failure during the authentication/checksum pass, you can easily discard it
without damaging the database.  

This also obviates the need for a third pass.

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 23 Nov 1998 16:00:28 -0800 (PST)

Tony,

Some comments on the IS-IS over IPv4 spec:

|     IS-IS does not normally define a way to fragment its protocol
|     packets, and depends on IP fragmentation when transmitting packets
|     larger than the network MTU.

Well, strictly speaking, IS-IS does not transmit packets larger than the
MTU.  In your _proposal_ IS-IS over IPv4 would _allow_ the protocol to use
IPv4 fragmentation as necessary.

There is a bigger question here as to the padding of IIH's and flooding of
LSPs.  One would assume that we should continue the current minimum MTU of
1492 bytes for LSPs.  However, what do we do about IIH's?  Is there any
point in padding IIH's, only to have them fragmented?  

I would propose that we say something to the effect that IIH's should be
sent with the DF bit and use a size that's the IP MTU less 20 bytes for the
IP header.

|            IPAllL1ISs
|  
|               OSI multicast value of this address was O1-80-C2-00-00-14.
|               This multicast address has been assigned the IP address
|               value 224.0.0.?  for IP encapsulated IS-IS. All routers
|               running L1 IS-IS in IP should be prepared to receive
|               packets sent to this address.  Hello packets are always
|               sent to this destination.  Also, certain IS-IS in IP
|               protocol packets are sent to this address during the
|               flooding procedure.
|  
|            IPAllL2ISs
|  
|               OSI multicast value of this address was O1-80-C2-00-00-15.
|               This multicast address has been assigned the IP address
|               value 224.0.0.?  for IP encapsulated IS-IS. All routers
|               running L2 IS-IS in IP should be prepared to receive
|               packets sent to this address.  Hello packets are always
|               sent to this destination.  Also, certain IS-IS in IP
|               protocol packets are sent to this address during the
|               flooding procedure.
|  
|            IPAllIntermediateSystems
|  
|               OSI multicast value of this address was 09-00-2B-0O-00-05.
|               This multicast address has been assigned the IP address
|               value 224.0.0.?  for IP encapsulated IS-IS. All routers
|               running IS-IS in IP should be prepared to receive packets
|               sent to this address.  ISO 9542 is using this address.

A particularly sick hack might be to continue to use the orginal MAC
addresses.  One could then use the "all routers" mcast address (224.0.0.2)
at the IP layer.  The advantage here is that we don't have to push yet
another MAC address into the address filters.  

|     In the case of broadcast media, MAC addresses are used for adjacency
|     maintainance.  It would be rather painful to assume that an IS-IS
|     implementation can have access to MAC headers, therefore when sending
|     IS-IS encapsulated on broadcast networks an encapsulation header
|     preeceds the Intradomain Routeing Protocol Discriminator.  It is
|     essentially an LLC/SNAP [Hei93] encapsulation indicating bridged
|     traffic with a contained routed OSI frame.  From the possible
|     PIDs the one must be used that omits the LAN FCS since the IP
|     PDU is already checksummed.  The following figure illustrates the
|     encapsulation for 802.3 type PDUs.

While I understand your reason for doing this, I don't see the practical
need.  I would prefer to drop this overhead and simply depend on the
implementation to have access to MAC addresses.  Certainly any current
implementation must have this access.

Tony

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 24 Nov 1998 11:22:26 -0500

> SNP Checksums

ouch, sorry for that ;-) the packet format is however right & indicating
the length
of always 2 would be beneficial, yes, I'll correct ...

> a) BOTH checksums compute OK. In that case a MAY is perhaps reasonable

weir'd case. I would assume that's at best an implementation error ;-)
.
> was more appropriate there.

yes ...

> have a MUST discard for multiple copies.

agreed ...

> put it first would be OK.

I am reluctant to "recommend" to do the "first" or "sorted" or any
similar thing. As Paul
Koning once pointed out:

	what if someone puts it somewhere else ? Either you say:you must 
	discard, in which case you can say as well: You MUST put it first. If
you 
	use it anyway, than you can as well just drop the restriction. 

Additionally, recent implementation experience tells me that the double
parsing 
of packets is becoming less and less of a problem. My personal view of
things
is that the processors are getting so fast that parsing of packets
starts to become
negligible more and more. On the other hand, the internal processing of
the protocols 
in terms of state machines & timers becomes more and more complex &
that's where the 
CPU is being hammered these days. 

> omit the checksum option), it would seem prefereable to deem an all zeros

I actually thought about the case & was tempted to make the 0 value mean
that 
it's to be disregarded, however couldn't find a scenario you'd need it
;-) 
ok, let's say the all 0's is corrupt. 

> Maintaining more than 255 adjacencies

I take it. My terminology was loose.

> done. It *might* therefore be helpful to advise against such rapid re-use.

that's an excellent observation, I think I put something into the draft
recommending that 
you try not to reuse the circuit ids as long as possible when
shutting/bringing up
interfaces. 

> IS-IS over IPv4

;-)    Can't help people are asking for it ...

> migrate a LAN to IP operation.

yes, one of the comments I expected was the concern about mixed LANs.
The best 
answer I have is that you'd end up with segmented LANs where all the IP
guys will
talk IP and all the OSI guys will be left out and talk to each other. 
Not a 
very tempting prospect. 

On p2p links where the migration is clearer,
I got the comment that since the main advantage of such an encaps 
is getting rid of the LLC/SNAP stuff, you'd have to shut interfaces to
configure 
null encaps on them anyway and therefore you could change the ISIS to
run IP encaps
on both sides. Therefore the migration is not overly interesting. 

Given all that, maybe I should just ditch the migration path ? 

			thank you

			--- tony

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 24 Nov 1998 11:49:53 -0500

> IPv4 fragmentation as necessary.

yes, I word more carefully, but I ment what you say, that was the
intention. 
I think in the discussion we had previously I indicated 
that I don't necessarily think you should fragment but in certain
situations it
can save you lots of headaches and confgiuration pain ...

> sent with the DF bit and use a size that's the IP MTU less 20 bytes for the

ok, I'm tempted to scrap the IIH padding completely but I had already
operators
pushing back on that. The DF and 20 bytes less is a good solution ...

> another MAC address into the address filters.

not too excited about that. I'd rather solve it cleanly here. Things
like 
protocol hacks tend to chase you for years and years to come (look at
the 
255 circuits and 255 fragments), whereas things like number of MAC
filters are
something the hardware  guys provide cheaply relatively fast. Other
opinions ? 

> implementation must have this access.

Let's wait for more comments here. I'd like to see a gated
implementation of that
stuff (I wouldn't pay for it though of course ;-) or any other hacker
coming
up with a raw socket, unix daemon stuff that does the thing, that's why
I think
we should do it. Without the encaps there will be a lot of unportable
solutions 
possibly (Linux has a good solution with the PACKET socket whereas other 
people are less elegant ;-).

I thought as well that we could have a "routed in bridged" encaps and
just "routed"
encaps in the ether frame which would save some of the overhead.
However, I 
hate having too many optional ways to do things. They break
interoperability ...

		thanks

		--- tony

---

From: Mike Shand <[email-masked]>
Date: Wed, 25 Nov 1998 09:21:18 +0000

>CPU is being hammered these days. 

Yeah, Paul's right (as always) in general. However, sometimes such a
recommendation can make the normal case more efficient. You still have to
code for the 'non-recommended' variant, and take the performance hit when
someone is uncooperative, but mostly it will save you. In this instance I
take your point. Parsing is almost free.

BTW, have you heard of what we used to call "Koning's Razor", which goes
something like, "Never design for future compatibility with some yet to be
understood requirement." i.e. don't include features which you think might
be useful sometime, since when you do want to use them it will nearly
always turn out that they aren't quite what you want, and you would have
been better off designing them from scratch when you needed them.

A corollary is "There are never quite enough reserved bits".

>Given all that, maybe I should just ditch the migration path ? 

Yes. I've done my fair share of designing "If you hear one of these, then
stop sending those" type protocols, and most of them have ended in tears.
Determinism rules OK.

	Mike