draft-ietf-ospf-2547-dnbit-02.txt   draft-ietf-ospf-2547-dnbit-03.txt 
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Peter Psenak Internet Draft Peter Psenak
Expiration Date: June 2004 Cisco Systems, Inc. Expiration Date: July 2004 Cisco Systems, Inc.
Padma Pillay-Esnault Padma Pillay-Esnault
Juniper Networks, Inc. Juniper Networks, Inc.
December 2003 January 2004
Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs
draft-ietf-ospf-2547-dnbit-02.txt draft-ietf-ospf-2547-dnbit-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
[VPN] describes a method by which a Service Provider (SP) may This document specifies a procedure that deals with a particular
provide an "IP VPN" service to its customers. In VPNs of that sort, issue that may arise when a Service Provider (SP) provides "BGP/MPLS
a Customer Edge (CE) Router and a Provider Edge Router become routing IP VPN" service to a customer, and the customer uses OSPF to
peers, and the customer routes are sent to the SP. BGP is then used advertise its routes to the SP. In this situation, a Customer Edge
to carry the customer routes across the SP's backbone to other PE (CE) Router and a Provider Edge (PE) Router are OSPF peers, and
routers, and the routes are then sent to other CE routers. Since CE customer routes are sent via OSPF from the CE to the PE. The
routers and PE routers are routing peers, it is customary to run a customer routes are converted into BGP routes, and BGP carries them
routing protocol between them. [VPN] allows a number of different across the backbone to other PE routers. The routes are then
PE-CE protocols. If OSPF is used as the PE-CE routing protocol, the converted back to OSPF routes sent via OSPF to other CE routers. As
PE must execute additional procedures not specified in [VPN]; these a result of converting the routes from OSPF to BGP and back to OSPF,
procedures are specified in [OSPF-VPN]. These additional procedures some of the information needed to prevent loops may be lost. A
translate customer OSPF routes from a CE router into BGP routes. The procedure is needed to ensure that once a route is sent from a PE to
BGP routes are sent to the other PE routers, which translate them a CE, the route will be ignored by any PE which receives it back from
back into OSPF routes, and then distribute them to CE routers. a CE. This document specifies the necessary procedure, using one of
During this translation, some of the information needed to prevent the options bits in the LSA (Link State Advertisements) to indicate
loops may be lost. The procedures specified in this document remedy that an LSA has already been forwarded by a PE, and should be ignored
this situation by specifying that one of the options bits in the LSA by any other PEs that see it.
(Link State Advertisements) header be used to ensure that when a VPN
route is sent from a PE to a CE, the route will be ignored by any PE
which receives it back from a CE.
Table of Contents Table of Contents
1 Specification of Requirements ........................ 2 1 Specification of Requirements ........................ 2
2 Introduction ......................................... 2 2 Introduction ......................................... 2
3 Information Loss and Loops ........................... 4 3 Information Loss and Loops ........................... 4
4 Using the LSA Options to Prevent Loops ............... 5 4 Using the LSA Options to Prevent Loops ............... 5
5 Acknowledgments ...................................... 5 5 Security Considerations .............................. 5
6 Authors' Addresses ................................... 6 6 Acknowledgments ...................................... 6
7 Normative References ................................. 6 7 Authors' Addresses ................................... 6
8 Normative References ................................. 6
9 Intellectual Property ................................ 7
10 Full Copyright Statement ............................. 7
1. Specification of Requirements 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. Introduction 2. Introduction
[VPN] describes a method by which a Service Provider (SP) can use its [VPN] describes a method by which a Service Provider (SP) can use its
skipping to change at page 5, line 11 skipping to change at page 5, line 11
router. If the PE-CE link is an area 0 link, then it is possible for router. If the PE-CE link is an area 0 link, then it is possible for
the PE to receive, over that link, a summary LSA which originated at the PE to receive, over that link, a summary LSA which originated at
another PE router. Thus we need some way of marking a summary LSA to another PE router. Thus we need some way of marking a summary LSA to
indicate that it is carrying information about a path via a PE indicate that it is carrying information about a path via a PE
router. router.
4. Using the LSA Options to Prevent Loops 4. Using the LSA Options to Prevent Loops
The high-order bit of the LSA Options field (a previously unused bit) The high-order bit of the LSA Options field (a previously unused bit)
is used to solve the problem described in the previous section. We is used to solve the problem described in the previous section. We
refer to this bit as the DN bit. When an LSA is sent from a PE to a refer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent
CE, the DN bit MUST be set. from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear
in all other LSA types.
+-------------------------------------+ +-------------------------------------+
| DN | * | DC | EA | N/P | MC | E | * | | DN | * | DC | EA | N/P | MC | E | * |
+-------------------------------------+ +-------------------------------------+
Options Field with DN Bit Options Field with DN Bit
(RFC 2328, Section A.2) (RFC 2328, Section A.2)
When the PE receives, from a CE router, an LSA with the DN bit set, When the PE receives, from a CE router, a type 3, 5, or 7 LSA with
the information from that LSA MUST NOT be used during the OSPF route the DN bit set, the information from that LSA MUST NOT be used during
calculation. As a result, the LSA is not translated into a BGP the OSPF route calculation. As a result, the LSA is not translated
route. into a BGP route. The DN bit MUST be ignored in all other LSA types.
This prevents routes learned via BGP from being redistributed to BGP. This prevents routes learned via BGP from being redistributed to BGP.
Note that the DN bit has no other effect on LSA handling. In Note that the DN bit has no other effect on LSA handling. In
particular, an LSA with the DN bit set will be put in the topological particular, an LSA with the DN bit set will be put in the topological
database, aged, flooded, etc., just as if DN was not set. database, aged, flooded, etc., just as if DN was not set.
5. Acknowledgments 5. Security Considerations
An attacker may cause the DN bit to be set, in an LSA traveling from
CE to PE, when the DN bit should really be clear. This may cause the
address prefixes mentioned in that LSA to be unreachable from other
sites of the VPN. Similarly, an attacker may cause the DN bit to be
clear, in an LSA traveling in either direction, when the DN bit
should really be set. This may cause routing loops for traffic which
is destined to the address prefixes mentioned in that LSA.
These possibilities may be eliminated by using cryptographic
authentication as specified in section D of [OSPF].
6. Acknowledgments
The idea of using the high-order options bit for this purpose is due The idea of using the high-order options bit for this purpose is due
to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this
work. We also wish to thank Acee Lindem for his helpful comments. work. We also wish to thank Acee Lindem for his helpful comments.
6. Authors' Addresses 7. Authors' Addresses
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
E-mail: erosen@cisco.com E-mail: erosen@cisco.com
Peter Psenak Peter Psenak
Parc Pegasus, Parc Pegasus,
skipping to change at page 6, line 29 skipping to change at page 6, line 35
E-mail: ppsenak@cisco.com E-mail: ppsenak@cisco.com
Padma Pillay-Esnault Padma Pillay-Esnault
Juniper Networks Juniper Networks
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
E-mail: padma@juniper.net E-mail: padma@juniper.net
7. Normative References 8. Normative References
[OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998 [OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998
[VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen, [VPN] "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen,
Rekhter, et. al., September 2003 Rekhter, et. al., September 2003
[OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft- [OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft-
ietf-l3vpn-ospf-2547-00.txt, Rosen, Psenak, Pillay-Esnault, June 2003 ietf-l3vpn-ospf-2547-00.txt, Rosen, Psenak, Pillay-Esnault, June 2003
9. Intellectual Property
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.
10. Full Copyright Statement
"Copyright (C) The Internet Society (2004). All Rights Reserved.
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."
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/