[Isis-wg] New WG document

[Jeff Learman]

A few minor comments:

1.  The term "Ethertype" is used but not defined.  Of course we
    all know what it means, but it would be easy to define it
    in Section 4 (perhaps as the label for the "type" field
    in the Ethernet II packet format.)

2.  In section 6, it says

     "There is no loss of information from 802.3/802.2 frames. Although 
      the 802.3 length field is missing, the frame length is known by 
      virtue of the frame being accepted by the network interface."

    This is true only if the physical layer does not have a minimum
    frame size less than 1500 bytes.  For example, Ethernet II has
    a minimum frame size of 64 due to transmission characteristics
    and collision detection, so small frames are padded to that size
    before transmission -- ergo the lenght field in the 802.3 format.
    ISIS and ESIS packets rely on a valid frame size from the Datalink
    layer.

    Therefore, this RFC should be explicitly limited in application to
    physical layers that have a minimum frame size of 1500 bytes or
    less (excluding source & destination MAC addresses and Ethertype
    fields).  Hopefully, this is not too restrictive to be applicable
    to anticipated bit rates, transmission line lengths, and collision
    detection methods.  If it is too restrictive, then it might be
    better to deal with it now and save trouble later.

3.  I am curious why IS-IS frames larger than 1500 would be desirable.

    It looks like this draft RFC takes a straightforward approach to
    a straightforward issue: running IS-IS on subnetworks that support
    MTU sizes greater than 1500.  (Of course, it's commendable to take
    the straightforward approach ;-)

    But it might be worthwhile to look at an alternative: to
    set a different MTU size for IS-IS than for the data protocols it
    supports routing for.  A way of evaluating this is to ask why
    it might be useful for IS-IS to be able to send large packets.

    The following are potential reasons why it would be better to
    support large IS-IS PDUs (per the draft) than to have separate
    MTU sizes for IS-IS and the data protocols (the alternative)

    A)  Checking consistency of MTU size settings between routers on
        a LAN.

        I understand that IS-IS's ability to verify that frames of a
        certain size can be exchanged on a link is useful, but it is
        far more important for maintaining the integrity of route
        exchange than data exchange, because of the nasty problems
        that result from incomplete route propagation (far worse to
        diagnose and repair than simple data loss).

    B)  Optimizing LSP traffic

        The use of very large LSPs might be useful, but only in a 
        subdomain where all links supported the larger MTU size.
        I doubt that this is what is intended, since no mention of
        is made of maxLspReceiveBufferSize.

    C)  Optimizing CSNP traffic

        In a very large subdomain, fewer CSNP PDUs would be required
        if they could be larger.  But since only the DR transmits
        them, the difference in efficiency should be negligible.
    
    D)  Permitting more than 200 routers on a LAN

        For IIH PDUs, the size of the IIH limits the number of ISs that
        can be present on a LAN (about 200 for 1500-byte IIHs with no
        authentication field).  Is this limit significant?  Maybe so.

    E)  Permitting rediculously large ISH or ESH PDUs.

        I hope nobody is seriously considering this!

    F)  Just following the rules

        The IS-IS spec has requirements about the MTU size, and doesn't
        have any provision for separate max sizes for routing and data
        protocols.  It might be best just to follow those rules.

    But if none of these issues is very important, it might be simpler
    to keep the 1500-byte MTU size for ES-IS and IS-IS PDUs regardless
    of the MTU size for IP and other protocols.

    Note that this would NOT necessarily invalidate the draft RFC,
    which could still be used (e.g., to permit a large MTU size for
    CLNP).  It might make it a bit less significant.

    Note also that since IIH PDUs on a broadcast LAN are required to
    be the max MTU size, if the max MTU size increases by a higher
    ratio than the bandwidth then IS-IS would take a higher percentage
    of the LAN bandwidth than it does now.  Of course, this is not
    much of an issue unless there is a large number of routers on
    the LAN.


Regards,
Jeff

At 09:58 AM 9/20/99 -0700, Tony Li wrote:
>
>Folks,
>
>We've been asked to make draft-kaplan-isis-ext-eth-00.txt as IS-IS WG
>document.  I believe that this was discussed in Oslo, but just in case
>there are a few people who didn't make it to Oslo ;-), it seems sane just
>to check one more time.
>
>If you have any objection to making this a WG document, please respond by
>this Friday.
>
>Once again, the reason that this document makes sense as an IS-IS WG
>document is that it's quite self-contained, shouldn't be very contentious
>(we hope ;-), and of the things currently in the Internet, affects IS-IS
>the most.
>
>Tony & Tony
>
>_______________________________________________
>Isis-wg mailing list  -  Isis-wg@external.juniper.net
>http://external.juniper.net/mailman/listinfo/isis-wg
>
>
____________________________________________________________________

  Jeff Learman                           Internet:     jjl@one.com
  Engineering Manager                    Voice:     (734)-975-7323
  ONE (Open Networks Engineering, Inc)   Fax:       (734)-975-6940
  2725 South Industrial Pkwy, Suite 100
  Ann Arbor, MI  48104  USA
____________________________________________________________________