Subject: [Isis-wg] Feedback on IS-IS Automatic Encapsulation

From: Pekka Savola <[email-masked]>
Date: Sat, 19 Jul 2003 10:32:20 +0300 (EEST)

Hi,

I was asked to review the IS-IS Automatic Encapsulation document.

Overall, the specification is of very high quality one seldom gets to review
(thanks!), but I do not think this is architecturally or operationally the
right way to solve the problem.  Therefore I do not recommend on continuing
with the work.

subtantive comments
-------------------

1) area of applicability.

It is not clear what the real applicability of this technique is; or rather,
it is easy to guess one: being able to implement automatic IPv6-over-IPv4
tunneling mechanism in a routing protocol (similar have been proposed for
OSPF, and for BGP multiple times) so that it would be possible to avoid
upgrading some of the routers to handle dual protocols.

The operational community and v6ops working group has been very hesitant
about techniques like these, and as of yet, the v6ops working group has not
been able to determine any real use cases for techniques like this.  If
asked at any point (with current knowledge), the v6ops working group would
not recommend specifying or publishing this mechanism.

Instead of real deployment of dual-stack networks, 
we add more code to the routers, and add hacks/features
which add significantly to the complexity of the code and the network.

Note that the multiple topology IS-IS specification would probably satisfy
the requirements of partial IPv4/IPv6 deployment in a simpler manner, if
really necessary.  As an aside, we run an IPv4/IPv6 backbone, use IS-IS as
our IPv6 routing protocol, and haven't had *any* need for even
multiple-topology IS-IS (and I'm not sure if even that is needed).

In short, I do not believe this work should be continued.

2) operational requirements.

There is always a desire to be able to manage
and maintain the interfaces of routers.  In particular, it is a strict
requirement to know of things such as packet/byte counts, error counts, etc.
-- using a command-line interface as well as other management tools such as
SNMP.

As far as I know, the document does not take stance on this at all.  The
probable implementation technique is probably some kind of generic
tunneling mechanism pseudo-interface which includes all of this information. 
In this particular case, it might also be desirable to be able to see
between which intermediate systems automatic tunnels have been built, how
much traffic has been passed through them etc.  This is to be able to see
whether the implementation is working as expected, i.e. encapsulating
towards directions it should, and not encapsulating to those directions it
should not.

It is worth considering whether this is something to mention in the
specification.

3) a doubt about specification.

I note that the pseudocode for Dijkstra's new algorithm appears quite
complex and is 4 pages long.

I note that there is a possibility of IPR claims on this subject.  This may
or may not be a significant drawback for the specification and
implementation.

4) two significant technical worries about the specification.

   An IS that also supports manually configured tunnels will need to
   check that a packet has not arrived over a manual tunnel in the
   normal way before discarding it.

==> no way to check that for certain, because there could be a configured
(GRE) tunnel between the two systems (without IS-IS being run over one) as
it is.

      Encapsulated packets should never arrive from any source other
      than another IS in the same level-1 area or level-2 subdomain,
      and this MAY then be used as the basis of a security filter.

==> how do you know if the source address correspons to the address of
another IS?  Note that nowhere does it specify which source address to use
when encapsulating a packet, only that it must equal to the identity of the
IS (whatever that means).

==> note that in general, automatic tunneling techniques have been
considered as a rather dubious area of work, security-wise.  Luckily enough,
this specification luckily describes some mechanisms to mitigate this
threat.

editorial
---------

==> as the length is more than 15 pages, a table-of-contents is required

==> the abstract has references (disallowed), and is too long; perhaps the
distinction between an abstract/introduction is not clear.

  The IETF is advised of potential intellectual property rights in
   regard to some or all of the specification contained in this
   document. For more information consult the online list for notices
   and/or updates.

==> this should be removed and moved to a full-flegded IPR Statement at the
end, before the Copyright Notice section; like:

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

2.Introduction

==> s/2./2. / (and similar elsewhere)

3.The automatic encapsulation mechanism.

==> s/mechanism./mechanism/ (similar everywhere)
==> the title should be written like: "The Automatic Encapsulation
Mechanism"

   7.1 Injection of IP and CLNP packets into the network

      An IS that employs automatic encapsulation is required to
      unencapsulate any incoming packet that is of a an advertised
      encapsulation mode, and forward the contents.

==> s/of a/of/
==> still a bit unclear, maybe change s/that is of/that uses/ ?

8.References

==> references need to split to normative/informative

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: Albert Tian <[email-masked]>
Date: Tue, 22 Jul 2003 16:21:13 -0700

Hi, Pekka,

Pekka Savola wrote:

[snip]

> multiple-topology IS-IS (and I'm not sure if even that is needed).

Just a quick comment on your side note. 

Using the single-topology ipv6 ( as opposed to multi-topology ipv6 ), you need a
flag day to upgrade all your routers and turn it on on all interfaces. Using
multi-topology gives you more control regarding to which protocol goes where and
allows you to roll out ipv6 incrementally. For a sizable network, these
flexibilities will probably generate some demand for MT.

Cheers,

Albert