Subject: [Isis-wg] Concerns about ISIS in IP encapsulation

From: Henk Smit <[email-masked]>
Date: Fri, 28 Jan 2000 20:06:51 +0100 (MET)

During the IETF ISIS WG meeting in Oslo we had a bit of a discussion
 about the proposal for ISIS in IP encapsulation.
 (See draft-ietf-isis-wg-over-ip-01.txt for details).
 At that meeting, I have voiced my concerns about the proposal.
 I had prepared an email to send to this list long time ago. But there
 was never a compeling reason to bring up the subject again.

  Let me try to recap some of the discussion.

  Benefits of ISIS in IP encapsulation.
 A) ISIS-in-IP improves the efficiency of ATM when using ISIS as IP IGP.

  My opinion:
  - This true. But had I hope my proposal was a more simple and easier
    solution for this problem. (See draft-hsmit-isis-ip-aal5mux-00.txt).
    Last summer I have emailed two of our largest ISIS+ATM customers
    that I had the code ready, but they didn't seem much interested.
    Now I wonder how bad ISPs really want to improve the efficiency
    of the ISIS+ATM combo.

 B) ISIS-in-IP prevents the need of defining OSI/ISIS encapses every time
    a new layer2 technology is emerging.
  - This is true. But it is very likely that native OSI/ISIS encapsulations
    will be defined for new layer2 technologies anyway. E.g. CLNS itself
    is not dead yet. CLNS is not relevant in the Internet, and probably
    not in Enterprise networks. But RBOCs are using CLNS for their
    management networks for their Sonet/SDH infrastructure. So native
    OSI/ISIS/CLNS will be around for a while, so there will be new
    encapsulations for OSI/ISIS/CLNS defined.

 C) ISIS-in-IP improves portability of gated.
  - Personally I don't care much about this. While people might not
    expect this from a cisco employee, I do like open source software.
    But I think that new technology should not be based on what is
    easy to implement in one particular operating system (even if
    it is Unix).
    Also the fact remains that all current ISIS implementation run
    native over layer2, so if gated or any other ISIS implementation
    wants any acceptance in the real world, it still needs to implement
    ISIS-in-layer2 encapsulation.

 D) ISIS-in-IP might improve the acceptance of ISIS in circles of IP bigots.
  - IMHO people who don't like ISIS won't suddenly like it because
    they can now encapsulate ISIS in IP.

  Now the drawbacks:
 1) Why add a second method of encapsulation ?
    ISIS-over-IP doesn't solve a real problem. If the efficiency of
    ISIS+ATM is really an issue for some customers, this could be solved
    by using the first byte in the IP header as NLPID. Maybe we can get 
    away without a more complex solution. If we solve this problem just
    for ATM (actually just for "aal5mux ip"), then if ATM becomes less
    popular in a couple of years (at least in highspeed networks), we
    can forget about this hack. If we do ISIS-over-IP we will be stuck
    with it forever. See IPX.

 2) It adds more complexity to the protocol.
    One of the reasons some people like ISIS over OSPF is the fact
    that ISIS is simpler in some areas. We are now adding all kinds of
    features and  extensions. If we add too many, ISIS will be worse
    than OSPF in this respect. Personally I would hate to see that
    happen.

 3) It adds more complexity to the configuration.
    The less configuration choices there are, the easier ISIS will be
    to deploy. Look at a similar case: IPX. It has four encapsulations.
    There are no benefits to that, just added confusion.

 4) IP fragmentation.
    I think that people will not move whole networks at the same time.
    They will run hybrid networks with ISIS-over-layer2 and ISIS-over-IP.
    That in itself will add complexity. I am sure customers won't configure
    smaller LSP buffer sizes on all their routers. At least not until
    their network really breaks.
    So I am afraid that LSP will be fragmented at the IP layer.
    Note, if a router has more than 1492 bytes of info to advertise
    into ISIS, that router must fragment its LSP. It will probably create
    a first LSP of size 1492, and at least one small LSP. That first
    LSP of size 1492 will be fragmented at the IP layer on links that
    have an MTU of 1500 and run ISIS-over-IP.
    So a router that redistributes more than 100 IP routes or so will
    have at least one LSP of size 1492. Right now lots of ISIS networks
    I know run in a single flat area. But if they ever do true L1L2, the
    L1L2 routers will advertise lots of interarea routes. So most likely
    the L1L2 routers will all create LSP fragments of size 1492.

    As you all know, link-state protocols have two areas of concern
    regarding scalability. One is route computation, and the other is
    flooding. I think fragmentation at the IP layer will make ISIS
    flooding less scalable. I was told by one of editors of 10589
    that preventing fragmentation during the flooding was the main
    reason why ISIS fragments only at the originating router.

    BTW, I am not so much concerned about fragmentation, but more
    about reassambly.

 5) Consistency towards other standards bodies.
    The ISIS-over-IP draft recommends that routers use an LSPBufferSize
    of 1480 (or rather 1472) bytes. In the Sonet/SDH/Telco world 
    the Sonet Interoperability Forum (SIF) works on ISIS too.
    They want to run ISIS over the DCC. The DCC channel is a part of
    the bandwidth of a Sonet/SDH ring. The Bellcore spec for DCC 
    says that the DCC must use LAPD encaps, and that the *maximum*
    MTU is 512 bytes. So you can't run ISIS over the DCC, because
    some routers might send LSPs of size larger than 512 bytes.
    Those LSPs can not be flooded over the DCC.
    So the SIF wanted to add some cruft to 10589 that changes the
    LSPBufferSize from 1492 to 512 bytes. I am heavily opposed to
    that. But if the ISIS WG in the IETF recommends to lower the
    LSPBufferSize from 1492 to 1480, why not lower it to 512 ?
    We will not be able to defend ourselves to changes like the
    proposal from the SIF.
    To be honest, I don't know about the latest status on the SIF
    proposal. It actually might have been withdrawn.

 6) Security.
    ISIS-over-layer2 is actually a feature. ISIS packets are not routable.
    It makes sure that nobody but your direct physical neighbors can
    inject routing packets into your IGP.  Suppose a network uses
    ISIS-over-IP. That means I can send ISIS packets from my PC at home
    to any router in that network. It is easy to fake source IP addresses.
    So I can inject LSPs into this network, or do other nasty things,
    like break adjacencies, etc. So now this network needs to use
    ISIS authentication. Probably strong authentication, like HMAC/MD5
    (not cleartext passwords). But still if that is done, I can send
    a 1000 LSPs/second to those routers. And they need to check the
    authentication, which might use lots of CPU power. Or I can send
    IP fragments, which will use buffers. All kinds of nasty denial
    of service attacks come to mind.
    I guess these attacks could be applicable to OSPF today, so the
    OSPF people might already have a solution which we can use.
    But I would like to point out that ISIS-over-layer2 is a feature.

 7) What about IPv6 ?
    If we ever get around to define TLVs to do IPv6 routing in ISIS,
    which encapsulation would it use ? A nice thing about ISIS is
    that ISIS packets are not encapsulated in CLNS, and not in IP.
    Now if we add ISIS-over-IPv4, we might end up in a situation
    where we will have to define an ISIS-over-IPv6 encapsulation too.
    What if routing for other layer3 protocols gets defined ? Will
    we add an encapsulation for that layer3 too ?

 8) Why not encapsulate in CLNS as well ?
    10589 defines virtual links for area repair. Those virtual
    links use CLNS encapsulation to get packets across the L2 backbone.
    Extra complexity for little gain. (The gain would be that networks
    with a broken design seem a little less broken).
    That added complexity was one of the reasons why I have discourge
    my employer from implementing virtual links and area partition repair.
    Once we implement virtual links for area partition repair, we probably
    will have to support area partitioning for IP as well. The
    result will be that if gated and others want to stay compatible
    with current features, they might have to implement a full CLNS stack,
    just to be able to deal with area partition repair. Just ISIS-over-layer2
    encapsulation will not be enough anymore.

  Some comments on my concerns.
 - Curtis Villamizer said that networks don't run their IGP over
   10 Mbps ethernet anymore. ISPs use POS, ATM, FDDI, Fast Ethernet
   and Gigabit Ethernet. Those layer2 technology all can have MTUs
   of 1512 or higher. 10 Mbps ethernet is only used at the edges
   towards the hosts.
    
   I guess that is correct. So fragmentation migh occur less often
   then I fear. After all, the large NBMA meshes are mostly over
   ATM today, which has a larger MTU.

   However, enterprise networks might run ISIS over 10 Mbps Ethernet.
   And some router implementations use standard MTUs of 1500 on
   their serial (PPP, HDLC, frame-relay) interfaces. To use larger
   MTUs over FE and Gig-ethernet we need the new encapsulation,
   which might cause other problems (like on bridges). So I am
   not fully convinced yet that fragmentation won't be a problem.

    Thank you for your attention,

                  Henk.

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

