Subject: draft-eng-nalawade-ospf-tunnel-cap-00.txt

From: Acee Lindem <[email-masked]>
Date: Tue, 28 Oct 2003 11:04:09 -0500

There has been some discussion of this draft off-list and I decided it
time to bring to the list rather than continue with multiple off-list
e-mail threads.

Here are the issues as I see them.

   1. Should OSPF be used for tunnel auto-configuration?

      The arguments for this are that OSPF is used for TE and
      this is yet another opaque application. Additionally, one
      proposed TE application (mesh group) is related to
      auto-configuration.

      The arguments against is that we must be very careful what
      we put in the IGP.

      I don't feel that strongly one way or another here. The thing
      about this application is that it doesn't really modify any
      basic OSPF mechanisms so it only has impact on the OSPF routing
      domain if it is used.

      My biggest fear would be that if this draft is accepted it
      would only be the first of a torrent of auto-configuration
      drafts.

   2. If the answer to #1 is yes, do we want to use the OSPF capability
      opaque LSA?

      As an author of the capabilities draft, I'd say "no" since there
      is a variable amount of information that may be advertised and we
      don't want to make the capabilities LSA an all purpose container for
      multitudes of TLVs. Rather it is meant to contain the router's
      overall capabilities and possibily a sub-TLV or two describing
      the a capability. While the techniques for concatenating LSAs
      are well-known, there really isn't any advantage here of stuffing
      all the local tunnel endpoints into the capabilities LSA.

      In short, if this application is worth doing it is worth allocating
      an opaque LSA type (and OSPFv3 LSA type) for it.

   3. Percisely how will the opaque LSA be used? When will the tunnel be
      created, deleted, brought up/down? How does tunnel group ID come
      into play? Must there be OSPF connectivity for the tunnel to be
      considered up or will any type of route do?

      I believe the authors are in agreement that more specification is
      needed for this to be a viable draft that would facilitate
      interoperable implementations.

Thanks,
Acee

Network Working Group                                  Sandy Eng
Internet Draft                                         Gargi Nalawade
Expires: March 2004                                    Peter Psenak
                                                       Cisco Systems

                      OSPF Tunnel capability TLVs

               draft-eng-nalawade-ospf-tunnel-cap-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   As increasing number of tunnels are deployed in a Provider core,
   there is a need for improving the efficiency and ease of tunnel
   establishment.  OSPF running as the IGP in a Provider core, can act
   as the signalling agent for the Tunnel endpoints. OSPF can carry
   tunnel endpoint information in the intra-AS scope, easing BGP of the
   extra burden of signalling within the core.

1. Introduction

draft-eng-nalawade-ospf-tunnel-00.txt                                   [Page 1]

Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt              September 2003

   Two end-points of a Tunnel need to know the end-point information and
   its binding to a network address at the remote point. Normally, this
   can be statically shared and configured. But in case of a large
   network where there may be a need for a large number of tunnels. The
   number of tunnel end-points that would need to be configured and
   maintained soon becomes unmanageable. This draft proposes using OSPF
   for signalling the Tunnel endpoints and introdcues an OSPF IPv4
   tunnel capability TLV that will be carried within the OSPF router
   information LSA.

2. Specification

   This document defines a Tunnel TLV to be carried in the OSPF Router
   Information LSA.

   The Tunnel Information TLV has a type of 4. The first twelve bytes
   contain the following :

    - Address Type (2 octects)
    - Reserved (6 octects)
    - Tunnel endpoint address (4 or 16 octects)
    - Tunnel ID (2 Octets)
    - Tunnel-Group ID (2 Octets)

   This is followed by tunnel sub-TLVs which MUST be included.

   The Tunnel TLV looks as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Type =  4             |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Address Type             |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Reserved              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Tunnel endpoint address (4 - 16 octects)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Tunnel ID (2 octects)      |  Tunnel-Group ID (2 octets)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         sub-TLV(s)                            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

draft-eng-nalawade-ospf-tunnel-00.txt                                   [Page 2]

Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt              September 2003

   where

   Type: identifies the Tunnel TLV type and will have a value of 4

   Length: length of the value field in octets

   Address Type : defines the Address-Type used as defined for AFIs by
   [9]

   Tunnel endpoint address : is a 4-octet address for the IPv4 Tunnel
   TLV and 16-octet for the IPv6 Tunnel TLV.

   Tunnel ID : is a 2-octet identifier to identify a Tunnel endpoint

   Tunnel-Group ID : is a 2-octet global group Identifier used by all PE
   endpoints who are interested in establishing tunnel relationships
   with each other.

   sub-TLVs : will contain Tunnel encapsulation sub-TLVs. Eg.

   1 : L2TPv3 Tunnel information

   2 : mGRE Tunnel information

   3 : IPSec Tunnel information

   4 : MPLS Tunnel information

