Subject: SV: [Isis-wg] More vendor data on IP/GigE MTU

From: Anders Lowinger <[email-masked]>
Date: Tue, 26 Jun 2001 23:18:38 +0200

> Such buffers are typically on-chip and thus are relatively 
> expensive.  They also need to be MTU sized.  The combination of 
> these two factors generally push designers to want a smaller MTU.
> It makes the hardware more efficient, which in turn makes the 
> system more efficient.

Tony,

I'm pretty sure you know this so this is for the rest of the list.

One big difference between POS and Ethernet is that if you have
channelized interfaces on POS the data is byte-interleaved =>
reassembly is needed.

If you have channelization on Ethernet, or VLAN's as it is
called :-) each frame is sent back-to-back.

What is the difference?

Well, on a 10GE interface, to support 192 VLAN's you need
3x9180 bytes of store-and-forward buffer.

On a channelized OC192 down to OC1 (DS3/T3) this will require
192x9180 bits of store-and-forward buffer. As Tony mentioned
these buffers usually are on-chip and 1,68 Mbyte of on-chip
memory is very much.

(Actually you need the same amount in the transmit path also).

Lower MTU really helps here!

Back to ISIS, do we really need LSP datagrams with sizes over
1492? We could use the trick with multiple system-ID's if we
run out of LSP space.

What is the probability that we will have an ISIS area in
which we can increase the LSP size >1492? I doubt we will
see many of them.

Send IP Jumbograms with EthernetII type codes, the ISIS
datagrams as we do today (I think Henk mentioned this
a long time ago).

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

---

From: Tony Li <[email-masked]>
Date: Tue, 26 Jun 2001 16:04:37 -0700

| On a channelized OC192 down to OC1 (DS3/T3) this will require
 | 192x9180 bits of store-and-forward buffer. As Tony mentioned
 | these buffers usually are on-chip and 1,68 Mbyte of on-chip
 | memory is very much.

Excellent point.

 | Back to ISIS, do we really need LSP datagrams with sizes over
 | 1492? We could use the trick with multiple system-ID's if we
 | run out of LSP space.

Practically speaking, increasing the size of the LSP is a non-starter.  It
requires domain-wide coordination of the LSP size.  That would practically
be impossible for any domain that actually needed a larger LSP.

 | Send IP Jumbograms with EthernetII type codes, the ISIS
 | datagrams as we do today (I think Henk mentioned this
 | a long time ago).

It's not just the LSPs.  There are also the IIH's to think about.

Tony

---

From: Henk Smit <[email-masked]>
Date: Tue, 26 Jun 2001 16:10:09 -0700 (PDT)

> Back to ISIS, do we really need LSP datagrams with sizes over 1492?

  No, ISIS doesn't need larger LSPs.

  The problem was this:
 *) Some router vendors support "jumboframes" over GE.
 *) IP packets are encapsulated in EthernetII frames. (*)
 *) Encapsulation of EthernetII frames in such jumboframes is easy.
 *) ISIS sends hellos padded to mtu size, to do early detection
    of mtu mismatches, and other problems.
 *) Some ISPs wanted this early detection to keep working even over
    GE with jumboframes.
 *) Therefor, ISIS must send hellos padded up to "jumboframe mtu"
 *) ISIS packets are encapsulated in 802.3/802.2 frames. (*)
 *) 802.3/802.2 frames can not be longer than 1500 bytes.
 *) Therefor ISIS can not use jumboframes.
 *) To solve this problem (and IMHO only this problem of padded hellos)
    draft-ietf-isis-ext-eth-00.txt was written.

  Possible solutions:
 1) Change ethernet specs.
 2) Make IS-IS use EthernetII encapsulation.
 3) Make IS-IS use IP encapsulation.
 4) Forget about padding IS-IS hellos to mtu-size.
                
  It seems proposal 1) encountered more opposition than envisioned. :-)
 Proposals 2) and 3) are gonna introduce lots and lots of interoperability
 problems. Not worthwile, IMHO.

  Doing 4) seems a nice and simple solution. And it has the benefit that
 ISIS will  keep working on bridged networks of GE and other flavors
 of Ethernet.

  I never understood why ISPs insisted on keeping ISIS to pad its hellos
 to mtu-size. OSPF sends small hellos, and that does not seem to give
 many more headaches.

     henk.

--
PS.(*) I know this terminology is not the proper lingo anymore. If you know
how to call those 2 encapsulation methods, please educate me. Thanks.
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Derek Yeung <[email-masked]>
Date: Tue, 26 Jun 2001 16:27:09 -0700

