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

From: Pekka Savola <[email-masked]>
Date: Mon, 4 Aug 2003 12:02:47 +0300 (EEST)

Hi,

On Sun, 27 Jul 2003 [email-masked] wrote:
> Do you accept what I said about the usefulness of autoencap in SONET/SDH DCN 
> networks ?

I do not know those networks and environemtns in enough detail to comment 
for certainty, but their characteristics seemed to be slightly different 
than those of a typical Internet network.

> On 20 Jul 2003 at 1:13, Philip Christian wrote:
> 
> > 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
> 
> 

-- 
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