2.1. OSPF L2TPv3 tunnel sub-TLV

   The L2TPv3 Tunnel Information TLV has a type value of 1.  The value
   part of the L2TPv3 Tunnel Information Type contains the following :

    - Preference (2 Octets)
    - Flags (1 Octet)
    - Cookie Length (1 Octet)
    - Session ID (4 Octets)
    - Cookie     (Variable)

   The L2TPv3 Tunnel sub-TLV looks as follows :

draft-eng-nalawade-ospf-tunnel-00.txt                                   [Page 3]

Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt              September 2003

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Sub-Type = 1          |  Length (Variable)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Preference (2 octects)     |S| Flags       | Cookie Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Session ID (4 Octects)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Cookie (Variable, 0 or 8 octexts)            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where

   Length : is a multiple of 4 octects.

   Preference : is a 2-octet field containing a Preference associated
   with the TLV. The Preference value indicates a preferred ordering of
   tunneling encapsulations according to the sender. The recipient of
   the information SHOULD take the sender's preference into account in
   selecting which encapsulation it will use. A higher value indicates a
   higher preference.

   Flags : is a 1-octet field containing flag-bits. The leftmost bit
   indicates whether Sequence numbering is to be used or not. The
   remaining bits are reserved for future use.

   Cookie Length : is a 1-octet field that contains the length of the
   variable length Cookie.

   Session ID : is a 4-octet field containing a non-zero identifier for
   a session.

   Cookie : is a variable length (maximum 64 bits), value used by L2TPv3
   to check the association of a received data message with the session
   identified by the Session ID.

2.2. OSPF mGRE Tunnel sub-TLV

   The OSPF mGRE Tunnel sub-TLV has a type value of 2.  The value part
   of the mGRE Tunnel Information Type contains the following :

draft-eng-nalawade-ospf-tunnel-00.txt                                   [Page 4]

Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt              September 2003

   - Preference (2 Octets)
   - Flags (1 Octet)
   - mGRE Key   (0 or 4 Octets)

   The mGRE Tunnel sub-TLV looks as follows :

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Sub-Type = 2         |  Length (8 octects)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Preference (2 octects)  |S|K|    Flags  |  Reserved       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   mGRE Key (4 Octects)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where

   Length : is 8 octets.

   Preference : is a 2-octet field containing a Preference associated
   with the TLV. The Preference value indicates a preferred ordering of
   tunneling encapsulations according to the sender. The recipient of
   the information SHOULD take the sender's preference into account in
   selecting which encapsulation it will use. A higher value indicates a
   higher preference.

   Flags : is 1-octet field containing flag-bits. The leftmost bit
   indicates whether Sequence numbering is to be used or not. The 2nd
   bit indicates whether an mGRE Key is present or not. The remaining
   bits are reserved for future use.

   mGRE Key : A 4-octet field containing an optional mGRE Key.

3. Operation

   A router must originate a new OSPF router information LSA whenever
   the content of the Tunnel TLV changes or whenever required by the
   regular OSPF procedure (LSA refresh (every LSRefreshTime, ...)).

   The Tunnel TLV may be carried within either a type 10 or 11 router
   information LSA. As defined in RFC2370, an opaque LSA has a flooding
   scope determined by its LSA type:

draft-eng-nalawade-ospf-tunnel-00.txt                                   [Page 5]

Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt              September 2003

    - area-local (type 10)
    - entire OSPF routing domain (type 11)

   If all Tunnel endpoints lie within a single area, a type 10 router
   infomation LSA must be generated.

   If the Tunnel endpoints span multiple OSPF areas, a type 11 router
   information LSA must be generated.

4. Deployment Considerations and Interoperability

   In an IP VPN environment, this specification does not require any
   provider core routers to be upgraded. Only routers who are interested
   to be tunnel endpoints are required to understand this specification.
   This poses no backward compatibility issue as routers which do not
   understand this specification will simply ignore the TLVs.

5. Security Considerations

   This extension to OSPF does not change the underlying security
   issues.

6. Acknowledgements

   The authors would like to thank Steven Luong, Raja Daoud, Dan Tappan,
   Jean-Phillip Vasseur and Eric Rosen for their inputs and comments.

