Subject: [Isis-wg] New WG document

From: Tony Li <[email-masked]>
Date: Mon, 20 Sep 1999 09:58:00 -0700

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  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Mon, 20 Sep 1999 15:05:14 -0400

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

>(we hope ;-), and of the things currently in the Internet, affects IS-IS
____________________________________________________________________

  Jeff Learman                           Internet:     [email-masked]
  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
____________________________________________________________________

---

From: Tony Li <[email-masked]>
Date: Mon, 20 Sep 1999 13:52:27 -0700

Jeff,

|      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).  

Thanks, yes.  FWIW, the primary driver behind this is Jumbo Frames on
Gigabit Ethernet.  The above caveat is reasonable in case someone ever
generalizes stuff.

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

Jumbo Frames are going to get deployed to avoid MTU issues in the
backbone.  As IS-IS tends to use the available MTU, we need some
well-defined way of encapsulating PDUs.

|      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).

Insuring that the data exchange happens is the key point.  MTU issues in
the data plane are no fun and IS-IS as it stands today obviates the issue.
We would like to preserve this property.

Tony