---

From: Vijay Gill <[email-masked]>
Date: Fri, 28 Jan 2000 18:15:00 -0500 (EST)

>     Now I wonder how bad ISPs really want to improve the efficiency

I'll speak to this point briefly.

As the promising local ISP I work for transitions from IP over ATM to
Packet over SONET, the effort to deploy the above proposals doesn't give
us a good enough return.  Two years ago, yes; today, the benefits are not
that glaringly obvious given the transitioning already in place. 

/vijay

---

From: [email-masked] (Christian E. Hopps)
Date: 29 Jan 2000 15:04:51 -0500

>  C) ISIS-in-IP improves portability of gated.

This of course was my fault, and was not the intent of what I was trying
to say.  People who were at the meeting will recall that I was asked to
give an example of system that might not have OSI available. I too
quickly fired off, ``well e.g., someone using gated on unix''.  I
unfortunetly mentioned an implementation and so it seemed like a at
least a few people ``latched'' that and didn't actually take the
statement in context.

GateD has support for OSI/CLNS.  So this is not a GateD issue.  As you 
point out: if your going to do an IS-IS, right now, you have to support
CLNS encapsulation.

>     ISIS-in-layer2 encapsulation.

A huge amount of networking research occurs on Unix systems.  To toss
Unix out as unimportant to the internet or routing protocols seems
unwise to me.  Some Unix vendors even have OSI support e.g., NetBSD,
BSDI and I think Digital/Compaq.  The BSD stacks, at least, are aging,
poorly, mostly through lack of use.

