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] > > >
- draft-eng-nalawade-ospf-tunnel-cap-00.txt Acee Lindem
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Sandy Eng
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Gargi Nalawade
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Robert Raszuk
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Rahul Aggarwal
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Gargi Nalawade
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Sandy Eng
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Sastry, Ravi
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Sandy Eng
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Rahul Aggarwal
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Rahul Aggarwal
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Gargi Nalawade
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Sandy Eng
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Robert Raszuk
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Rahul Aggarwal
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Gargi Nalawade
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Gargi Nalawade
- draft-eng-nalawade-ospf-tunnel-cap-00.txt Yakov Rekhter
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Yakov Rekhter
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Robert Raszuk
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Yakov Rekhter
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Robert Raszuk
- Re: draft-eng-nalawade-ospf-tunnel-cap-00.txt Yakov Rekhter