Re: OSPF : Summarization of type-7 lsa's
"Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov> Thu, 07 July 2005 14:47 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXfP-0000tD-5S for ospf-archive@megatron.ietf.org; Thu, 07 Jul 2005 10:47:57 -0400
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14001 for <ospf-archive@LISTS.IETF.ORG>; Thu, 7 Jul 2005 10:47:49 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0109DAF2@cherry.ease.lsoft.com>; Thu, 7 Jul 2005 10:47:48 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 78251439 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Jul 2005 10:47:44 -0400
Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Thu, 7 Jul 2005 10:47:44 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01LQC49EC9G8003LOZ@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 07 Jul 2005 07:50:51 -0700 (PDT)
X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM
X-VMS-Cc: pmurphy
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Message-ID: <01LQC49ECAE2003LOZ@omega7.wr.usgs.gov>
Date: Thu, 07 Jul 2005 07:50:51 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: OSPF : Summarization of type-7 lsa's
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Ajay, > 1> If path type selected is external type 2 then type 5 metric >should be set to the largest type-7 metric subsumed by this net range + >1 ; >****** I have doubt like.. why we add 1 in this cost ..Is there any >specific reason behind this? The only hint comes from RFC 1587/3101 wording These metric and path type rules will avoid routing loops in the event that path type 1 and 2 are both used within the area. I believe this was done in RFC 1587 to distinguish the Type-5 LSA originated via the Type-7 translation/summarization process from a Type-7 LSA that has the same prefix. However this is conjecture on my part and I don't ever remember verifying it in a discussion with Rob Coltun. A tight routing loop seems possible in this case when the tie breaker rules of RFC 1587's external route calculation Step 5 are applied: a. Any type 5 LSA. b. A type-7 LSA with the P-bit set and the forwarding address non-zero. c. Any other type-7 LSA. An NSSA would need two ABRs and the translator would have to see an NSSA path to the Type-7 LSA's prefix through the second ABR for the loop to occur. The RFC 3101 tie breaker rules deal with this situation completely differently, and it is possible that adding +1 is no longer necessary. I realized this once, but adding +1 to the type 2 computed metric appeared harmless enough that a change seemed unwarranted. I do have a minor correction to make to RFC 3101 from an earlier disuccsion, so if the current WG feels this should be changed I have no objections. >2> If the path type selected in external type 1 , the type -5 metric >should be set to the largest metric.. >*** In this case we don't add any cost to ASBR. why this is so? The distance to the originator of the type-7 LSA plays a role in computing the translated Type 5's type 1 metric. Hence the second ABR above would compute a more preferred path via the Type-7 LSA that does not go through the translator ABR Pat
- Re: OSPF : Summarization of type-7 lsa's Pat Murphy - (650)329-4044
- Re: OSPF : Summarization of type-7 lsa's tajay