From wwwrun@core3.amsl.com Mon Jan 4 06:15:38 2010 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id ADDD53A6870; Mon, 4 Jan 2010 06:15:38 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100104141538.ADDD53A6870@core3.amsl.com> Date: Mon, 4 Jan 2010 06:15:38 -0800 (PST) Cc: ospf mailing list , ospf chair , Internet Architecture Board , RFC Editor Subject: [OSPF] Protocol Action: 'Advertising a Router's Local Addresses in OSPF TE Extensions' to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2010 14:15:38 -0000 The IESG has approved the following document: - 'Advertising a Router's Local Addresses in OSPF TE Extensions ' as a Proposed Standard This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Ross Callon and Adrian Farrel. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-te-node-addr-07.txt Technical Summary OSPF Traffic Engineering (TE) extensions are used to advertise TE Link State Advertisements (LSAs) containing information about TE- enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE- enabled links, and the local address corresponding to the Router ID. In order to allow other routers in a network to compute Multiprotocol Label Switching (MPLS) traffic engineered Label Switched Paths (TE LSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE. This document describes procedures that enhance OSPF TE to advertise a router's local addresses. Working Group Summary No controversy reported (see PROTO writeup in the ID tracker). At least one CCAMP draft requires this as a normative reference. Document Quality There is one known implementation, but no products (at the current time). Personnel Acee Lindem is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. From christian.vogt@ericsson.com Tue Jan 5 15:26:22 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E0A3A67EF; Tue, 5 Jan 2010 15:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhH5Zg4i1xaR; Tue, 5 Jan 2010 15:26:21 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 38EB03A657C; Tue, 5 Jan 2010 15:26:20 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o05NLKLp020540; Tue, 5 Jan 2010 17:27:31 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.164]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 5 Jan 2010 18:24:16 -0500 From: Christian Vogt To: Acee Lindem Date: Tue, 5 Jan 2010 18:24:14 -0500 Thread-Topic: Gen-ART review of draft-ietf-ospf-af-alt-09 Thread-Index: AcqOXjJ7zIvrKH+uStun6QhjeyAcYA== Message-ID: References: <77E0431C-710C-4F12-B4F4-56528F9A8B6C@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "smirtora@cisco.com" , Gen-ART Mailing List , "ospf@ietf.org" Subject: Re: [OSPF] Gen-ART review of draft-ietf-ospf-af-alt-09 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 23:26:22 -0000 Acee - Excellent. Thank you for addressing my comments. - Christian On Jan 5, 2010, at 14:27, Acee Lindem wrote: > Hi Christian, > I believe I've addressed both of your comments in the draft-ietf-=20 > ospf-af-alt-10.txt version. I did take your suggestion of explicitly =20 > stately that these enhancements only apply when multiple instances =20 > are being used to support multiple address families as defined in =20 > the draft. > > Thanks, > Acee > > |-----Original Message----- > |From: Christian Vogt > |Sent: Wednesday, December 02, 2009 6:18 PM > |To: Gen-ART Mailing List > |Cc: Acee Lindem; smirtora@cisco.com; akr@cisco.com; > |mjbarnes@cisco.com; rahul@juniper.net; Ross Callon; ospf@ietf.org > |Subject: Gen-ART review of draft-ietf-ospf-af-alt-09 > | > |I have been selected as the General Area Review Team (Gen-ART) > |reviewer for this draft (for background on Gen-ART, please see > |http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > | > |Please resolve these comments along with any other Last Call > |comments you may receive. > | > | > |Document..........: draft-ietf-ospf-af-alt-09 > |Reviewer..........: Christian Vogt > |Review date.......: December 2, 2009 > |IESG Telechat date: December 3, 2009 > | > | > |Summary: This draft is basically ready for publication, but has nits > | that should be fixed before publication. > | > | > |The document describes small modifications to the OSPFv3 > |protocol that enable the use of OSPFv3 for multiple address > |families simultaneously. > |The document is well-written and concise, and is ready for =20 > publication. > |However, one nit that should be fixed is the following editorial one: > | > |The document uses the acronym "AF" both to denote the term > |address family, as well as to refer to the OSPF extensions > |being specified in the document (e.g., in the definition of > |the AF bit in section 2.2). > |This is confusing, in particular because "AF" is explicitly > |defined only to mean the former, not the latter. I suggest > |using a different name, e.g., "AF support", to denote the OSPF > |extensions being specified, and adding a definition for this > |to the introduction of the document. > | > |In section 3, "Backwards Compatibility", it may furthermore be > |worth mentioning that all modifications to OSPFv3, as > |specified in this document, exclusively affect the use of > |OSPFv3 for new address families. > |Since this is a prerequisite for backwards compatibility, it > |will further support the backwards compatibility claim of this =20 > section. > | > |- Christian > | > | > | From babukv99@yahoo.com Wed Jan 13 20:12:39 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B8F3A68DF for ; Wed, 13 Jan 2010 20:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zI6UM0LZzbs for ; Wed, 13 Jan 2010 20:12:37 -0800 (PST) Received: from web33404.mail.mud.yahoo.com (web33404.mail.mud.yahoo.com [68.142.206.136]) by core3.amsl.com (Postfix) with SMTP id 2D8EE3A68D7 for ; Wed, 13 Jan 2010 20:12:37 -0800 (PST) Received: (qmail 69261 invoked by uid 60001); 14 Jan 2010 04:12:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1263442352; bh=1fHKqWY+j5hsaHPWLkOymHgIWWllRzPIsycIyhWKqfY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=vNugBZeHCpKXw1EAiu9BSWXoghbs3Hkef/RfHUcazgcnbBj2r3g04E5ORdG/9qPYHQHXdWq7DbPbPZqPqWyVORxUJIeSpgnyy8NPJKVHkQCCKomrjgiETj5DHkeIsa5DF6YTriL67D5kC858F5YyWi2jLnwv8KucuVmoHteiwTA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=3a/Gz96Yuhdb2Uaou1aCt9VWYTJ9XeWtkCtdnQwYKnP8AqZ7zBDsWuUpqaD7HztvFEgyuJ+U2R7Xfm6bLIZT2i01e9pbA4ffLpxIUng8v4DLeKs8EHPT05HQSgxxRv6ED3PiesiwpsIfd12WZTZlWMjaS0fC317tut90xVa5cio=; Message-ID: <540961.64112.qm@web33404.mail.mud.yahoo.com> X-YMail-OSG: 53OsuwEVM1ktW5H0yfB7cyDBt_3axy.Y9WRwQbv9dFRmBHxJS9Cjy_xNAHiAMAoqp4ZMIA8J11pkRxJEUolUm5Ezgb7cPvD3kCNidbZDyFig7vn7ZYzOMOD_KEgAahPhIbZBQtsQ8e5aruNN1v7yQkzic7mxprBzYaumhB5PlQkMeC6t9aEGNVlSksF920j0GwBl63G5XSYXbHlopu1YUvZ6ddY3yOHd1mWXiPxyC6jdHty0ly62NvsDffmPz8WiK55HI_NsyTXd9j_gl0g6nw8SmcgVSSMi0SzMOun2INfizsDfRc8Lp98skRro2NKGn7Ohom50UfQvpyUYLUM8F_OsQKRqrnnp4lm_eSWb6l54mrCRuM_dJioOwtusijTQurm.I.qOPDpEiUau4jKaccGKgvs2n8EMVe77mdwmlbeCkDuAknkFQree2ZN1BhJpo6OrSA-- Received: from [59.92.173.9] by web33404.mail.mud.yahoo.com via HTTP; Wed, 13 Jan 2010 20:12:32 PST X-Mailer: YahooMailClassic/9.0.20 YahooMailWebService/0.8.100.260964 Date: Wed, 13 Jan 2010 20:12:32 -0800 (PST) From: Babu George To: ospf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [OSPF] help needed on ospdf simulator X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 04:19:22 -0000 Hi, I am new to this forum.Can someone give me some tips on how to run the ospf simulator mentioned in attached mail thread.Downloaded the code from the location, but don't know how to proceed.Didn't find any help/install file Thanks Babu A distributed version of John Moy's ospfd simulator is available at http://www.cs.uwm.edu/~mukul/newospfd.html The main changes over the original simulator are: 1) Individual router processes could be run over different machines. 2) Topology changes can be specified in a simulation script. 3) It is possible to associate time requirement with different processing tasks (processing packets, doing Dijkstra calculation etc.) (hence it is possible to track router "busy" periods). 4) Took away the GUI. We have been using the simulator for over 6 months now and hence are pretty confident that it is now bug free. We have used the simulator to do 80 router simulations over 2 linux machines. We have not yet worked on porting it to other OS. We dont yet have extensive documentation for the modified simulator. Some documentation is available on the web page identified above. I will be happy to help any one interested in using this simulator. I will be happy to receive any comments on our modifications. Thanks, Mukul Goyal From wwwrun@core3.amsl.com Fri Jan 15 06:59:55 2010 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 963D128C0D9; Fri, 15 Jan 2010 06:59:55 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100115145955.963D128C0D9@core3.amsl.com> Date: Fri, 15 Jan 2010 06:59:55 -0800 (PST) Cc: ospf mailing list , ospf chair , Internet Architecture Board , RFC Editor Subject: [OSPF] Document Action: 'Extensions to OSPF to Support Mobile Ad Hoc Networking' to Experimental RFC X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 14:59:55 -0000 The IESG has approved the following document: - 'Extensions to OSPF to Support Mobile Ad Hoc Networking ' as an Experimental RFC This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Ross Callon and Adrian Farrel. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-or-03.txt Technical Summary This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extension, called OSPF-OR, includes a mechanism for link-local signaling, a OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. Working Group Summary The OSPF WG was unable to reach concensus on a single MANET OSPF approach and agreed to go forward with the three competing approaches as experimental RFCs. Document Quality Passed idnits. The document has been updated in response to Gen-Art and Sec-Dir comments. The protocol in this document has been simulated, and there are at least two implementations (see PROTO writeup by Acee Lindem in the I.D. Tracker). Personnel Dave Ward was the original responsible AD. Ross Callon is the current responsible AD. Acee Lindem is the Document Shepherd. From rcallon@juniper.net Fri Jan 22 12:20:50 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A87C3A67DF for ; Fri, 22 Jan 2010 12:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.756 X-Spam-Level: X-Spam-Status: No, score=-5.756 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNtLyXC2grbI for ; Fri, 22 Jan 2010 12:20:49 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with ESMTP id F24793A6452 for ; Fri, 22 Jan 2010 12:20:48 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKS1oImcITAg94qW9L4UBNXfaFZ8kfCADp@postini.com; Fri, 22 Jan 2010 12:20:45 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 22 Jan 2010 12:16:59 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 22 Jan 2010 15:16:58 -0500 From: Ross Callon To: "ospf@ietf.org" Date: Fri, 22 Jan 2010 15:16:57 -0500 Thread-Topic: OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' Thread-Index: Acqbn9ipKZ8SgvNZT8aRABlqa+TwCQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB177049A1B0756ADEMBX01WFjnprn_" MIME-Version: 1.0 Cc: Adrian Farrel Subject: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 20:20:50 -0000 --_000_DF7F294AF4153D498141CBEFADB177049A1B0756ADEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for publicat= ion, and is currently in the RFC editor's queue. While this document passed= WG last call in the L3VPN working group, and also passed IETF last call, w= e forgot to either do an last call in the OSPF working group, or to specifi= cally flag the IETF last call to the OSPF working group. With this in mind, we would like to solicit comments on this draft from the= OSPF working group. If there are minor comments we can fix this during AUT= H48. If there are major concerns then we will need to figure out what to do= (which in the most extreme situation might require un-approving the docume= nt). Thus, please review this document and reply to the OSPF working group email= list by the end of next Friday, January 29th, if you have any comments or = concerns. Thanks, Ross (acting in my role as the AD who goofed in this case). --_000_DF7F294AF4153D498141CBEFADB177049A1B0756ADEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for publication, and is currently in the RFC editor's queue. While this documen= t passed WG last call in the L3VPN working group, and also passed IETF last call, we forgot to either do an last call in the OSPF working group, or to specifica= lly flag the IETF last call to the OSPF working group.=

 

With this in mind, we would like to solicit comments on this draft = from the OSPF working group. If there are minor comments we can fix this during AUTH48. If there are major concerns then we will need to figure out what to= do (which in the most extreme situation might require un-approving the documen= t).

 

Thus, please review this document and reply to the OSPF working gro= up email list by the end of next Friday, January 29th, if you have any comments or concerns.

 

Thanks, Ross

(acting in my role as the AD who goofed in this case).

--_000_DF7F294AF4153D498141CBEFADB177049A1B0756ADEMBX01WFjnprn_-- From James.Huang@watchguard.com Mon Jan 25 13:30:36 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7E793A691C for ; Mon, 25 Jan 2010 13:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce7beY8-0C63 for ; Mon, 25 Jan 2010 13:30:32 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id 913003A67F3 for ; Mon, 25 Jan 2010 13:30:32 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA9E05.A3DF5880" Date: Mon, 25 Jan 2010 13:30:38 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F30190F870@ES02CO.wgti.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPF multiple-area network Thread-Index: AcqeBaNDh0GPc2e8SQm8IZRePeSNOA== From: "James Huang" To: Subject: [OSPF] OSPF multiple-area network X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:30:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA9E05.A3DF5880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, When a network is connected to multiple areas (maybe as a stub network), what is the expected behavior according to RFC 2328? In RFC 2328, a "network" route is always associated with a single area. But in the following topology, router R will receive two network-LSAs, one from each attached area: R is connected to area-1 and area-2. R's area-1 neighbor R1 has an interface (part of area-1) connected to a stub network N. R's area-2 neighbor R2 has an interface (part of area-2) also connected to the stub network N.=20 =20 RFC 2328, Sec 16.1, Step (4) has some consideration for resolving conflicting intra-area network routes. But is it applicable to this case? =20 If the routing table entry already exists (i.e., there is already an intra-area route to the destination installed in the routing table), multiple vertices have mapped to the same IP network. For example, this can occur when a new Designated Router is being established. In this case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current routing table entry's Link State Origin has a smaller Link State ID than the newly added vertex' LSA. =20 Also I do not understand this RFC 2382 logic above. Why does it have to compare both the distance and the link state ID. Suppose there are two possible paths, P1 and P2, to a network. P1 is shorter than P2 but P1 has an origin of smaller link state ID. According to this rule, which path will be installed in the routing table depends on the order the LSAs are examined. That seems very strange to me. =20 Thanks, James Huang =20 =20 =20 ------_=_NextPart_001_01CA9E05.A3DF5880 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

         &= nbsp;      When a network is connected to multiple areas (maybe as a stub network), what = is the expected behavior according to RFC 2328?

In RFC 2328, a “network” route is = always associated with a single area.  But in the following topology, = router R will receive two network-LSAs, one from each attached area: =   R is connected to area-1 and area-2.  R’s area-1 neighbor R1 has = an interface (part of area-1) connected to a stub network N.  R’s area-2 = neighbor R2 has an interface (part of area-2) also connected to the stub network = N.

         &= nbsp;     

         &= nbsp;      RFC 2328, Sec 16.1, Step (4) has some consideration for resolving = conflicting intra-area network routes.  But is it applicable to this = case?

 

        &nbs= p;   If the routing table entry = already exists

            (i.e., there is already an intra-area route to the

            destination installed in the routing table), = multiple

            vertices have mapped to the same IP network.  For = example,

            this can occur when a new Designated Router is = being

            established.  In this case, the current routing table = entry

            should be overwritten if and only if the newly found path = is

            just as short and the current routing table entry's = Link

            State Origin has a smaller Link State ID than the = newly

            added vertex' LSA.

 

         &= nbsp;      Also I do not understand this RFC 2382 logic above.  Why does it have to compare both the distance and the link state ID.  Suppose there are = two possible paths, P1 and P2, to a network.  P1 is shorter than P2 but = P1 has an origin of smaller link state ID.  According to this rule, which = path will be installed in the routing table depends on the order the LSAs are examined.  That seems very strange to me.

 

Thanks,

James Huang

 

 

 

------_=_NextPart_001_01CA9E05.A3DF5880-- From acee.lindem@ericsson.com Mon Jan 25 13:36:37 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6083A691F; Mon, 25 Jan 2010 13:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyIp6bPgwVTT; Mon, 25 Jan 2010 13:36:36 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C69E63A691A; Mon, 25 Jan 2010 13:36:36 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o0PLbQuL030386; Mon, 25 Jan 2010 15:37:28 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.185]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 25 Jan 2010 16:36:39 -0500 From: Acee Lindem To: Ross Callon , "l3vpn@ietf.org" Date: Mon, 25 Jan 2010 16:36:35 -0500 Thread-Topic: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' Thread-Index: AcqeBnpNdHPCQk9SSjSNkCbQO3XXpw== Message-ID: <4103179E-4282-4F9C-A96B-F078FD494BDA@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" , Adrian Farrel Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 21:36:37 -0000 Here are my comments: There is a typo on page 14: 0x50 External 0x2005 AS-external-LSA Should be: 0x50 External 0x4005 AS-external-LSA Additionally, I don't think the addition of the instance ID to the OSPFv3 R= oute Extended Communities attribute accomplishes all the much. Assuming an = IPv6 route is advertised once in BGP for a given VRF, how does one advertis= e it into multiple PE OSPFv3 instances associated with the VRF? Given that = secondary routing domains can be configured for OSPFv3 PE instances (as des= cribed in 4.1.2), it would seem you'd need different routing domains for ea= ch instance and accomplish this. However, if you need to use different doma= in IDs and keep the instance ID common, what is the utility of the instance= ID as an additional route demultiplexer? There whole discussion of instanc= e ID in sections 4.1 and 4.1.1 doesn't make sense to me. The OSPFv3 instanc= e ID is used in OSPFv3 packets in order to allow multiple instances to shar= e a link. Hence, the only place it maps directly to this draft is for the s= ham link as described in section 5. In order to advertise a route into mult= iple instances in the same VRF, one would need to associate multiple OSPFv3= Route Extended Communities with the route. If this is the indent, the draf= t should should state as such. However, there is no reason why OSPFv2 PE-CE= , as described in RFC 4577, couldn't also take advantage of such of mechani= sm. Thanks, Acee On Jan 22, 2010, at 3:16 PM, Ross Callon wrote: draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for publicat= ion, and is currently in the RFC editor's queue. While this document passed= WG last call in the L3VPN working group, and also passed IETF last call, w= e forgot to either do an last call in the OSPF working group, or to specifi= cally flag the IETF last call to the OSPF working group. With this in mind, we would like to solicit comments on this draft from the= OSPF working group. If there are minor comments we can fix this during AUT= H48. If there are major concerns then we will need to figure out what to do= (which in the most extreme situation might require un-approving the docume= nt). Thus, please review this document and reply to the OSPF working group email= list by the end of next Friday, January 29th, if you have any comments or = concerns. Thanks, Ross (acting in my role as the AD who goofed in this case). _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Mon Jan 25 14:47:49 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9753A68DD for ; Mon, 25 Jan 2010 14:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5dPKa9UmFK4 for ; Mon, 25 Jan 2010 14:47:48 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 3481C3A68BE for ; Mon, 25 Jan 2010 14:47:48 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o0PMmfln028172; Mon, 25 Jan 2010 16:48:41 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.185]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 25 Jan 2010 17:47:54 -0500 From: Acee Lindem To: James Huang Date: Mon, 25 Jan 2010 17:47:49 -0500 Thread-Topic: [OSPF] OSPF multiple-area network Thread-Index: AcqeEG5VQMS6waZMTNOKANqdUglUdg== Message-ID: References: <7C3D15DD6E8F464998CA1470D8A322F30190F870@ES02CO.wgti.net> In-Reply-To: <7C3D15DD6E8F464998CA1470D8A322F30190F870@ES02CO.wgti.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF multiple-area network X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:47:49 -0000 Hi James, The excerpted text is referring to multiple LSAs in the same area - not LSA= s in different areas. If you read it closely you'll see that the example gi= ven is a transient condition. While some vendors do, in fact, support an IP= subnet connected to multiple areas, this is not considered to be a valid = topology and is not addressed by RFC 2328. Consider the following excerpt f= rom page 6 of RFC 2328: OSPF allows sets of networks to be grouped together. Such a grouping is called an area. The topology of an area is hidden from the rest of the Autonomous System. This information hiding enables a significant reduction in routing traffic. Also, routing within the area is determined only by the area's own topology, lending the area protection from bad routing data. An area is a generalization of an IP subnetted network. Hope this Helps, Acee On Jan 25, 2010, at 4:30 PM, James Huang wrote: Hi all, When a network is connected to multiple areas (maybe as a s= tub network), what is the expected behavior according to RFC 2328? In RFC 2328, a =93network=94 route is always associated with a single area.= But in the following topology, router R will receive two network-LSAs, on= e from each attached area: R is connected to area-1 and area-2. R=92s ar= ea-1 neighbor R1 has an interface (part of area-1) connected to a stub netw= ork N. R=92s area-2 neighbor R2 has an interface (part of area-2) also con= nected to the stub network N. RFC 2328, Sec 16.1, Step (4) has some consideration for res= olving conflicting intra-area network routes. But is it applicable to this= case? If the routing table entry already exists (i.e., there is already an intra-area route to the destination installed in the routing table), multiple vertices have mapped to the same IP network. For example, this can occur when a new Designated Router is being established. In this case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current routing table entry's Link State Origin has a smaller Link State ID than the newly added vertex' LSA. Also I do not understand this RFC 2382 logic above. Why do= es it have to compare both the distance and the link state ID. Suppose the= re are two possible paths, P1 and P2, to a network. P1 is shorter than P2 = but P1 has an origin of smaller link state ID. According to this rule, whi= ch path will be installed in the routing table depends on the order the LSA= s are examined. That seems very strange to me. Thanks, James Huang _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From James.Huang@watchguard.com Mon Jan 25 15:35:54 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD3F3A6917 for ; Mon, 25 Jan 2010 15:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w07wRdK22Lxz for ; Mon, 25 Jan 2010 15:35:53 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id A11B93A6812 for ; Mon, 25 Jan 2010 15:35:52 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 15:35:59 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F3019EE0A5@ES02CO.wgti.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF multiple-area network Thread-Index: AcqeEHBqdF2s+vqaS7mPiqcPUptJpAABJYIw References: <7C3D15DD6E8F464998CA1470D8A322F30190F870@ES02CO.wgti.net> From: "James Huang" To: "Acee Lindem" Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF multiple-area network X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 23:35:54 -0000 Hi Acee, Thanks for the reply. I agreed with you that RFC 2328 assumes each network can only reside in one area and that is what I always assume too. But when I tried to find a scenario to explain the reason for re-running the complete SPF route computation starting from sec 16.1 in Case 2 of sec 16.5 (incremental updates: summary-LSAs), I just cannot find one unless there is a multi-area network. If you have one scenario to explain Case 2 of sec 16.5, can you show it? Thanks, James Huang =20 -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Monday, January 25, 2010 2:48 PM To: James Huang Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF multiple-area network Hi James, The excerpted text is referring to multiple LSAs in the same area - not LSAs in different areas. If you read it closely you'll see that the example given is a transient condition. While some vendors do, in fact, support an IP subnet connected to multiple areas, this is not considered to be a valid topology and is not addressed by RFC 2328. Consider the following excerpt from page 6 of RFC 2328: OSPF allows sets of networks to be grouped together. Such a grouping is called an area. The topology of an area is hidden from the rest of the Autonomous System. This information hiding enables a significant reduction in routing traffic. Also, routing within the area is determined only by the area's own topology, lending the area protection from bad routing data. An area is a generalization of an IP subnetted network. Hope this Helps, Acee On Jan 25, 2010, at 4:30 PM, James Huang wrote: Hi all, When a network is connected to multiple areas (maybe as a stub network), what is the expected behavior according to RFC 2328? In RFC 2328, a "network" route is always associated with a single area. But in the following topology, router R will receive two network-LSAs, one from each attached area: R is connected to area-1 and area-2. R's area-1 neighbor R1 has an interface (part of area-1) connected to a stub network N. R's area-2 neighbor R2 has an interface (part of area-2) also connected to the stub network N. RFC 2328, Sec 16.1, Step (4) has some consideration for resolving conflicting intra-area network routes. But is it applicable to this case? If the routing table entry already exists (i.e., there is already an intra-area route to the destination installed in the routing table), multiple vertices have mapped to the same IP network. For example, this can occur when a new Designated Router is being established. In this case, the current routing table entry should be overwritten if and only if the newly found path is just as short and the current routing table entry's Link State Origin has a smaller Link State ID than the newly added vertex' LSA. Also I do not understand this RFC 2382 logic above. Why does it have to compare both the distance and the link state ID. Suppose there are two possible paths, P1 and P2, to a network. P1 is shorter than P2 but P1 has an origin of smaller link state ID. According to this rule, which path will be installed in the routing table depends on the order the LSAs are examined. That seems very strange to me. Thanks, James Huang _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From acee.lindem@ericsson.com Mon Jan 25 16:12:42 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0A83A687F for ; Mon, 25 Jan 2010 16:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLM0H0tkjvFi for ; Mon, 25 Jan 2010 16:12:41 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 6065A3A68A4 for ; Mon, 25 Jan 2010 16:12:41 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o0Q0DZia006727; Mon, 25 Jan 2010 18:13:35 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.185]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 25 Jan 2010 19:12:48 -0500 From: Acee Lindem To: James Huang Date: Mon, 25 Jan 2010 19:12:43 -0500 Thread-Topic: [OSPF] OSPF multiple-area network Thread-Index: AcqeHEpB1FNKRYOzRze0BKN1stZ+Tg== Message-ID: <60A8722E-C742-453D-92D7-E0C17654E67C@ericsson.com> References: <7C3D15DD6E8F464998CA1470D8A322F30190F870@ES02CO.wgti.net> <7C3D15DD6E8F464998CA1470D8A322F3019EE0A5@ES02CO.wgti.net> In-Reply-To: <7C3D15DD6E8F464998CA1470D8A322F3019EE0A5@ES02CO.wgti.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF multiple-area network X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 00:12:42 -0000 Hi James, On Jan 25, 2010, at 6:35 PM, James Huang wrote: > Hi Acee, >=20 > Thanks for the reply. > I agreed with you that RFC 2328 assumes each network can only > reside in one area and that is what I always assume too. But when I > tried to find a scenario to explain the reason for re-running the > complete SPF route computation starting from sec 16.1 in Case 2 of sec > 16.5 (incremental updates: summary-LSAs), I just cannot find one unless > there is a multi-area network. If you have one scenario to explain Case > 2 of sec 16.5, can you show it? If the path through the transit area was used to update intra-area path thr= ough the backbone as described in 16.3 and now the cost of a transit area p= ath increases, you must rerun the intra-area SPF which, in the case of RFC = 2328, implies rerunning the complete SPF. This isn't to say that the intra-= area portion couldn't be done incrementally as well but it isn't described = in RFC 2328.=20 Hope this helps,=20 Acee=20 >=20 > Thanks, > James Huang >=20 >=20 > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Monday, January 25, 2010 2:48 PM > To: James Huang > Cc: ospf@ietf.org > Subject: Re: [OSPF] OSPF multiple-area network >=20 > Hi James, > The excerpted text is referring to multiple LSAs in the same area - not > LSAs in different areas. If you read it closely you'll see that the > example given is a transient condition. While some vendors do, in fact, > support an IP subnet connected to multiple areas, this is not > considered to be a valid topology and is not addressed by RFC 2328. > Consider the following excerpt from page 6 of RFC 2328: >=20 >=20 > OSPF allows sets of networks to be grouped together. Such a > grouping is called an area. The topology of an area is hidden > from the rest of the Autonomous System. This information hiding > enables a significant reduction in routing traffic. Also, > routing within the area is determined only by the area's own > topology, lending the area protection from bad routing data. An > area is a generalization of an IP subnetted network. >=20 >=20 > Hope this Helps, > Acee >=20 > On Jan 25, 2010, at 4:30 PM, James Huang wrote: >=20 > Hi all, > When a network is connected to multiple areas (maybe as > a stub network), what is the expected behavior according to RFC 2328? > In RFC 2328, a "network" route is always associated with a single area. > But in the following topology, router R will receive two network-LSAs, > one from each attached area: R is connected to area-1 and area-2. R's > area-1 neighbor R1 has an interface (part of area-1) connected to a stub > network N. R's area-2 neighbor R2 has an interface (part of area-2) > also connected to the stub network N. >=20 > RFC 2328, Sec 16.1, Step (4) has some consideration for > resolving conflicting intra-area network routes. But is it applicable > to this case? >=20 > If the routing table entry already exists > (i.e., there is already an intra-area route to the > destination installed in the routing table), multiple > vertices have mapped to the same IP network. For example, > this can occur when a new Designated Router is being > established. In this case, the current routing table entry > should be overwritten if and only if the newly found path is > just as short and the current routing table entry's Link > State Origin has a smaller Link State ID than the newly > added vertex' LSA. >=20 > Also I do not understand this RFC 2382 logic above. Why > does it have to compare both the distance and the link state ID. > Suppose there are two possible paths, P1 and P2, to a network. P1 is > shorter than P2 but P1 has an origin of smaller link state ID. > According to this rule, which path will be installed in the routing > table depends on the order the LSAs are examined. That seems very > strange to me. >=20 > Thanks, > James Huang >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 From James.Huang@watchguard.com Mon Jan 25 17:07:01 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B9F3A6781 for ; Mon, 25 Jan 2010 17:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymLrJszyoQnu for ; Mon, 25 Jan 2010 17:07:00 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id B0F193A676A for ; Mon, 25 Jan 2010 17:07:00 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 17:07:08 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F3019EE0E8@ES02CO.wgti.net> In-Reply-To: <60A8722E-C742-453D-92D7-E0C17654E67C@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF multiple-area network Thread-Index: AcqeHEwW7FEJ9fPDQOCrp2pJ/V8ViQAAKAXQ References: <7C3D15DD6E8F464998CA1470D8A322F30190F870@ES02CO.wgti.net> <7C3D15DD6E8F464998CA1470D8A322F3019EE0A5@ES02CO.wgti.net> <60A8722E-C742-453D-92D7-E0C17654E67C@ericsson.com> From: "James Huang" To: "Acee Lindem" Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF multiple-area network X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 01:07:01 -0000 Hi Acee, I thought Sec 16.5 is about receiving a new summary LSA for a network N. It is not about transit area path changes (in which case it will be new router-LSAs or new network-LSAs for the transit area). =20 Let's say network N is in one region of area 0 (area0-a), the transit area is area 1, and the virtual link in area 1 connects area-0a to another region of area-0 (area0-b) from ABR router R1 to ABR router R2. ABR router R3 connects to area-0b and area-1. When R3 receives a new summary-LSA for N from R2 that increases the cost to N, R3 needs to re-compute 16.1/16.2 for area-0 and 16.3 for network N (for network N and all destinations in area-0a reachable through N). Why does R3 have to re-compute intra-area routes for area-1 or any other areas it attaches to? =20 This brings up another question: why sec 16.3 does not mention about re-computing area 0's intra-area routes for those destinations behind N if it find a better route to N than what was originally found in 16.1/16.2?=20 =20 Thanks, James Huang =20 -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Monday, January 25, 2010 4:13 PM To: James Huang Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF multiple-area network Hi James, On Jan 25, 2010, at 6:35 PM, James Huang wrote: > Hi Acee, >=20 > Thanks for the reply. > I agreed with you that RFC 2328 assumes each network can only > reside in one area and that is what I always assume too. But when I > tried to find a scenario to explain the reason for re-running the > complete SPF route computation starting from sec 16.1 in Case 2 of sec > 16.5 (incremental updates: summary-LSAs), I just cannot find one unless > there is a multi-area network. If you have one scenario to explain Case > 2 of sec 16.5, can you show it? If the path through the transit area was used to update intra-area path through the backbone as described in 16.3 and now the cost of a transit area path increases, you must rerun the intra-area SPF which, in the case of RFC 2328, implies rerunning the complete SPF. This isn't to say that the intra-area portion couldn't be done incrementally as well but it isn't described in RFC 2328.=20 Hope this helps,=20 Acee=20 >=20 > Thanks, > James Huang >=20 >=20 > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Monday, January 25, 2010 2:48 PM > To: James Huang > Cc: ospf@ietf.org > Subject: Re: [OSPF] OSPF multiple-area network >=20 > Hi James, > The excerpted text is referring to multiple LSAs in the same area - not > LSAs in different areas. If you read it closely you'll see that the > example given is a transient condition. While some vendors do, in fact, > support an IP subnet connected to multiple areas, this is not > considered to be a valid topology and is not addressed by RFC 2328. > Consider the following excerpt from page 6 of RFC 2328: >=20 >=20 > OSPF allows sets of networks to be grouped together. Such a > grouping is called an area. The topology of an area is hidden > from the rest of the Autonomous System. This information hiding > enables a significant reduction in routing traffic. Also, > routing within the area is determined only by the area's own > topology, lending the area protection from bad routing data. An > area is a generalization of an IP subnetted network. >=20 >=20 > Hope this Helps, > Acee >=20 > On Jan 25, 2010, at 4:30 PM, James Huang wrote: >=20 > Hi all, > When a network is connected to multiple areas (maybe as > a stub network), what is the expected behavior according to RFC 2328? > In RFC 2328, a "network" route is always associated with a single area. > But in the following topology, router R will receive two network-LSAs, > one from each attached area: R is connected to area-1 and area-2. R's > area-1 neighbor R1 has an interface (part of area-1) connected to a stub > network N. R's area-2 neighbor R2 has an interface (part of area-2) > also connected to the stub network N. >=20 > RFC 2328, Sec 16.1, Step (4) has some consideration for > resolving conflicting intra-area network routes. But is it applicable > to this case? >=20 > If the routing table entry already exists > (i.e., there is already an intra-area route to the > destination installed in the routing table), multiple > vertices have mapped to the same IP network. For example, > this can occur when a new Designated Router is being > established. In this case, the current routing table entry > should be overwritten if and only if the newly found path is > just as short and the current routing table entry's Link > State Origin has a smaller Link State ID than the newly > added vertex' LSA. >=20 > Also I do not understand this RFC 2382 logic above. Why > does it have to compare both the distance and the link state ID. > Suppose there are two possible paths, P1 and P2, to a network. P1 is > shorter than P2 but P1 has an origin of smaller link state ID. > According to this rule, which path will be installed in the routing > table depends on the order the LSAs are examined. That seems very > strange to me. >=20 > Thanks, > James Huang >=20 >=20 >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf >=20 From akr@cisco.com Tue Jan 26 13:20:05 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A51D3A6985 for ; Tue, 26 Jan 2010 13:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZaV5wJ1WSXm for ; Tue, 26 Jan 2010 13:20:03 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E40023A6890 for ; Tue, 26 Jan 2010 13:20:02 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkEAIrrXkurR7Hu/2dsb2JhbACCGMBnlyaEOQQ X-IronPort-AV: E=Sophos;i="4.49,348,1262563200"; d="scan'208,217";a="473284060" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2010 21:20:14 +0000 Received: from dhcp-171-71-55-156.cisco.com (dhcp-171-71-55-156.cisco.com [171.71.55.156]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0QLKEZu002762; Tue, 26 Jan 2010 21:20:14 GMT Message-ID: <4B5F5C9D.5030000@cisco.com> Date: Tue, 26 Jan 2010 13:20:29 -0800 From: Abhay Roy User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Ross Callon References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080000060702030408070706" Cc: "ospf@ietf.org" , Adrian Farrel Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 21:20:05 -0000 This is a multi-part message in MIME format. --------------080000060702030408070706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I also looked at the latest version and have a few comments. Nothing significant, so these can possibly be done in RFC Ed.. OSPFv3 Options : 1 byte The Options field indicates if the route carries a type-1 or type-2 metric. Setting the least significant bit in the field indicates that the route carries a External type-2 metric. #### When talking of bit positions, it's always better to show the bitfield, and name the bit(s) being allocated. For e.g. see section A.2 of rfc5340. #### We also need an IANA registry for: #### - Option bits (allocate the one's we need here) #### - Route Type (only a few values are currently permitted) 4.5.1. OSPFv3 Down Bit Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs, NSSA LSAs and External LSAs. Similarly, the DN-bit must be set in inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. As in [rfc4577], any LSA with the DN bit set must not be used for route calculations. #### Can we capitalize MUST in - "the DN-bit must be set .." #### The last sentence is confusing because it doesn't clarify this restriction to be only on PE routers. We could use similar language as in rfc4576: When a PE router receives, from a CE router, any LSA with the DN bit [OSPF-DN] set, the information from that LSA MUST NOT be used by the route calculation. Regards, -Abhay On 1/22/10 12:16 PM, Ross Callon wrote: > > draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for > publication, and is currently in the RFC editor's queue. While this > document passed WG last call in the L3VPN working group, and also > passed IETF last call, we forgot to either do an last call in the OSPF > working group, or to specifically flag the IETF last call to the OSPF > working group. > > With this in mind, we would like to solicit comments on this draft > from the OSPF working group. If there are minor comments we can fix > this during AUTH48. If there are major concerns then we will need to > figure out what to do (which in the most extreme situation might > require un-approving the document). > > Thus, please review this document and reply to the OSPF working group > email list by the end of next Friday, January 29th, if you have any > comments or concerns. > > Thanks, Ross > > (acting in my role as the AD who goofed in this case). > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --------------080000060702030408070706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I also looked at the latest version and have a few comments. Nothing significant, so these can possibly be done in RFC Ed.. 
      OSPFv3 Options : 1 byte

      The Options field indicates if the route carries a type-1 or
      type-2 metric.  Setting the least significant bit in the field
      indicates that the route carries a External type-2 metric.

#### When talking of bit positions, it's always better to show the bitfield, and name the bit(s) being allocated. For e.g. see section A.2 of rfc5340.
#### We also need an IANA registry for:
####  - Option bits (allocate the one's we need here)
####  - Route Type (only a few values are currently permitted)

4.5.1.  OSPFv3 Down Bit

   Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit
   for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs,
   NSSA LSAs and External LSAs.  Similarly, the DN-bit must be set in
   inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these
   are originated from a PE to a CE, to prevent those prefixes from
   being re-advertised into BGP.  As in [rfc4577], any LSA with the DN
   bit set must not be used for route calculations.
#### Can we capitalize MUST in - "the DN-bit must be set .."
#### The last sentence is confusing because it doesn't clarify this restriction to be only on PE routers. We could use similar language as in rfc4576:
   When a PE router receives, from a CE router, any LSA with the DN bit
   [OSPF-DN] set, the information from that LSA MUST NOT be used by the
   route calculation.
Regards,
-Abhay

On 1/22/10 12:16 PM, Ross Callon wrote:

draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for publication, and is currently in the RFC editor's queue. While this document passed WG last call in the L3VPN working group, and also passed IETF last call, we forgot to either do an last call in the OSPF working group, or to specifically flag the IETF last call to the OSPF working group.

 

With this in mind, we would like to solicit comments on this draft from the OSPF working group. If there are minor comments we can fix this during AUTH48. If there are major concerns then we will need to figure out what to do (which in the most extreme situation might require un-approving the document).

 

Thus, please review this document and reply to the OSPF working group email list by the end of next Friday, January 29th, if you have any comments or concerns.

 

Thanks, Ross

(acting in my role as the AD who goofed in this case). 


_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
--------------080000060702030408070706-- From acee.lindem@ericsson.com Tue Jan 26 16:50:21 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B5D3A68F0 for ; Tue, 26 Jan 2010 16:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rt+WEWwI+HOZ for ; Tue, 26 Jan 2010 16:50:20 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 57B9A3A68E1 for ; Tue, 26 Jan 2010 16:50:20 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o0R0pDq3019315; Tue, 26 Jan 2010 18:51:20 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.159]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 26 Jan 2010 19:50:24 -0500 From: Acee Lindem To: James Huang Date: Tue, 26 Jan 2010 19:50:18 -0500 Thread-Topic: [OSPF] OSPF multiple-area network Thread-Index: Acqe6rUFDJLJBjXQRESS4NB0vBAWxA== Message-ID: <53D64019-DBC8-4585-91EB-1AFD6BA6F30B@ericsson.com> References: <7C3D15DD6E8F464998CA1470D8A322F30190F870@ES02CO.wgti.net> <7C3D15DD6E8F464998CA1470D8A322F3019EE0A5@ES02CO.wgti.net> <60A8722E-C742-453D-92D7-E0C17654E67C@ericsson.com> <7C3D15DD6E8F464998CA1470D8A322F3019EE0E8@ES02CO.wgti.net> In-Reply-To: <7C3D15DD6E8F464998CA1470D8A322F3019EE0E8@ES02CO.wgti.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPF multiple-area network X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 00:50:21 -0000 Hi James, Thanks, Acee On Jan 25, 2010, at 8:07 PM, James Huang wrote: > Hi Acee, > I thought Sec 16.5 is about receiving a new summary LSA for a > network N. It is not about transit area path changes (in which case it > will be new router-LSAs or new network-LSAs for the transit area). =20 >=20 > Let's say network N is in one region of area 0 (area0-a), the transit > area is area 1, and the virtual link in area 1 connects area-0a to > another region of area-0 (area0-b) from ABR router R1 to ABR router R2. > ABR router R3 connects to area-0b and area-1. When R3 receives a new > summary-LSA for N from R2 that increases the cost to N, R3 needs to > re-compute 16.1/16.2 for area-0 and 16.3 for network N (for network N > and all destinations in area-0a reachable through N). Why does R3 have > to re-compute intra-area routes for area-1 or any other areas it > attaches to? =20 It probably doesn't. As I previously stated, RFC 2328 doesn't attempt to de= scribe all the possible incremental SPF optimizations . This is explicitly= stated in section 16.1 on page 167: The specification does not require that the above two stage method be used to calculate the shortest path tree. However, if another algorithm is used, an identical tree must be produced. For this reason, it is important to note that links between transit vertices must be bidirectional in order to be included in the above tree. It should also be mentioned that more efficient algorithms exist for calculating the tree; for example, the incremental SPF algorithm described in [Ref1]. Also note footnote [19] on page 181: [19]By keeping more information in the routing table, it is possible for an implementation to recalculate the shortest path tree for only a single area. In fact, there are incremental algorithms that allow an implementation to recalculate only a portion of a single area's shortest path tree [Ref1]. However, these algorithms are beyond the scope of this specification. Thanks, Acee > This brings up another question: why sec 16.3 does not mention about > re-computing area 0's intra-area routes for those destinations behind N > if it find a better route to N than what was originally found in > 16.1/16.2?=20 >=20 >=20 > Thanks, > James Huang =20 >=20 >=20 >=20 > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Monday, January 25, 2010 4:13 PM > To: James Huang > Cc: ospf@ietf.org > Subject: Re: [OSPF] OSPF multiple-area network >=20 > Hi James, >=20 > On Jan 25, 2010, at 6:35 PM, James Huang wrote: >=20 >> Hi Acee, >>=20 >> Thanks for the reply. >> I agreed with you that RFC 2328 assumes each network can only >> reside in one area and that is what I always assume too. But when I >> tried to find a scenario to explain the reason for re-running the >> complete SPF route computation starting from sec 16.1 in Case 2 of sec >> 16.5 (incremental updates: summary-LSAs), I just cannot find one > unless >> there is a multi-area network. If you have one scenario to explain > Case >> 2 of sec 16.5, can you show it? >=20 > If the path through the transit area was used to update intra-area path > through the backbone as described in 16.3 and now the cost of a transit > area path increases, you must rerun the intra-area SPF which, in the > case of RFC 2328, implies rerunning the complete SPF. This isn't to say > that the intra-area portion couldn't be done incrementally as well but > it isn't described in RFC 2328.=20 >=20 > Hope this helps,=20 > Acee=20 >=20 >=20 >>=20 >> Thanks, >> James Huang >>=20 >>=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >> Sent: Monday, January 25, 2010 2:48 PM >> To: James Huang >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] OSPF multiple-area network >>=20 >> Hi James, >> The excerpted text is referring to multiple LSAs in the same area - > not >> LSAs in different areas. If you read it closely you'll see that the >> example given is a transient condition. While some vendors do, in > fact, >> support an IP subnet connected to multiple areas, this is not >> considered to be a valid topology and is not addressed by RFC 2328. >> Consider the following excerpt from page 6 of RFC 2328: >>=20 >>=20 >> OSPF allows sets of networks to be grouped together. Such a >> grouping is called an area. The topology of an area is hidden >> from the rest of the Autonomous System. This information > hiding >> enables a significant reduction in routing traffic. Also, >> routing within the area is determined only by the area's own >> topology, lending the area protection from bad routing data. > An >> area is a generalization of an IP subnetted network. >>=20 >>=20 >> Hope this Helps, >> Acee >>=20 >> On Jan 25, 2010, at 4:30 PM, James Huang wrote: >>=20 >> Hi all, >> When a network is connected to multiple areas (maybe as >> a stub network), what is the expected behavior according to RFC 2328? >> In RFC 2328, a "network" route is always associated with a single > area. >> But in the following topology, router R will receive two network-LSAs, >> one from each attached area: R is connected to area-1 and area-2. > R's >> area-1 neighbor R1 has an interface (part of area-1) connected to a > stub >> network N. R's area-2 neighbor R2 has an interface (part of area-2) >> also connected to the stub network N. >>=20 >> RFC 2328, Sec 16.1, Step (4) has some consideration for >> resolving conflicting intra-area network routes. But is it applicable >> to this case? >>=20 >> If the routing table entry already exists >> (i.e., there is already an intra-area route to the >> destination installed in the routing table), multiple >> vertices have mapped to the same IP network. For example, >> this can occur when a new Designated Router is being >> established. In this case, the current routing table entry >> should be overwritten if and only if the newly found path > is >> just as short and the current routing table entry's Link >> State Origin has a smaller Link State ID than the newly >> added vertex' LSA. >>=20 >> Also I do not understand this RFC 2382 logic above. > Why >> does it have to compare both the distance and the link state ID. >> Suppose there are two possible paths, P1 and P2, to a network. P1 is >> shorter than P2 but P1 has an origin of smaller link state ID. >> According to this rule, which path will be installed in the routing >> table depends on the order the LSAs are examined. That seems very >> strange to me. >>=20 >> Thanks, >> James Huang >>=20 >>=20 >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 >=20 From James.Huang@watchguard.com Tue Jan 26 18:00:36 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5683A699C for ; Tue, 26 Jan 2010 18:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10svBjErqBd9 for ; Tue, 26 Jan 2010 18:00:35 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id B5C213A6997 for ; Tue, 26 Jan 2010 18:00:35 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 18:00:45 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F3019EE38B@ES02CO.wgti.net> In-Reply-To: <53D64019-DBC8-4585-91EB-1AFD6BA6F30B@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF multiple-area network Thread-Index: Acqe6rvGQaRVOm7FQneyBdzHs/7tCgACYBIw References: <7C3D15DD6E8F464998CA1470D8A322F30190F870@ES02CO.wgti.net> <7C3D15DD6E8F464998CA1470D8A322F3019EE0A5@ES02CO.wgti.net> <60A8722E-C742-453D-92D7-E0C17654E67C@ericsson.com> <7C3D15DD6E8F464998CA1470D8A322F3019EE0E8@ES02CO.wgti.net> <53D64019-DBC8-4585-91EB-1AFD6BA6F30B@ericsson.com> From: "James Huang" To: "Acee Lindem" Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF multiple-area network X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 02:00:36 -0000 Hi Acee, Got it. Thanks, James Huang -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 Sent: Tuesday, January 26, 2010 4:50 PM To: James Huang Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF multiple-area network Hi James, Thanks, Acee On Jan 25, 2010, at 8:07 PM, James Huang wrote: > Hi Acee, > I thought Sec 16.5 is about receiving a new summary LSA for a > network N. It is not about transit area path changes (in which case it > will be new router-LSAs or new network-LSAs for the transit area). =20 >=20 > Let's say network N is in one region of area 0 (area0-a), the transit > area is area 1, and the virtual link in area 1 connects area-0a to > another region of area-0 (area0-b) from ABR router R1 to ABR router R2. > ABR router R3 connects to area-0b and area-1. When R3 receives a new > summary-LSA for N from R2 that increases the cost to N, R3 needs to > re-compute 16.1/16.2 for area-0 and 16.3 for network N (for network N > and all destinations in area-0a reachable through N). Why does R3 have > to re-compute intra-area routes for area-1 or any other areas it > attaches to? =20 It probably doesn't. As I previously stated, RFC 2328 doesn't attempt to describe all the possible incremental SPF optimizations . This is explicitly stated in section 16.1 on page 167: The specification does not require that the above two stage method be used to calculate the shortest path tree. However, if another algorithm is used, an identical tree must be produced. For this reason, it is important to note that links between transit vertices must be bidirectional in order to be included in the above tree. It should also be mentioned that more efficient algorithms exist for calculating the tree; for example, the incremental SPF algorithm described in [Ref1]. Also note footnote [19] on page 181: [19]By keeping more information in the routing table, it is possible for an implementation to recalculate the shortest path tree for only a single area. In fact, there are incremental algorithms that allow an implementation to recalculate only a portion of a single area's shortest path tree [Ref1]. However, these algorithms are beyond the scope of this specification. Thanks, Acee > This brings up another question: why sec 16.3 does not mention about > re-computing area 0's intra-area routes for those destinations behind N > if it find a better route to N than what was originally found in > 16.1/16.2?=20 >=20 >=20 > Thanks, > James Huang =20 >=20 >=20 >=20 > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 > Sent: Monday, January 25, 2010 4:13 PM > To: James Huang > Cc: ospf@ietf.org > Subject: Re: [OSPF] OSPF multiple-area network >=20 > Hi James, >=20 > On Jan 25, 2010, at 6:35 PM, James Huang wrote: >=20 >> Hi Acee, >>=20 >> Thanks for the reply. >> I agreed with you that RFC 2328 assumes each network can only >> reside in one area and that is what I always assume too. But when I >> tried to find a scenario to explain the reason for re-running the >> complete SPF route computation starting from sec 16.1 in Case 2 of sec >> 16.5 (incremental updates: summary-LSAs), I just cannot find one > unless >> there is a multi-area network. If you have one scenario to explain > Case >> 2 of sec 16.5, can you show it? >=20 > If the path through the transit area was used to update intra-area path > through the backbone as described in 16.3 and now the cost of a transit > area path increases, you must rerun the intra-area SPF which, in the > case of RFC 2328, implies rerunning the complete SPF. This isn't to say > that the intra-area portion couldn't be done incrementally as well but > it isn't described in RFC 2328.=20 >=20 > Hope this helps,=20 > Acee=20 >=20 >=20 >>=20 >> Thanks, >> James Huang >>=20 >>=20 >> -----Original Message----- >> From: Acee Lindem [mailto:acee.lindem@ericsson.com]=20 >> Sent: Monday, January 25, 2010 2:48 PM >> To: James Huang >> Cc: ospf@ietf.org >> Subject: Re: [OSPF] OSPF multiple-area network >>=20 >> Hi James, >> The excerpted text is referring to multiple LSAs in the same area - > not >> LSAs in different areas. If you read it closely you'll see that the >> example given is a transient condition. While some vendors do, in > fact, >> support an IP subnet connected to multiple areas, this is not >> considered to be a valid topology and is not addressed by RFC 2328. >> Consider the following excerpt from page 6 of RFC 2328: >>=20 >>=20 >> OSPF allows sets of networks to be grouped together. Such a >> grouping is called an area. The topology of an area is hidden >> from the rest of the Autonomous System. This information > hiding >> enables a significant reduction in routing traffic. Also, >> routing within the area is determined only by the area's own >> topology, lending the area protection from bad routing data. > An >> area is a generalization of an IP subnetted network. >>=20 >>=20 >> Hope this Helps, >> Acee >>=20 >> On Jan 25, 2010, at 4:30 PM, James Huang wrote: >>=20 >> Hi all, >> When a network is connected to multiple areas (maybe as >> a stub network), what is the expected behavior according to RFC 2328? >> In RFC 2328, a "network" route is always associated with a single > area. >> But in the following topology, router R will receive two network-LSAs, >> one from each attached area: R is connected to area-1 and area-2. > R's >> area-1 neighbor R1 has an interface (part of area-1) connected to a > stub >> network N. R's area-2 neighbor R2 has an interface (part of area-2) >> also connected to the stub network N. >>=20 >> RFC 2328, Sec 16.1, Step (4) has some consideration for >> resolving conflicting intra-area network routes. But is it applicable >> to this case? >>=20 >> If the routing table entry already exists >> (i.e., there is already an intra-area route to the >> destination installed in the routing table), multiple >> vertices have mapped to the same IP network. For example, >> this can occur when a new Designated Router is being >> established. In this case, the current routing table entry >> should be overwritten if and only if the newly found path > is >> just as short and the current routing table entry's Link >> State Origin has a smaller Link State ID than the newly >> added vertex' LSA. >>=20 >> Also I do not understand this RFC 2382 logic above. > Why >> does it have to compare both the distance and the link state ID. >> Suppose there are two possible paths, P1 and P2, to a network. P1 is >> shorter than P2 but P1 has an origin of smaller link state ID. >> According to this rule, which path will be installed in the routing >> table depends on the order the LSAs are examined. That seems very >> strange to me. >>=20 >> Thanks, >> James Huang >>=20 >>=20 >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 >=20 From michaellundberg.ietf@gmail.com Wed Jan 27 13:37:40 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD733A69C7; Wed, 27 Jan 2010 13:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.264 X-Spam-Level: X-Spam-Status: No, score=0.264 tagged_above=-999 required=5 tests=[AWL=2.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0llQ8H9EsxS; Wed, 27 Jan 2010 13:37:39 -0800 (PST) Received: from mail-iw0-f184.google.com (mail-iw0-f184.google.com [209.85.223.184]) by core3.amsl.com (Postfix) with ESMTP id DF3953A688C; Wed, 27 Jan 2010 13:37:38 -0800 (PST) Received: by iwn14 with SMTP id 14so11257iwn.17 for ; Wed, 27 Jan 2010 13:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=5GpfntUBJEAsCEYK//5NxKYmdcR7JY7JAGSicoVGUHs=; b=SjI+u+sJMwyH0JRX6+PY8suOVYfYr31wodFeWELhb8fnLbNqt70FvEpFmVTIXZW7Ml ffQ8rblr2i6pzOe90iSL/u4LiqxPV1dll8FJprmFLCtLP7Z8nMXu3mxNC3vS/79og3lZ V3xCzD/TzQbeGbZVFE0u3BRhUu0MIUzQm1Oyc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BmMgcRmBJM+Gd+WK9d5Yw00MPcUWEb/Wa0oyKT1tLOPyyOBPrJ2x9i5VaJ6tG6gciw kPuPAtTXGiaM1kVRecfENJ1V7dTJcWZ5QT57Zdx3BYHfurykS0yh+4kTuIVOb2gOfZ42 ZJS3j+KebnnqVlS5ivVy95NiDB4DMK6YM82yw= MIME-Version: 1.0 Received: by 10.231.168.136 with SMTP id u8mr963287iby.56.1264628270611; Wed, 27 Jan 2010 13:37:50 -0800 (PST) In-Reply-To: References: Date: Wed, 27 Jan 2010 16:37:50 -0500 Message-ID: From: Michael Lundberg To: ospf@ietf.org, Adrian.Farrel@huawei.com, rcallon@juniper.net, acee.lindem@ericsson.com, l3vpn@ietf.org Content-Type: multipart/alternative; boundary=001636b148d9d7bf5d047e2c36b4 Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 21:37:58 -0000 --001636b148d9d7bf5d047e2c36b4 Content-Type: text/plain; charset=ISO-8859-1 Sending again; previous email wasn't posted to lists... -----Original Message----- From: Lundberg, Michael [USA] Sent: Tuesday, January 26, 2010 11:36 PM To: 'Acee Lindem'; Ross Callon; l3vpn@ietf.org Cc: ospf@ietf.org; Adrian Farrel Subject: RE: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' Hi Acee, Thanks for your review. Please see below for responses to your comments. > Here are my comments: > > There is a typo on page 14: > > 0x50 External 0x2005 AS-external-LSA > > Should be: > > > 0x50 External 0x4005 AS-external-LSA > You are correct, this should be 0x4005 > Additionally, I don't think the addition of the instance ID to the > OSPFv3 Route Extended Communities attribute accomplishes all the much. > Assuming an IPv6 route is advertised once in BGP for a given VRF, how > does one advertise it into multiple PE OSPFv3 instances associated with > the VRF? Given that secondary routing domains can be configured for > OSPFv3 PE instances (as described in 4.1.2), it would seem you'd need > different routing domains for each instance and accomplish this. > However, if you need to use different domain IDs and keep the instance > ID common, what is the utility of the instance ID as an additional > route demultiplexer? There whole discussion of instance ID in sections > 4.1 and 4.1.1 doesn't make sense to me. The OSPFv3 instance ID is used > in OSPFv3 packets in order to allow multiple instances to share a link. > Hence, the only place it maps directly to this draft is for the sham > link as described in section 5. In order to advertise a route into > multiple instances > in the same VRF, one would need to associate multiple OSPFv3 Route > Extended Communities with the route. If this is the indent, the draft > should should state as such. However, there is no reason why OSPFv2 PE- > CE, as described in RFC 4577, couldn't also take advantage of such of > mechanism. > The motivation for using an Instance ID was not to advertise a route into multiple OSPFv3 instances. This can be done through redistribution policies configured on the router (even for RFC 4577 implementations). Rather, the motivation was to leave implementers the room for flexibility, where Domain IDs can be assigned on a per-VRF or a per-OSPF-instance basis. In the per-VRF case, the Instance ID is used to demultiplex routes across different OSPFv3 instances. Regards, Michael S. Lundberg Associate Booz | Allen | Hamilton 22 Batterymarch Street Boston, MA 02109 Office: 617-428-4476 > Thanks, > Acee > > On Jan 22, 2010, at 3:16 PM, Ross Callon wrote: > > draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for > publication, and is currently in the RFC editor's queue. While this > document passed WG last call in the L3VPN working group, and also > passed IETF last call, we forgot to either do an last call in the OSPF > working group, or to specifically flag the IETF last call to the OSPF > working group. > > With this in mind, we would like to solicit comments on this draft from > the OSPF working group. If there are minor comments we can fix this > during AUTH48. If there are major concerns then we will need to figure > out what to do (which in the most extreme situation might require un- > approving the document). > > Thus, please review this document and reply to the OSPF working group > email list by the end of next Friday, January 29th, if you have any > comments or concerns. > > Thanks, Ross > (acting in my role as the AD who goofed in this case). > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --001636b148d9d7bf5d047e2c36b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sending again; previous email wasn't posted to lists...

-----Original Message-----
From: Lundberg, Michael [USA]
Sent: Tuesday, January 26, 2010 11:36 PM
To: 'Acee Lindem'; Ross Callon; l= 3vpn@ietf.org
Cc: ospf@ietf.org; Adrian Farrel
Subject: RE: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OS= PFv3 as a PE-CE routing protocol'

Hi Acee,

Thanks for your review. =A0Please see below for responses to your comments.=

> Here are my comments:
>
> There is a typo on page 14:
>
> =A0 =A00x50 External 0x2005 AS-external-LSA
>
> Should be:
>
>
> =A00x50 =A0 =A0 External =A0 =A0 =A0 =A0 =A0 0x4005 =A0 AS-external-LS= A
>

You are correct, this should be 0x4005

> Additionally, I don't think the addition of the instance ID to the=
> OSPFv3 Route Extended Communities attribute accomplishes all the much.=
> Assuming an IPv6 route is advertised once in BGP for a given VRF, how<= br> > does one advertise it into multiple PE OSPFv3 instances associated wit= h
> the VRF? Given that secondary routing domains can be configured for > OSPFv3 PE instances (as described in 4.1.2), it would seem you'd n= eed
> different routing domains for each instance and accomplish this.
> However, if you need to use different domain IDs and keep the instance=
> ID common, what is the utility of the instance ID as an additional
> route demultiplexer? There whole discussion of instance ID in sections=
> 4.1 and 4.1.1 doesn't make sense to me. The OSPFv3 instance ID is = used
> in OSPFv3 packets in order to allow multiple instances to share a link= .
> Hence, the only place it maps directly to this draft is for the sham > link as described in section 5. In order to advertise a route into
> multiple instances
> =A0in the same VRF, one would need to associate multiple OSPFv3 Route<= br> > Extended Communities with the route. If this is the indent, the draft<= br> > should should state as such. However, there is no reason why OSPFv2 PE= -
> CE, as described in RFC 4577, couldn't also take advantage of such= of
> mechanism.
>

The motivation for using an Instance ID was not to advertise a route into m= ultiple OSPFv3 instances. =A0This can be done through redistribution polici= es configured on the router (even for RFC 4577 implementations).

Rather, the motivation was to leave implementers the room for flexibility, = where Domain IDs can be assigned on a per-VRF or a per-OSPF-instance basis.= In the per-VRF case, the Instance ID is used to demultiplex routes across = different OSPFv3 instances.

Regards,

Michael S. Lundberg
Associate
Booz | Allen | Hamilton
22 Batterymarch Street
Boston, MA =A002109
Office: 617-428-4476

> Thanks,
> Acee
>
> On Jan 22, 2010, at 3:16 PM, Ross Callon wrote:
>
> draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for
> publication, and is currently in the RFC editor's queue. While thi= s
> document passed WG last call in the L3VPN working group, and also
> passed IETF last call, we forgot to either do an last call in the OSPF=
> working group, or to specifically flag the IETF last call to the OSPF<= br> > working group.
>
> With this in mind, we would like to solicit comments on this draft fro= m
> the OSPF working group. If there are minor comments we can fix this > during AUTH48. If there are major concerns then we will need to figure=
> out what to do (which in the most extreme situation might require un-<= br> > approving the document).
>
> Thus, please review this document and reply to the OSPF working group<= br> > email list by the end of next Friday, January 29th, if you have any > comments or concerns.
>
> Thanks, Ross
> (acting in my role as the AD who goofed in this case).
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org<mailto:OSPF@ietf.org>
> https://www.ietf.org/mailman/listinfo/ospf
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf

--001636b148d9d7bf5d047e2c36b4-- From acee.lindem@ericsson.com Wed Jan 27 15:06:25 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E4A3A6984; Wed, 27 Jan 2010 15:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRozJ3lzgAov; Wed, 27 Jan 2010 15:06:24 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id A3EBB3A635F; Wed, 27 Jan 2010 15:06:24 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o0RN7GTZ011272; Wed, 27 Jan 2010 17:07:28 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.219]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 27 Jan 2010 18:06:27 -0500 From: Acee Lindem To: "Lundberg, Michael [USA]" Date: Wed, 27 Jan 2010 18:06:27 -0500 Thread-Topic: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' Thread-Index: AcqfpVrfq1nbjTKnTD+nfw0DOmL2mQ== Message-ID: <79C327E0-C642-4EE6-BBC0-24BF87CB92B3@ericsson.com> References: <4103179E-4282-4F9C-A96B-F078FD494BDA@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ospf@ietf.org" , "l3vpn@ietf.org" , Adrian Farrel Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 23:06:25 -0000 Hi Michael,=20 See inline.=20 On Jan 26, 2010, at 11:35 PM, Lundberg, Michael [USA] wrote: > Hi Acee,=20 >=20 > Thanks for your review. Please see below for responses to your comments. >=20 >> Here are my comments: >>=20 >> There is a typo on page 14: >>=20 >> 0x50 External 0x2005 AS-external-LSA >>=20 >> Should be: >>=20 >>=20 >> 0x50 External 0x4005 AS-external-LSA >>=20 >=20 > You are correct, this should be 0x4005 >=20 >> Additionally, I don't think the addition of the instance ID to the >> OSPFv3 Route Extended Communities attribute accomplishes all the much. >> Assuming an IPv6 route is advertised once in BGP for a given VRF, how >> does one advertise it into multiple PE OSPFv3 instances associated with >> the VRF? Given that secondary routing domains can be configured for >> OSPFv3 PE instances (as described in 4.1.2), it would seem you'd need >> different routing domains for each instance and accomplish this. >> However, if you need to use different domain IDs and keep the instance >> ID common, what is the utility of the instance ID as an additional >> route demultiplexer? There whole discussion of instance ID in sections >> 4.1 and 4.1.1 doesn't make sense to me. The OSPFv3 instance ID is used >> in OSPFv3 packets in order to allow multiple instances to share a link. >> Hence, the only place it maps directly to this draft is for the sham >> link as described in section 5. In order to advertise a route into >> multiple instances >> in the same VRF, one would need to associate multiple OSPFv3 Route >> Extended Communities with the route. If this is the indent, the draft >> should should state as such. However, there is no reason why OSPFv2 PE- >> CE, as described in RFC 4577, couldn't also take advantage of such of >> mechanism. >>=20 >=20 > The motivation for using an Instance ID was not to advertise a route into= multiple OSPFv3 instances. This can be done through redistribution polici= es configured on the router (even for RFC 4577 implementations). If that is the case, why do sections 3.1 and 4.1 imply a direct functional = correlation between the OSPFv3 interface instance ID and the Route Extended= Communities attribute?=20 >From section 3.1: To distinguish between routes originated from different OSPFv3 instances, a= n Instance ID field is carried in a newly-defined OSPFv3 Route Extended Com= munity attribute. >From section 4.1: Since multiple OSPFv3 instances can be associated with a single VRF, an additional mechanism is needed to demultiplex routes across these instances. When a PE supports multiple OSPFv3 instances in a VRF, a local Instance ID is assigned to the "link" that spans over the MPLS VPN backbone (PE-PE). As specified in [rfc5340], the Instance ID has link-local significance only. Therefore, the Instance IDs assigned to the PE-PE "link" need not be the same as the Instance IDs assigned to the PE-CE links. By default, this Instance ID is set to NULL. The OSPFv3 Domain ID and local Instance ID associated with the MPLS backbone may be used to demultiplex routes for multiple instances. Further details on Domain IDs and Instance IDs are provided in Section 4.1.2. If you have multiple instances within a VRF, the assumption above is that = the subset of routes known to each instance are disjoint. This limitation d= oes not exist with OSPFv3 instances in the routing domain (or VRF) using = different Instance IDs to share links. >=20 > Rather, the motivation was to leave implementers the room for flexibility= , where Domain IDs can be assigned on a per-VRF or a per-OSPF-instance basi= s. In the per-VRF case, the Instance ID is used to demultiplex routes acros= s different OSPFv3 instances. Right, but in the case where instance ID is specified that route may be onl= y redistributed into an OSPFv3 instance configured with that instance ID (a= s specified in 4.1.2).=20 Thanks, Acee=20 >=20 > Regards, >=20 > Michael S. Lundberg > Associate > Booz | Allen | Hamilton > 22 Batterymarch Street > Boston, MA 02109 > Office: 617-428-4476 >=20 >> Thanks, >> Acee >>=20 >> On Jan 22, 2010, at 3:16 PM, Ross Callon wrote: >>=20 >> draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for >> publication, and is currently in the RFC editor's queue. While this >> document passed WG last call in the L3VPN working group, and also >> passed IETF last call, we forgot to either do an last call in the OSPF >> working group, or to specifically flag the IETF last call to the OSPF >> working group. >>=20 >> With this in mind, we would like to solicit comments on this draft from >> the OSPF working group. If there are minor comments we can fix this >> during AUTH48. If there are major concerns then we will need to figure >> out what to do (which in the most extreme situation might require un- >> approving the document). >>=20 >> Thus, please review this document and reply to the OSPF working group >> email list by the end of next Friday, January 29th, if you have any >> comments or concerns. >>=20 >> Thanks, Ross >> (acting in my role as the AD who goofed in this case). >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf From ppe@cisco.com Wed Jan 27 20:16:55 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB103A693E for ; Wed, 27 Jan 2010 20:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SAWuC34prcF for ; Wed, 27 Jan 2010 20:16:53 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BBEE13A68FD for ; Wed, 27 Jan 2010 20:16:53 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAKfYEurRN+J/2dsb2JhbADAcZc+hDkE X-IronPort-AV: E=Sophos;i="4.49,358,1262563200"; d="scan'208,217";a="80158991" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 28 Jan 2010 04:16:56 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0S4Gupk015431; Thu, 28 Jan 2010 04:16:56 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 20:16:56 -0800 Received: from thamilto-w2k.cisco.com ([10.21.88.25]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 Jan 2010 20:16:55 -0800 Message-ID: <4B611003.6050103@cisco.com> Date: Wed, 27 Jan 2010 20:18:11 -0800 From: Padma Pillay-Esnault User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Abhay Roy References: <4B5F5C9D.5030000@cisco.com> In-Reply-To: <4B5F5C9D.5030000@cisco.com> Content-Type: multipart/alternative; boundary="------------040007080903050104050009" X-OriginalArrivalTime: 28 Jan 2010 04:16:55.0944 (UTC) FILETIME=[BA33A080:01CA9FD0] Cc: "ospf@ietf.org" , Adrian Farrel Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 04:16:55 -0000 This is a multi-part message in MIME format. --------------040007080903050104050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 1/26/10 1:20 PM, Abhay Roy wrote: > I also looked at the latest version and have a few comments. Nothing > significant, so these can possibly be done in RFC Ed.. > OSPFv3 Options : 1 byte > > The Options field indicates if the route carries a type-1 or > type-2 metric. Setting the least significant bit in the field > indicates that the route carries a External type-2 metric. > > #### When talking of bit positions, it's always better to show the > bitfield, and name the bit(s) being allocated. For e.g. see section > A.2 of rfc5340. Only the least significant bit is set to indicate the presence of a type-2 metric we felt this was sufficient. If you feel this would make things clearer, we can make the change. > #### We also need an IANA registry for: > #### - Option bits (allocate the one's we need here) > #### - Route Type (only a few values are currently permitted) > While I feel it is not needed for the Options bit, an IANA registry for the route types could be added. I will defer to the ADs on this matter. > 4.5.1. OSPFv3 Down Bit > > Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit > for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs, > NSSA LSAs and External LSAs. Similarly, the DN-bit must be set in > inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these > are originated from a PE to a CE, to prevent those prefixes from > being re-advertised into BGP. As in [rfc4577], any LSA with the DN > bit set must not be used for route calculations. > > #### Can we capitalize MUST in - "the DN-bit must be set .." Agreed. > #### The last sentence is confusing because it doesn't clarify this > restriction to be only on PE routers. We could use similar language as > in rfc4576: > When a PE router receives, from a CE router, any LSA with the DN bit > [OSPF-DN] set, the information from that LSA MUST NOT be used by the > route calculation. Agree we can rephrase it. Thanks for your review Padma > Regards, > -Abhay > > On 1/22/10 12:16 PM, Ross Callon wrote: >> >> draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for >> publication, and is currently in the RFC editor's queue. While this >> document passed WG last call in the L3VPN working group, and also >> passed IETF last call, we forgot to either do an last call in the >> OSPF working group, or to specifically flag the IETF last call to the >> OSPF working group. >> >> With this in mind, we would like to solicit comments on this draft >> from the OSPF working group. If there are minor comments we can fix >> this during AUTH48. If there are major concerns then we will need to >> figure out what to do (which in the most extreme situation might >> require un-approving the document). >> >> Thus, please review this document and reply to the OSPF working group >> email list by the end of next Friday, January 29th, if you have any >> comments or concerns. >> >> Thanks, Ross >> >> (acting in my role as the AD who goofed in this case). >> >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > --------------040007080903050104050009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 1/26/10 1:20 PM, Abhay Roy wrote:
I also looked at the latest version and have a few comments. Nothing significant, so these can possibly be done in RFC Ed.. 
      OSPFv3 Options : 1 byte

      The Options field indicates if the route carries a type-1 or
      type-2 metric.  Setting the least significant bit in the field
      indicates that the route carries a External type-2 metric.

#### When talking of bit positions, it's always better to show the bitfield, and name the bit(s) being allocated. For e.g. see section A.2 of rfc5340.
Only the least significant bit is set to indicate the presence of  a type-2 metric we felt this was sufficient. If you feel this would make things clearer, we can make the change.
#### We also need an IANA registry for:
####  - Option bits (allocate the one's we need here)
####  - Route Type (only a few values are currently permitted)

While I feel it is not needed for the Options bit,  an IANA registry for the route types could be added.  I will defer to the ADs on this matter. 

4.5.1.  OSPFv3 Down Bit

   Section 1 and Section 3 of [rfc4576] describe the usage of the DN-bit
   for OSPFv2 and are applicable for OSPFv3 for inter-area-prefix LSAs,
   NSSA LSAs and External LSAs.  Similarly, the DN-bit must be set in
   inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these
   are originated from a PE to a CE, to prevent those prefixes from
   being re-advertised into BGP.  As in [rfc4577], any LSA with the DN
   bit set must not be used for route calculations.
#### Can we capitalize MUST in - "the DN-bit must be set .."
Agreed.
#### The last sentence is confusing because it doesn't clarify this restriction to be only on PE routers. We could use similar language as in rfc4576:
   When a PE router receives, from a CE router, any LSA with the DN bit
   [OSPF-DN] set, the information from that LSA MUST NOT be used by the
   route calculation.
Agree we can rephrase it.

Thanks for your review

Padma
Regards,
-Abhay

On 1/22/10 12:16 PM, Ross Callon wrote:

draft-ietf-l3vpn-ospfv3-pece was recently approved by the IESG for publication, and is currently in the RFC editor's queue. While this document passed WG last call in the L3VPN working group, and also passed IETF last call, we forgot to either do an last call in the OSPF working group, or to specifically flag the IETF last call to the OSPF working group.

 

With this in mind, we would like to solicit comments on this draft from the OSPF working group. If there are minor comments we can fix this during AUTH48. If there are major concerns then we will need to figure out what to do (which in the most extreme situation might require un-approving the document).

 

Thus, please review this document and reply to the OSPF working group email list by the end of next Friday, January 29th, if you have any comments or concerns.

 

Thanks, Ross

(acting in my role as the AD who goofed in this case). 

  
_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
  

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

--------------040007080903050104050009-- From balajig@huawei.com Thu Jan 28 05:03:42 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CD73A682A for ; Thu, 28 Jan 2010 05:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJry4p5sbK-o for ; Thu, 28 Jan 2010 05:03:41 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 386A83A67B0 for ; Thu, 28 Jan 2010 05:03:41 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWY00I84KACEC@szxga04-in.huawei.com> for ospf@ietf.org; Thu, 28 Jan 2010 21:03:48 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWY00L1TKACBJ@szxga04-in.huawei.com> for ospf@ietf.org; Thu, 28 Jan 2010 21:03:48 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.18.1.31]) by szxmc04-in.huawei.com (mshttpd); Thu, 28 Jan 2010 18:03:48 +0500 Date: Thu, 28 Jan 2010 18:03:48 +0500 From: BalajiGanesh 71128 To: ospf@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal Subject: [OSPF] Clarification needed on R-bit in OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 13:03:42 -0000 Hi all, I am looking for a clarification regarding the R-bit usage during SPF calculation. In the OSPFv3 RFC 5340, Section 4.8.1. Calculating the Shortest-Path Tree for an Area, Page 46, the step 2b states that o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is not set in the LSA options, the transit link W is ignored and V's next link is examined. This sentence is not clear. As per my understanding, here the router-LSA should refer to the Vertex V's router LSA. So when we consider the vertex V's link's, if the next vertex W is a router vertex, then we should ignore the link to Vertex W and consider next link of Vertex V. Also if the vertex V's link points to a network node, those links should be considered. Is this understanding correct? regards, Balaji ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** From acee@lindem.com Thu Jan 28 05:45:20 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46723A6405 for ; Thu, 28 Jan 2010 05:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=2.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuWB3hH03lsN for ; Thu, 28 Jan 2010 05:45:20 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by core3.amsl.com (Postfix) with ESMTP id F06D23A6849 for ; Thu, 28 Jan 2010 05:45:19 -0800 (PST) X-Authority-Analysis: v=1.0 c=1 a=Mt6yR5S3a6EA:10 a=48vgC7mUAAAA:8 a=A4TC-Vnu8MWKCZFelxoA:9 a=egOgYo50D0rms1507RMA:7 a=r3ES6dNUp4oxhJzCeebhXGh4Zh0A:4 a=lZB815dzVvQA:10 a=pNLZ_70KONRWp7dg:21 a=MlBNsV2pB7-x99Re:21 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.1.238 Received: from [65.190.1.238] ([65.190.1.238:36809] helo=[10.0.1.13]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id 8D/52-19307-105916B4; Thu, 28 Jan 2010 13:45:37 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Thu, 28 Jan 2010 08:45:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: BalajiGanesh 71128 X-Mailer: Apple Mail (2.1077) Cc: ospf@ietf.org Subject: Re: [OSPF] Clarification needed on R-bit in OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 13:45:21 -0000 Hi Balaji, See inline.=20 On Jan 28, 2010, at 8:03 AM, BalajiGanesh 71128 wrote: >=20 > Hi all,=20 >=20 > I am looking for a clarification regarding the R-bit usage during SPF = calculation. > In the OSPFv3 RFC 5340, Section 4.8.1. Calculating the Shortest-Path = Tree for an Area, Page 46, > the step 2b states that=20 >=20 > o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit = is > not set in the LSA options, the transit link W is ignored and V's > next link is examined. >=20 > This sentence is not clear. It is perfectly clear in the context of Step 2b in section 16.1 of RFC = 2328. The only thing I might change is replace "transit link W" with = "transit link to W". However, it is clear without this edit.=20 >=20 > As per my understanding, here the router-LSA should refer to the = Vertex V's router LSA. No! It says "if W is a router and the router-LSA.." It is obvious that = this is W's router-LSA.=20 > So when we consider the vertex V's link's, if the next vertex W is a = router vertex, then we should ignore the link to Vertex W and consider > next link of Vertex V. Yes.=20 > Also if the vertex V's link points to a network node, those links = should be considered.=20 The bullet in question only pertains to router vertices.=20 Hope this helps, Acee=20 >=20 > Is this understanding correct? >=20 > regards, > Balaji >=20 > = **************************************************************************= **************** > This email and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained here in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient(s) is prohibited. If you receive this email in error, please = notify the sender by phone or email immediately and delete it! > = **************************************************************************= *************** > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From balajig@huawei.com Fri Jan 29 04:02:52 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5243A693E for ; Fri, 29 Jan 2010 04:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCk0OTg8U9Yw for ; Fri, 29 Jan 2010 04:02:51 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3B3503A688D for ; Fri, 29 Jan 2010 04:02:51 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX0005PWC52GR@szxga01-in.huawei.com> for ospf@ietf.org; Fri, 29 Jan 2010 20:03:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX000GYYC519Y@szxga01-in.huawei.com> for ospf@ietf.org; Fri, 29 Jan 2010 20:03:02 +0800 (CST) Received: from [172.24.1.24] (Forwarded-For: [10.18.1.31]) by szxmc04-in.huawei.com (mshttpd); Fri, 29 Jan 2010 17:03:01 +0500 Date: Fri, 29 Jan 2010 17:03:01 +0500 From: BalajiGanesh 71128 In-reply-to: To: Acee Lindem Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: Cc: ospf@ietf.org Subject: Re: [OSPF] Clarification needed on R-bit in OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 12:02:52 -0000 Hi Acee, >From RFC 2328 it means that in section 16.1, 2b, it is W's router LSA. But from RFC 5340 Section 4.8.1, 2b, if we consider the same, would that not mean that vertex W is completely ignored from topology? That is if we consider the below topology, according to R-bit definition, RT2 will have its R-bit as 0, so that it does not participate in transit traffic. Now when vertex RT1 is added to topology and we are considering the next vertex of RT1, ie RT2, then it will mean that RT2 is ignored as per section 4.8.1, 2b of RFC 5340. So RT2 will not be added to the topology. RT1 RT3 | | | | | | | | RT2 So should it be that from RFC 5340, section 4.8.1, o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is not set in the LSA options, the transit link W is ignored and V's next link is examined. o In Step 2b, if W is a router, there may again be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to W's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router- LSA. First point of step 2b is Vertex V's router LSA and in the second point we consider Vertex W's router LSA (ie RT2 is vertex V). This will mean that Router RT2 is added to the topology but no other router links from RT2. regards, Balaji ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** ----- Original Message ----- From: Acee Lindem Date: Thursday, January 28, 2010 7:16 pm Subject: Re: [OSPF] Clarification needed on R-bit in OSPFv3 To: BalajiGanesh 71128 Cc: ospf@ietf.org > Hi Balaji, > See inline. > On Jan 28, 2010, at 8:03 AM, BalajiGanesh 71128 wrote: > > > > > Hi all, > > > > I am looking for a clarification regarding the R-bit usage > during SPF calculation. > > In the OSPFv3 RFC 5340, Section 4.8.1. Calculating the Shortest- > Path Tree for an Area, Page 46, > > the step 2b states that > > > > o In Step 2b, if W is a router and the router-LSA V6-bit or R- > bit is > > not set in the LSA options, the transit link W is ignored > and V's > > next link is examined. > > > > This sentence is not clear. > > It is perfectly clear in the context of Step 2b in section 16.1 of > RFC 2328. The only thing I might change is replace "transit link > W" with "transit link to W". However, it is clear without this > edit. > > > > > > As per my understanding, here the router-LSA should refer to the > Vertex V's router LSA. > > No! It says "if W is a router and the router-LSA.." It is obvious > that this is W's router-LSA. > > > > So when we consider the vertex V's link's, if the next vertex W > is a router vertex, then we should ignore the link to Vertex W and > consider> next link of Vertex V. > > Yes. > > > Also if the vertex V's link points to a network node, those > links should be considered. > > The bullet in question only pertains to router vertices. > > Hope this helps, > Acee > > > > > > Is this understanding correct? > > > > regards, > > Balaji > > > > > ******************************************************************************************> This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! > > > *****************************************************************************************> _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > From acee@lindem.com Fri Jan 29 17:09:47 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCCF13A6846 for ; Fri, 29 Jan 2010 17:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lG6CScHxEDI for ; Fri, 29 Jan 2010 17:09:46 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by core3.amsl.com (Postfix) with ESMTP id 8BAA43A67D7 for ; Fri, 29 Jan 2010 17:09:46 -0800 (PST) X-Authority-Analysis: v=1.0 c=1 a=Mt6yR5S3a6EA:10 a=QYaTxUjTAAAA:8 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=JOByDRRhpoKDjTINRj0A:9 a=W_Qjyf8lpvLtbn5_YgwA:7 a=RXHfvCWYWBn1uGRhvB1a4qAHAD0A:4 a=U-q-bRhx1rIA:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=TkIU2oagTyAfsbkp:21 a=Zs_bG84fFT8ttJZP:21 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.1.238 Received: from [65.190.1.238] ([65.190.1.238:32855] helo=[10.0.1.13]) by cdptpa-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id CE/57-02205-1F6836B4; Sat, 30 Jan 2010 01:10:09 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Acee Lindem In-Reply-To: Date: Fri, 29 Jan 2010 20:10:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: BalajiGanesh 71128 X-Mailer: Apple Mail (2.1077) Cc: ospf@ietf.org Subject: Re: [OSPF] Clarification needed on R-bit in OSPFv3 X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 01:09:47 -0000 Hi Balaji, Okay - I now see what you are saying and agree that the bullet is wrong. = I believe it is step 2 rather than step 2 (b) that needs to be modified = to take the V-bit and R-bit into consideration. The way it reads now, = vertex W will not be added to the SPF tree and W will be unreachable. = I'll need to write an errata.=20 Thanks, Acee=20 On Jan 29, 2010, at 7:03 AM, BalajiGanesh 71128 wrote: > Hi Acee, >=20 > =46rom RFC 2328 it means that in section 16.1, 2b, it is W's router = LSA. > But from RFC 5340 Section 4.8.1, 2b, if we consider the same, would = that not > mean that vertex W is completely ignored from topology?=20 >=20 > That is if we consider the below topology, according to R-bit = definition, > RT2 will have its R-bit as 0, so that it does not participate in = transit traffic. > Now when vertex RT1 is added to topology and we are considering the = next vertex of RT1, ie RT2, then it will mean that RT2 is ignored as per = section 4.8.1, 2b of RFC 5340. So RT2 will not be added to the topology. >=20 > RT1 RT3=20 > | | > | | > | | > | | > RT2 >=20 > So should it be that from RFC 5340, section 4.8.1,=20 >=20 > o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit = is > not set in the LSA options, the transit link W is ignored and V's > next link is examined. >=20 > o In Step 2b, if W is a router, there may again be multiple LSAs > associated with the router. All router-LSAs with the Advertising > Router set to W's OSPF Router ID MUST be processed as an > aggregate, treating them as fragments of a single large router- > LSA. >=20 > First point of step 2b is Vertex V's router LSA and in=20 > the second point we consider Vertex W's router LSA (ie RT2 is vertex = V). > This will mean that Router RT2 is added to the topology but no other=20= > router links from RT2. >=20 >=20 > regards, > Balaji >=20 >=20 > = **************************************************************************= **************** > This email and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is = listed above. Any use of the information contained here in any way = (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient(s) is prohibited. If you receive this email in error, please = notify the sender by phone or email immediately and delete it! > = **************************************************************************= *************** >=20 > ----- Original Message ----- > From: Acee Lindem > Date: Thursday, January 28, 2010 7:16 pm > Subject: Re: [OSPF] Clarification needed on R-bit in OSPFv3 > To: BalajiGanesh 71128 > Cc: ospf@ietf.org >=20 >> Hi Balaji, >> See inline.=20 >> On Jan 28, 2010, at 8:03 AM, BalajiGanesh 71128 wrote: >>=20 >>>=20 >>> Hi all,=20 >>>=20 >>> I am looking for a clarification regarding the R-bit usage=20 >> during SPF calculation. >>> In the OSPFv3 RFC 5340, Section 4.8.1. Calculating the Shortest- >> Path Tree for an Area, Page 46, >>> the step 2b states that=20 >>>=20 >>> o In Step 2b, if W is a router and the router-LSA V6-bit or R- >> bit is >>> not set in the LSA options, the transit link W is ignored=20 >> and V's >>> next link is examined. >>>=20 >>> This sentence is not clear. >>=20 >> It is perfectly clear in the context of Step 2b in section 16.1 of=20 >> RFC 2328. The only thing I might change is replace "transit link=20 >> W" with "transit link to W". However, it is clear without this=20 >> edit.=20 >>=20 >>=20 >>>=20 >>> As per my understanding, here the router-LSA should refer to the=20 >> Vertex V's router LSA. >>=20 >> No! It says "if W is a router and the router-LSA.." It is obvious=20 >> that this is W's router-LSA.=20 >>=20 >>=20 >>> So when we consider the vertex V's link's, if the next vertex W=20 >> is a router vertex, then we should ignore the link to Vertex W and=20 >> consider> next link of Vertex V. >>=20 >> Yes.=20 >>=20 >>> Also if the vertex V's link points to a network node, those=20 >> links should be considered.=20 >>=20 >> The bullet in question only pertains to router vertices.=20 >>=20 >> Hope this helps, >> Acee=20 >>=20 >>=20 >>>=20 >>> Is this understanding correct? >>>=20 >>> regards, >>> Balaji >>>=20 >>>=20 >> = **************************************************************************= ****************> This email and its attachments contain confidential = information from HUAWEI, which is intended only for the person or entity = whose address is listed above. Any use of the information contained here = in any way (including, but not limited to, total or partial disclosure, = reproduction, or dissemination) by persons other than the intended = recipient(s) is prohibited. If you receive this email in error, please = notify the sender by phone or email immediately and delete it! >>>=20 >> = **************************************************************************= ***************> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf >>=20 >>=20 From ppe@cisco.com Fri Jan 29 21:45:20 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1463A6857 for ; Fri, 29 Jan 2010 21:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N88jAgeAmx59 for ; Fri, 29 Jan 2010 21:45:19 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 09EFE3A681E for ; Fri, 29 Jan 2010 21:45:19 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,372,1262563200"; d="scan'208,217";a="142544891" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2010 05:45:44 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0U5jis1003316; Sat, 30 Jan 2010 05:45:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 21:45:43 -0800 Received: from Padma-Pillay-Esnaults-MacBook-Pro-2.local ([10.21.118.118]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Jan 2010 21:45:42 -0800 Message-ID: <4B63C7D4.1070901@cisco.com> Date: Fri, 29 Jan 2010 21:47:00 -0800 From: Padma Pillay-Esnault User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Ross Callon , Adrian Farrel , acee.lindem@ericsson.com, "Abhay Roy (akr)" , "Peter Psenak (ppsenak)" Content-Type: multipart/alternative; boundary="------------020004000605000009080305" X-OriginalArrivalTime: 30 Jan 2010 05:45:43.0531 (UTC) FILETIME=[768463B0:01CAA16F] Cc: "jdoyle@doyleassociates.net" , "Ertekin, Emre \[USA\]" , "ospf@ietf.org" , "pete@pollere.net" Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 05:45:20 -0000 This is a multi-part message in MIME format. --------------020004000605000009080305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks to everyone for their thorough review. Assessing the different review comments on the flexibility of assigning domain ID on a per-OSPF-Instance or a per-VRF basis, the authors think offering a single approach will greatly improve the document's clarity. The sections 4.1, 4.1.1, 4.1.2, 4.3, 4.3.1, 4.3.2.1, 4.3.2.3 will be modified to reflect assigning Domain ID per OSPF-instance only. See below for other proposed changes and suggestions from reviews of the wg. Section 3.1 OSPFv3 Specificities "For an IPv6 MPLS/VPN architecture where customers interface to providers through OSPFv3, traditional BGP/OSPF interactions specify that VPN-IPv6 reachability information redistributed into OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, it may be desirable to view these LSAs as AS-internal (inter-area-prefix, and intra-area-prefix) LSAs." Proposed change /"For an IPv6 MPLS/VPN architecture where customers interface to providers through OSPFv3, traditional BGP/OSPF interactions specify that VPN-IPv6 reachability information redistributed into OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, it may be desirable to view these LSAs as inter-area-prefix LSAs."/ Remove paragraph, "To distinguish between routes originated from different OSPFv3 instances, an Instance ID field is carried in a newly-defined OSPFv3 Route Extended Community attribute." Section 4.3.2.2. OSPF Intra-Area Route "A route is advertised from a PE to a CE as an intra-area route using an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, as described in Section 5. Otherwise routes are advertised as either inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes." Proposed Changes / "A route is advertised as an intra-area route using an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, as described in Section 5. Otherwise routes are advertised as either inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes."/ Section 4.4 OSPFv3 Route Extended Communities Attribute " 0x50 External 0x2005 AS-external-LSA" Proposed change /" 0x50 External 0x4005 AS-external-LSA"/ Section 4.5.1. OSPFv3 Down Bit " Similarly, the DN-bit must be set in inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. " Proposed change / " Similarly, the DN-bit MUST be set in inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. " / Section 5 OSPFv3 Sham Links "Sham link endpoint addresses MUST be distributed by BGP as routeable VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As specified in [rfc4577], these endpoint addresses MUST NOT be advertised by OSPFv3." changed to /"Sham link endpoint addresses MUST be distributed by BGP as routeable VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As specified in section 4.2.7.1 of [rfc4577], these endpoint addresses MUST NOT be advertised by OSPFv3; if there is no BGP route to the Sham Link Endpoint Address, that address is to appear unreachable, so that the sham link appears to be down."/ Section 5.1 Creating A Sham link Remove the paragraph. "One difference from Section 4.2.7.3 of [rfc4577] is the addition of Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs across the sham link. Furthermore, where prefixes associated with OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs. This change is required based on [rfc5340], which states that loopback interfaces are advertised in intra-area-prefix LSAs." Suggestions OSPFv3 Options : 1 byte The Options field indicates if the route carries a type-1 or type-2 metric. Setting the least significant bit in the field indicates that the route carries a External type-2 metric. #### When talking of bit positions, it's always better to show the bitfield, and name the bit(s) being allocated. For e.g. see section A.2 of rfc5340. PPE : Only the least significant bit is set to indicate the presence of a type-2 metric we felt this was sufficient. If you feel this would make things clearer, we can make the change. > #### We also need an IANA registry for: > #### - Option bits (allocate the one's we need here) > #### - Route Type (only a few values are currently permitted) > PPE: While I feel it is not needed for the Options bit, an IANA registry for the route types could be added. I will defer to the ADs on this matter. Regards, The authors --------------020004000605000009080305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks to everyone for their thorough review.

Assessing the different review comments on the flexibility of
assigning domain ID on a per-OSPF-Instance or a per-VRF basis, 
the authors think offering a single approach will greatly improve the document's
clarity. The sections 4.1, 4.1.1, 4.1.2, 4.3, 4.3.1, 4.3.2.1, 4.3.2.3
will be modified to reflect assigning Domain ID per OSPF-instance only.

See below for other proposed changes and suggestions from reviews of the wg.

Section 3.1 OSPFv3 Specificities

"For an IPv6 MPLS/VPN architecture where customers interface to
providers through OSPFv3, traditional BGP/OSPF interactions
specify that VPN-IPv6 reachability information redistributed into
OSPFv3 will be expressed as an AS-External OSPFv3 LSAs.  Instead,
it may be desirable to view these LSAs as AS-internal (inter-area-prefix,
and intra-area-prefix) LSAs."

Proposed change

"For an IPv6 MPLS/VPN architecture where customers interface to
providers through OSPFv3, traditional BGP/OSPF interactions
specify that VPN-IPv6 reachability information redistributed into
OSPFv3 will be expressed as an AS-External OSPFv3 LSAs.  Instead,
it may be desirable to view these LSAs as inter-area-prefix LSAs."

Remove paragraph,

"To distinguish between routes originated from different
 OSPFv3 instances, an Instance ID field is carried in a
newly-defined OSPFv3 Route Extended Community attribute."

Section 4.3.2.2.  OSPF Intra-Area Route

"A route is advertised from a PE to a CE as an intra-area route using
an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used,
as described in Section 5.  Otherwise routes are advertised as either
inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes."

Proposed Changes

"A route is advertised as an intra-area route using
an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used,
as described in Section 5.  Otherwise routes are advertised as either
inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes."

Section 4.4 OSPFv3 Route Extended Communities Attribute

"  0x50     External           0x2005   AS-external-LSA"

Proposed change

"  0x50     External           0x4005   AS-external-LSA"

Section 4.5.1.  OSPFv3 Down Bit

   "  Similarly, the DN-bit must be set in inter-area-prefix-LSAs,
   NSSA-LSAs and AS-External-LSAs, when these
   are originated from a PE to a CE, to prevent those prefixes from
   being re-advertised into BGP.  "

Proposed change

  " Similarly, the DN-bit MUST be set in inter-area-prefix-LSAs,
   NSSA-LSAs and AS-External-LSAs, when these
   are originated from a PE to a CE, to prevent those prefixes from
   being re-advertised into BGP.  "

Section 5 OSPFv3 Sham Links

"Sham link endpoint addresses MUST be distributed by BGP as routeable
VPN IPv6 addresses whose IPv6 address prefix is 128 bits long.  As
specified in [rfc4577], these endpoint addresses MUST NOT be
advertised by OSPFv3."

changed to

"Sham link endpoint addresses MUST be distributed by BGP as routeable
  VPN IPv6 addresses whose IPv6 address prefix is 128 bits long.  As
specified in section 4.2.7.1 of [rfc4577], these endpoint
addresses MUST NOT be advertised by OSPFv3; if there is no BGP route
to the Sham Link Endpoint Address, that address is to appear unreachable,
so that the sham link appears to be down."

Section 5.1 Creating A Sham link

Remove the paragraph.

"One difference from Section 4.2.7.3 of [rfc4577] is the addition of
Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs
across the sham link.  Furthermore, where prefixes associated with
OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated
with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs.
This change is required based on [rfc5340], which states that
loopback interfaces are advertised in intra-area-prefix LSAs."

Suggestions
      OSPFv3 Options : 1 byte

      The Options field indicates if the route carries a type-1 or
      type-2 metric.  Setting the least significant bit in the field
      indicates that the route carries a External type-2 metric.

#### When talking of bit positions, it's always better to show the bitfield, and name the bit(s) being allocated. For e.g. see section A.2 of rfc5340.
PPE : Only the least significant bit is set to indicate the presence of  a type-2 metric we felt this was sufficient. If you feel this would make things clearer, we can make the change.

#### We also need an IANA registry for:
####  - Option bits (allocate the one's we need here)
####  - Route Type (only a few values are currently permitted)

PPE: While I feel it is not needed for the Options bit,  an IANA registry for the route types could be added.  I will defer to the ADs on this matter.

Regards,

The authors
--------------020004000605000009080305-- From acee.lindem@ericsson.com Sun Jan 31 11:14:34 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F1F3A6993 for ; Sun, 31 Jan 2010 11:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Td0pMewirVNV for ; Sun, 31 Jan 2010 11:14:33 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 683993A6452 for ; Sun, 31 Jan 2010 11:14:33 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o0VJFqkj003186; Sun, 31 Jan 2010 13:15:53 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.231]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 31 Jan 2010 14:14:50 -0500 From: Acee Lindem To: Padma Pillay-Esnault Date: Sun, 31 Jan 2010 14:14:43 -0500 Thread-Topic: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' Thread-Index: Acqiqahv42dB3bfuRem+pirGuTrUfQ== Message-ID: <0C28285D-12F6-4023-BB9D-63F97449E1E9@ericsson.com> References: <4B63C7D4.1070901@cisco.com> In-Reply-To: <4B63C7D4.1070901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jdoyle@doyleassociates.net" , "Ertekin, Emre \[USA\]" , "ospf@ietf.org" , Adrian Farrel , "pete@pollere.net" Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 19:14:34 -0000 Hi Padma, et al, On Jan 30, 2010, at 12:47 AM, Padma Pillay-Esnault wrote: Thanks to everyone for their thorough review. Assessing the different review comments on the flexibility of assigning domain ID on a per-OSPF-Instance or a per-VRF basis, the authors think offering a single approach will greatly improve the docum= ent's clarity. The sections 4.1, 4.1.1, 4.1.2, 4.3, 4.3.1, 4.3.2.1, 4.3.2.3 will be modified to reflect assigning Domain ID per OSPF-instance only. Great. Just to be clear, you will remove the instance-id from the OSPFv3 ro= ute extended communities attributes as well - right? See below for other proposed changes and suggestions from reviews of the wg= . Section 3.1 OSPFv3 Specificities "For an IPv6 MPLS/VPN architecture where customers interface to providers through OSPFv3, traditional BGP/OSPF interactions specify that VPN-IPv6 reachability information redistributed into OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, it may be desirable to view these LSAs as AS-internal (inter-area-prefix, and intra-area-prefix) LSAs." Proposed change "For an IPv6 MPLS/VPN architecture where customers interface to providers through OSPFv3, traditional BGP/OSPF interactions specify that VPN-IPv6 reachability information redistributed into OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, it may be desirable to view these LSAs as inter-area-prefix LSAs." Replace "as an AS-External LSAs" with "as AS-External LSAs". Remove paragraph, "To distinguish between routes originated from different OSPFv3 instances, an Instance ID field is carried in a newly-defined OSPFv3 Route Extended Community attribute." Section 4.3.2.2. OSPF Intra-Area Route "A route is advertised from a PE to a CE as an intra-area route using an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, as described in Section 5. Otherwise routes are advertised as either inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes." Proposed Changes "A route is advertised as an intra-area route using an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, as described in Section 5. Otherwise routes are advertised as either inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes." You could replace "external" with "external/NSSA" to be more precise. Section 4.4 OSPFv3 Route Extended Communities Attribute " 0x50 External 0x2005 AS-external-LSA" Proposed change " 0x50 External 0x4005 AS-external-LSA" Section 4.5.1. OSPFv3 Down Bit " Similarly, the DN-bit must be set in inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. " Proposed change " Similarly, the DN-bit MUST be set in inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. " Section 5 OSPFv3 Sham Links "Sham link endpoint addresses MUST be distributed by BGP as routeable VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As specified in [rfc4577], these endpoint addresses MUST NOT be advertised by OSPFv3." changed to "Sham link endpoint addresses MUST be distributed by BGP as routeable VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As specified in section 4.2.7.1 of [rfc4577], these endpoint addresses MUST NOT be advertised by OSPFv3; if there is no BGP route to the Sham Link Endpoint Address, that address is to appear unreachable, so that the sham link appears to be down." Section 5.1 Creating A Sham link Remove the paragraph. "One difference from Section 4.2.7.3 of [rfc4577] is the addition of Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs across the sham link. Furthermore, where prefixes associated with OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs. This change is required based on [rfc5340], which states that loopback interfaces are advertised in intra-area-prefix LSAs." Will 0x90 remain as a assigned value for the OSPFv3 Route extended communit= y route-type? Suggestions OSPFv3 Options : 1 byte The Options field indicates if the route carries a type-1 or type-2 metric. Setting the least significant bit in the field indicates that the route carries a External type-2 metric. #### When talking of bit positions, it's always better to show the bitfield= , and name the bit(s) being allocated. For e.g. see section A.2 of rfc5340. PPE : Only the least significant bit is set to indicate the presence of a = type-2 metric we felt this was sufficient. If you feel this would make thin= gs clearer, we can make the change. #### We also need an IANA registry for: #### - Option bits (allocate the one's we need here) #### - Route Type (only a few values are currently permitted) PPE: While I feel it is not needed for the Options bit, an IANA registry f= or the route types could be added. I will defer to the ADs on this matter. I'd agree. Thanks, Acee Regards, The authors From acee.lindem@ericsson.com Sun Jan 31 11:28:29 2010 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D382F3A6784 for ; Sun, 31 Jan 2010 11:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQvTRQgNk+a1 for ; Sun, 31 Jan 2010 11:28:28 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C33983A6837 for ; Sun, 31 Jan 2010 11:28:28 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o0VJTq3W008700; Sun, 31 Jan 2010 13:29:52 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.231]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 31 Jan 2010 14:28:49 -0500 From: Acee Lindem To: Padma Pillay-Esnault Date: Sun, 31 Jan 2010 14:28:41 -0500 Thread-Topic: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' Thread-Index: Acqiq50k8mngsMMOTUSA5uWhS0NOVA== Message-ID: <2C8883F6-48A9-4F04-B7D3-A95906E1393A@ericsson.com> References: <4B63C7D4.1070901@cisco.com> In-Reply-To: <4B63C7D4.1070901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "jdoyle@doyleassociates.net" , "Ertekin, Emre \[USA\]" , "ospf@ietf.org" , Adrian Farrel , "pete@pollere.net" Subject: Re: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2010 19:28:29 -0000 Hi Padma, et al, Somehow my response quoting was lost. I've prefixed my responses with "ACEE= :" just to make sure. On Jan 30, 2010, at 12:47 AM, Padma Pillay-Esnault wrote: Thanks to everyone for their thorough review. Assessing the different review comments on the flexibility of assigning domain ID on a per-OSPF-Instance or a per-VRF basis, the authors think offering a single approach will greatly improve the docum= ent's clarity. The sections 4.1, 4.1.1, 4.1.2, 4.3, 4.3.1, 4.3.2.1, 4.3.2.3 will be modified to reflect assigning Domain ID per OSPF-instance only. ACEE: Great. Just to be clear, you will remove the instance-id from the OSP= Fv3 route extended communities attributes as well - right? See below for other proposed changes and suggestions from reviews of the wg= . Section 3.1 OSPFv3 Specificities "For an IPv6 MPLS/VPN architecture where customers interface to providers through OSPFv3, traditional BGP/OSPF interactions specify that VPN-IPv6 reachability information redistributed into OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, it may be desirable to view these LSAs as AS-internal (inter-area-prefix, and intra-area-prefix) LSAs." Proposed change "For an IPv6 MPLS/VPN architecture where customers interface to providers through OSPFv3, traditional BGP/OSPF interactions specify that VPN-IPv6 reachability information redistributed into OSPFv3 will be expressed as an AS-External OSPFv3 LSAs. Instead, it may be desirable to view these LSAs as inter-area-prefix LSAs." ACEE: Replace "as an AS-External LSAs" with "as AS-External LSAs". Remove paragraph, "To distinguish between routes originated from different OSPFv3 instances, an Instance ID field is carried in a newly-defined OSPFv3 Route Extended Community attribute." Section 4.3.2.2. OSPF Intra-Area Route "A route is advertised from a PE to a CE as an intra-area route using an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, as described in Section 5. Otherwise routes are advertised as either inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes." Proposed Changes "A route is advertised as an intra-area route using an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used, as described in Section 5. Otherwise routes are advertised as either inter-area (Section 4.3.2.1) or external (Sections 4.3.2.3) routes." ACEE: You could replace "external" with "external/NSSA" to be more precise. Section 4.4 OSPFv3 Route Extended Communities Attribute " 0x50 External 0x2005 AS-external-LSA" Proposed change " 0x50 External 0x4005 AS-external-LSA" Section 4.5.1. OSPFv3 Down Bit " Similarly, the DN-bit must be set in inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. " Proposed change " Similarly, the DN-bit MUST be set in inter-area-prefix-LSAs, NSSA-LSAs and AS-External-LSAs, when these are originated from a PE to a CE, to prevent those prefixes from being re-advertised into BGP. " Section 5 OSPFv3 Sham Links "Sham link endpoint addresses MUST be distributed by BGP as routeable VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As specified in [rfc4577], these endpoint addresses MUST NOT be advertised by OSPFv3." changed to "Sham link endpoint addresses MUST be distributed by BGP as routeable VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. As specified in section 4.2.7.1 of [rfc4577], these endpoint addresses MUST NOT be advertised by OSPFv3; if there is no BGP route to the Sham Link Endpoint Address, that address is to appear unreachable, so that the sham link appears to be down." Section 5.1 Creating A Sham link Remove the paragraph. "One difference from Section 4.2.7.3 of [rfc4577] is the addition of Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs across the sham link. Furthermore, where prefixes associated with OSPFv2 sham links are advertised in Type-1 LSAs, prefixes associated with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs. This change is required based on [rfc5340], which states that loopback interfaces are advertised in intra-area-prefix LSAs." ACEE: Will 0x90 remain as a assigned value for the OSPFv3 Route extended co= mmunity route-type? Suggestions OSPFv3 Options : 1 byte The Options field indicates if the route carries a type-1 or type-2 metric. Setting the least significant bit in the field indicates that the route carries a External type-2 metric. #### When talking of bit positions, it's always better to show the bitfield= , and name the bit(s) being allocated. For e.g. see section A.2 of rfc5340. PPE : Only the least significant bit is set to indicate the presence of a = type-2 metric we felt this was sufficient. If you feel this would make thin= gs clearer, we can make the change. #### We also need an IANA registry for: #### - Option bits (allocate the one's we need here) #### - Route Type (only a few values are currently permitted) PPE: While I feel it is not needed for the Options bit, an IANA registry f= or the route types could be added. I will defer to the ADs on this matter. ACEE: I'd agree. Thanks, Acee Regards, The authors