Re: IPv7 (CLNP) a mistake

[[e-mail]]

>	However, we aren't binding ourselves (for reasons of abilty to meet
>requirements) to keeping that protocol exactly the same. To me, this sounds
>like we have just voided the best argument for switching to a second protocol,
>which is the interoperability issue. Surely, if the Internet CLNP is
>functionally different in a useful way, it won't be interoperable, right?

        Well, Noel, I disagree with most of your assessment.
        I truly believe that with CLNP, you can have your cake (change
        control) and eat it (maximize interoperability). I wish I could
        say it was designed that way, but I'll be happy to treat eat as
        a pleasant mistake.

        I interpret "change control" within the IETF as follows: we have
        a protocol that looks like CLNP, smells like CLNP, waddles over
        LANs and WANs like CLNP, but is called IPv7, and the documentation
        is in RFC form, available electronically, and changes are
introduced
        through the process outlined in RFC 1310. It would be nice if 
        every change we introduce is enthusiastically accepted by ISO, but
        not necessary. 

        First, let's look at the options. Suppose the IETF wants to add
        an option and ISO don't:-( (maybe PROTO, maybe something else, 
        maybe a preferred way of encoding an option over one ISO had used
in    
        CLNP).  My vague and limited recollection of CLNP    
        reminds me that CLNP options fall into three categories:
        1- you gotta implement it or you die
        2- you don't have to implement it, but if you don't and you
          receive it, you gotta discard the packet
        3- you don't have to implement it, and if you receive it, be
          rude: ignore it, and process the packet as if it weren't
          there
        Since options are Header Item encoded, the extent of the agreement
        one needs from ISO is that they reserve some of the 2**6-1 values
        for IETF use, and that they treat options with header item values
        in this range as type 3's. 


        Second, let's look at introducing efficiency. Folks claim that
        variable length headers are bad; we can fix the length of the CLNP
        address fields to the maximum length of IPv7 addresses, so for
        headers that don't carry variable length options, we've made
        processing predictable. And note that, absent the addressing info &

        options, the CLNP packet overhead is only 15 bytes.

        Now that nasty checksum. Evidence that the OSI TP/CLNP checksum
        is slow and misplaced is growing, and I see an opportunity here
        for us to correct a bad judgement. I'll also mention that there
        is a note in the ISO Transport Protocol spec that seems to imply
        that not everyone who worked on the checksum was happy with it:
        it suggests that a different checksum is an item for further study.
        In my mind, field experience falls into the category of further
        study:-) I think there is a real good chance to fix this.

>	In fact, the cost would be less, since we wouldn't have to make some
>of the major changes to our protcol suite that a switch to a new network layer
>would entail (e.g. phasing in ES-IS, etc, etc).

        this is a big assumption, don't you think? maybe I'm dense (yes,
        I borrowed this from your email to me earlier) but it seems to
        me that the impact here depends on what sort of addressing we
        come up with. 

        I also think that there are lots of assumptions being made about
        the composition of the glorious ultimate NSAPA for IPv7; I haven't
        seen a concrete proposal that suggests we use RFC 1237 for IPv7,
        the TUBA proposal only suggests that we use NSAPAs--I see room
        to improve here, if necessary.  

>	If we are going to modify an existing protocol to get what we need
>(and I don't agree we should be doing this at the moment), why switch to a
>totally different one to do it?

        probably for all the reasons you don't think carry weight:

        - compatibility/interoperability--maybe a platitude for you,
          but from an operational standpoint, I imagine there is
          some sympathy for having to train staff to operate one
          protocol for an otherwise multi-stack environment
        - NM instrumentation exists within the SNMP for CLNP (MIBs);
          none exist for a totally new protocol
        - midlevels, backbone, and stub networks have experience with
          CLNP--certainly not as much as IP, but more than a totally
          new protocol

>	I'm also less sanguine than you are about the ability to get the ISO
>world to track changes made here. Standards bodies *all* (including the IETF,
>I willingly admit) seem to have a bad case of N.I.H. I mean, look at IEEE;
>they just *couldn't* resist dinkering with Ethernet, a widely deployed and
>very sucessful standard.
 
        history repeats...history repeats...history repeats...

        maybe it doesn't have to. Lyman's point that the very same 
        CLNPeople attend the IETF, ANSI, and ISO meetings should not
        be dismissed too easily. Dave Oran, Ross Callon, Radia
        Perlman and Paul Tsuchiya can attest more accurately than I to
        how amenable the "other" OSI folks have become to improving 
        the CLNP "stack"; it sounds like they enjoy talking
        about link state packets, I appear to have left too soon (of
        course, I get to do *this* now:-)

>	I *still* think the best interim path is to put off the adoption of a
>new packet layer as long as we possibly can, 

        have you any idea how long is long? what risk do we run that
        CIDR will forestall collapse for that timeframe?

---------
David M. Piscitello
Bellcore NVC 1C322
331 Newman Springs Road
Red Bank, NJ 07701
(908)-758-2286
(908)-785-4177 (Fax)