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

From: Philip Christian <[email-masked]>
Date: Sun, 20 Jul 2003 01:13:28 +0100 (BST)

I always felt that automatic encapsulation might be of
less practical use in the Internet 
than in the context in which it was thought of, and
that is in SDH/SONET DCN 
networks.

Most Internet routers (more probably all) are
reasonably easily upgradable, and 
operators probably don't mind taking a router out of
service for a while in order to 
upgrade it to IPv6.  The only slight problem that they
have is that because of IS-IS 
topological restrictions they shouldn't really forward
any IPv6 traffic in the level-1 area or 
level-2 subdomain until all of the routers have been
upgraded, unless they use 
something like MT.

One slight advantage might be to tunnel v6 over v4 to
get past routers that have 
hardware forwarding of v4 but software forwarding for
v6, another (compared with 6to4)
is that there is no one explicit gateway.  With
automatic encap one can have as many 
tunnelling gateways as one wishes and let IS-IS choose
one.

SDH/SONET networks are different.  Some SDH/SONET ADMs
are twenty years old, 
and only forward CLNP, and will most likely never be
able to forward IP.  Moreover, 
restarting or rebooting one of these boxes that has
live traffic on it is simply out of the 
question.

One solution is to use manually configured RFC 3147
tunnels in order to run IP traffic 
through these old ADMs.  Most likely many vendors will
offer this option.  The problem 
with manual tunnels is that in order to achieve any
redundancy one has to run a routing 
protocol inside the tunnel.

The D1-D3 overhead channel in SDH/SONET is only
192kbps.  Moreover many of the 
older ADMs may not even be able to forward 192kbps. 
One popular ADM can only 
forward about 128kbps before it runs out of processing
power.

This means that if one runs more than about 10 or 12
tunnels, each with an adjacency 
maintained inside it, then one can very quickly run
out of bandwidth just because of all 
the hellos and LSPs/LSAs.  Each time the topology
changes the LSPs/LSAs get flooded 
down all interfaces and all tunnels, and if there are
10 tunnels then that is a lot of 
packets (well more than 192kbps anyway).  Pretty soon
adjacencies in the tunnels fail 
causing more topology change and eventual complete
instability.

Automatic encapsulation solves this problem because
there are no tunnel "interfaces" 
as such, and only one adjacency to maintain, which is
the original IS-IS one.

The other beauty of automatic encapsulation is that
the tunnels don't need to be 
configured, and then configured again for redundancy. 
They just happen automatically.

For this reason I expect automatic encapsulation to
become quite popular amongst 
SHD/SONET vendors.  It is really an answer to their
backward compatibility and support 
issues, as they can provide IP management to their new
ADMs without needing to 
upgrade the old ones, in a scalable and reliable way
and without a lot of configuration 
needed.

This stuff is already out there in ITU-T G.7712 and it
will happen.  The question may be 
simply whether and how to document it in the IETF.

I accept many of the comments in your e-mail, however
I feel that the comments on the
 pseudo code are not fair.  Pseudo code of Dijkstra's
algorithm already appears in ISO
 10589 and in RFC 1195, and is already about four
pages long in those documents.  
The changes made compared with the pseudo code in RFC
1195 really only amount to
a few lines.

Secondly I have not seen any OSPF or BGB proposal that
has been progressed quite to
this level of functionality or usefulness.  I really
don't believe that this can be done with 
OSPF as IPv4 is so imbedded in OSPFv2 and IPv6 so
imbedded in OSPFv3.  This 
approach works in IS-IS only because IS-IS all about
discribing topology independantly 
of network layer protocols.  I have little knowledge
of BGP.

Philip Christian

On 19 Jul 2003 at 10:32, Pekka Savola wrote:

> 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

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

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

---

From: [email-masked]
Date: Sun, 27 Jul 2003 23:10:51 +0100

Pekka,

Do you accept what I said about the usefulness of autoencap in SONET/SDH DCN 
networks ?

If one accepts that this is going to get implemented by the ITU-T folks, how do you think 
that the IETF ISIS WG should handle it ?

Philip