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

Sandy Eng <swkeng@CISCO.COM> Tue, 28 October 2003 17:55 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12924 for <ospf-archive@LISTS.IETF.ORG>; Tue, 28 Oct 2003 12:55:33 -0500 (EST)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00C299A3@cherry.ease.lsoft.com>; Tue, 28 Oct 2003 12:55:42 -0500
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 58961663 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Oct 2003 12:55:39 -0500
Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 28 Oct 2003 12:55:39 -0400
Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9SHtZQY005483 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 28 Oct 2003 09:55:35 -0800 (PST)
Received: from cisco.com (sjc-vpn3-349.cisco.com [10.21.65.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANP34824; Tue, 28 Oct 2003 09:55:33 -0800 (PST)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <3F9E9379.3070602@redback.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID: <3F9EAD95.9050101@cisco.com>
Date: Tue, 28 Oct 2003 09:55:33 -0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Sandy Eng <swkeng@CISCO.COM>
Subject: Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Acee,

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

Acee Lindem wrote:
> 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.

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.

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



>      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:swkeng@cisco.com
>
>    Gargi Nalawade mailto:gargi@cisco.com
>
>    Peter Psenak mailto:ppsenak@cisco.com
>
>    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]
>
>
>