>  to mtu-size. OSPF sends small hellos, and that does not seem to give

	OSPF have the same problem. OSPF solves the problem by putting the 
MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable to put a TLV in 
IIH to carry the MTU instead of padding IIH to full MTU size ?

- Derek

---

From: Alex Zinin <[email-masked]>
Date: Tue, 26 Jun 2001 17:06:18 -0700

I like Derek's suggestion.

On the other hand, (and I do know option 3 has been beaten
to death), using IP encapsulation solves this problem in
a "natural" way, i.e., routing traffic follows the path
of transit traffic. As an additional benefit, this will
solve the problem of an ISIS adjacency staying up (and thus
attracting transit traffic) even though IP processing of
the box (or a line card) has gone south.

Alex.

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 26 Jun 2001 18:07:41 -0700

>  problems.

agreed for 2), for 3) I think you're exaggerating. I still think long-term
that
will take care of quite some problems that a lot of hacks are being invented
to
get around today. I remember the e-mail exchange and don't care to rehash all
the
arguments again. Let's just wait till time is ripe (and I know, it may be
never ;-)

> Not worthwile, IMHO.
>  of Ethernet.  I never understood why ISPs insisted on keeping ISIS to pad
> its hellos

>  to mtu-size. OSPF sends small hellos, and that does not seem to give

Some vendors feel strongly (maybe there was some marketing brain-washing that
caused that, don't know) that it's a desirable feature to detect
MTU mismatches and
broken equipment loosing last 2-3 bytes and such jazz.

I like Derek proposal and  I think that a TLV is easily added for that purpose
... That will
not diagnose broken equipment that looses the last bytes but it will take care
of
misconfiguration.

And yes, for the list,
most modern implementations allow to squelch off the padding to mtu-size
as people probably know.

    thanks

    -- tony

---

From: Dave Katz <[email-masked]>
Date: Tue, 26 Jun 2001 19:26:07 -0700 (PDT)

For what it's worth, we only pad to the max LSP size (1492) since that's
really all the padding is trying to accomplish (detecting links too small
to carry some of the LSPs.)  In all of the years I've been working with
ISIS, the padding has shown no obvious operational benefit, but has
created countless problems (anybody remember FDDI/Ethernet bridges?)

MTU mismatch detection is best handled as a more straightforward extension,
if anybody really cares.

--Dave

   X-JNPR-Received-From: outside
   From: Henk Smit <[email-masked]>
   X-Confidential: Procket Confidential/Need to know
   Cc: [email-masked]
   X-Mailer: ELM [version 2.5 PL3]
   MIME-Version: 1.0
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit
   Sender: [email-masked]
   Errors-To: [email-masked]
   X-BeenThere: [email-masked]
   X-Mailman-Version: 2.0rc1
   Precedence: bulk
   List-Help: <mailto:[email-masked]?subject=help>
   List-Post: <mailto:[email-masked]>
   List-Subscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=subscribe>
   List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
   List-Unsubscribe: <http://external.juniper.net/mailman/listinfo/isis-wg>,
	   <mailto:[email-masked]?subject=unsubscribe>
   List-Archive: <http://external.juniper.net/pipermail/isis-wg/>
   Date: Tue, 26 Jun 2001 16:10:09 -0700 (PDT)

     The problem was this:

     Possible solutions:

	henk.

---

From: Ran Atkinson <[email-masked]>
Date: Wed, 27 Jun 2001 10:34:13 -0400

Henk's historical analysis is extremely helpful.
I hope we are all now focused on the problem at hand.
Thanks much for the detailed analysis and history.

At 19:27 26/06/01, Derek Yeung wrote:
>MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable 
>to put a TLV in IIH to carry the MTU instead of padding IIH to full 
>MTU size ?

        This seems like a simpler approach.  The concept is known to
work (thanks to OSPF).  Why don't we just try this to solve the
immediate IS-IS issue that Henk outlined ?  Oh, and if we do this,
it might not hurt to add a MIB object or two to make MTU mismatches
discovered by IS-IS easy for operators to grab via SNMP.

        Quite separately, I'll probably draft up an "IP over
Jumbogram Ethernet-II Framing" spec that just documents the
as deployed IP/Ethernet practice, as an Informational RFC.  I don't 
see that as an IS-IS WG work item, in no small part because IS-IS 
does not use Ethernet-II Framing.  

Cheers,

Ran
[email-masked]