From christian.vogt@ericsson.com Wed Dec 2 15:18:06 2009 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 8A0DA3A69B1; Wed, 2 Dec 2009 15:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 pv90FXupibLn; Wed, 2 Dec 2009 15:18:04 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 41EF23A6974; Wed, 2 Dec 2009 15:18:00 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nB2NHCG2010854; Wed, 2 Dec 2009 17:17:12 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 2 Dec 2009 18:17:06 -0500 From: Christian Vogt To: Gen-ART Mailing List Date: Wed, 2 Dec 2009 18:18:27 -0500 Thread-Topic: Gen-ART review of draft-ietf-ospf-af-alt-09 Thread-Index: AcpzpZAJduzmJ3PvT6KU0F3Smtx0RA== Message-ID: <77E0431C-710C-4F12-B4F4-56528F9A8B6C@ericsson.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: "smirtora@cisco.com" , "ospf@ietf.org" Subject: [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: Wed, 02 Dec 2009 23:18:06 -0000 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 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 section. - Christian From James.Huang@watchguard.com Mon Dec 28 15:54:07 2009 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 8818C3A6947 for ; Mon, 28 Dec 2009 15:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.186 X-Spam-Level: X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_20=-0.74, 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 pvQemQxxHiGq for ; Mon, 28 Dec 2009 15:54:05 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id 4562A3A6955 for ; Mon, 28 Dec 2009 15:54:05 -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_01CA8818.FE5D2756" Date: Mon, 28 Dec 2009 15:53:46 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F3016E7CEB@ES02CO.wgti.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSSA type-7 to type-5 external LSA translation with forwarding address suppression Thread-Index: AcqIGP50Paav3XVoQEat31eVaY8AUQ== From: "James Huang" To: Subject: [OSPF] NSSA type-7 to type-5 external LSA translation with forwarding address suppression 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, 28 Dec 2009 23:54:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA8818.FE5D2756 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, The following is from RFC 3101, section 3.2, step (2): =20 "The newly originated Type-5 LSA will describe the same network and have the same network mask, path type, metric, forwarding address and external route tag as the Type-7 LSA. The advertising router field will be the router ID of this NSSA border router."=20 =20 This statement is correct (with regarding to the metric) when forwarding address suppression is not performed at the ABR. If forwarding address suppression is performed at the ABR and the type-7 LSA is metric-type-1, the metric in the type-5 LSA should be set to the original metric in the type-7 LSA plus the distance from this ABR to the ASBR through the NSSA area. This is because with forwarding address suppression, the forwarding address field will be set to 0 and the advertising router will be this ABR. So the metric in the originated type-5 LSA should be the distance from this ABR to the destination. =20 Is my thinking correct? I tested this scenario against Cisco IOS version 12.4. It did not set the metric correctly as described above when forwarding address suppression is performed against a metric-type-1 external LSA. That makes me wonder ... =20 n James Huang =20 =20 ------_=_NextPart_001_01CA8818.FE5D2756 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

         &= nbsp;      The following is from RFC 3101, section 3.2, step (2):

 

   = “The newly originated Type-5 LSA will describe the same network

        &nbs= p; and have the same network mask, path type, metric, = forwarding

        &nbs= p; address and external route tag as the Type-7 LSA.  = The

        &nbs= p; advertising router field will be the router ID of this NSSA border = router.”

     

     This statement = is correct (with regarding to the metric) when forwarding address = suppression is not performed at the ABR.

If forwarding address suppression is performed at the ABR and the type-7 = LSA is metric-type-1, the metric in the type-5 LSA should be set to the original metric in the = type-7 LSA plus the distance from this ABR to the ASBR through the NSSA = area.   This is because with forwarding address suppression, the forwarding = address field will be set to 0 and the advertising router will be this = ABR.   So the metric in the originated type-5 LSA should be the distance from = this ABR to the destination.

 

Is my thinking correct?

I tested this scenario against Cisco IOS version = 12.4.

It did not set the metric correctly as described above when =  forwarding address suppression is performed against a metric-type-1 external = LSA.

That makes me wonder …

 

n  = James = Huang

 

 

------_=_NextPart_001_01CA8818.FE5D2756-- From acee@lindem.com Mon Dec 28 16:48:11 2009 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 B5D543A6889 for ; Mon, 28 Dec 2009 16:48:11 -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 QDZX3KKy9Ldc for ; Mon, 28 Dec 2009 16:48:10 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by core3.amsl.com (Postfix) with ESMTP id A2EE83A686B for ; Mon, 28 Dec 2009 16:48:10 -0800 (PST) X-Authority-Analysis: v=1.0 c=1 a=7B5dm8sXfHEA:10 a=48vgC7mUAAAA:8 a=u7YCiqBDSZa8F824fAEA:9 a=MRnSsgUXMLSffX67WCoA:7 a=N9jIaaXUDtVOtab8FkEQz5isw20A:4 a=lZB815dzVvQA:10 a=V3CstNjCXdxlQ4YW:21 a=l9CAS4BYO_K8YzPA:21 a=a6kF6nSo2Zyus3F7tvwA:9 a=7i43y1woZ8hAysZPyssA:7 a=U_Iui1mr1bX9sSW7CfMpyAXh3rwA:4 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.1.238 Received: from [65.190.1.238] ([65.190.1.238:38618] helo=[10.0.1.2]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id 8F/E3-08392-6B1593B4; Tue, 29 Dec 2009 00:47:51 +0000 In-Reply-To: <7C3D15DD6E8F464998CA1470D8A322F3016E7CEB@ES02CO.wgti.net> References: <7C3D15DD6E8F464998CA1470D8A322F3016E7CEB@ES02CO.wgti.net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-6-272615126 Message-Id: <0146836A-FB17-46B5-9761-BDD36CFCD292@lindem.com> From: Acee Lindem Date: Mon, 28 Dec 2009 19:47:36 -0500 To: James Huang X-Mailer: Apple Mail (2.753.1) Cc: ospf@ietf.org Subject: Re: [OSPF] NSSA type-7 to type-5 external LSA translation with forwarding address suppression 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, 29 Dec 2009 00:48:11 -0000 --Apple-Mail-6-272615126 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi James, Forwarding address suppression is proprietary feature and is not =20 described in RFC 3101. Hence, you question is not applicable to RFC =20 3101. Hope this helps, Acee On Dec 28, 2009, at 6:53 PM, James Huang wrote: > Hi all, > > The following is from RFC 3101, section 3.2, step (2): > > > > =93The newly originated Type-5 LSA will describe the same network > > and have the same network mask, path type, metric, =20 > forwarding > > address and external route tag as the Type-7 LSA. The > > advertising router field will be the router ID of this =20 > NSSA border router.=94 > > > > This statement is correct (with regarding to the metric) when =20 > forwarding address suppression is not performed at the ABR. > > If forwarding address suppression is performed at the ABR and the =20 > type-7 LSA is metric-type-1, the metric in the type-5 LSA should be =20= > set to the original metric in the type-7 LSA plus the distance from =20= > this ABR to the ASBR through the NSSA area. This is because with =20 > forwarding address suppression, the forwarding address field will =20 > be set to 0 and the advertising router will be this ABR. So the =20 > metric in the originated type-5 LSA should be the distance from =20 > this ABR to the destination. > > > > Is my thinking correct? > > I tested this scenario against Cisco IOS version 12.4. > > It did not set the metric correctly as described above when =20 > forwarding address suppression is performed against a metric-type-1 =20= > external LSA. > > That makes me wonder =85 > > > > n James Huang > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-6-272615126 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi James,
Forwarding address suppression is proprietary feature and = is not described in RFC 3101. Hence, you question is not applicable to = RFC 3101. 
Hope this helps,
Acee =  
On Dec 28, 2009, at 6:53 PM, James Huang = wrote:

Hi = all,

         =        The following is from RFC 3101, = section 3.2, step (2):

 

   =93The newly originated Type-5 = LSA will describe the same network

        &nb= sp; and have the same network mask, path type, metric, = forwarding

        &nb= sp; address and external route tag as the Type-7 LSA.  = The

        &nb= sp; advertising router field will be the router ID of this NSSA border = router.=94

     

     This statement is correct (with regarding to the metric) when = forwarding address suppression is not performed at the = ABR.

If forwarding address suppression is performed at the ABR and the = type-7 LSA is metric-type-1, the metric in the type-5 LSA should be set = to the original metric in the type-7 LSA plus the distance from this ABR = to the ASBR through the NSSA area.   This is because with = forwarding address suppression, the forwarding address field will be set = to 0 and the advertising router will be this ABR.   So the = metric in the originated type-5 LSA should be the distance from this ABR = to the destination.

 

Is my thinking correct?

I tested this scenario against Cisco IOS version = 12.4.

It did not set the metric correctly as described above when =  forwarding address suppression is performed against a = metric-type-1 external LSA.

That makes me wonder =85

 

n  James Huang

 

 

OSPF mailing list
=

= --Apple-Mail-6-272615126--