I think the only point I'd like to make WRT to this discussion is that:
CLNS is dead to most of the world. Maybe IS-IS will continue to drag the
dead horse along with it, and maybe IS-IS will continue to be a mostly
unknown or unpopular routing protocol for most people. I think this
would be sad.  Why should such a nice protocol be restricted to only the
elite in routing?

Thanks,
Chris.

P.S. I found many of Henk's comments worthwhile and well though out,
specifically with regards to issues facing us today.  Other than what
I've said above I choose not to disagree with any of them.

---

From: "Lester Ginsberg" <[email-masked]>
Date: Mon, 31 Jan 2000 11:09:34 -0800

> proposal. It actually might have been withdrawn.

To clarify the position presented by SIF -

SIF never proposed changing the LSPBufferSize. The current spec allows
values of 512-1492, though most folks prefer to use 1492 whenever possible -
which, as Henk points out is not possible over the SONET DCC.

What SIF did propose is to define TLVs to allow the detection of inconsistent
provisioning throughout the area/domain. So at least someone would have a
clue when a system generated a 1492 LSP and it couldn't be forwarded over
a DCC link. A complete discussion of the SIF proposal can be found on the
(renamed) NSIF web site:

    www.atis.org
    go to NSIF - then documents - then 1998 - then find SIF-AR-9802-031
                                                   (R7)
    or

    ftp from ftp.juniper.net:/pub/isis/lspsize.PDF

The proposal is still viable - if the work on the 10589 second edition draft
ever resumes (there is still hope, I think) - then this proposal will be
part of the discussion.

  Les