Subject: Re: [Isis-wg] draft-noguchi-isis-protocol-topology-00.txt

From: Jeff Learman <[email-masked]>
Date: Wed, 05 Feb 2003 17:40:55 -0500

With the exception of the capability to support different protocols on
different interfaces, I have advocated this solution like since I first
read RFC-1195.  However, that was way too late to change 1195, and
by the time I brought it up in this forum, it was considered a bad
idea by most.  It was not a new idea at that time.

In most cases, the reasons were related to existing implementations
rather than the merits of the solution.  One disadvantage that was
pointed out was that in order for it to work, you need network
of connectivity for each protocol, considered separately.  I don't
think that's such a big disadvantage, and it avoids unnecessary
tunneling that Philip's solution can entail.  But it does not
automatically close gaps like Philip's solution.  (Philip's
solution was driven by a valid requirement to be able to handle
gaps due to specific problems that occur in SONET management networks,
which may or may not be representative of the way IP networks are
planned and deployed.)

One of the biggest sticking points is the need to form an adjacency
even when IP subnet addresses don't match.  While there is no
theoretical need for this match, the practical reality is that
IP router implementations expect neighbors to have IP addresses with
matching subnets and which support ARP.  Any proposal that requires
a change to this behavior is not likely to be supported by the major
vendors.  It would dictate a more radical implementation change than
you might think.

The ability to support different protocols on different interfaces
complicates the subject considerably, especially with respect to
interoperability, legacy issues, and configuration difficulties.
We want to build routers so that there are as few knobs as possible
that have to be set correctly in order for the router to work.  This
solution requires that you turn the special behavior for this RFC
on or off in order to work well with existing implementations.
It would be better to try to avoid that if possible.  (Note that
the only reason this proposal has interoperability problems in
1995-supported networks is that it omits the necessary Protocol
Supported TLVs.) On the other hand, this ability might be very
important for today's distributed implementations, where all
protocols might not be supportable on all interface types.

Of course, it doesn't interoperate with Philip's ITU spec, which
requires the typical behavior (not specified in 1195) of rejecting
adjacencies when there are no protocols in common.

More comments below, if you're serious about pursuing this.
More detail is required in the behavioral sections.  As it is,
it's rather ambiguous, especially how it should operate in a "normal"
(e.g., single-protocol) network alongside legacy equipment.  I believe
all these details shouldn't be too hard to work out.  But different
people would work them out quite differently!

Regards,
Jeff

>Abstract
>
>   RFC 1195 [1] documents a dual routing protocol that can be used to
>   route both CLNP and IPv4, that is Integrated IS-IS.  [2] adds
>   functionality to Integrated IS-IS so that it supports IPv6.
>
>   RFC 1195 [1] places topological restrictions on networks that are
>   routed using Integrated IS-IS, specifically, that every router in a
>   level-1 area must be capable of all network layer protocols that are
>   present in that area, and every router in a level-2 area must be
>   capable of all network layer protocols that are present in the whole
>   IS-IS routing domain.
>
>   The mechanism described in this document enables a single IS-IS
>   routing domain to support different network layer protocol topologies
>   by maintaining separate SPF trees for each network layer protocol.

    Furthermore, it no longer requires a router's protocol support to
    be identical for all interfaces.

[Note that this is not necessary for multiple topologies.]

>3  Maintaining Router Adjacency
>
>   All routers MUST announce the interface-specific protocols-supported
>   capability in IS-IS Hello packet to build the concrete view of the
>   network layer protocol topology in the IS-IS routing domain.
>
>   The "Interface Protocols Supported TLV" is introduced into the IS-IS
>   Hello packet for this purpose. It replaces the existing Protocols
>   Supported TLV that is prohibited from having different protocols-
>   capability for each interface as specified in RFC 1195 [1] section 4.4
>
>   Adjacency is made depending on with which interface the IS-IS Hello
>   packet is exchanged.

Try this:

    The rules for adjacency formation are different for broadcast
    and point-to-point interfaces.

>3.1  Maintaining Adjacencies on Point-to-Point interfaces
>
>   On point-to-point interfaces, all routers MUST be adjacent if the
>   neighboring router supports at least one of the same interface-
>   specific protocols-supported capabilities reported by "Interface
>   Protocols Supported TLV" in IS-IS Hello packet.

This isn't clear.  It says that routers "MUST be adjacent" -- I think
you mean that they must attempt to form an adjacency.  Do you mean to
imply that an adjacency MUST be rejected if there are no matching
protocols?  If so, you need to say it, because it's not strictly
implied.  Also, you need to say what to do if the conditions are NOT
met and the adjacency is rejected.  Also, note that a legacy implementation
might accept the adjacency, since it will ignore the TLVs it doesn't
recognize.

You need to make it clear whether the old protocols-supported TLV
should be included or excluded.  Above you say it "replaces", but
it isn't clear whether you mean that literally in the PDUs, or
whether you mean that their function replaces the function of the
old TLV.

Hopefully you expect people to include the old option in addition
to the new one.  Otherwise there will be serious problems caused
by simple configuration problems, because without the old option,
an RFC-1195 compliant router is required to assume that the neighbor
is an OSI-only router.

You need to make a lot of behavior very clear here.

>3.2  Maintaining Adjacencies on Broadcast interfaces
>
>   On broadcast interfaces, all routers MUST be adjacent regardless of
>   the neighbor's interface-specific protocols-supported capability
>   reported by "Interface Protocols Supported TLV" in IS-IS Hello
>   packet.

As above, "MUST be adjacent" isn't good spec-writing.  Talk about
what a router should do, not about what is true.  Are two routers
adjacent if they have a connecting link, or only if they form
adjacencies with each other?  Avoid that kind of confusion by
stating specifically what they are required to do.  In this case,
what you mean is:

    A router MUST NOT check Interface Protocols Supported TLVs
    for a protocol match when deciding whether to accept or reject
    a received IIH PDU.

You must state exactly what the router should do if it receives
a PDU with the old TLV present, or with both old and new TLV
present (if that is permitted -- and if it isn't, then there
will be a LOT of problems!)

>   There is no change regarding Designated IS selection, CSNP and CSNP
>   with ISO 10589 [3].
>
>
>4  Advertising Protocols Supported Sub-TLV in Extended IS Reachability
>   TLV
>
>   The routing capability of network layer protocols between two
>   neighboring routers MUST be encoded by "Protocols Supported Sub-TLV"
>   in the Extended IS Reachability TLV [4]. This sub-TLV replaces the
>   existing Protocols Supported TLV in LSP that contains only the node-
>   specific routing capability of the network layer protocols.
>
>   Encoding is made differently depending on which network the
>   neighboring router exists on.

I think you mean:

    The rules for encoding this sub-TLV depend on the type of
    interface.

Note that "which network" does NOT mean "what type of network".

>4.1  Protocols Supported Sub-TLV for Point-to-Point Interface Neighbors
>
>   On point-to-point interfaces, "Protocols Supported Sub-TLV" MUST be
>   encoded by ORing the local side of interface-specific protocols-
>   supported capability with the remote side of interface-specific
>   protocols-supported capability, which is reported by the "Interface
>   Protocols Supported TLV" in the neighboring router's IS-IS Hello
>   packet.

Don't you mean AND-ing?  If I support IPV4 and OSI and he supports IPV4
and IPV6, then I mark all three protocols?  I doubt it!

Regards,
Jeff

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Wed, 05 Feb 2003 17:55:05 -0500

Sorry, should have proofread first ...

At 05:40 PM 2/5/2003, Jeff Learman wrote:

>different interfaces, I have advocated this solution since I first

  1195-supported ...