7. References

   [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. .

   [2] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF",
   draft-katz-yeung-ospf-traffic-04.txt

   [3] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998

   [4]  Aggarwal et all, ''Extensions to IS-IS and OSPF for Advertising
   Optional Router Capabilities'', Internet draft, draft-raggarwa-igp-
   cap-01.txt, October 2002.

   [5] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-
   4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.

draft-eng-nalawade-ospf-tunnel-00.txt                                   [Page 6]

Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt              September 2003

   [6] Nalawade G., Kapoor R., Tappan D., "BGP IPv4-Tunnel SAFI",
   draft-nalawade-kapoor-tunnel-safi-00.txt, work in progress.

   [7] Bates et al, Multiprotocol Extensions for BGP-4, draft- ietf-
   idr-rfc2858bis-02.txt, work in progress.

   [8] Kent, S., and R. Atkinson, "Security Architecture for the
   Internet Protocol", RFC 2401, November 1998.

   [9] http://www.iana.org/assignments/address-family-numbers

8. Authors' Addresses

   Sandy Eng mailto:[email-masked]

   Gargi Nalawade mailto:[email-masked]

   Peter Psenak mailto:[email-masked]

   Cisco Systems, Inc 170 West Tasman Drive San Jose, CA 95134

9. 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 implementers 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.

10. Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

draft-eng-nalawade-ospf-tunnel-00.txt                                   [Page 7]

Internet Draft draft-eng-nalawade-ospf-tunnel-00.txt              September 2003

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.  The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its successors or
   assigns.  This document and the information contained herein is
   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

draft-eng-nalawade-ospf-tunnel-00.txt                                   [Page 8]

---

From: Sandy Eng <[email-masked]>
Date: Tue, 28 Oct 2003 09:55:33 -0800

Acee,

Continuing our discussion, and reiterating some points we had made -

>      would only be the first of a torrent of auto-configuration

We are not just dealing with auto-configuration here, but announcing a
unique capability a router has for a specific tunnel type. Applications
which use this capability can then take respective actions.

>      overall capabilities and possibily a sub-TLV or two describing

The draft is describing exactly this. We are not over stuffing the TLV
with more than one or two sub-TLV(s) per PE announing the capability.

Thanks,
Sandy

> ------------------------------------------------------------------------
>
>
>
>
>
>
>

---

From: Gargi Nalawade <[email-masked]>
Date: Tue, 28 Oct 2003 10:08:18 -0800

Acee,

>      would only be the first of a torrent of auto-configuration

You mean second :) Let me point out though that this isnt a new application.
The basic application is a customer-driven requirement for advertising tunnel
capabilities and info. The config-reduction is a by-product of that. Also,
this is simply a generalized mechanism for advertising the tunnel capabilties.

>      the a capability. While the techniques for concatenating LSAs

That is exactly what it is used for by this draft as well. To advertise the
Tunnels capability set to the peers.

>      considered up or will any type of route do?

Most of this is implementation-specific really. But to answer your last
question, there needs to be connectivity for the tunnel to be considered
up.

-Gargi

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 28 Oct 2003 19:44:02 +0100

Acee,

>      would only be the first of a torrent of auto-configuration

Second one not first ;). Notice this one submitted a while back:
draft-raszuk-ospf-bgp-peer-discovery-00.txt

 >     1. Should OSPF be used for tunnel auto-configuration?

I think in general this requires a study on a case by case basis. Most
important factors which should be taken into consideration are:

*A* How frequently the information advertised changed - is it static
configuration or dynamic in nature which triggers reflooding ?

*B* Is the application which the uses delivered information limited to
IGP domain or crosses domains ?

*C* What is the amount of information to be flooded (keeping in mind
that majority of P routers - those in the core - will never use it.

*D* What are the alternatives available & _deployed_ today to deliver
the same information to it's users

*E* How often area wide flooding will be sufficient versus domain wide.

Coming back to draft-eng-nalawade-ospf-tunnel-cap-00.txt I see the
following:

Reg A: Info is essentially static except the L2TPv3 cookie rollover
intervals which if implementation permits could be changing periodically

Reg B: I think that in any application of tunnels we can't limit the
scope of use to one IGP domain. There can be a lot of customers who may
never need to go over a domain (which this draft is targeting though).

Reg C: Minimal (comparing to TE at least :):).

Reg D: It is worth noting that there is a few drafts in IDR describing
the ideas for the same information distribution

Reg E: Looking at the most common OSPF topologies I would say that most
tunnels will be build between edge PEs and those in a lot of cases are
located in it's own POP areas. Not to say that there are no customers
who keep most of their PEs on the edges of area 0.

Rgs,
R.