From James.Huang@watchguard.com Thu Feb 4 13:22: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 C028E3A6E3A for ; Thu, 4 Feb 2010 13:22:40 -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=[AWL=-0.000, 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 9JoXisWYwdww for ; Thu, 4 Feb 2010 13:22:39 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id 61C263A6E45 for ; Thu, 4 Feb 2010 13:22:39 -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_01CAA5E0.4A3DD184" Date: Thu, 4 Feb 2010 13:23:25 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F301AB4A8D@ES02CO.wgti.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OSPF NSSA ABR bahaviors Thread-Index: Acql4ElUKT1hu4/oSLq1R6FO6yA0mw== From: "James Huang" To: Subject: [OSPF] OSPF NSSA ABR bahaviors 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, 04 Feb 2010 21:22:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAA5E0.4A3DD184 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I have a few questions regarding NSSA ABR:=20 =20 (1) Under what circumstances will an ABR originate type-7 LSAs with P-bit set to 1 into a NSSA area for locally sourced external routes? And why is it better than itself originating a type-5 LSA into type-5 capable areas and a type-7 LSA with P-bit set to 0 into NSSA areas? =20 (2) Suppose an ABR is connected to area 0 and multiple NSSA areas, it redistributes locally sourced external route for subnet N into OSPF, and this ABR is a translator for all of its NSSA areas. In this case, what will the type-5/type-7 LSAs originated by this ABR for subnet N look like (in terms of LSA-type, forwarding address, P-bit setting)? I think there are at least three sub-cases here, depending on where the next hop gateway (G) for N is located: (2.1) G is not within the OSPF domain; (2.2) G is within area 0; (2.3) G is within one of the NSSA areas. =20 =20 (3) RFC 3101 sec 3.2: The path type and metric of the Type-7 address range is determined from the path types and metrics of those translatable Type-7 LSAs that best match the range plus any locally sourced Type-5 LSAs whose network has the same [address,mask] pair. If any of these LSAs have a path type of 2, the range's path type is 2, otherwise it is 1. If the range's path type is 1 its metric is the highest cost amongst these LSAs; if the range's path type is 2 its metric is the highest Type-2 cost + 1 amongst these LSAs. (See Section 2.5 step (5).) 1 is added to the Type-2 cost to ensure that the translated Type-5 LSA does not appear closer on the NSSA border than a translatable Type-7 LSA whose network has the same [address,mask] pair and Type-2 cost. =20 Can someone explain the reason for adding 1 to the type-2 cost above (in plain English please)? =20 Thanks, James Huang ------_=_NextPart_001_01CAA5E0.4A3DD184 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have a few questions regarding NSSA ABR: =

 

(1)    Under what circumstances will an ABR originate = type-7 LSAs with P-bit set to 1 into a NSSA area for locally sourced external = routes?  And why is it better than itself originating a type-5 LSA into type-5 = capable areas and a type-7 LSA with P-bit set to 0 into NSSA = areas?

 

(2)    Suppose an ABR is connected to area 0 and = multiple NSSA areas, it redistributes locally sourced external route for subnet N into = OSPF, and this ABR is a translator for all of its NSSA areas.  In this = case, what will the type-5/type-7 LSAs originated by this ABR for subnet N look = like (in terms of LSA-type, forwarding address, P-bit setting)?  I think there are = at least three sub-cases here, depending on where the next hop gateway (G) = for N is located: (2.1) G is not within the OSPF domain; (2.2) G is within = area 0; (2.3) G is within one of the NSSA areas.  

 

(3)    RFC 3101 sec 3.2:

        &nbs= p; The path type and metric of the Type-7 address range is

        &nbs= p; determined from the path types and metrics of those

        &nbs= p; translatable Type-7 LSAs that best match the range plus = any

        &nbs= p; locally sourced Type-5 LSAs whose network has the same

        &nbs= p; [address,mask] pair.  If any of these LSAs have a path type of

        &nbs= p; 2, the range's path type is 2, otherwise it is 1.  If = the

        &nbs= p; range's path type is 1 its metric is the highest cost = amongst

        &nbs= p; these LSAs; if the range's path type is 2 its metric is = the

        &nbs= p; highest Type-2 cost + 1 amongst these LSAs.  (See Section = 2.5

        &nbs= p; step (5).)  1 is added to the Type-2 cost to ensure that = the

        &nbs= p; translated Type-5 LSA does not appear closer on the NSSA

        &nbs= p; border than a translatable Type-7 LSA whose network has = the

        &nbs= p; same [address,mask] pair and Type-2 cost.

 

Can someone explain the reason for adding 1 = to the type-2 cost above (in plain English please)?

 

Thanks,

James Huang

------_=_NextPart_001_01CAA5E0.4A3DD184-- From pmurphy@noc.usgs.net Thu Feb 4 17:26: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 C917F3A68E4 for ; Thu, 4 Feb 2010 17:26:49 -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 vFC9kENaBiOb for ; Thu, 4 Feb 2010 17:26:48 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id 328C03A68C8 for ; Thu, 4 Feb 2010 17:26:48 -0800 (PST) Received: from patsworkstation (pats-desktop.wr.usgs.gov [130.118.4.24]) by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) with ESMTP id <01NJ9TX8FNSI000DIB@omega7.wr.usgs.gov> for ospf@ietf.org; Thu, 04 Feb 2010 17:27:35 -0700 (PDT) Date: Thu, 04 Feb 2010 17:27:30 -0800 From: "Patrick W. Murphy, Ph.D." In-reply-to: <7C3D15DD6E8F464998CA1470D8A322F301AB4A8D@ES02CO.wgti.net> To: ospf@ietf.org Message-id: <001b01caa602$62941de0$27bc59a0$@usgs.net> Organization: WR-GIO-BTS MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_001C_01CAA5BF.5470DDE0" Content-language: en-us Thread-Index: Acql4ElUKT1hu4/oSLq1R6FO6yA0mwAIXgZA References: <7C3D15DD6E8F464998CA1470D8A322F301AB4A8D@ES02CO.wgti.net> Subject: Re: [OSPF] OSPF NSSA ABR bahaviors X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: pmurphy@noc.usgs.net List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 01:26:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01CAA5BF.5470DDE0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit My NSSA recollections are getting dimmer and dimmer. But here it is: >(1) Under what circumstances will an ABR originate type-7 LSAs with >P-bit set to 1 into a NSSA area for locally sourced external routes? >And why is it better than itself originating a type-5 LSA into type-5 >capable areas and a type-7 LSA with P-bit set to 0 into NSSA areas? RFC 3101 simply states: If the border router only originates a Type-7 LSA, it may set the P-bit so that the network may be aggregated/propagated during Type-7 translation. If an NSSA's border router originates a Type-5 LSA with a forwarding address from the NSSA, it should also originate a Type-7 LSA into the NSSA. Thus if one desires to aggregate the external route during Type-7 translation using a Type-7 address range then a Type-7 LSA with the P-bit set must be originated. Note the latter statement from RFC 3101 simply ensures that non-NSSA traffic forwarded by a Type-5 LSA installation toward a forwarding address inside an NSSA won't loop. I prefer originating the Type-7 LSA with the P-bit set and simply letting the Type-7 translation process originate the Type-5 LSA. Thus Type-5 LSAs would then never need to set a forwarding address that belongs in a stub area or an NSSA, except during the Type-7 LSA translation process. Hence if the best forwarding address is in the transit topology, it is better to originate both a Type-5 LSA and a Type-7 LSA with the P-bit clear. If the best forwarding address belongs to the NSSA, it is better to simply originate a Type-7 LSA with the P-bit set and let the Type-7 translation process originate the Type-5 LSA. >(2) Suppose an ABR is connected to area 0 and multiple NSSA areas, it >redistributes locally sourced external route for subnet N into OSPF, >and this ABR is a translator for all of its NSSA areas. In this case, >what will the type-5/type-7 LSAs originated by this ABR for subnet N >look like (in terms of LSA-type, forwarding address, P-bit setting)? I >think there are at least three sub-cases here, depending on where the >next hop gateway (G) for N is located: (2.1) G is not within the OSPF >domain;(2.2) G is within area 0; (2.3) G is within one of the NSSA areas. If one follows my recommendation above, the answer depends on whether N belongs to one of the NSSAs or to the non-NSSA topology. Also does your implementation allow the granularity of deciding whether or not to redistribute the route into each NSSA specifically as well as the non-NSSA topology. Let's assume that the redistribute is intended to feed the route into all NSSAs and the non-NSSA topology. If (G) belongs to the non-NSSA topology, originate a Type-5 LSA with forwarding address (G) into the non-NSSA topology and also originate a Type-7 LSA with the P-bit clear into each NSSA. Here the Type-7 LSAs can simply use a 0.0.0.0 forwarding address. If (G) belongs to one of the NSSAs, then originate a Type-7 LSA with the P-bit set into that NSSA with the forwarding address set to (G). Finally originate a Type-7 LSA with the P-bit clear into the remaining NSSAs. Note again that Type-7 translation will cause the appropriate Type-5 LSA to be originated into the non-NSSA topology. >(3) RFC 3101 sec 3.2: > The path type and metric of the Type-7 address range is > determined from the path types and metrics of those > translatable Type-7 LSAs that best match the range plus any > locally sourced Type-5 LSAs whose network has the same > [address,mask] pair. If any of these LSAs have a path type of > 2, the range's path type is 2, otherwise it is 1. If the > range's path type is 1 its metric is the highest cost amongst > these LSAs; if the range's path type is 2 its metric is the > highest Type-2 cost + 1 amongst these LSAs. (See Section 2.5 > step (5).) 1 is added to the Type-2 cost to ensure that the > translated Type-5 LSA does not appear closer on the NSSA > border than a translatable Type-7 LSA whose network has the > same [address,mask] pair and Type-2 cost. Can someone explain the reason for adding 1 to the type-2 cost above (in plain English please)? It is entirely possible that a Type-7 LSA may be aggregated by a Type 7 range into a Type-5 translation that has the same prefix ([address,mask] pair) as the Type 7 LSA. If there are other Type 7 LSAs subsumed by the same Type 7 range then the forwarding address of the Type-5 translation is set to 0.0.0.0. This could easily make the Type-5 translation appear closer on the border than the original Type-7 LSA, thus potentially causing a tight righting loop. I believe OSPF Section 16.4.1 resolves this issue unless RFC1583Compatibility is set to "enabled". Regardless retaining the metric settings of RFC 1587 translation process maintained compatibility with older implementations. Pat From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of James Huang Sent: Thursday, February 04, 2010 1:23 PM To: ospf@ietf.org Subject: [OSPF] OSPF NSSA ABR bahaviors Hi all, I have a few questions regarding NSSA ABR: (1) Under what circumstances will an ABR originate type-7 LSAs with P-bit set to 1 into a NSSA area for locally sourced external routes? And why is it better than itself originating a type-5 LSA into type-5 capable areas and a type-7 LSA with P-bit set to 0 into NSSA areas? (2) Suppose an ABR is connected to area 0 and multiple NSSA areas, it redistributes locally sourced external route for subnet N into OSPF, and this ABR is a translator for all of its NSSA areas. In this case, what will the type-5/type-7 LSAs originated by this ABR for subnet N look like (in terms of LSA-type, forwarding address, P-bit setting)? I think there are at least three sub-cases here, depending on where the next hop gateway (G) for N is located: (2.1) G is not within the OSPF domain; (2.2) G is within area 0; (2.3) G is within one of the NSSA areas. (3) RFC 3101 sec 3.2: The path type and metric of the Type-7 address range is determined from the path types and metrics of those translatable Type-7 LSAs that best match the range plus any locally sourced Type-5 LSAs whose network has the same [address,mask] pair. If any of these LSAs have a path type of 2, the range's path type is 2, otherwise it is 1. If the range's path type is 1 its metric is the highest cost amongst these LSAs; if the range's path type is 2 its metric is the highest Type-2 cost + 1 amongst these LSAs. (See Section 2.5 step (5).) 1 is added to the Type-2 cost to ensure that the translated Type-5 LSA does not appear closer on the NSSA border than a translatable Type-7 LSA whose network has the same [address,mask] pair and Type-2 cost. Can someone explain the reason for adding 1 to the type-2 cost above (in plain English please)? Thanks, James Huang ------=_NextPart_000_001C_01CAA5BF.5470DDE0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

My NSSA recollections are getting dimmer and = dimmer. But here it is:

 

>(1)    Under what = circumstances will an ABR originate type-7 LSAs with

>P-bit set to 1 into a NSSA area for locally = sourced external routes?

>And why is it better than itself originating = a type-5 LSA into type-5

>capable areas and a type-7 LSA with P-bit = set to 0 into NSSA areas?

 

RFC 3101 simply states:

 

   If the border router only = originates a Type-7 LSA, it

   may set the P-bit so that the = network may be aggregated/propagated

   during Type-7 translation.  If = an NSSA's border router originates a

   Type-5 LSA with a forwarding = address from the NSSA, it should also

   originate a Type-7 LSA into the = NSSA.

 

Thus if one desires to aggregate the external = route during Type-7 translation using a Type-7 address range then a Type-7 LSA = with the P-bit set must be originated.

 

Note the latter statement from RFC 3101 simply = ensures that non-NSSA traffic forwarded by a Type-5 LSA installation toward a = forwarding address inside an NSSA won't loop. I prefer originating the Type-7 LSA = with the P-bit set and simply letting the Type-7 translation process originate = the Type-5 LSA. Thus Type-5 LSAs would then never need to set a forwarding = address that belongs in a stub area or an NSSA, except during the Type-7 LSA translation process. Hence if the best forwarding address is in the = transit topology, it is better to originate both a Type-5 LSA and a Type-7 LSA = with the P-bit clear. If the best forwarding address belongs to the NSSA, it is = better to simply originate a Type-7 LSA with the P-bit set and let the Type-7 = translation process originate the Type-5 LSA.

 

 

>(2)    Suppose an ABR is = connected to area 0 and multiple NSSA areas, it

>redistributes locally sourced external route = for subnet N into OSPF,

>and this ABR is a translator for all of its = NSSA areas.  In this case,

>what will the type-5/type-7 LSAs originated = by this ABR for subnet N

>look like (in terms of LSA-type, forwarding = address, P-bit setting)?  I

>think there are at least three sub-cases = here, depending on where the

>next hop gateway (G) for N is located: (2.1) = G is not within the OSPF

>domain;(2.2) G is within area 0; (2.3) G is = within one of the NSSA areas.

 

If one follows my recommendation above, the = answer depends on whether N belongs to one of the NSSAs or to the non-NSSA = topology. Also does your implementation allow the granularity of deciding whether = or not to redistribute the route into each NSSA specifically as well as the = non-NSSA topology. Let's assume that the redistribute is intended to feed the = route into all NSSAs and the non-NSSA topology. If (G) belongs to the non-NSSA = topology, originate a Type-5 LSA with forwarding address (G) into the non-NSSA = topology and also originate a Type-7 LSA with the P-bit clear into each NSSA. = Here the Type-7 LSAs can simply use a 0.0.0.0 forwarding address. If (G) belongs = to one of the NSSAs, then originate a Type-7 LSA with the P-bit set into that = NSSA with the forwarding address set to (G). Finally originate a Type-7 LSA = with the P-bit clear into the remaining NSSAs. Note again that Type-7 translation = will cause the appropriate Type-5 LSA to be originated into the non-NSSA = topology.

 

>(3)  RFC 3101 sec 3.2:

>        =   The path type and metric of the Type-7 address range is

>        =   determined from the path types and metrics of those

>        =   translatable Type-7 LSAs that best match the range plus = any

>        =   locally sourced Type-5 LSAs whose network has the same

>        =   [address,mask] pair.  If any of these LSAs have a path type = of

>        =   2, the range's path type is 2, otherwise it is 1.  If = the

>        =   range's path type is 1 its metric is the highest cost = amongst

>        =   these LSAs; if the range's path type is 2 its metric is = the

>        =   highest Type-2 cost + 1 amongst these LSAs.  (See Section = 2.5

>        =   step (5).)  1 is added to the Type-2 cost to ensure that = the

>        =   translated Type-5 LSA does not appear closer on the NSSA

>        =   border than a translatable Type-7 LSA whose network has = the

>        =   same [address,mask] pair and Type-2 cost.

 

Can someone explain the reason for adding 1 to = the type-2 cost above (in plain English please)?

 

It is entirely possible that a Type-7 LSA may be aggregated by a Type 7 range into a Type-5 translation that has the same = prefix ([address,mask] pair) as the Type 7 LSA. If there are other Type 7 LSAs subsumed by the same Type 7 range then the forwarding address of the = Type-5 translation is set to 0.0.0.0. This could easily make the Type-5 = translation appear closer on the border than the original Type-7 LSA, thus = potentially causing a tight righting loop. I believe OSPF Section 16.4.1 resolves this issue = unless RFC1583Compatibility is set to "enabled". Regardless retaining = the metric settings of RFC 1587 translation process maintained compatibility = with older implementations.

 

Pat

 

From:= ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of = James Huang
Sent: Thursday, February 04, 2010 1:23 PM
To: ospf@ietf.org
Subject: [OSPF] OSPF NSSA ABR bahaviors

 

Hi all,

 

I have a few questions regarding NSSA ABR: =

 

(1)    Under what circumstances will an ABR originate = type-7 LSAs with P-bit set to 1 into a NSSA area for locally sourced external = routes?  And why is it better than itself originating a type-5 LSA into type-5 = capable areas and a type-7 LSA with P-bit set to 0 into NSSA = areas?

 

(2)    Suppose an ABR is connected to area 0 and = multiple NSSA areas, it redistributes locally sourced external route for subnet N into = OSPF, and this ABR is a translator for all of its NSSA areas.  In this = case, what will the type-5/type-7 LSAs originated by this ABR for subnet N = look like (in terms of LSA-type, forwarding address, P-bit setting)?  I think = there are at least three sub-cases here, depending on where the next hop = gateway (G) for N is located: (2.1) G is not within the OSPF domain; (2.2) G is = within area 0; (2.3) G is within one of the NSSA areas.  

 

(3)    RFC 3101 sec 3.2:

        &nbs= p; The path type and metric of the Type-7 address range is

        &nbs= p; determined from the path types and metrics of those

        &nbs= p; translatable Type-7 LSAs that best match the range plus = any

        &nbs= p; locally sourced Type-5 LSAs whose network has the same

        &nbs= p; [address,mask] pair.  If any of these LSAs have a path type = of

        &nbs= p; 2, the range's path type is 2, otherwise it is 1.  If = the

        &nbs= p; range's path type is 1 its metric is the highest cost = amongst

        &nbs= p; these LSAs; if the range's path type is 2 its metric is = the

        &nbs= p; highest Type-2 cost + 1 amongst these LSAs.  (See Section = 2.5

        &nbs= p; step (5).)  1 is added to the Type-2 cost to ensure that = the

        &nbs= p; translated Type-5 LSA does not appear closer on the NSSA

        &nbs= p; border than a translatable Type-7 LSA whose network has = the

        &nbs= p; same [address,mask] pair and Type-2 cost.

 

Can someone explain the reason for adding 1 = to the type-2 cost above (in plain English please)?

 

Thanks,

James Huang

------=_NextPart_000_001C_01CAA5BF.5470DDE0-- From rcallon@juniper.net Fri Feb 5 09:41:43 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 4FB7B28C1DC; Fri, 5 Feb 2010 09:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 riRHAnN3eHKf; Fri, 5 Feb 2010 09:41:42 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 41D0628C189; Fri, 5 Feb 2010 09:41:38 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS2xYhFjvpwyLVMrM8IXTk9pJX41fuXI3@postini.com; Fri, 05 Feb 2010 09:42:33 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, 5 Feb 2010 09:41:19 -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, 5 Feb 2010 12:41:18 -0500 From: Ross Callon To: The IESG , IETF-Announce Date: Fri, 5 Feb 2010 12:39:29 -0500 Thread-Topic: Protocol Action: 'OSPFv3 as a PE-CE routing protocol' to Proposed Standard Thread-Index: AcqCYwurkGappoAxTYqyUIRItTZ5gQkJGv3Q Message-ID: References: <20091221172849.625393A6A64@core3.amsl.com> In-Reply-To: <20091221172849.625393A6A64@core3.amsl.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: "ospf@ietf.org" , l3vpn chair , Internet Architecture Board , l3vpn mailing list , RFC Editor Subject: Re: [OSPF] Protocol Action: 'OSPFv3 as a PE-CE routing protocol' 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: Fri, 05 Feb 2010 17:41:43 -0000 The authors, in response to comments received since this approval, have dec= ided to make a further update to this document (as has been announced to th= e L3VPN and OSPF email lists in recent mail from the authors). We have ther= efore taken the unusual step of unapproving this document and returning it = to the WG for additional work.=20 Thanks, Ross=20 (as AD for the L3VPN WG) -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of The IESG Sent: 21 December 2009 12:29 To: IETF-Announce Cc: l3vpn chair; Internet Architecture Board; l3vpn mailing list; RFC Edito= r Subject: Protocol Action: 'OSPFv3 as a PE-CE routing protocol' to Proposed = Standard The IESG has approved the following document: - 'OSPFv3 as a PE-CE routing protocol ' as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Workin= g Group.=20 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-l3vpn-ospfv3-pece-04.txt Technical Summary Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is very similar to the previously-specified approached for OSPFv2. Working Group Summary No controversy reported (see PROTO writeup by Danny McPherson in the=20 ID Tracker). There were no objections during the WG Last Call on the document, and the utility of this specification is straight-forward, as well as both obvious and intuitive. Document Quality No known implementations.=20 Personnel Danny McPherson is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. RFC Editor Note All references to [BGP-EXTCOMM-IPV6] should be replaced by a=20 references to [RFC5701]. In the informative references section (11.2), please remove the reference to [BGP-EXTCOMM-IPV6]. Please add a reference to RFC5701 in the normative references=20 section (11.1). _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From rcallon@juniper.net Fri Feb 5 09:53: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 AB26B3A68FA; Fri, 5 Feb 2010 09:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 d7JxKhwPP3bU; Fri, 5 Feb 2010 09:53:54 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 3112828C147; Fri, 5 Feb 2010 09:53:53 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS2xbV4eh8CXpuY/qxgUUaKvX/gts5QFk@postini.com; Fri, 05 Feb 2010 09:54:45 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 5 Feb 2010 09:53:37 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 5 Feb 2010 12:53:36 -0500 From: Ross Callon To: Padma Pillay-Esnault Date: Fri, 5 Feb 2010 12:53:35 -0500 Thread-Topic: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' Thread-Index: Acqhb3ius3INpb0DSiG0UPWCK2kuogFG6T0Q Message-ID: 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: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB177049A1B7CBB8FEMBX01WFjnprn_" MIME-Version: 1.0 Cc: "benjamin.niven-jenkins@bt.com" , l3vpn mailing list , "jdoyle@doyleassociates.net" , "Ertekin, Emre \[USA\]" , "ospf@ietf.org" , Eubanks , Adrian Farrel , "pete@pollere.net" , Marshall 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: Fri, 05 Feb 2010 17:53:55 -0000 --_000_DF7F294AF4153D498141CBEFADB177049A1B7CBB8FEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have changed the state back to "AD is Watching", and informed the appropr= iate folks (IESG, RFC Editor, secretariat). Thus you can feel free to updat= e the document whenever is convenient for the authors. Once the document is updated, we will need to repeat the WG last call (whic= h I believe should be sent to both L3VPN and OSPF WGs). Please let me know= when this is complete. Thanks, Ross ________________________________ From: Padma Pillay-Esnault [mailto:ppe@cisco.com] Sent: 30 January 2010 00:47 To: Ross Callon; Adrian Farrel; acee.lindem@ericsson.com; Abhay Roy (akr); = Peter Psenak (ppsenak) Cc: Padma Pillay-Esnault; pete@pollere.net; Lundberg, Michael [USA]; Erteki= n, Emre [USA]; jdoyle@doyleassociates.net; ospf@ietf.org Subject: RE: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3= as a PE-CE routing protocol' 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. 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 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. Regards, The authors --_000_DF7F294AF4153D498141CBEFADB177049A1B7CBB8FEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have changed the state back to "= ;AD is Watching", and informed the appropriate folks (IESG, RFC Editor, secretariat). Thus you can feel free to update the document whenever is convenient for the authors.

 

Once the document is updated, we will = need to repeat the WG last call (which I believe should be sent to both L3VPN an= d OSPF WGs).  Please let me know when this is complete.

 

Thanks, Ross =

 

From: Padma Pillay-Esnault [mailto:ppe@cisco.com]
Sent: 30 January 2010 00:47<= br> To: Ross Callon; Adrian Farr= el; acee.lindem@ericsson.com; Abhay Roy (akr); Peter Psenak (ppsenak)
Cc: Padma Pillay-Esnault; pete@pollere.net; Lundberg, Michael [USA]; Ertekin, Emre [USA]; jdoyle@doyleassociates.net; ospf@ietf.org
Subject: RE: [OSPF] OSPF WG = review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol'

=  

=
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 architectur= e 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<= br> an Intra-Area-Prefix (type 0x2009) LSA only when sham links are used,
as described in Section 5.  Otherwise routes are advertised as either<= br> 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<= br> 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   &nb= sp; 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 fr= om
   being re-advertised into BGP.  "

Proposed change

  " Similarly, the DN-bit MU= ST 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 fr= om
   being re-advertised into BGP.  "

Section 5 OSPFv3 Sham Links

"Sham link endpoint addresses MUST be distributed by BGP as routeable<= br> 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 MUS= T 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 c=
arries a type-1 or
      type-2 metric.  Setting the least sig=
nificant bit in the field
      indicates that the route carries a Externa=
l 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. <= br> PPE : Only the least significant bit is set to indicate the presence of&nbs= p; 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 Optio= ns bit,  an IANA registry for the route types could be added.  I wil= l defer to the ADs on this matter.

Regards,

The authors

--_000_DF7F294AF4153D498141CBEFADB177049A1B7CBB8FEMBX01WFjnprn_-- From James.Huang@watchguard.com Fri Feb 5 12:51: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 D11ED3A68C6 for ; Fri, 5 Feb 2010 12:51: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 gJ24sZsHXxPe for ; Fri, 5 Feb 2010 12:51:00 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id ABAD43A6B40 for ; Fri, 5 Feb 2010 12:51: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Feb 2010 12:51:51 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F301AB4D4F@ES02CO.wgti.net> In-Reply-To: <001b01caa602$62941de0$27bc59a0$@usgs.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF NSSA ABR behaviors Thread-Index: AcqmAmntWZTVpRYDQ0i5DsTFbW+AhwAjOFmg References: <7C3D15DD6E8F464998CA1470D8A322F301AB4A8D@ES02CO.wgti.net> <001b01caa602$62941de0$27bc59a0$@usgs.net> From: "James Huang" To: , Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 05 Feb 2010 20:51:01 -0000 Hi Pat, See my comments below. -- James Huang >From: Patrick W. Murphy, Ph.D. [mailto:pmurphy@noc.usgs.net]=20 >Sent: Thursday, February 04, 2010 5:28 PM >To: ospf@ietf.org >Cc: James Huang >Subject: RE: [OSPF] OSPF NSSA ABR behaviors > >My NSSA recollections are getting dimmer and dimmer. But here it is: > >>(1)=A0=A0=A0 Under what circumstances will an ABR originate type-7 = LSAs with >>P-bit set to 1 into a NSSA area for locally sourced external routes? >>And why is it better than itself originating a type-5 LSA into type-5=20 >>capable areas and a type-7 LSA with P-bit set to 0 into NSSA areas? > >RFC 3101 simply states: > >=A0=A0 If the border router only originates a Type-7 LSA, it >=A0=A0 may set the P-bit so that the network may be = aggregated/propagated >=A0=A0 during Type-7 translation.=A0 If an NSSA's border router = originates a >=A0=A0 Type-5 LSA with a forwarding address from the NSSA, it should = also >=A0=A0 originate a Type-7 LSA into the NSSA. > >Thus if one desires to aggregate the external route during Type-7 = translation using a Type-7 address range then >a Type-7 LSA with the = P-bit set must be originated. > >Note the latter statement from RFC 3101 simply ensures that non-NSSA = traffic forwarded by a Type-5 LSA >installation toward a forwarding = address inside an NSSA won't loop. I prefer originating the Type-7 LSA = with >the P-bit set and simply letting the Type-7 translation process = originate the Type-5 LSA. Thus Type-5 LSAs >would then never need to set = a forwarding address that belongs in a stub area or an NSSA, except = during the >Type-7 LSA translation process. Hence if the best forwarding = address is in the transit topology, it is better >to originate both a = Type-5 LSA and a Type-7 LSA with the P-bit clear. If the best forwarding = address belongs to >the NSSA, it is better to simply originate a Type-7 = LSA with the P-bit set and let the Type-7 translation >process originate = the Type-5 LSA. > > [James Huang]=20 When you say a router originates a type-7 LSA, does it mean that the = type-7 LSA will be advertised? Or it simply means that the type-7 LSA is generated internally and it = depends on the translation process to determine whether it should be = aggregated with some other external LSA(s) or be advertised = individually? What you said above will make sense if the answer is the = second one. >>(2)=A0=A0=A0 Suppose an ABR is connected to area 0 and multiple NSSA = areas, it >>redistributes locally sourced external route for subnet N into OSPF,=20 >>and this ABR is a translator for all of its NSSA areas.=A0 In this = case,=20 >>what will the type-5/type-7 LSAs originated by this ABR for subnet N=20 >>look like (in terms of LSA-type, forwarding address, P-bit = setting)?=A0 I=20 >>think there are at least three sub-cases here, depending on where the=20 >>next hop gateway (G) for N is located: (2.1) G is not within the OSPF=20 >>domain;(2.2) G is within area 0; (2.3) G is within one of the NSSA = areas. > >If one follows my recommendation above, the answer depends on whether N = belongs to one of the NSSAs or to the >non-NSSA topology. Also does your = implementation allow the granularity of deciding whether or not to = >redistribute the route into each NSSA specifically as well as the = non-NSSA topology. Let's assume that the >redistribute is intended to = feed the route into all NSSAs and the non-NSSA topology. If (G) belongs = to the non->NSSA topology, originate a Type-5 LSA with forwarding = address (G) into the non-NSSA topology and also originate >a Type-7 LSA = with the P-bit clear into each NSSA. Here the Type-7 LSAs can simply use = a 0.0.0.0 forwarding >address. If (G) belongs to one of the NSSAs, then = originate a Type-7 LSA with the P-bit set into that NSSA with >the = forwarding address set to (G). Finally originate a Type-7 LSA with the = P-bit clear into the remaining >NSSAs. Note again that Type-7 = translation will cause the appropriate Type-5 LSA to be originated into = the non->NSSA topology. [James Huang]=20 Agree - assuming address aggregation is not performed. >>(3)=A0 RFC 3101 sec 3.2: >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 The path type and metric of the Type-7 = address range is >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 determined from the path types and metrics = of those >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 translatable Type-7 LSAs that best match = the range plus any >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 locally sourced Type-5 LSAs whose network = has the same >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 [address,mask] pair.=A0 If any of these = LSAs have a path type of >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 2, the range's path type is 2, otherwise = it is 1.=A0 If the >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 range's path type is 1 its metric is the = highest cost amongst >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 these LSAs; if the range's path type is 2 = its metric is the >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 highest Type-2 cost + 1 amongst these = LSAs.=A0 (See Section 2.5 >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 step (5).)=A0 1 is added to the Type-2 = cost to ensure that the >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 translated Type-5 LSA does not appear = closer on the NSSA >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 border than a translatable Type-7 LSA = whose network has the >>=A0=A0=A0=A0=A0=A0=A0=A0=A0 same [address,mask] pair and Type-2 cost. >> >>Can someone explain the reason for adding 1 to the type-2 cost above = (in plain English please)? >It is entirely possible that a Type-7 LSA may be aggregated by a Type 7 = range into a Type-5 translation that >has the same prefix = ([address,mask] pair) as the Type 7 LSA. If there are other Type 7 LSAs = subsumed by the >same Type 7 range then the forwarding address of the = Type-5 translation is set to 0.0.0.0. This could easily >make the Type-5 = translation appear closer on the border than the original Type-7 LSA, = thus potentially causing >a tight righting loop. I believe OSPF Section = 16.4.1 resolves this issue unless RFC1583Compatibility is set to = >"enabled". Regardless retaining the metric settings of RFC 1587 = translation process maintained compatibility >with older = implementations. > > >Pat [James Huang]=20 I see. Adding 1 to the type-2 cost is to make sure that the aggregated = type-7 LSA (p=3D0) sent into the NSSA area will have a larger metric = than the original type-7 (p=3D1) LSA (with the same [address, range]) = received from the NSSA. This will prevent the other router in the NSSA = area from choosing the best route for the destination towards this ABR. = But, as you has pointed out, RFC2328 sec16.4.1 will prefer intra-area = forwarding address/advertising router. So this will not happen if = RFC1583Compatibility is set to disabled. Note the tie breaking rule in = sec 2.5, step (6e) will not help the other routers to choose the right = type-7 LSA because these two LSAs are not functionally equivalent (one = has forwarding address set to 0).=20 On a related question: When a MSSA ABR originates a aggregated type-5 = LSA, does it has to advertise a corresponding type-7 (p=3D0) LSA into = the NSSA area? I cannot find any rule in RFC 3101 about this. I think = the answer is no unless more than one locally sourced external LSAs with = the best forwarding addresses NOT in the NSSA are aggregated into the = type-5 LSA (otherwise, individual type-7 LSA (p=3D0) should be = advertised). Is this correct? =20 One more question, RFC3101, sec 3.2 step (3): The path type and metric of the Type-7 address range is determined from the path types and metrics of those translatable Type-7 LSAs that best match the range plus any locally sourced Type-5 LSAs whose network has the same [address,mask] pair. What is the reason aggregation can only aggregate those locally sourced = type-5 LSAs with the same [address, mask] as the configured address = range? If a locally sourced type-5 LSA is subsumed within the range, = can it be aggregated too? From pmurphy@noc.usgs.net Fri Feb 5 15:19:10 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 CA2BD28C173 for ; Fri, 5 Feb 2010 15:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[AWL=-2.700, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=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 6rac9TQFykbu for ; Fri, 5 Feb 2010 15:19:09 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id B012328C167 for ; Fri, 5 Feb 2010 15:19:06 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01NJB3RECGOW000DP4@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Fri, 05 Feb 2010 15:19:57 -0700 (PDT) Date: Fri, 05 Feb 2010 15:19:57 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: OSPF@IETF.ORG Message-id: <01NJB3RECHMQ000DP4@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHY,James.Huang@watchguard.com MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: JAMES.HUANG@WATCHGUARD.COM Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 05 Feb 2010 23:19:11 -0000 James, See comments inline. P>Thus if one desires to aggregate the external route during Type-7 P>translation using a Type-7 address range then a Type-7 LSA with the P-bit P>set must be originated. P>Note the latter statement from RFC 3101 simply ensures that non-NSSA P>traffic forwarded by a Type-5 LSA installation toward a forwarding address P>inside an NSSA won't loop. I prefer originating the Type-7 LSA with the P>P-bit set and simply letting the Type-7 translation process originate the P>Type-5 LSA. Thus Type-5 LSAs would then never need to set a forwarding P>address that belongs in a stub area or an NSSA, except during the Type-7 P>LSA translation process. Hence if the best forwarding address is in the P>transit topology, it is better to originate both a Type-5 LSA and a Type-7 P>LSA with the P-bit clear. If the best forwarding address belongs to the P>NSSA, it is better to simply originate a Type-7 LSA with the P-bit set and P>let the Type-7 translation process originate the Type-5 LSA. J>When you say a router originates a type-7 LSA, does it mean J>that the type-7 LSA will be advertised? Of course, all LSAs are advertised by an originating router. See RFC 2328 Appendix A.4.1, "The LSA header". J>Or it simply means that the type-7 LSA is generated internally J>and it depends on the translation process to determine whether J>it should be aggregated with some other external LSA(s) or be J>advertised individually? Like all LSAs, Type-7 LSAs are only generated to be originated by an advertising router. But once originated with the P-bit set the Type-7 LSA may generate a Type-5 translation as described in RFC 3101 Section 3.2, Translating Type-7 LSAs into Type-5 LSAs. P>Let's assume that the redistribute is intended to feed the route P>into all NSSAs and the non-NSSA topology. If (G) belongs to the non-NSSA P>topology, originate a Type-5 LSA with forwarding address (G) into the P>non-NSSA topology and also originate a Type-7 LSA with the P-bit clear P>into each NSSA. Here the Type-7 LSAs can simply use a 0.0.0.0 forwarding P>address. If (G) belongs to one of the NSSAs, then originate a Type-7 LSA P>with the P-bit set into that NSSA with the forwarding address set to (G). P>Finally originate a Type-7 LSA with the P-bit clear into the remaining P>NSSAs. Note again that Type-7 translation will cause the appropriate P>Type-5 LSA to be originated into the non-NSSA topology. J>Agree - assuming address aggregation is not performed. Type-7 ranges that subsume only a single prefix with the same [address,mask] pair result in a normal translation. Hence, since type-7 ranges can even subsume other type-7 ranges, one can negate the effects of aggregation under configuration control. This is a subtle point from RFC 3101 Section 3.2. J>On a related question: When a MSSA ABR originates a aggregated J>type-5 LSA, does it has to advertise a corresponding type-7 (p=0) J>LSA into the NSSA area? I cannot find any rule in RFC 3101 about this. The origination of a type-5 LSA generated by the translation of a type-7 LSA NEVER forces the origination of another type-7 LSA. J>I think the answer is no unless more than one locally sourced J>external LSAs with the best forwarding addresses NOT in the NSSA are J>aggregated into the type-5 LSA (otherwise, individual type-7 LSA J>(p=0) should be advertised). Is this correct? The non-zero forwarding addresses of Type-7 LSAs are always chosen from interfaces that belong to the NSSA. See Section 2.3. A type-5 translation that aggregates a set of installed type-7 LSAs also NEVER forces the origination of another type-7 LSA. J>One more question, RFC3101, sec 3.2 step (3): The path type and metric of the Type-7 address range is determined from the path types and metrics of those translatable Type-7 LSAs that best match the range plus any locally sourced Type-5 LSAs whose network has the same [address,mask] pair. J>What is the reason aggregation can only aggregate those locally sourced J>type-5 LSAs with the same [address, mask] as the configured address range? Since this is an aggregation its metric must reflect the highest cost amongst the type-7 LSAs being aggregated. A locally source type-5 LSA that has the same [address,mask] pair coupled with a lower cost could negate the translation metrics. Similarly a lower cost in the Type-5 translation of a type-7 range would negate the high cost of a locally sourced type-5 LSA with the same [address,mask] pair. Hence a single advertisement is required. J>If a locally sourced type-5 LSA is subsumed within the range, can it J>be aggregated too? No. The above excerpt is the only exception. Pat From James.Huang@watchguard.com Fri Feb 5 16:57:28 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 7C2403A6E79 for ; Fri, 5 Feb 2010 16:57:28 -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 RVLpu6WpFUsA for ; Fri, 5 Feb 2010 16:57:27 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id 611453A681A for ; Fri, 5 Feb 2010 16:57:27 -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: Fri, 5 Feb 2010 16:58:16 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F301AB4E12@ES02CO.wgti.net> In-Reply-To: <01NJB3RECHMQ000DP4@omega7.wr.usgs.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF NSSA ABR behaviors Thread-Index: AcqmubyY//pXEa1YTWeTEQ/LDDW6DQABs97A References: <01NJB3RECHMQ000DP4@omega7.wr.usgs.gov> From: "James Huang" To: "Pat Murphy - (650)329-4044" , Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 06 Feb 2010 00:57:28 -0000 Hi Pat, I did some NSSA test on a router (with very new software installed) from the #1 networking vendor. Here is my observation about their NSSA ABR behavior with regarding to external LSA aggregation: (1) When an NSSA ABR does not have any locally sourced external routes matching an address range, it will aggregate installed type-7 LSAs = (p=3D1) received from the NSSA matching the address range into a type-5 LSA and advertise the LSA to the transit topology.=20 (2) When an NSSA ABR has some locally sourced external routes subsumed within an address range (may or may not be strictly), it will aggregate installed type-7 LSAs (p=3D1) received from the NSSA matching the = address range and all those external routes into a type-5 LSA and advertise the LSA into the transit topology. In addition, it will originate a corresponding type-7 LSA (same destination, cost, and advertising router as the aggregated type-5 LSA, p=3D0, forwarding address=3D0) to the NSSA area. It will not originate a type-7 LSA individually for each of the locally sourced external routes. So their NSSA ABR behavior does not seem to comply with what was stated in your previous email in two ways: (1) origination of an aggregated type-5 LSA from at least one locally sourced external route will always force the origination of a corresponding type-7 LSA (p=3D0) into the NSSA, and (2) locally sourced external routes subsumed within the address range are aggregated into the type-5 LSA. They does not have to have the same [address, mask] as the address range. Now I am really confused. -- James Huang =20 >-----Original Message----- >From: Pat Murphy - (650)329-4044 [mailto:pmurphy@noc.usgs.net] >Sent: Friday, February 05, 2010 2:20 PM >To: OSPF@IETF.ORG >Cc: James Huang >Subject: Re: [OSPF] OSPF NSSA ABR behaviors > >James, > >See comments inline. > >P>Thus if one desires to aggregate the external route during Type-7 >P>translation using a Type-7 address range then a Type-7 LSA with the P- >bit >P>set must be originated. > >P>Note the latter statement from RFC 3101 simply ensures that non-NSSA >P>traffic forwarded by a Type-5 LSA installation toward a forwarding >address >P>inside an NSSA won't loop. I prefer originating the Type-7 LSA with >the >P>P-bit set and simply letting the Type-7 translation process originate >the >P>Type-5 LSA. Thus Type-5 LSAs would then never need to set a forwarding >P>address that belongs in a stub area or an NSSA, except during the >Type-7 >P>LSA translation process. Hence if the best forwarding address is in >the >P>transit topology, it is better to originate both a Type-5 LSA and a >Type-7 >P>LSA with the P-bit clear. If the best forwarding address belongs to >the >P>NSSA, it is better to simply originate a Type-7 LSA with the P-bit set >and >P>let the Type-7 translation process originate the Type-5 LSA. > >J>When you say a router originates a type-7 LSA, does it mean >J>that the type-7 LSA will be advertised? > >Of course, all LSAs are advertised by an originating router. >See RFC 2328 Appendix A.4.1, "The LSA header". > >J>Or it simply means that the type-7 LSA is generated internally >J>and it depends on the translation process to determine whether >J>it should be aggregated with some other external LSA(s) or be >J>advertised individually? > >Like all LSAs, Type-7 LSAs are only generated to be originated >by an advertising router. But once originated with the P-bit set >the Type-7 LSA may generate a Type-5 translation as described in >RFC 3101 Section 3.2, Translating Type-7 LSAs into Type-5 LSAs. > >P>Let's assume that the redistribute is intended to feed the route >P>into all NSSAs and the non-NSSA topology. If (G) belongs to the non- >NSSA >P>topology, originate a Type-5 LSA with forwarding address (G) into the >P>non-NSSA topology and also originate a Type-7 LSA with the P-bit clear >P>into each NSSA. Here the Type-7 LSAs can simply use a 0.0.0.0 >forwarding >P>address. If (G) belongs to one of the NSSAs, then originate a Type-7 >LSA >P>with the P-bit set into that NSSA with the forwarding address set to >(G). >P>Finally originate a Type-7 LSA with the P-bit clear into the remaining >P>NSSAs. Note again that Type-7 translation will cause the appropriate >P>Type-5 LSA to be originated into the non-NSSA topology. > >J>Agree - assuming address aggregation is not performed. > >Type-7 ranges that subsume only a single prefix with the same >[address,mask] pair result in a normal translation. Hence, since >type-7 ranges can even subsume other type-7 ranges, one can negate >the effects of aggregation under configuration control. This is a >subtle point from RFC 3101 Section 3.2. > >J>On a related question: When a MSSA ABR originates a aggregated >J>type-5 LSA, does it has to advertise a corresponding type-7 (p=3D0) >J>LSA into the NSSA area? I cannot find any rule in RFC 3101 about >this. > >The origination of a type-5 LSA generated by the translation of a >type-7 LSA NEVER forces the origination of another type-7 LSA. > >J>I think the answer is no unless more than one locally sourced >J>external LSAs with the best forwarding addresses NOT in the NSSA are >J>aggregated into the type-5 LSA (otherwise, individual type-7 LSA >J>(p=3D0) should be advertised). Is this correct? > >The non-zero forwarding addresses of Type-7 LSAs are always >chosen from interfaces that belong to the NSSA. See Section 2.3. >A type-5 translation that aggregates a set of installed type-7 >LSAs also NEVER forces the origination of another type-7 LSA. > >J>One more question, RFC3101, sec 3.2 step (3): > > The path type and metric of the Type-7 address range is > determined from the path types and metrics of those > translatable Type-7 LSAs that best match the range plus any > locally sourced Type-5 LSAs whose network has the same > [address,mask] pair. > >J>What is the reason aggregation can only aggregate those locally >sourced >J>type-5 LSAs with the same [address, mask] as the configured address >range? > >Since this is an aggregation its metric must reflect the highest cost >amongst the type-7 LSAs being aggregated. A locally source type-5 LSA >that has the same [address,mask] pair coupled with a lower cost could >negate the translation metrics. Similarly a lower cost in the Type-5 >translation of a type-7 range would negate the high cost of a >locally sourced type-5 LSA with the same [address,mask] pair. Hence >a single advertisement is required. > >J>If a locally sourced type-5 LSA is subsumed within the range, can it >J>be aggregated too? > >No. The above excerpt is the only exception. > >Pat > > > From pmurphy@noc.usgs.net Fri Feb 5 19:36:15 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 E38E83A682E for ; Fri, 5 Feb 2010 19:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=1.350, 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 zSDG9DJ1l8js for ; Fri, 5 Feb 2010 19:36:14 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id B338B3A6359 for ; Fri, 5 Feb 2010 19:36:14 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01NJBCR760QW000D68@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Fri, 05 Feb 2010 19:37:06 -0700 (PDT) Date: Fri, 05 Feb 2010 19:37:06 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: OSPF@IETF.ORG Message-id: <01NJBCR760QY000D68@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHYJames.Huang@watchguard.com MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: PMURPHYJAMES.HUANG@WATCHGUARD.COM Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 06 Feb 2010 03:36:16 -0000 James, I can only respond to your questions regarding the RFC 3101 specification. Specific implementations can deviate from RFC 3101. RFC 3101 is an optional OSPF addition. Deviations from the original NSSA specification are not wrong. They are just different and perhaps not fully featured. Usually most of the more popular and useful features will be present. For specific implementations you will have to refer to implementation specific NSSA documentation. The RFC 3101 specification has been in place for years and to date only one minor tweak has been reported. A complete implementation should function as I have described. Note NSSA is widely used. Perhaps its status as optional should change. Incomplete implementations are disappointing and confusing. In the meantime folk should talk to their vendors about the features they need and perhaps these features will be added in future releases. Pat Date: Fri, 05 Feb 2010 16:58:16 -0800 From: James Huang Subject: RE: [OSPF] OSPF NSSA ABR behaviors In-reply-to: <01NJB3RECHMQ000DP4@omega7.wr.usgs.gov> To: "Pat Murphy - (650)329-4044" , OSPF@IETF.ORG Hi Pat, I did some NSSA test on a router (with very new software installed) from the #1 networking vendor. Here is my observation about their NSSA ABR behavior with regarding to external LSA aggregation: (1) When an NSSA ABR does not have any locally sourced external routes matching an address range, it will aggregate installed type-7 LSAs = (p=3D1) received from the NSSA matching the address range into a type-5 LSA and advertise the LSA to the transit topology.=20 (2) When an NSSA ABR has some locally sourced external routes subsumed within an address range (may or may not be strictly), it will aggregate installed type-7 LSAs (p=3D1) received from the NSSA matching the = address range and all those external routes into a type-5 LSA and advertise the LSA into the transit topology. In addition, it will originate a corresponding type-7 LSA (same destination, cost, and advertising router as the aggregated type-5 LSA, p=3D0, forwarding address=3D0) to the NSSA area. It will not originate a type-7 LSA individually for each of the locally sourced external routes. So their NSSA ABR behavior does not seem to comply with what was stated in your previous email in two ways: (1) origination of an aggregated type-5 LSA from at least one locally sourced external route will always force the origination of a corresponding type-7 LSA (p=3D0) into the NSSA, and (2) locally sourced external routes subsumed within the address range are aggregated into the type-5 LSA. They does not have to have the same [address, mask] as the address range. Now I am really confused. -- James Huang =20 >-----Original Message----- >From: Pat Murphy - (650)329-4044 [mailto:pmurphy@noc.usgs.net] >Sent: Friday, February 05, 2010 2:20 PM >To: OSPF@IETF.ORG >Cc: James Huang >Subject: Re: [OSPF] OSPF NSSA ABR behaviors > >James, > >See comments inline. > >P>Thus if one desires to aggregate the external route during Type-7 >P>translation using a Type-7 address range then a Type-7 LSA with the P- >bit >P>set must be originated. > >P>Note the latter statement from RFC 3101 simply ensures that non-NSSA >P>traffic forwarded by a Type-5 LSA installation toward a forwarding >address >P>inside an NSSA won't loop. I prefer originating the Type-7 LSA with >the >P>P-bit set and simply letting the Type-7 translation process originate >the >P>Type-5 LSA. Thus Type-5 LSAs would then never need to set a forwarding >P>address that belongs in a stub area or an NSSA, except during the >Type-7 >P>LSA translation process. Hence if the best forwarding address is in >the >P>transit topology, it is better to originate both a Type-5 LSA and a >Type-7 >P>LSA with the P-bit clear. If the best forwarding address belongs to >the >P>NSSA, it is better to simply originate a Type-7 LSA with the P-bit set >and >P>let the Type-7 translation process originate the Type-5 LSA. > >J>When you say a router originates a type-7 LSA, does it mean >J>that the type-7 LSA will be advertised? > >Of course, all LSAs are advertised by an originating router. >See RFC 2328 Appendix A.4.1, "The LSA header". > >J>Or it simply means that the type-7 LSA is generated internally >J>and it depends on the translation process to determine whether >J>it should be aggregated with some other external LSA(s) or be >J>advertised individually? > >Like all LSAs, Type-7 LSAs are only generated to be originated >by an advertising router. But once originated with the P-bit set >the Type-7 LSA may generate a Type-5 translation as described in >RFC 3101 Section 3.2, Translating Type-7 LSAs into Type-5 LSAs. > >P>Let's assume that the redistribute is intended to feed the route >P>into all NSSAs and the non-NSSA topology. If (G) belongs to the non- >NSSA >P>topology, originate a Type-5 LSA with forwarding address (G) into the >P>non-NSSA topology and also originate a Type-7 LSA with the P-bit clear >P>into each NSSA. Here the Type-7 LSAs can simply use a 0.0.0.0 >forwarding >P>address. If (G) belongs to one of the NSSAs, then originate a Type-7 >LSA >P>with the P-bit set into that NSSA with the forwarding address set to >(G). >P>Finally originate a Type-7 LSA with the P-bit clear into the remaining >P>NSSAs. Note again that Type-7 translation will cause the appropriate >P>Type-5 LSA to be originated into the non-NSSA topology. > >J>Agree - assuming address aggregation is not performed. > >Type-7 ranges that subsume only a single prefix with the same >[address,mask] pair result in a normal translation. Hence, since >type-7 ranges can even subsume other type-7 ranges, one can negate >the effects of aggregation under configuration control. This is a >subtle point from RFC 3101 Section 3.2. > >J>On a related question: When a MSSA ABR originates a aggregated >J>type-5 LSA, does it has to advertise a corresponding type-7 (p=3D0) >J>LSA into the NSSA area? I cannot find any rule in RFC 3101 about >this. > >The origination of a type-5 LSA generated by the translation of a >type-7 LSA NEVER forces the origination of another type-7 LSA. > >J>I think the answer is no unless more than one locally sourced >J>external LSAs with the best forwarding addresses NOT in the NSSA are >J>aggregated into the type-5 LSA (otherwise, individual type-7 LSA >J>(p=3D0) should be advertised). Is this correct? > >The non-zero forwarding addresses of Type-7 LSAs are always >chosen from interfaces that belong to the NSSA. See Section 2.3. >A type-5 translation that aggregates a set of installed type-7 >LSAs also NEVER forces the origination of another type-7 LSA. > >J>One more question, RFC3101, sec 3.2 step (3): > > The path type and metric of the Type-7 address range is > determined from the path types and metrics of those > translatable Type-7 LSAs that best match the range plus any > locally sourced Type-5 LSAs whose network has the same > [address,mask] pair. > >J>What is the reason aggregation can only aggregate those locally >sourced >J>type-5 LSAs with the same [address, mask] as the configured address >range? > >Since this is an aggregation its metric must reflect the highest cost >amongst the type-7 LSAs being aggregated. A locally source type-5 LSA >that has the same [address,mask] pair coupled with a lower cost could >negate the translation metrics. Similarly a lower cost in the Type-5 >translation of a type-7 range would negate the high cost of a >locally sourced type-5 LSA with the same [address,mask] pair. Hence >a single advertisement is required. > >J>If a locally sourced type-5 LSA is subsumed within the range, can it >J>be aggregated too? > >No. The above excerpt is the only exception. > >Pat > > > From James.Huang@watchguard.com Mon Feb 8 13:39: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 93CA028C0E6 for ; Mon, 8 Feb 2010 13:39:39 -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 rnXiqO5g2N10 for ; Mon, 8 Feb 2010 13:39:38 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id 25BDB3A749F for ; Mon, 8 Feb 2010 13:39:38 -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, 8 Feb 2010 13:40:15 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F301AB4F79@ES02CO.wgti.net> In-Reply-To: <01NJBCR760QY000D68@omega7.wr.usgs.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF NSSA ABR behaviors Thread-Index: Acqm3azG7BUe8Uu7Q42mRzKx07mh8QCJ6DzA References: <01NJBCR760QY000D68@omega7.wr.usgs.gov> From: "James Huang" To: "Pat Murphy - (650)329-4044" , Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 08 Feb 2010 21:39:39 -0000 Hi Pat, One more question about NSSA ABR: In RFC 3101, Section 2.5, step (6e), the following priorities are specified to resolve multiple functional equivalent external LSAs (same destination, cost, and non-zero forwarding address): 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. =20 This means that type-7 LSA with P-bit set is preferred over type-5 LSA and type-5 LSA is preferred over type-7 LSA with P-bit clear. I checked the old NSSA RFC (RFC 1587), it specifies a different priority ordering: 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. What is the reason for this change? Thanks, James Huang >-----Original Message----- >From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of >Pat Murphy - (650)329-4044 >Sent: Friday, February 05, 2010 6:37 PM >To: OSPF@IETF.ORG >Cc: PMURPHYJAMES.HUANG@WATCHGUARD.COM >Subject: Re: [OSPF] OSPF NSSA ABR behaviors > >James, > >I can only respond to your questions regarding the RFC 3101 >specification. Specific implementations can deviate from RFC 3101. RFC >3101 is an optional OSPF addition. Deviations from the original NSSA >specification are not wrong. They are just different and perhaps not >fully featured. Usually most of the more popular and useful features >will be present. For specific implementations you will have to refer to >implementation specific NSSA documentation. The RFC 3101 specification >has been in place for years and to date only one minor tweak has been >reported. A complete implementation should function as I have described. > >Note NSSA is widely used. Perhaps its status as optional should change. >Incomplete implementations are disappointing and confusing. In the >meantime folk should talk to their vendors about the features they need >and perhaps these features will be added in future releases. > >Pat > >Date: Fri, 05 Feb 2010 16:58:16 -0800 >From: James Huang >Subject: RE: [OSPF] OSPF NSSA ABR behaviors >In-reply-to: <01NJB3RECHMQ000DP4@omega7.wr.usgs.gov> >To: "Pat Murphy - (650)329-4044" , OSPF@IETF.ORG > >Hi Pat, > > I did some NSSA test on a router (with very new software >installed) from the #1 networking vendor. >Here is my observation about their NSSA ABR behavior with regarding to >external LSA aggregation: > >(1) When an NSSA ABR does not have any locally sourced external routes >matching an address range, it will aggregate installed type-7 LSAs =3D >(p=3D3D1) >received from the NSSA matching the address range into a type-5 LSA and >advertise the LSA to the transit topology.=3D20 > >(2) When an NSSA ABR has some locally sourced external routes subsumed >within an address range (may or may not be strictly), it will aggregate >installed type-7 LSAs (p=3D3D1) received from the NSSA matching the =3D >address >range and all those external routes into a type-5 LSA and advertise the >LSA into the transit topology. In addition, it will originate a >corresponding type-7 LSA (same destination, cost, and advertising router >as the aggregated type-5 LSA, p=3D3D0, forwarding address=3D3D0) to the NSSA >area. It will not originate a type-7 LSA individually for each of the >locally sourced external routes. > >So their NSSA ABR behavior does not seem to comply with what was stated >in your previous email in two ways: >(1) origination of an aggregated type-5 LSA from at least one locally >sourced external route will always force the origination of a >corresponding type-7 LSA (p=3D3D0) into the NSSA, and >(2) locally sourced external routes subsumed within the address range >are aggregated into the type-5 LSA. They does not have to have the same >[address, mask] as the address range. > >Now I am really confused. > > >-- James Huang > =3D20 > >>-----Original Message----- >>From: Pat Murphy - (650)329-4044 [mailto:pmurphy@noc.usgs.net] >>Sent: Friday, February 05, 2010 2:20 PM >>To: OSPF@IETF.ORG >>Cc: James Huang >>Subject: Re: [OSPF] OSPF NSSA ABR behaviors >> >>James, >> >>See comments inline. >> >>P>Thus if one desires to aggregate the external route during Type-7 >>P>translation using a Type-7 address range then a Type-7 LSA with the >P- >>bit >>P>set must be originated. >> >>P>Note the latter statement from RFC 3101 simply ensures that non-NSSA >>P>traffic forwarded by a Type-5 LSA installation toward a forwarding >>address >>P>inside an NSSA won't loop. I prefer originating the Type-7 LSA with >>the >>P>P-bit set and simply letting the Type-7 translation process originate >>the >>P>Type-5 LSA. Thus Type-5 LSAs would then never need to set a >forwarding >>P>address that belongs in a stub area or an NSSA, except during the >>Type-7 >>P>LSA translation process. Hence if the best forwarding address is in >>the >>P>transit topology, it is better to originate both a Type-5 LSA and a >>Type-7 >>P>LSA with the P-bit clear. If the best forwarding address belongs to >>the >>P>NSSA, it is better to simply originate a Type-7 LSA with the P-bit >set >>and >>P>let the Type-7 translation process originate the Type-5 LSA. >> >>J>When you say a router originates a type-7 LSA, does it mean >>J>that the type-7 LSA will be advertised? >> >>Of course, all LSAs are advertised by an originating router. >>See RFC 2328 Appendix A.4.1, "The LSA header". >> >>J>Or it simply means that the type-7 LSA is generated internally >>J>and it depends on the translation process to determine whether >>J>it should be aggregated with some other external LSA(s) or be >>J>advertised individually? >> >>Like all LSAs, Type-7 LSAs are only generated to be originated >>by an advertising router. But once originated with the P-bit set >>the Type-7 LSA may generate a Type-5 translation as described in >>RFC 3101 Section 3.2, Translating Type-7 LSAs into Type-5 LSAs. >> >>P>Let's assume that the redistribute is intended to feed the route >>P>into all NSSAs and the non-NSSA topology. If (G) belongs to the non- >>NSSA >>P>topology, originate a Type-5 LSA with forwarding address (G) into the >>P>non-NSSA topology and also originate a Type-7 LSA with the P-bit >clear >>P>into each NSSA. Here the Type-7 LSAs can simply use a 0.0.0.0 >>forwarding >>P>address. If (G) belongs to one of the NSSAs, then originate a Type-7 >>LSA >>P>with the P-bit set into that NSSA with the forwarding address set to >>(G). >>P>Finally originate a Type-7 LSA with the P-bit clear into the >remaining >>P>NSSAs. Note again that Type-7 translation will cause the appropriate >>P>Type-5 LSA to be originated into the non-NSSA topology. >> >>J>Agree - assuming address aggregation is not performed. >> >>Type-7 ranges that subsume only a single prefix with the same >>[address,mask] pair result in a normal translation. Hence, since >>type-7 ranges can even subsume other type-7 ranges, one can negate >>the effects of aggregation under configuration control. This is a >>subtle point from RFC 3101 Section 3.2. >> >>J>On a related question: When a MSSA ABR originates a aggregated >>J>type-5 LSA, does it has to advertise a corresponding type-7 = (p=3D3D0) >>J>LSA into the NSSA area? I cannot find any rule in RFC 3101 about >>this. >> >>The origination of a type-5 LSA generated by the translation of a >>type-7 LSA NEVER forces the origination of another type-7 LSA. >> >>J>I think the answer is no unless more than one locally sourced >>J>external LSAs with the best forwarding addresses NOT in the NSSA are >>J>aggregated into the type-5 LSA (otherwise, individual type-7 LSA >>J>(p=3D3D0) should be advertised). Is this correct? >> >>The non-zero forwarding addresses of Type-7 LSAs are always >>chosen from interfaces that belong to the NSSA. See Section 2.3. >>A type-5 translation that aggregates a set of installed type-7 >>LSAs also NEVER forces the origination of another type-7 LSA. >> >>J>One more question, RFC3101, sec 3.2 step (3): >> >> The path type and metric of the Type-7 address range is >> determined from the path types and metrics of those >> translatable Type-7 LSAs that best match the range plus any >> locally sourced Type-5 LSAs whose network has the same >> [address,mask] pair. >> >>J>What is the reason aggregation can only aggregate those locally >>sourced >>J>type-5 LSAs with the same [address, mask] as the configured address >>range? >> >>Since this is an aggregation its metric must reflect the highest cost >>amongst the type-7 LSAs being aggregated. A locally source type-5 LSA >>that has the same [address,mask] pair coupled with a lower cost could >>negate the translation metrics. Similarly a lower cost in the Type-5 >>translation of a type-7 range would negate the high cost of a >>locally sourced type-5 LSA with the same [address,mask] pair. Hence >>a single advertisement is required. >> >>J>If a locally sourced type-5 LSA is subsumed within the range, can it >>J>be aggregated too? >> >>No. The above excerpt is the only exception. >> >>Pat >> >> >> > > >_______________________________________________ >OSPF mailing list >OSPF@ietf.org >https://www.ietf.org/mailman/listinfo/ospf From pmurphy@noc.usgs.net Mon Feb 8 17:38: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 B12D128C1D5 for ; Mon, 8 Feb 2010 17:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_19=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 GIlqeS2IZduq for ; Mon, 8 Feb 2010 17:38:29 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id F123E28C1C7 for ; Mon, 8 Feb 2010 17:38:28 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01NJFFIH02N4000E26@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Mon, 08 Feb 2010 17:39:31 -0700 (PDT) Date: Mon, 08 Feb 2010 17:39:31 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: OSPF@IETF.ORG Message-id: <01NJFFIH03KY000E26@omega7.wr.usgs.gov> X-VMS-To: ospf@ietf.org X-VMS-Cc: PMURPHY,James.Huang@watchguard.com MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: JAMES.HUANG@WATCHGUARD.COM Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 09 Feb 2010 01:38:29 -0000 James, Regarding, J>One more question about NSSA ABR: J>In RFC 3101, Section 2.5, step (6e), the following priorities are J>specified to resolve multiple functional equivalent external LSAs (same J>destination, cost, and non-zero forwarding address): 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. =20 J>This means that type-7 LSA with P-bit set is preferred over type-5 LSA J>and type-5 LSA is preferred over type-7 LSA with P-bit clear. J>I checked the old NSSA RFC (RFC 1587), it specifies a different priority J>ordering: 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. J>What is the reason for this change? RFC 1587 was written before the current OSPFv2 spec, RFC 2328; and its calculation is based on the old OSPF spec, RFC 1583. RFC 1587 attempted to define a pecking order for external routes of equal preference using its tie breaker rules. I was not there at the time; but I suspect the authors were grappling with similar routing loops that have since been resolved by RFC 2328 Section 16.4.1, "External path preferences". NSSA RFC 3101 was written according to RFC 2328 Section 16.4, "Calculating AS external routes", and its Section 16.4.1. RFC 3101's calculation, as defined in Section 2.5, is not a rehash of RFC 1587 Section 3.5. The only preference decision that prunes Type-5 and Type-7 LSAs is defined by RFC 2328 Section 16.4.1. If RFC1583Compatibility is set to "enabled" no pruning occurs. After possible pruning Type-5 and Type-7 LSAs with equal prefix and metrics, but different forwarding addresses, are simply installed as equal cost paths. The tie breaker rules of RFC 3101 make no attempt to distinguish Type-5 and Type-7 LSAs unless they are functionally equivalent (i.e., same destination, cost and non-zero forwarding address). Its pecking order is based on the assumptions that "1" is preferred over "2" since 2 is most likely a translation of "1" (Note that under a steady state OSPF topology a type-5 translation would never be installed complements of the last paragraph of Section 2.5 Step (3)). By implication Type-7 LSAs with the P-bit clear have no preference over functionally equivalent Type-5 LSAs or Type-7 LSAs with the P-bit clear. Finally "3" is in keeping with OSPF RFC 2328 Section 12.4.4.1 and NSSA RFC 3101 Section 2.4. Hope this helps. Pat From James.Huang@watchguard.com Tue Feb 9 16:30:41 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 83C5E28C188 for ; Tue, 9 Feb 2010 16:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=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 it3ABg-3o3ty for ; Tue, 9 Feb 2010 16:30:40 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id 8473528C17D for ; Tue, 9 Feb 2010 16:30:40 -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, 9 Feb 2010 16:31:09 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F301AB5238@ES02CO.wgti.net> In-Reply-To: <01NJFFIH03KY000E26@omega7.wr.usgs.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF NSSA ABR behaviors Thread-Index: AcqpKL57ZYxXTRCpTQW0m834QPYkQQAAyAjA References: <01NJFFIH03KY000E26@omega7.wr.usgs.gov> From: "James Huang" To: "Pat Murphy - (650)329-4044" , Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 10 Feb 2010 00:30:41 -0000 Hi Pat, >-----Original Message----- >From: Pat Murphy - (650)329-4044 [mailto:pmurphy@noc.usgs.net] >Sent: Monday, February 08, 2010 4:40 PM >To: OSPF@IETF.ORG >Cc: James Huang >Subject: Re: [OSPF] OSPF NSSA ABR behaviors > >James, > >Regarding, > >J>One more question about NSSA ABR: > >J>In RFC 3101, Section 2.5, step (6e), the following priorities are >J>specified to resolve multiple functional equivalent external LSAs >(same >J>destination, cost, and non-zero forwarding address): > > 1. A Type-7 LSA with the P-bit set. > 2. A Type-5 LSA. > 3. The LSA with the higher router ID. =3D20 > >J>This means that type-7 LSA with P-bit set is preferred over type-5 LSA >J>and type-5 LSA is preferred over type-7 LSA with P-bit clear. > >J>I checked the old NSSA RFC (RFC 1587), it specifies a different priority >J>ordering: > > 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. > >J>What is the reason for this change? > >RFC 1587 was written before the current OSPFv2 spec, RFC 2328; and its >calculation is based on the old OSPF spec, RFC 1583. RFC 1587 attempted >to define a pecking order for external routes of equal preference using its >tie breaker rules. I was not there at the time; but I suspect the >authors were grappling with similar routing loops that have since been resolved >by RFC 2328 Section 16.4.1, "External path preferences". > >NSSA RFC 3101 was written according to RFC 2328 Section 16.4, >"Calculating AS external routes", and its Section 16.4.1. RFC 3101's calculation, as >defined in Section 2.5, is not a rehash of RFC 1587 Section 3.5. The >only preference decision that prunes Type-5 and Type-7 LSAs is defined by RFC >2328 Section 16.4.1. If RFC1583Compatibility is set to "enabled" no >pruning occurs. After possible pruning Type-5 and Type-7 LSAs with equal prefix >and metrics, but different forwarding addresses, are simply installed as >equal cost paths. > >The tie breaker rules of RFC 3101 make no attempt to distinguish Type-5 >and Type-7 LSAs unless they are functionally equivalent (i.e., same >destination, cost and non-zero forwarding address). Its pecking order is >based on the assumptions that "1" is preferred over "2" since 2 is most >likely a translation of "1" (Note that under a steady state OSPF >topology a type-5 translation would never be installed complements of the last >paragraph of Section 2.5 Step (3)). By implication Type-7 LSAs with the >P-bit clear have no preference over functionally equivalent Type-5 LSAs >or Type-7 LSAs with the P-bit clear. Finally "3" is in keeping with OSPF >RFC 2328 Section 12.4.4.1 and NSSA RFC 3101 Section 2.4. > [James Huang]=20 I have a few scenarios.=20 Let's assume the non-zero forwarding address is X, which is part of a subnet N,=20 in the following discussion. (Scenario 1)=20 Assuming multi-area network is not allowed (i.e. N is part of the NSSA area only). There are two ABRs, R1 and R2, in this NSSA and=20 R1 is this router doing the route computation.=20 =20 An ASBR R3 within the NSSA originates a type-7 P=3D1 E2-cost LSA. (case 1.1) R2 translates type-7 LSA to type-5 LSA without aggregation: In this case, R1 may receive one LSA from NSSA=20 and another LSA from the transit topology. The routing table for N is intra-area associated with the NSSA. =20 So the type-5 LSA will not pass the check in the last paragraph of step (3) of sec 2.5. (case 1.2) R2 translates type-7 LSA to type-5 LSA with aggregation (aggregating with=20 some other LSAs): In this case, R1 may receive one LSA from NSSA and=20 another LSA from the transit = topology. The routing table for N is intra-area associated with the NSSA. =20 If the routing table for R2 is non-backbone intra-area and the cost from R1 to N=20 and from R1 to R2 are the same, then R1 will install both LSAs into the routing table. =20 So neither (1.1) nor (1.2) requires the tie-breaking rule in sec 2.5 (6e). (Scenario 2)=20 Assuming multi-area network is allowed.=20 Let's say, subnet N is part of this NSSA area 1 and another type-5 capable area 2. R1 is this ABR router in area 1 and R2 (an ASBR within area 1)=20 originates a LSA. R3 (an ASBR within area 2) also originates a LSA. =20 This type-5 LSA may traverse the transit topology to reach R1.=20 There are two sub-cases here: (case 2.1) R1 is not connected to area 2:=20 The route for N is intra-area through the NSSA area 1 (intra-area route is preferred=20 over inter-area route).=20 So the type-5 LSA will not pass the last paragraph of step (3) of sec 2.5. =20 (case 2.2) R1 is also connected to area 2: The route for N is intra-area through the area 1 and area 2. In this case, the tie-breaking rule in sec 2.5 (6e) will be used.=20 According to rule (6e), R1 should prefer the type-7, P=3D1, FA=3DX, ADV=3DR2, E2-cost> LSA=20 over the LSA. But if the type-7 LSA has P=3D0, R1 should prefer the type-5 = LSA over type-7 LSA. Why is it so? I know that RFC 2328 does not support multi-area network. So case (2) is not valid in that sense. But I just cannot find other cases where the rule in sec 2.5 (6e) will be used for tie-breaking with good rationales. =20 Thanks, James Huang =20 >Hope this helps. > >Pat > > From pmurphy@noc.usgs.net Tue Feb 9 18:00:02 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 DD3A33A7651 for ; Tue, 9 Feb 2010 18:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, J_CHICKENPOX_21=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 UnDMdla6uF6g for ; Tue, 9 Feb 2010 18:00:02 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id 1C4EF3A764A for ; Tue, 9 Feb 2010 18:00:01 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01NJGUKHSG5S000E53@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Tue, 09 Feb 2010 18:01:03 -0700 (PDT) Date: Tue, 09 Feb 2010 18:01:03 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: JAMES.HUANG@WATCHGUARD.COM Message-id: <01NJGUKHSH3M000E53@omega7.wr.usgs.gov> X-VMS-To: James.Huang@watchguard.com X-VMS-Cc: PMURPHY,ospf@ietf.org MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: OSPF@IETF.ORG Subject: [OSPF] FWD: RE: OSPF NSSA ABR behaviors 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, 10 Feb 2010 02:00:03 -0000 James, You seem to be questioning whether the tie breakers rules ever apply. Don't forget that the calculation is linear; plus it can be updated incrementally. If the NSSA partitions separating the R2 translator and its R3 ASBR from R1, then R1 will install the Type-5 translation. Later, when the full NSSA is restored, R1 will have to make an incremental decision about what to do with the installed Type-5 LSA as soon as it receives the newly arrived Type-7 LSA. In this case the already installed Type-5 LSA will be pruned by the tie breaker rules. Indeed anomalous topologies can probably tweak all of the tie breaker rules. Also don't forget in Scenario 1 that aggregations always add +1 to their E2 metrics. In Scenario 2, the broken configuration, a Type-5 LSA is preferred over a Type-7 LSA with a zero P-bit simply because a zero P-bit indicates there is no intent that the Type-7 path be a transit path for the full OSPF domain. Pat [James Huang] I have a few scenarios. Let's assume the non-zero forwarding address is X, which is part of a subnet N, in the following discussion. (Scenario 1) Assuming multi-area network is not allowed (i.e. N is part of the NSSA area only). There are two ABRs, R1 and R2, in this NSSA and R1 is this router doing the route computation. An ASBR R3 within the NSSA originates a type-7 P=1 E2-cost LSA. (case 1.1) R2 translates type-7 LSA to type-5 LSA without aggregation: In this case, R1 may receive one LSA from NSSA and another LSA from the transit topology. The routing table for N is intra-area associated with the NSSA. So the type-5 LSA will not pass the check in the last paragraph of step (3) of sec 2.5. (case 1.2) R2 translates type-7 LSA to type-5 LSA with aggregation (aggregating with some other LSAs): In this case, R1 may receive one LSA from NSSA and another LSA from the transit topology. The routing table for N is intra-area associated with the NSSA. If the routing table for R2 is non-backbone intra-area and the cost from R1 to N and from R1 to R2 are the same, then R1 will install both LSAs into the routing table. So neither (1.1) nor (1.2) requires the tie-breaking rule in sec 2.5 (6e). (Scenario 2) Assuming multi-area network is allowed. Let's say, subnet N is part of this NSSA area 1 and another type-5 capable area 2. R1 is this ABR router in area 1 and R2 (an ASBR within area 1) originates a LSA. R3 (an ASBR within area 2) also originates a LSA. This type-5 LSA may traverse the transit topology to reach R1 There are two sub-cases here: (case 2.1) R1 is not connected to area 2: The route for N is intra-area through the NSSA area 1 (intra-area route is preferred over inter-area route). So the type-5 LSA will not pass the last paragraph of step (3) of sec 2.5. (case 2.2) R1 is also connected to area 2: The route for N is intra-area through the area 1 and area 2. In this case, the tie-breaking rule in sec 2.5 (6e) will be used. According to rule (6e), R1 should prefer the type-7, P=1, FA=X, ADV=R2, E2-cost> LSA over the LSA. But if the type-7 LSA has P=0, R1 should prefer the type-5 LSA over type-7 LSA. Why is it so? I know that RFC 2328 does not support multi-area network. So case (2) is not valid in that sense. But I just cannot find other cases where the rule in sec 2.5 (6e) will be used for tie-breaking with good rationales. Thanks, James Huang =20 >Hope this helps. > >Pat > > From sanddey.80@gmail.com Tue Feb 9 20:12: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 9045C3A766C for ; Tue, 9 Feb 2010 20:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.555, 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 gYXo7xO9hc8R for ; Tue, 9 Feb 2010 20:12:32 -0800 (PST) Received: from mail-pz0-f190.google.com (mail-pz0-f190.google.com [209.85.222.190]) by core3.amsl.com (Postfix) with ESMTP id 953903A7669 for ; Tue, 9 Feb 2010 20:12:32 -0800 (PST) Received: by pzk28 with SMTP id 28so1175141pzk.31 for ; Tue, 09 Feb 2010 20:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=pfYDngJFqRhIPKPkfrHy96dKH7ftxUiPWUR6i6iBNF4=; b=vO5K2u0G6LyiZf4sKgF8Sni/nHkVtJpW85gpTSdxon2H/Tl2p0jZlAXEDxNZawyUCT SUBgHi9ni7+5NpyqK5bD7S6koSPc5cfcvwP5p0QeJva/saOIl0QaEBjDIi/NODBAZZV0 +duj+aDmLOou31/Gy2wgzVZ0Zxmdn597C8qSs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sxKERsEDVZfiPGsaQsIJTyau14peFIBoiSj1S1Ck6QI69zY8emfawpmkfGX7ZrpRSY 0Tzpc2IvSn0v++00m5C2FmIhtGIYt6uD4uDkYOyVb7IcUa4fa+IJaM87DC/93LTkDIn+ HYC3EqDijxNvTqXKxQU4pKt/e8ToPlUdp4bQM= MIME-Version: 1.0 Received: by 10.142.2.15 with SMTP id 15mr593745wfb.289.1265775218536; Tue, 09 Feb 2010 20:13:38 -0800 (PST) Date: Wed, 10 Feb 2010 09:43:38 +0530 Message-ID: <752ba5831002092013v64b1a6d4yc6b303ba37250ee1@mail.gmail.com> From: Sandip Dey To: ospf@ietf.org Content-Type: multipart/alternative; boundary=00504502b512443797047f37420e Subject: [OSPF] OSPF for IPv6: Router link LSA 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, 10 Feb 2010 04:14:15 -0000 --00504502b512443797047f37420e Content-Type: text/plain; charset=ISO-8859-1 Hi I have a very basic query. As per RFC 2740 , section 3.4.3.1 "Each of the router's interfaces to the area are then described by appending "link descriptions" to the router-LSA. Each link description is 16 bytes long, consisting of 5 fields: (link) Type, Metric, Interface ID, Neighbor Interface ID and Neighbor Router ID (see Section A.4.3). *Interfaces in state "Down" or "Loopback" are not* *described (although looped back interfaces can contribute prefixes to* *Intra-Area-Prefix-LSAs). Nor are interfaces without any full* *adjacencies described.* All other interfaces to the area add zero, one or more link descriptions, the number and content of which depend on the interface type. Within each link description, the Metric field is always set the interface's output cost and the Interface ID field is set to the interface's OSPF Interface ID." Does it mean that during exchange state , the DD packet won't conatin the summary for router LSA since the condition "Nor are interfaces without any full adjacencies described" not satisfied? Regards Sandip --00504502b512443797047f37420e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
=A0
I have a very basic query.
=A0
As per RFC 2740 , section 3.4.3.1

"Each of the router's interfaces to the area are then described= by

appending "link descriptions" to the router-LSA. Each link

description is 16 bytes long, consisting of 5 fields: (link) Type,

Metric, Interface ID, Neighbor Interface ID and Neighbor Router ID

(see Section A.4.3). Interfaces in state= "Down" or "Loopback" are not

described (although looped back interfac= es can contribute prefixes to

Intra-Area-Prefix-LSAs). Nor are interfa= ces without any full

adjacencies described. A= ll other interfaces to the area add zero, one

or more link descriptions, the number and content of which depend on

the interface type. Within each link description, the Metric field is

always set the interface's output cost and the Interface ID field is=

set to the interface's OSPF Interface ID."

Does it mean that during exchange state , the DD packet won't conati= n the summary for router LSA since =A0the condition "Nor are interfaces without any full

adjacencies described" not satisfied?=A0=A0

Regards

Sandip

--00504502b512443797047f37420e-- From acee@lindem.com Wed Feb 10 03:16:02 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 61A7E3A69F4 for ; Wed, 10 Feb 2010 03:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.749, 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 w-f9Xc2X59iJ for ; Wed, 10 Feb 2010 03:15:54 -0800 (PST) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by core3.amsl.com (Postfix) with ESMTP id B47FC28C1CD for ; Wed, 10 Feb 2010 03:15:52 -0800 (PST) X-Authority-Analysis: v=1.0 c=1 a=KWqhaH8PlQwA:10 a=48vgC7mUAAAA:8 a=J8whH0Go_CEQSFC3FvkA:9 a=Fbf1QUNJDFR1bGI7OpkA:7 a=pbdStsNFfuBskSjcM9AnqMcb0d4A:4 a=lZB815dzVvQA:10 a=iHjaYkbIFQJ4rXRt:21 a=_SR6VP2fb7rIpMVm:21 a=W_04sdb_v7Wiq5p0jzoA:7 a=fnRyoRkZc1j05s6QZPwHKHis1GYA:4 X-Cloudmark-Score: 0 X-Originating-IP: 65.190.1.238 Received: from [65.190.1.238] ([65.190.1.238:47008] helo=[10.0.1.13]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id DA/80-02313-DA5927B4; Wed, 10 Feb 2010 11:17:02 +0000 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-4--269388500 From: Acee Lindem In-Reply-To: <752ba5831002092013v64b1a6d4yc6b303ba37250ee1@mail.gmail.com> Date: Wed, 10 Feb 2010 06:17:00 -0500 Message-Id: <6781C153-FA67-4E9F-8874-4427CB7A570A@lindem.com> References: <752ba5831002092013v64b1a6d4yc6b303ba37250ee1@mail.gmail.com> To: Sandip Dey X-Mailer: Apple Mail (2.1077) Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF for IPv6: Router link LSA 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, 10 Feb 2010 11:16:02 -0000 --Apple-Mail-4--269388500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Sandip, If there are no links meeting the criteria for inclusion in the = Router-LSA, I'd say it doesn't really matter whether you originate an = empty Router-LSA or defer origination until you have a constituent link. = I think originating an empty Router-LSA is slightly simpler from an = implementation standpoint.=20 Hope this helps, Acee P.S. Note that RFC 2740 has been replaced by RFC 5340.=20 On Feb 9, 2010, at 11:13 PM, Sandip Dey wrote: > Hi > =20 > I have a very basic query. > =20 > As per RFC 2740 , section 3.4.3.1 > "Each of the router's interfaces to the area are then described by >=20 > appending "link descriptions" to the router-LSA. Each link >=20 > description is 16 bytes long, consisting of 5 fields: (link) Type, >=20 > Metric, Interface ID, Neighbor Interface ID and Neighbor Router ID >=20 > (see Section A.4.3). Interfaces in state "Down" or "Loopback" are not >=20 > described (although looped back interfaces can contribute prefixes to >=20 > Intra-Area-Prefix-LSAs). Nor are interfaces without any full >=20 > adjacencies described. All other interfaces to the area add zero, one >=20 > or more link descriptions, the number and content of which depend on >=20 > the interface type. Within each link description, the Metric field is >=20 > always set the interface's output cost and the Interface ID field is >=20 > set to the interface's OSPF Interface ID." >=20 > Does it mean that during exchange state , the DD packet won't conatin = the summary for router LSA since the condition "Nor are interfaces = without any full >=20 > adjacencies described" not satisfied? =20 >=20 > Regards >=20 > Sandip >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-4--269388500 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Sandip,

If there are no links meeting the criteria = for inclusion in the Router-LSA, I'd say it doesn't really matter = whether you originate an empty Router-LSA or defer origination until you = have a constituent link. I think originating an empty Router-LSA is = slightly simpler from an implementation standpoint. 
Hope = this helps,
Acee
P.S. Note that RFC 2740 has been = replaced by RFC 5340. 

On Feb 9, 2010, at = 11:13 PM, Sandip Dey wrote:

Hi
 
I have a very basic query.
 
As per RFC 2740 , section = 3.4.3.1

"Each of the router's interfaces to the area = are then described by

appending "link descriptions" to the = router-LSA. Each link

description is 16 bytes long, consisting of = 5 fields: (link) Type,

Metric, Interface ID, Neighbor Interface ID = and Neighbor Router ID

(see Section A.4.3). Interfaces in state "Down" or "Loopback" are = not

described = (although looped back interfaces can contribute prefixes = to

Intra-Area-Prefix-LSAs). Nor are interfaces without = any full

adjacencies= described. All other interfaces to the area add zero, = one

or more link descriptions, the number and content of which = depend on

the interface type. Within each link description, the = Metric field is

always set the interface's output cost and the = Interface ID field is

set to the interface's OSPF Interface = ID."

Does it mean that during exchange state , the DD packet won't = conatin the summary for router LSA since  the condition "Nor are interfaces without any full

adjacencies described" = not = satisfied?  

Regards

Sandip

_______________________________________________
OSPF mailing = list
OSPF@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ospf

= --Apple-Mail-4--269388500-- From michaellundberg.ietf@gmail.com Wed Feb 10 10:03:00 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 3C57428C147 for ; Wed, 10 Feb 2010 10:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=1.085, 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 8dDKbV12lizy for ; Wed, 10 Feb 2010 10:02:59 -0800 (PST) Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com [209.85.223.199]) by core3.amsl.com (Postfix) with ESMTP id EFD0728C238 for ; Wed, 10 Feb 2010 10:02:58 -0800 (PST) Received: by iwn37 with SMTP id 37so298346iwn.22 for ; Wed, 10 Feb 2010 10:04:07 -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:cc:content-type :content-transfer-encoding; bh=LcO6j+5q9K970EHJOJXr++VZefGQ8iEPGjJ6qYeBnGQ=; b=LJ6VLCx+RGDPMvxDz8cukYafm4vvJC6zlCIc2c+eDI1VTdBqU7Ra5HG3bDP+lu7s8V HFms5jQyWtV4FccTZtGFWiVkmfu+F7Vg4GouWrHG2ZEfemjTSe/mNNc4kYCAKZMMCKKT x0WYmNN/iexIQKrLvsLurL7+pqYbp45Ay33HY= 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 :cc:content-type:content-transfer-encoding; b=HR0zYuUo5AAiWNmaaQLjWLvlSJv+VODQ3W+Uqs/AFGULcn3aeItWZhKSYaKc4CVy0o 7fS0DdPPOEv6Fb1IxdtMzAonFn0rwKKsV6J0jlLNpismkAyc8UJnlME9bkWQmwRKs6lw RDLSUUOHjHYPjueok4C98rEwRlCJsYmSZtH3w= MIME-Version: 1.0 Received: by 10.231.169.71 with SMTP id x7mr1042104iby.18.1265825047339; Wed, 10 Feb 2010 10:04:07 -0800 (PST) In-Reply-To: <2C8883F6-48A9-4F04-B7D3-A95906E1393A@ericsson.com> References: <4B63C7D4.1070901@cisco.com> <2C8883F6-48A9-4F04-B7D3-A95906E1393A@ericsson.com> Date: Wed, 10 Feb 2010 13:04:07 -0500 Message-ID: From: Michael Lundberg To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Wed, 10 Feb 2010 18:03:00 -0000 Hi Acee, Please find responses to your questions below. Thanks, Michael On Sun, Jan 31, 2010 at 2:28 PM, Acee Lindem wro= te: > > Hi Padma, et al, > Somehow my response quoting was lost. I've prefixed my responses with "AC= EE:" 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 doc= ument'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 O= SPFv3 route extended communities attributes as well - right? > Yes > > 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. =A0Instead, > 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. =A0Instead, > 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". > Agree > > > Remove paragraph, > > "To distinguish between routes originated from different > =A0OSPFv3 instances, an Instance ID field is carried in a > newly-defined OSPFv3 Route Extended Community attribute." > > Section 4.3.2.2. =A0OSPF 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. =A0Otherwise 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. =A0Otherwise 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 precis= e. > Agree > > Section 4.4 OSPFv3 Route Extended Communities Attribute > > " =A00x50 =A0 =A0 External =A0 =A0 =A0 =A0 =A0 0x2005 =A0 AS-external-LSA= " > > Proposed change > > " =A00x50 =A0 =A0 External =A0 =A0 =A0 =A0 =A0 0x4005 =A0 AS-external-LSA= " > > Section 4.5.1. =A0OSPFv3 Down Bit > > =A0 " =A0Similarly, the DN-bit must be set in inter-area-prefix-LSAs, > =A0 NSSA-LSAs and AS-External-LSAs, when these > =A0 are originated from a PE to a CE, to prevent those prefixes from > =A0 being re-advertised into BGP. =A0" > > Proposed change > > =A0" Similarly, the DN-bit MUST be set in inter-area-prefix-LSAs, > =A0 NSSA-LSAs and AS-External-LSAs, when these > =A0 are originated from a PE to a CE, to prevent those prefixes from > =A0 being re-advertised into BGP. =A0" > > 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. =A0As > 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 > =A0VPN IPv6 addresses whose IPv6 address prefix is 128 bits long. =A0As > 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. =A0Furthermore, 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 = community route-type? > Yes, Intra-area-prefix-LSAs can still be advertised via bgp. Section 4.3.2.1. describes how they will be handled. > > > Suggestions > > =A0 =A0 =A0OSPFv3 Options : 1 byte > > =A0 =A0 =A0The Options field indicates if the route carries a type-1 or > =A0 =A0 =A0type-2 metric. =A0Setting the least significant bit in the fie= ld > =A0 =A0 =A0indicates that the route carries a External type-2 metric. > > #### When talking of bit positions, it's always better to show the bitfie= ld, and name the bit(s) being allocated. For e.g. see section A.2 of rfc534= 0. > PPE : Only the least significant bit is set to indicate the presence of = =A0a 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: > #### =A0- Option bits (allocate the one's we need here) > #### =A0- Route Type (only a few values are currently permitted) > > PPE: While I feel it is not needed for the Options bit, =A0an IANA regist= ry for the route types could be added. =A0I will defer to the ADs on this m= atter. > > ACEE: I'd agree. > > Thanks, > Acee > > > > > Regards, > > The authors > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From James.Huang@watchguard.com Wed Feb 10 10:47:31 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 487C53A73B6 for ; Wed, 10 Feb 2010 10:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_21=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 zJto0sPvehAw for ; Wed, 10 Feb 2010 10:47:30 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id 498653A6858 for ; Wed, 10 Feb 2010 10:47:30 -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: Wed, 10 Feb 2010 10:48:37 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F301AB537A@ES02CO.wgti.net> In-Reply-To: <01NJGUKHSH3M000E53@omega7.wr.usgs.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [OSPF] OSPF NSSA ABR behaviors Thread-Index: Acqp9OgjfxFg5T+jSdeapWn1CpFI3QAhYZAQ References: <01NJGUKHSH3M000E53@omega7.wr.usgs.gov> From: "James Huang" To: "Pat Murphy - (650)329-4044" Cc: OSPF@IETF.ORG Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 10 Feb 2010 18:47:31 -0000 Pat, In your area partitioning scenario, the decision about whether to prune a type-5=20 or a functionally equivalent type-7 LSA can be done at the check in the last=20 paragraph of step (3) of sec 2.5. There are three cases: (1) network N (which contains the forwarding address X) and this ABR router are in the=20 same partition:=20 In this case, the route to network N is intra-area through the NSSA. So step (3) of sec 2.5 will prune the type-5 LSA. (2) network N and this ABR are in different partitions: =20 In this case, the route to network N is inter-area.=20 So step (3) of sec 2.5 will prune the type-7 LSA. =20 Later when the partitioning is repaired and the route to network N is changed back to=20 intra-area, step (3) of sec 2.5 will prune the type-5 LSA and let the type-7 LSA pass. =20 (3) both the NSSA area and the network N itself are partitioned: OSPF cannot handle this case. The part of Network N in the other partition is always=20 unreachable. So I still do not see when the tie-breaker rules at sec 2.5 step (6e) will ever get applied. As for incremental updates, I assume that this ABR will perform a full SPF computation when=20 a new router LSA or a new network LSA is received (as per RFC 2328). =20 But even if iSPF is performed for intra-area routes instead, we still have to reexamine all=20 external routes (at least those with a forwarding address in N) after iSPF computation for=20 intra-area routes completes. So the above arguments are still valid. -- James Huang =20 =20 >-----Original Message----- >From: Pat Murphy - (650)329-4044 [mailto:pmurphy@noc.usgs.net] >Sent: Tuesday, February 09, 2010 5:01 PM >To: James Huang >Cc: OSPF@IETF.ORG >Subject: FWD: RE: [OSPF] OSPF NSSA ABR behaviors > >James, > >You seem to be questioning whether the tie breakers rules ever apply. >Don't >forget that the calculation is linear; plus it can be updated >incrementally. If >the NSSA partitions separating the R2 translator and its R3 ASBR from >R1, then >R1 will install the Type-5 translation. Later, when the full NSSA is >restored, >R1 will have to make an incremental decision about what to do with the >installed Type-5 LSA as soon as it receives the newly arrived Type-7 >LSA. In >this case the already installed Type-5 LSA will be pruned by the tie >breaker >rules. Indeed anomalous topologies can probably tweak all of the tie >breaker >rules. > >Also don't forget in Scenario 1 that aggregations always add +1 to their >E2 >metrics. > >In Scenario 2, the broken configuration, a Type-5 LSA is preferred over >a >Type-7 LSA with a zero P-bit simply because a zero P-bit indicates there >is no >intent that the Type-7 path be a transit path for the full OSPF domain. > >Pat > >[James Huang] > >I have a few scenarios. Let's assume the non-zero forwarding address is >X, >which is part of a subnet N, in the following discussion. > >(Scenario 1) > >Assuming multi-area network is not allowed (i.e. N is part of the NSSA >area >only). There are two ABRs, R1 and R2, in this NSSA and R1 is this router >doing >the route computation. An ASBR R3 within the NSSA originates a type-7 >P=3D1 >E2-cost LSA. > >(case 1.1) R2 translates type-7 LSA to type-5 LSA without aggregation: > >In this case, R1 may receive one LSA = from >NSSA and >another LSA from the transit topology. The >routing table >for N is intra-area associated with the NSSA. So the type-5 LSA will not >pass >the check in the last paragraph of step (3) of sec 2.5. > >(case 1.2) R2 translates type-7 LSA to type-5 LSA with aggregation >(aggregating >with some other LSAs): > >In this case, R1 may receive one LSA = from >NSSA and >another LSA from the transit topology. The >routing table >for N is intra-area associated with the NSSA. If the routing table for >R2 is >non-backbone intra-area and the cost from R1 to N and from R1 to R2 are >the >same, then R1 will install both LSAs into the routing table. > >So neither (1.1) nor (1.2) requires the tie-breaking rule in sec 2.5 >(6e). > >(Scenario 2) > >Assuming multi-area network is allowed. Let's say, subnet N is part of >this >NSSA area 1 and another type-5 capable area 2. R1 is this ABR router in >area 1 >and R2 (an ASBR within area 1) originates a E2-cost> LSA. R3 (an ASBR within area 2) also originates a FA=3DX, >ADV=3DR3, E2-cost> LSA. This type-5 LSA may traverse the transit = topology >to >reach R1 > >There are two sub-cases here: > >(case 2.1) R1 is not connected to area 2: The route for N is intra-area >through >the NSSA area 1 (intra-area route is preferred over inter-area route). >So the >type-5 LSA will not pass the last paragraph of step (3) of sec 2.5. > >(case 2.2) R1 is also connected to area 2: The route for N is intra-area >through the area 1 and area 2. In this case, the tie-breaking rule in >sec 2.5 >(6e) will be used. According to rule (6e), R1 should prefer the type-7, >P=3D1, >FA=3DX, ADV=3DR2, E2-cost> LSA over the LSA. >But if >the type-7 LSA has P=3D0, R1 should prefer the type-5 LSA over type-7 LSA. > >Why is it so? > >I know that RFC 2328 does not support multi-area network. So case (2) is >not >valid in that sense. But I just cannot find other cases where the rule >in sec >2.5 (6e) will be used for tie-breaking with good rationales. > >Thanks, >James Huang =3D20 > > > > >>Hope this helps. >> >>Pat >> >> > From acee.lindem@ericsson.com Wed Feb 10 14:38:17 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 326973A758C for ; Wed, 10 Feb 2010 14:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 XfAX75S9qtKR for ; Wed, 10 Feb 2010 14:38:15 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 148913A74A2 for ; Wed, 10 Feb 2010 14:38:14 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o1AMdKI2019978; Wed, 10 Feb 2010 16:39:20 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.231]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 10 Feb 2010 17:37:50 -0500 From: Acee Lindem To: Michael Lundberg Date: Wed, 10 Feb 2010 17:37:45 -0500 Thread-Topic: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' Thread-Index: AcqqoayviFTjE4DfSROhQPZQydw3WQ== Message-ID: <09ED892A-4B64-4833-A9DA-4DCA7317C73D@ericsson.com> References: <4B63C7D4.1070901@cisco.com> <2C8883F6-48A9-4F04-B7D3-A95906E1393A@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: "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: Wed, 10 Feb 2010 22:38:17 -0000 Hi Michael, Thanks - sounds good. See one comment below.=20 On Feb 10, 2010, at 1:04 PM, Michael Lundberg wrote: > Hi Acee, >=20 > Please find responses to your questions below. >=20 > Thanks, > Michael >=20 > On Sun, Jan 31, 2010 at 2:28 PM, Acee Lindem w= rote: >>=20 >> Hi Padma, et al, >> Somehow my response quoting was lost. I've prefixed my responses with "A= CEE:" just to make sure. >>=20 >> On Jan 30, 2010, at 12:47 AM, Padma Pillay-Esnault wrote: >>=20 >>=20 >> Thanks to everyone for their thorough review. >>=20 >> 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 do= cument'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. >>=20 >> ACEE: Great. Just to be clear, you will remove the instance-id from the = OSPFv3 route extended communities attributes as well - right? >>=20 >=20 > Yes >=20 >>=20 >> See below for other proposed changes and suggestions from reviews of the= wg. >>=20 >> Section 3.1 OSPFv3 Specificities >>=20 >> "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." >>=20 >>=20 >> Proposed change >>=20 >> "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." >>=20 >> ACEE: Replace "as an AS-External LSAs" with "as AS-External LSAs". >>=20 >=20 > Agree >=20 >>=20 >>=20 >> Remove paragraph, >>=20 >> "To distinguish between routes originated from different >> OSPFv3 instances, an Instance ID field is carried in a >> newly-defined OSPFv3 Route Extended Community attribute." >>=20 >> Section 4.3.2.2. OSPF Intra-Area Route >>=20 >> "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." >>=20 >> Proposed Changes >>=20 >> "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." >>=20 >> ACEE: You could replace "external" with "external/NSSA" to be more preci= se. >>=20 >=20 > Agree >=20 >>=20 >> Section 4.4 OSPFv3 Route Extended Communities Attribute >>=20 >> " 0x50 External 0x2005 AS-external-LSA" >>=20 >> Proposed change >>=20 >> " 0x50 External 0x4005 AS-external-LSA" >>=20 >> Section 4.5.1. OSPFv3 Down Bit >>=20 >> " 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. " >>=20 >> Proposed change >>=20 >> " 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. " >>=20 >> Section 5 OSPFv3 Sham Links >>=20 >> "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." >>=20 >> changed to >>=20 >> "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." >>=20 >> Section 5.1 Creating A Sham link >>=20 >> Remove the paragraph. >>=20 >> "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." >>=20 >> ACEE: Will 0x90 remain as a assigned value for the OSPFv3 Route extended= community route-type? >>=20 >=20 > Yes, Intra-area-prefix-LSAs can still be advertised via bgp. Section > 4.3.2.1. describes how they will be handled. I believe you mean 4.3.2.2 and 5.1. It would be good to explicitly spell ou= t the use of the 0x90 route-type for the host (/128) address used as a Sham= Link endpoint in section 5.1 since this is not exactly the same as RFC 457= 7. =20 Thanks, Acee >=20 >>=20 >>=20 >> Suggestions >>=20 >> OSPFv3 Options : 1 byte >>=20 >> 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. >>=20 >> #### When talking of bit positions, it's always better to show the bitfi= eld, and name the bit(s) being allocated. For e.g. see section A.2 of rfc53= 40. >> 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 t= hings clearer, we can make the change. >>=20 >> #### 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) >>=20 >> PPE: While I feel it is not needed for the Options bit, an IANA registr= y for the route types could be added. I will defer to the ADs on this matt= er. >>=20 >> ACEE: I'd agree. >>=20 >> Thanks, >> Acee >>=20 >>=20 >>=20 >>=20 >> Regards, >>=20 >> The authors >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf From michaellundberg.ietf@gmail.com Wed Feb 10 17:52: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 A0B0628B56A for ; Wed, 10 Feb 2010 17:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.904, 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 ij91IEu3hdpK for ; Wed, 10 Feb 2010 17:52:33 -0800 (PST) Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com [209.85.223.199]) by core3.amsl.com (Postfix) with ESMTP id A8A9C3A77F2 for ; Wed, 10 Feb 2010 17:52:33 -0800 (PST) Received: by iwn37 with SMTP id 37so788721iwn.22 for ; Wed, 10 Feb 2010 17:53:41 -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:cc:content-type :content-transfer-encoding; bh=Bg93OH9giagTe88UT2RvzpImqngGUBO4K9orpPWqpGc=; b=h0iB21jvtp7N3CAUSQriokBpqqhTrel95dU+9xU1zTI1FpLYi8MLlCpcScaE24+HFc 3rZw6PHm/lYJBQ+7yjhDcb8t+khmYbgi3+pvQmv8/+Em8VujT8YhJj6A+hzhSrR+xVIo cj38GDXmXirtQaHIyZ0PgmklH6ktACowYnREA= 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 :cc:content-type:content-transfer-encoding; b=Rb/0XIWDZwFA0qa5nTFIQRm2OH5SFmxaKTwae5QupSPbFHq/ybBMNWPUamQKusnrHG ESZMkCbRxtxBPIeiY2iD6F5O1W3Yj6Jm/nImalPV+a/kj9pnp3DFrTWlP3zso9kbUO8V ScRVwZ2emk2P895Hmm3iaqagVeTjJy+a5CaIs= MIME-Version: 1.0 Received: by 10.231.149.10 with SMTP id r10mr66908ibv.63.1265853217018; Wed, 10 Feb 2010 17:53:37 -0800 (PST) In-Reply-To: <09ED892A-4B64-4833-A9DA-4DCA7317C73D@ericsson.com> References: <4B63C7D4.1070901@cisco.com> <2C8883F6-48A9-4F04-B7D3-A95906E1393A@ericsson.com> <09ED892A-4B64-4833-A9DA-4DCA7317C73D@ericsson.com> Date: Wed, 10 Feb 2010 20:53:36 -0500 Message-ID: From: Michael Lundberg To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Thu, 11 Feb 2010 01:52:34 -0000 Hi Acee, Comments inline: >>> 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. =A0Furthermore, 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 extende= d community route-type? >>> >> >> Yes, Intra-area-prefix-LSAs can still be advertised via bgp. Section >> 4.3.2.1. =A0describes how they will be handled. > > I believe you mean 4.3.2.2 and 5.1. It would be good to explicitly spell = out the use of the 0x90 route-type for the host (/128) address used as a Sh= am Link endpoint in section 5.1 since this is not exactly the same as RFC 4= 577. The text in section 5.1 stating the sham link is advertised as a type 0x90 is being removed, as Padma indicated above. The sham link will be advertised in BGP, but it does not need an extended community, as the sham link end point addresses are preconfigured at each PE. Therefore, if PE2 learns a route to PE1's sham link endpoint address via BGP, the sham link is considered up. Section 4.3.2.2 talks about PE to CE advertisement of Intra-Area-Prefix LSAs. This would be an actual OSPF LSA, not the extended community. A type 0x90 encoding in the OSPFv3 route extended community attribute would be used for cases such as PE1 advertising to PE2 the PE1-CE1 prefix. If the policy in 4.3.2.1 is true, PE2 will advertise this route to CE2 as an inter-area route, otherwise it will be advertised as an OSPF external route. Thanks, Michael > > Thanks, > Acee > > >> >>> >>> >>> Suggestions >>> >>> =A0 =A0 =A0OSPFv3 Options : 1 byte >>> >>> =A0 =A0 =A0The Options field indicates if the route carries a type-1 or >>> =A0 =A0 =A0type-2 metric. =A0Setting the least significant bit in the f= ield >>> =A0 =A0 =A0indicates that the route carries a External type-2 metric. >>> >>> #### When talking of bit positions, it's always better to show the bitf= ield, and name the bit(s) being allocated. For e.g. see section A.2 of rfc5= 340. >>> PPE : Only the least significant bit is set to indicate the presence of= =A0a type-2 metric we felt this was sufficient. If you feel this would mak= e things clearer, we can make the change. >>> >>> #### We also need an IANA registry for: >>> #### =A0- Option bits (allocate the one's we need here) >>> #### =A0- Route Type (only a few values are currently permitted) >>> >>> PPE: While I feel it is not needed for the Options bit, =A0an IANA regi= stry for the route types could be added. =A0I will defer to the ADs on this= matter. >>> >>> ACEE: I'd agree. >>> >>> Thanks, >>> Acee >>> >>> >>> >>> >>> Regards, >>> >>> The authors >>> >>> _______________________________________________ >>> OSPF mailing list >>> OSPF@ietf.org >>> https://www.ietf.org/mailman/listinfo/ospf > > From pmurphy@noc.usgs.net Wed Feb 10 17:56:15 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 AC5C53A7646 for ; Wed, 10 Feb 2010 17:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, 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 1DWjQaFtVWP4 for ; Wed, 10 Feb 2010 17:56:14 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id 326D23A77F2 for ; Wed, 10 Feb 2010 17:56:14 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01NJI8Q8D8FK000E9M@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Wed, 10 Feb 2010 17:57:20 -0700 (PDT) Date: Wed, 10 Feb 2010 17:57:20 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: JAMES.HUANG@WATCHGUARD.COM Message-id: <01NJI8Q8D9DU000E9M@omega7.wr.usgs.gov> X-VMS-To: James.Huang@watchguard.com X-VMS-Cc: PMURPHY,ospf@ietf.org MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: OSPF@IETF.ORG Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 11 Feb 2010 01:56:15 -0000 James, Sorry for the weak example. The incremental update of Type-5 and Type-7 LSAs is described in RFC 3101 Section 2.6; and it is true that the entire routing table entry for the destination N is invalidated before the recalculation. However multiple functionally equivalent external Type-5 and Type-7 LSAs with non-zero forwarding addresses can coexist in the LSDB. They will eventually be purged to just one by flushing as described in RFC 2328 Section 12.4.4.1 and RFC 3101 Section 2.4 so that only one LSA will remain in the stable topology (except for Type-5 translations of Type-7 LSAs). A set of such beasts can have Type-7 LSAs with both the P-bit set and not set. Flushing is not immediate. These tie breaker rules simply insure that only one of these LSAs is installed at all times. I could have dropped (2) in the tie breaker rules: 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. However (2) does emphasize that (3) applies to both Type-5 and Type-7 LSAs. Furthermore, as you have noticed, a broken topological deployment (or a more forgiving implementation) can break the intent of the last paragraph of Section 2.5 step (3). The tie breaker rules simply ensure that the calculation always only installs one LSA for a set of external LSAs that are functionally equivalent with a non-zero forwarding address. The rules, as they are written, are fine and recommended. However, if an implementation chooses to ignore them, it should not effect a stable proper topology. Pat Return-path: Received: from gscamnls01.wr.usgs.gov (gscamnls01.wr.usgs.gov [130.118.4.108]) by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) with ESMTP id <01NJHTQTBRVU000E5Q@omega7.wr.usgs.gov> for pmurphy@omega7.wr.usgs.gov (ORCPT pmurphy@noc.usgs.net); Wed, 10 Feb 2010 10:48:42 -0700 (PDT) Received: from mx1.watchguard.com (HELO watchguard.com) ([206.191.171.101]) by gscamnls01.wr.usgs.gov with ESMTP; Wed, 10 Feb 2010 10:48:54 -0800 Date: Wed, 10 Feb 2010 10:48:37 -0800 From: James Huang Subject: RE: RE: [OSPF] OSPF NSSA ABR behaviors In-reply-to: <01NJGUKHSH3M000E53@omega7.wr.usgs.gov> To: "Pat Murphy - (650)329-4044" Cc: OSPF@IETF.ORG Pat, In your area partitioning scenario, the decision about whether to prune a type-5=20 or a functionally equivalent type-7 LSA can be done at the check in the last=20 paragraph of step (3) of sec 2.5. There are three cases: (1) network N (which contains the forwarding address X) and this ABR router are in the=20 same partition:=20 In this case, the route to network N is intra-area through the NSSA. So step (3) of sec 2.5 will prune the type-5 LSA. (2) network N and this ABR are in different partitions: =20 In this case, the route to network N is inter-area.=20 So step (3) of sec 2.5 will prune the type-7 LSA. =20 Later when the partitioning is repaired and the route to network N is changed back to=20 intra-area, step (3) of sec 2.5 will prune the type-5 LSA and let the type-7 LSA pass. =20 (3) both the NSSA area and the network N itself are partitioned: OSPF cannot handle this case. The part of Network N in the other partition is always=20 unreachable. So I still do not see when the tie-breaker rules at sec 2.5 step (6e) will ever get applied. As for incremental updates, I assume that this ABR will perform a full SPF computation when=20 a new router LSA or a new network LSA is received (as per RFC 2328). =20 But even if iSPF is performed for intra-area routes instead, we still have to reexamine all=20 external routes (at least those with a forwarding address in N) after iSPF computation for=20 intra-area routes completes. So the above arguments are still valid. -- James Huang =20 =20 >-----Original Message----- >From: Pat Murphy - (650)329-4044 [mailto:pmurphy@noc.usgs.net] >Sent: Tuesday, February 09, 2010 5:01 PM >To: James Huang >Cc: OSPF@IETF.ORG >Subject: FWD: RE: [OSPF] OSPF NSSA ABR behaviors > >James, > >You seem to be questioning whether the tie breakers rules ever apply. >Don't >forget that the calculation is linear; plus it can be updated >incrementally. If >the NSSA partitions separating the R2 translator and its R3 ASBR from >R1, then >R1 will install the Type-5 translation. Later, when the full NSSA is >restored, >R1 will have to make an incremental decision about what to do with the >installed Type-5 LSA as soon as it receives the newly arrived Type-7 >LSA. In >this case the already installed Type-5 LSA will be pruned by the tie >breaker >rules. Indeed anomalous topologies can probably tweak all of the tie >breaker >rules. > >Also don't forget in Scenario 1 that aggregations always add +1 to their >E2 >metrics. > >In Scenario 2, the broken configuration, a Type-5 LSA is preferred over >a >Type-7 LSA with a zero P-bit simply because a zero P-bit indicates there >is no >intent that the Type-7 path be a transit path for the full OSPF domain. > >Pat > >[James Huang] > >I have a few scenarios. Let's assume the non-zero forwarding address is >X, >which is part of a subnet N, in the following discussion. > >(Scenario 1) > >Assuming multi-area network is not allowed (i.e. N is part of the NSSA >area >only). There are two ABRs, R1 and R2, in this NSSA and R1 is this router >doing >the route computation. An ASBR R3 within the NSSA originates a type-7 >P=3D1 >E2-cost LSA. > >(case 1.1) R2 translates type-7 LSA to type-5 LSA without aggregation: > >In this case, R1 may receive one LSA = from >NSSA and >another LSA from the transit topology. The >routing table >for N is intra-area associated with the NSSA. So the type-5 LSA will not >pass >the check in the last paragraph of step (3) of sec 2.5. > >(case 1.2) R2 translates type-7 LSA to type-5 LSA with aggregation >(aggregating >with some other LSAs): > >In this case, R1 may receive one LSA = from >NSSA and >another LSA from the transit topology. The >routing table >for N is intra-area associated with the NSSA. If the routing table for >R2 is >non-backbone intra-area and the cost from R1 to N and from R1 to R2 are >the >same, then R1 will install both LSAs into the routing table. > >So neither (1.1) nor (1.2) requires the tie-breaking rule in sec 2.5 >(6e). > >(Scenario 2) > >Assuming multi-area network is allowed. Let's say, subnet N is part of >this >NSSA area 1 and another type-5 capable area 2. R1 is this ABR router in >area 1 >and R2 (an ASBR within area 1) originates a E2-cost> LSA. R3 (an ASBR within area 2) also originates a FA=3DX, >ADV=3DR3, E2-cost> LSA. This type-5 LSA may traverse the transit = topology >to >reach R1 > >There are two sub-cases here: > >(case 2.1) R1 is not connected to area 2: The route for N is intra-area >through >the NSSA area 1 (intra-area route is preferred over inter-area route). >So the >type-5 LSA will not pass the last paragraph of step (3) of sec 2.5. > >(case 2.2) R1 is also connected to area 2: The route for N is intra-area >through the area 1 and area 2. In this case, the tie-breaking rule in >sec 2.5 >(6e) will be used. According to rule (6e), R1 should prefer the type-7, >P=3D1, >FA=3DX, ADV=3DR2, E2-cost> LSA over the LSA. >But if >the type-7 LSA has P=3D0, R1 should prefer the type-5 LSA over type-7 LSA. > >Why is it so? > >I know that RFC 2328 does not support multi-area network. So case (2) is >not >valid in that sense. But I just cannot find other cases where the rule >in sec >2.5 (6e) will be used for tie-breaking with good rationales. > >Thanks, >James Huang =3D20 > > > > >>Hope this helps. >> >>Pat >> >> > From acee.lindem@ericsson.com Wed Feb 10 19:04:23 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 DDD0D3A750D for ; Wed, 10 Feb 2010 19:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 BTmL2s+sZfZg for ; Wed, 10 Feb 2010 19:04:22 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id B4BAC3A74F2 for ; Wed, 10 Feb 2010 19:04:22 -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 o1B34iVH001881; Wed, 10 Feb 2010 21:04:44 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.231]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 10 Feb 2010 22:03:13 -0500 From: Acee Lindem To: Michael Lundberg Date: Wed, 10 Feb 2010 22:03:12 -0500 Thread-Topic: [OSPF] OSPF WG review of draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' Thread-Index: AcqqvSdWMef2qJe1TpGDYOMvEzoINAACQ74g Message-ID: References: <4B63C7D4.1070901@cisco.com> <2C8883F6-48A9-4F04-B7D3-A95906E1393A@ericsson.com> <09ED892A-4B64-4833-A9DA-4DCA7317C73D@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="iso-8859-1" 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: Thu, 11 Feb 2010 03:04:24 -0000 Hi Michael, Ok - that sounds good to me. I was recalling the sham link auto-discovery m= echanism that was in the early RFC 4577 drafts but removed.=20 Thanks, Acee=20 |-----Original Message----- |From: Michael Lundberg [mailto:michaellundberg.ietf@gmail.com]=20 |Sent: Wednesday, February 10, 2010 8:54 PM |To: Acee Lindem |Cc: Padma Pillay-Esnault; jdoyle@doyleassociates.net; Ertekin,=20 |Emre [USA]; ospf@ietf.org; Adrian Farrel; pete@pollere.net |Subject: Re: [OSPF] OSPF WG review of=20 |draft-ietf-l3vpn-ospfv3-pece, 'OSPFv3 as a PE-CE routing protocol' | |Hi Acee, | |Comments inline: | | | | |>>> Section 5.1 Creating A Sham link |>>> |>>> Remove the paragraph. |>>> |>>> "One difference from Section 4.2.7.3 of [rfc4577] is the=20 |addition of=20 |>>> Type 0x2009 intra-area-prefix LSAs, and the flooding of these LSAs=20 |>>> across the sham link. =A0Furthermore, where prefixes associated with |>>> OSPFv2 sham links are advertised in Type-1 LSAs, prefixes=20 |associated=20 |>>> with OSPFv3 sham links are advertised as OSPFv3 Type 0x2009 LSAs. |>>> This change is required based on [rfc5340], which states that=20 |>>> loopback interfaces are advertised in intra-area-prefix LSAs." |>>> |>>> ACEE: Will 0x90 remain as a assigned value for the OSPFv3=20 |Route extended community route-type? |>>> |>> |>> Yes, Intra-area-prefix-LSAs can still be advertised via=20 |bgp. Section=20 |>> 4.3.2.1. =A0describes how they will be handled. |> |> I believe you mean 4.3.2.2 and 5.1. It would be good to=20 |explicitly spell out the use of the 0x90 route-type for the=20 |host (/128) address used as a Sham Link endpoint in section=20 |5.1 since this is not exactly the same as RFC 4577. | |The text in section 5.1 stating the sham link is advertised as=20 |a type 0x90 is being removed, as Padma indicated above. The=20 |sham link will be advertised in BGP, but it does not need an=20 |extended community, as the sham link end point addresses are=20 |preconfigured at each PE. |Therefore, if PE2 learns a route to PE1's sham link endpoint=20 |address via BGP, the sham link is considered up. | |Section 4.3.2.2 talks about PE to CE advertisement of=20 |Intra-Area-Prefix LSAs. This would be an actual OSPF LSA, not=20 |the extended community. | |A type 0x90 encoding in the OSPFv3 route extended community=20 |attribute would be used for cases such as PE1 advertising to=20 |PE2 the PE1-CE1 prefix. If the policy in 4.3.2.1 is true, PE2=20 |will advertise this route to CE2 as an inter-area route,=20 |otherwise it will be advertised as an OSPF external route. | |Thanks, |Michael | |> |> Thanks, |> Acee |> |> |>> |>>> |>>> |>>> Suggestions |>>> |>>> =A0 =A0 =A0OSPFv3 Options : 1 byte |>>> |>>> =A0 =A0 =A0The Options field indicates if the route carries a type-1 o= r |>>> =A0 =A0 =A0type-2 metric. =A0Setting the least significant bit in the = field |>>> =A0 =A0 =A0indicates that the route carries a External type-2 metric. |>>> |>>> #### When talking of bit positions, it's always better to=20 |show the bitfield, and name the bit(s) being allocated. For=20 |e.g. see section A.2 of rfc5340. |>>> PPE : Only the least significant bit is set to indicate=20 |the presence of =A0a type-2 metric we felt this was sufficient.=20 |If you feel this would make things clearer, we can make the change. |>>> |>>> #### We also need an IANA registry for: |>>> #### =A0- Option bits (allocate the one's we need here) ####=20 |=A0- Route=20 |>>> Type (only a few values are currently permitted) |>>> |>>> PPE: While I feel it is not needed for the Options bit, =A0 |an IANA registry for the route types could be added. =A0I will=20 |defer to the ADs on this matter. |>>> |>>> ACEE: I'd agree. |>>> |>>> Thanks, |>>> Acee |>>> |>>> |>>> |>>> |>>> Regards, |>>> |>>> The authors |>>> |>>> _______________________________________________ |>>> OSPF mailing list |>>> OSPF@ietf.org |>>> https://www.ietf.org/mailman/listinfo/ospf |> |> |= From sanddey.80@gmail.com Wed Feb 10 21:32:59 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 118FF3A7649 for ; Wed, 10 Feb 2010 21:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.294, 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 PFwizuXLRY5h for ; Wed, 10 Feb 2010 21:32:57 -0800 (PST) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id C368028C10A for ; Wed, 10 Feb 2010 21:32:57 -0800 (PST) Received: by pzk4 with SMTP id 4so329081pzk.5 for ; Wed, 10 Feb 2010 21:34:08 -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:cc:content-type; bh=AizV++q2cNF+hddXJsizU6pE3F14QI9djz391kYivk4=; b=K+djY4f+SwOfQ/8me3ceoWvMHnEOjede5aGnhbVHt2ywMnO3jOSfC9mVv/6K6aZH5+ gXiOi68tsBaLVtO7GboF6cSGLX7VG7SVUJohODnpPaj0idPGSmrfeUEVty4LZP79+OLO krc9kKQxrwRQWOfo7xfM9ur2b5M5l4iB3Fr9E= 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 :cc:content-type; b=uUf/ftDVo2BOqQJX4V/6sRFF0hX3Hnn63c2wMVW/bia7qEeTRKEvBMArReLDxCcxrU mCFEvjscI4mV/IB1g44Y0WA9GcRiLnXOj1w4i0ntxESIEbd0NWQfRLYsPCG6QZ6R9RF8 avEt1NcLKdyNKlJCx6OBu1rruOWRJZpFPGOlQ= MIME-Version: 1.0 Received: by 10.142.152.6 with SMTP id z6mr839341wfd.214.1265866448532; Wed, 10 Feb 2010 21:34:08 -0800 (PST) In-Reply-To: <6781C153-FA67-4E9F-8874-4427CB7A570A@lindem.com> References: <752ba5831002092013v64b1a6d4yc6b303ba37250ee1@mail.gmail.com> <6781C153-FA67-4E9F-8874-4427CB7A570A@lindem.com> Date: Thu, 11 Feb 2010 11:04:08 +0530 Message-ID: <752ba5831002102134t460203f9q56866d6643539b8d@mail.gmail.com> From: Sandip Dey To: Acee Lindem Content-Type: multipart/alternative; boundary=000e0cd154aaff76c0047f4c7fbf Cc: ospf@ietf.org Subject: Re: [OSPF] OSPF for IPv6: Router link LSA 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, 11 Feb 2010 05:32:59 -0000 --000e0cd154aaff76c0047f4c7fbf Content-Type: text/plain; charset=ISO-8859-1 Thanks. It really helped. Regards Sandip On Wed, Feb 10, 2010 at 4:47 PM, Acee Lindem wrote: > Hi Sandip, > > If there are no links meeting the criteria for inclusion in the Router-LSA, > I'd say it doesn't really matter whether you originate an empty Router-LSA > or defer origination until you have a constituent link. I think originating > an empty Router-LSA is slightly simpler from an implementation standpoint. > Hope this helps, > Acee > P.S. Note that RFC 2740 has been replaced by RFC 5340. > > On Feb 9, 2010, at 11:13 PM, Sandip Dey wrote: > > Hi > > I have a very basic query. > > As per RFC 2740 , section 3.4.3.1 > > "Each of the router's interfaces to the area are then described by > > appending "link descriptions" to the router-LSA. Each link > > description is 16 bytes long, consisting of 5 fields: (link) Type, > > Metric, Interface ID, Neighbor Interface ID and Neighbor Router ID > > (see Section A.4.3). *Interfaces in state "Down" or "Loopback" are not* > > *described (although looped back interfaces can contribute prefixes to* > > *Intra-Area-Prefix-LSAs). Nor are interfaces without any full* > > *adjacencies described.* All other interfaces to the area add zero, one > > or more link descriptions, the number and content of which depend on > > the interface type. Within each link description, the Metric field is > > always set the interface's output cost and the Interface ID field is > > set to the interface's OSPF Interface ID." > > Does it mean that during exchange state , the DD packet won't conatin the > summary for router LSA since the condition "Nor are interfaces without > any full > > adjacencies described" not satisfied? > > Regards > > Sandip > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > > --000e0cd154aaff76c0047f4c7fbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks. It really helped.
=A0
Regards
Sandip

On Wed, Feb 10, 2010 at 4:47 PM, Acee Lindem <acee@lindem.com&g= t; wrote:
Hi Sandip,=20

If there are no links meeting the criteria for inclusion in the Router= -LSA, I'd say it doesn't really matter whether you originate an emp= ty Router-LSA or defer origination until you have a constituent link. I thi= nk originating an empty Router-LSA is slightly simpler from an implementati= on standpoint.=A0
Hope this helps,
Acee
P.S. Note that RFC 2740 has been replaced by RFC 5340.=A0

On Feb 9, 2010, at 11:13 PM, Sandip Dey wrote:

Hi
=A0
I have a very basic query.
=A0
As per RFC 2740 , section 3.4.3.1

"Each of the router's interfaces to the area are then described= by

appending "link descriptions" to the router-LSA. Each link

description is 16 bytes long, consisting of 5 fields: (link) Type,

Metric, Interface ID, Neighbor Interface ID and Neighbor Router ID

(see Section A.4.3). Interfaces in state= "Down" or "Loopback" are not

described (although looped back interfac= es can contribute prefixes to

Intra-Area-Prefix-LSAs). Nor are interfa= ces without any full

adjacencies described. A= ll other interfaces to the area add zero, one

or more link descriptions, the number and content of which depend on

the interface type. Within each link description, the Metric field is

always set the interface's output cost and the Interface ID field is=

set to the interface's OSPF Interface ID."

Does it mean that during exchange state , the DD packet won't conati= n the summary for router LSA since =A0the condition "Nor are interfaces without any full

adjacencies described" not satisfied?=A0=A0

Regards

Sandip

_____________________________________= __________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf


--000e0cd154aaff76c0047f4c7fbf-- From pmurphy@noc.usgs.net Thu Feb 11 08:31: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 9582C28C0F8 for ; Thu, 11 Feb 2010 08:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 sJn3vfFbR2TG for ; Thu, 11 Feb 2010 08:31:20 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id D17FE3A7746 for ; Thu, 11 Feb 2010 08:31:20 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01NJJ3ADE2FK000EAW@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Thu, 11 Feb 2010 08:32:34 -0700 (PDT) Date: Thu, 11 Feb 2010 08:32:34 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: JAMES.HUANG@WATCHGUARD.COM Message-id: <01NJJ3ADE2FM000EAW@omega7.wr.usgs.gov> X-VMS-To: James.Huang@watchguard.com X-VMS-Cc: PMURPHY,ospf@ietf.org MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: OSPF@IETF.ORG Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 11 Feb 2010 16:31:21 -0000 James, Regarding OSPF RFC 2328 Section 16.6, "Incremental updates -- AS-external-LSAs", and NSSA RFC 3101 Section 2.6, "Incremental updates", there is some efficiency to simply first running the NSSA Section 2.5 calculation on the newly arrived external LSA to see if it actually replaces the current route to its destination N; or it simply updates the route's current list of next hops and/or installed LSAs; or it is not installed. This is only slightly different than what would happen if the newly arrived external LSA were simply the last LSA to pass through the calculation of NSSA Section 2.5. Note that when a newly arrived external LSA for destination N is functionally equivalent (i.e., same destination, cost and non-zero forwarding address) to an installed LSA in the current path set, it could invalidate the current route if it involves a comparison between items 1 and 2 of Section 2.5 Step (6)(c), ala 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. If an installed Type-7 LSA with the P-bit set is functionally equivalent to a newly arrived Type-5 LSA, then a recalculation is not required. If a newly arrived Type-7 LSA is functionally equivalent to an installed Type-5 LSA, then a recalculation is required. Here current route can simply be invalidated and recalculated; or the current list of next hops can be CAREFULLY adjusted. Note that if item 3 applies it does not change the set of next hops. It only potentially changes the set of installed LSAs. Again these efficiencies are implementation specific. The current RFC 2328 and RFC 3101 specs simply suggest that the current route to destination N be invalidated and recalculated. Hope this helps. Pat From James.Huang@watchguard.com Tue Feb 16 12:16:43 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 CD8743A7BD0 for ; Tue, 16 Feb 2010 12:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 n7Sc11todcCg for ; Tue, 16 Feb 2010 12:16:42 -0800 (PST) Received: from watchguard.com (mx1.watchguard.com [206.191.171.101]) by core3.amsl.com (Postfix) with ESMTP id C160E3A73A5 for ; Tue, 16 Feb 2010 12:16:42 -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, 16 Feb 2010 12:18:16 -0800 Message-ID: <7C3D15DD6E8F464998CA1470D8A322F301B844D1@ES02CO.wgti.net> In-Reply-To: <01NJJ3ADE2FM000EAW@omega7.wr.usgs.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OSPF] OSPF NSSA ABR behaviors Thread-Index: AcqrN9HQ928LZQHTTj+BCET8SoG56QD/2elw References: <01NJJ3ADE2FM000EAW@omega7.wr.usgs.gov> From: "James Huang" To: "Pat Murphy - (650)329-4044" Cc: OSPF@IETF.ORG Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 16 Feb 2010 20:16:44 -0000 Hi Pat, Please see my comments below. Regards, James Huang >-----Original Message----- >From: Pat Murphy - (650)329-4044 [mailto:pmurphy@noc.usgs.net] >Sent: Thursday, February 11, 2010 7:33 AM >To: James Huang >Cc: OSPF@IETF.ORG >Subject: Re: [OSPF] OSPF NSSA ABR behaviors > >James, > >Regarding OSPF RFC 2328 Section 16.6, "Incremental updates -- >AS-external-LSAs", and NSSA RFC 3101 Section 2.6, "Incremental updates", >there is some efficiency to simply first running the NSSA Section 2.5 >calculation on the newly arrived external LSA to see if it actually >replaces the current route to its destination N; or it simply updates >the route's current list of next hops and/or installed LSAs; or it is >not installed. This is only slightly different than what would happen if >the newly arrived external LSA were simply the last LSA to pass through >the calculation of NSSA Section 2.5. > >Note that when a newly arrived external LSA for destination N is >functionally equivalent (i.e., same destination, cost and non-zero >forwarding address) to an installed LSA in the current path set, it >could invalidate the current route if it involves a comparison between >items 1 and 2 of Section 2.5 Step (6)(c), ala > > 1. A Type-7 LSA with the P-bit set. > > 2. A Type-5 LSA. > > 3. The LSA with the higher router ID. > >If an installed Type-7 LSA with the P-bit set is functionally equivalent >to a newly arrived Type-5 LSA, then a recalculation is not required.=20 [James Huang]=20 I guess you mean that there will be no change to the installed route in this case. >If a newly arrived Type-7 LSA is functionally equivalent to an installed >Type-5 LSA, then a recalculation is required. Here current route can >simply be invalidated and recalculated; or the current list of next hops >can be CAREFULLY adjusted.=20 [James Huang]=20 I think this may happen after recovery of the NSSA area partitioning. When such an event happens (i.e. detection of a new router with B-bit set=20 in its router-LSA), will ASBR's in NSSA be triggered to refresh their=20 type-7 LSAs immediately? Or it has to wait for the next refresh timer=20 expiration? There are two cases to consider at the ABR: (1) The type-7 LSA is received after the ABR re-computes the NSSA=20 intra-area routes:=20 The route to the forwarding address points toward a router in the NSSA. In this case, the ABR would have re-examined external LSAs with a forwarding address=20 in the NSSA network after the intra-area routes are recomputed.=20 So the installed route from type-5 LSA would have been invalidated at that time. =20 (2) The type-7 LSA is received before the ABR re-computes the NSSA intra-area routes:=20 The route to the forwarding address still points toward a router in the transit topology. This means that the ABR has not yet received the intra-area LSA that will change the route=20 towards the forwarding address. =20 In this case, the type-7 LSA will not pass the check at the last paragraph of=20 Section 2.5 Step 3.=20 Later after the ABR receives an intra-area LSA that changes the route towards the=20 forwarding address, it will re-examined all external LSAs with a forwarding address=20 in the NSSA network. The type-7 LSA will then replace the installed route from type-5 LSA (according to the check at the last paragraph of Section 2.5 Step 3).=20 There is a small window in case (1) after the route from the type-5 LSA is invalidated. Within the window, no route exists at the ABR for those external destinations.=20 So should the ABR postpone invalidation of the route from the type-5 LSA until the type-7 LSA=20 is received instead? (If so, this will be the only use that I can find for the rules in=20 Section 2.5 Step (6)(e).) >Note that if item 3 applies it does not >change the set of next hops. It only potentially changes the set of >installed LSAs. [James Huang]=20 Doe it really matter that the LSA with highest router-ID is installed? After all, they all have the same non-zero forwarding address. So the same next-hop(s) will be computed regardless which one of the functional=20 equivalent LSAs is installed.=20 > >Again these efficiencies are implementation specific. The current RFC >2328 and RFC 3101 specs simply suggest that the current route to >destination N be invalidated and recalculated. > >Hope this helps. > >Pat From pmurphy@noc.usgs.net Tue Feb 16 17:39:10 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 2384D3A7E1B for ; Tue, 16 Feb 2010 17:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.542 X-Spam-Level: X-Spam-Status: No, score=-0.542 tagged_above=-999 required=5 tests=[AWL=-0.943, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 d3-8O0QnafZb for ; Tue, 16 Feb 2010 17:39:09 -0800 (PST) Received: from ns0.wr.usgs.gov (omega7.wr.usgs.gov [130.118.4.3]) by core3.amsl.com (Postfix) with ESMTP id 70F5B3A79EF for ; Tue, 16 Feb 2010 17:39:09 -0800 (PST) Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01NJQLVQHII8000EPR@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Tue, 16 Feb 2010 17:40:44 -0700 (PDT) Date: Tue, 16 Feb 2010 17:40:44 -0700 (PDT) From: "Pat Murphy - (650)329-4044" To: JAMES.HUANG@WATCHGUARD.COM Message-id: <01NJQLVQHIIA000EPR@omega7.wr.usgs.gov> X-VMS-To: James.Huang@watchguard.com X-VMS-Cc: PMURPHY,ospf@ietf.org MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Cc: OSPF@IETF.ORG Subject: Re: [OSPF] OSPF NSSA ABR behaviors 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, 17 Feb 2010 01:39:10 -0000 James, When I wrote: P>Regarding OSPF RFC 2328 Section 16.6, "Incremental updates -- P>AS-external-LSAs", and NSSA RFC 3101 Section 2.6, "Incrementalupdates", P>there is some efficiency to simply first running the NSSA Section 2.5 P>calculation on the newly arrived external LSA to see if it actually P>replaces the current route to its destination N; or it simply updates P>the route's current list of next hops and/or installed LSAs; or it is P>not installed. This is only slightly different than what would happen if P>the newly arrived external LSA were simply the last LSA to pass through P>the calculation of NSSA Section 2.5. my intent is that the preferences defined in NSSA RFC 3101 step 6, which include the (6)(e) priorities, 1. A Type-7 LSA with the P-bit set. 2. A Type-5 LSA. 3. The LSA with the higher router ID. should result in a set of next hops for the Type-7 LSA's(s') network(s) N that reflects the current state of the LSDB. Let's not over think this. Some topologies have routers that use their 30 second Hello intervals and 120 second router-dead-intervals (2 minute) default settings. These specs simply define an orderly process that keeps everything in sync with the LSDB as best as possible at all times. Regarding, J>Does it really matter that the LSA with highest router-ID is installed? J>After all, they all have the same non-zero forwarding address. J>So the same next-hop(s) will be computed regardless which one J>of the functional equivalent LSAs is installed. Yes it does as only installed LSAs with the P-bit set are translated. Also a current accurate external routing table that reflects actual installed LSAs should help keep the external portion of the OSPF routing table stable. If a change is as simple as updating the LSA source of a next hop, it should be done (See OSPF RFC 2328 Section 11). Note again that as long as the preferences and priorities of Section 2.5 are followed the incremental handling of external LSA updates is implementation specific. How this is done is a matter of taste. If you have more questions let's take them off line, barring any objections from this list. Pat From wwwrun@core3.amsl.com Wed Feb 17 06:55:16 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 65F993A7ECB; Wed, 17 Feb 2010 06:55:16 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100217145516.65F993A7ECB@core3.amsl.com> Date: Wed, 17 Feb 2010 06:55:16 -0800 (PST) Cc: ospf mailing list , ospf chair , Internet Architecture Board , RFC Editor Subject: [OSPF] Protocol Action: 'Support of address families in OSPFv3' 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: Wed, 17 Feb 2010 14:55:16 -0000 The IESG has approved the following document: - 'Support of address families in OSPFv3 ' 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-af-alt-10.txt Technical Summary This document describes a mechanism for supporting multiple address families in OSPFv3 using multiple instances. It maps an address family (AF) to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. For example, this supports a requirement to advertise other AFs in OSPFv3 including multicast IPv6, unicast IPv4, and multicast IPv4. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. Working Group Summary No controversy reported (see PROTO writeup by Acee Lindem in the ID tracker). Document Quality The document has been well reviewed. Dave Ward, in his capacity as Routing AD, reviewed it several times. There are several implementations, at least one of which is commercially available. Personnel Acee Lindem is the Document Shepherd for this document. Ross Callon is the Responsible Area Director. From wwwrun@rfc-editor.org Wed Feb 17 12:43: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 6B62B28C0DD for ; Wed, 17 Feb 2010 12:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-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 wbGnmM8WFA9u for ; Wed, 17 Feb 2010 12:43:20 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 97A163A6818 for ; Wed, 17 Feb 2010 12:43:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AB9FC130002; Wed, 17 Feb 2010 12:45:00 -0800 (PST) To: none@rfc-editor.org, dennis@juniper.net, jmoy@sycamorenet.com, acee@redback.com, rcallon@juniper.net, adrian.farrel@huawei.com, acee@redback.com, akr@cisco.com From: RFC Errata System Message-Id: <20100217204500.AB9FC130002@rfc-editor.org> Date: Wed, 17 Feb 2010 12:45:00 -0800 (PST) Cc: ospf@ietf.org, rfc-editor@rfc-editor.org Subject: [OSPF] [Technical Errata Reported] RFC5340 (2046) 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, 17 Feb 2010 20:43:21 -0000 The following errata report has been submitted for RFC5340, "OSPF for IPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5340&eid=2046 -------------------------------------- Type: Technical Reported by: Acee Lindem Section: 4.8.1 Original Text ------------- o In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the Coltun, et al. Standards Track [Page 45] ^L RFC 5340 OSPF for IPv6 July 2008 router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. 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. Corrected Text -------------- o In Step 2, when a router Vertex V has just been added to the shortest-path tree and the router-LSA R-bit is not set in the LSA options, Vertex V's links are ignored and the next vertex on the candidate list should be examined as described in Step 3. Coltun, et al. Standards Track [Page 45] ^L RFC 5340 OSPF for IPv6 July 2008 o Also In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. o In Step 2b, if W is a router and the router-LSA V6-bit is not set in the LSA options, the transit link to W is ignored and V's next link is examined. Notes ----- This changes reflects the fact that the R-bit and the V6-bit should not be handled identically. The R-bit allows the router to participate in the IPv6 unicast topology but does not allow transit traffic. The V6-bit doesn't allow either. This problem was pointed out by Balaji Ganesh. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5340 (draft-ietf-ospf-ospfv3-update-23) -------------------------------------- Title : OSPF for IPv6 Publication Date : July 2008 Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG From acee.lindem@ericsson.com Sun Feb 21 11:58:10 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 B45FB28C126 for ; Sun, 21 Feb 2010 11:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 VqOjDi+zTgiw for ; Sun, 21 Feb 2010 11:58:09 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 564113A7BA1 for ; Sun, 21 Feb 2010 11:58:09 -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 o1LK23Gg030726 for ; Sun, 21 Feb 2010 14:02:04 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 21 Feb 2010 15:00:04 -0500 From: Acee Lindem To: "ospf@ietf.org" Date: Sun, 21 Feb 2010 14:59:56 -0500 Thread-Topic: Saving the Best for Last - OSPF WG at IETF 77 Thread-Index: AcqzMHT7I7zoVr18TSio6tMj01UdHw== Message-ID: <0FC52A0A-4652-4709-9129-A0B6947ED078@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 Subject: [OSPF] Saving the Best for Last - OSPF WG at IETF 77 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, 21 Feb 2010 19:58:10 -0000 It looks like we've drawn that last session of IETF 77 (13:00-15:15 on Frid= ay). Unless you can get a red-eye, this will give you all another night in = Anaheim to take advantage of all vices this great city has to offer. Please let us know if you have an agenda request for our session at IETF 77= . Please send Abhay and I an E-mail with the desired duration, topic/draft= title, and presenter for each slot that you request. Please let us have yo= ur requests by Friday, March 12th. Key dates are at: http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF77 2010-02-26 (Friday): Final agenda to be published. 2010-03-01 (Monday): Internet Draft Cut-off for initial document (-00) subm= ission by 17:00 PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Subm= ission Tool. 2010-03-08 (Monday): Internet Draft final submission cut-off by 17:00 PST (= 01:00 Tuesday, March 9 UTC), upload using IETF ID Submission Tool. The preliminary agenda is at: https://datatracker.ietf.org/meeting/agenda/ Abhay and Acee From mohamed.boucadair@orange-ftgroup.com Mon Feb 22 04:52:30 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 64BD928C2BA for ; Mon, 22 Feb 2010 04:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 LH2gdJe2Is1F for ; Mon, 22 Feb 2010 04:52:29 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id B6B1428C191 for ; Mon, 22 Feb 2010 04:52:28 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id B64533B42B5 for ; Mon, 22 Feb 2010 13:54:25 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 8F863C8058 for ; Mon, 22 Feb 2010 13:54:25 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 22 Feb 2010 13:54:25 +0100 From: To: "ospf@ietf.org" Date: Mon, 22 Feb 2010 13:54:23 +0100 Thread-Topic: Multi-Topology/Multi-Instance OSPFv3 for IPv4-Embedded IPv6 Thread-Index: AcqzviiC8HMF+ps0ReeOCYGR1C/A/g== Message-ID: <32677_1266843265_4B827E81_32677_6233_1_94C682931C08B048B7A8645303FDC9F30EFAEAA299@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.22.122125 Subject: [OSPF] Multi-Topology/Multi-Instance OSPFv3 for IPv4-Embedded IPv6 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, 22 Feb 2010 12:52:30 -0000 Dear all, An updated version of this document has been submitted recently: Title : Multi-Topology/Multi-Instance OSPFv3 for IPv4-Embedded I= Pv6 Author(s) : M. Boucadair, et al. Filename : draft-boucadair-ospf-v4v6-ospfv3-mt-02.txt Pages : 9 Date : 2010-02-11 This memo defines two new Multi Topology Routing Identifiers (MT IDs), based on [I-D.ietf-ospf-mt-ospfv3] and two new Instance Identifiers (MI IDs), based on [I-D.ietf-ospf-af-alt], respectively, in OSPFv3. With these identifiers, an IPv4-Embedded IPv6 topology is maintained for both IPv6 unicast and multicast traffic. The purpose of running separate instances or topologies for IPv4- Embedded IPv6 traffic is to distinguish from the native IPv6 routing topology, and the topology that is used for routing IPv4-Embedded IPv6 datagrams only. Separate instances/topologies are also meant to prevent any overload of the native IPv6 routing tables by IPv4-Embedded IPv6 routes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-ospf-v4v6-ospfv3-mt-02.= txt Comments are more than welcome. Cheers, Med PS: IPv4-Embedded IPv6 addresses are defined in http://tools.ietf.org/html/= draft-ietf-behave-address-format-04. ********************************* This message and any attachments (the "message") are confidential and inten= ded solely for the addressees.=20 Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration.=20 France Telecom Group shall not be liable for the message if altered, change= d or falsified. If you are not the intended addressee of this message, please cancel it imm= ediately and inform the sender. ******************************** From Chengd@huawei.com Mon Feb 22 10:44: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 CCED528C376 for ; Mon, 22 Feb 2010 10:44:42 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat 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=[BAYES_00=-2.599] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com 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 v30oubBlzRpL for ; Mon, 22 Feb 2010 10:44:42 -0800 (PST) Content-Type: multipart/mixed; boundary="----------=_1266864282-5267-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id DA9DC28C164 for ; Mon, 22 Feb 2010 10:44:41 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KY900AK9ATS7C@usaga02-in.huawei.com> for ospf@ietf.org; Mon, 22 Feb 2010 10:46:40 -0800 (PST) Received: from DeanChengSC ([10.193.34.123]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KY900FO1ATQGG@usaga02-in.huawei.com> for ospf@ietf.org; Mon, 22 Feb 2010 10:46:39 -0800 (PST) Date: Mon, 22 Feb 2010 10:46:38 -0800 From: Dean Cheng In-reply-to: <0FC52A0A-4652-4709-9129-A0B6947ED078@ericsson.com> To: 'Acee Lindem' , 'Abhay Roy' , ospf@ietf.org Message-id: <2082A96DA14A4974BDE74138D32A05C2@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 References: <0FC52A0A-4652-4709-9129-A0B6947ED078@ericsson.com> Cc: Yiu_Lee@Cable.Comcast.com Subject: Re: [OSPF] Saving the Best for Last - OSPF WG at IETF 77 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, 22 Feb 2010 18:44:42 -0000 This is a multi-part message in MIME format... ------------=_1266864282-5267-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1266864282-5267-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id DA9DC28C164 for ; Mon, 22 Feb 2010 10:44:41 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KY900AK9ATS7C@usaga02-in.huawei.com> for ospf@ietf.org; Mon, 22 Feb 2010 10:46:40 -0800 (PST) Received: from DeanChengSC ([10.193.34.123]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KY900FO1ATQGG@usaga02-in.huawei.com> for ospf@ietf.org; Mon, 22 Feb 2010 10:46:39 -0800 (PST) Date: Mon, 22 Feb 2010 10:46:38 -0800 From: Dean Cheng Subject: RE: [OSPF] Saving the Best for Last - OSPF WG at IETF 77 In-reply-to: <0FC52A0A-4652-4709-9129-A0B6947ED078@ericsson.com> To: 'Acee Lindem' , 'Abhay Roy' , ospf@ietf.org Cc: mohamed.boucadair@orange-ftgroup.com, 'JACQUENET Christian NCPI/NAD/TIP' , Yiu_Lee@Cable.Comcast.com Message-id: <2082A96DA14A4974BDE74138D32A05C2@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_hZTIVB7nx83/NY2Ze5ZLhQ)" Thread-index: AcqzMHT7I7zoVr18TSio6tMj01UdHwAvKJ8A X-MS-TNEF-Correlator: 00000000241FD6060C25714BA618F9877206F928049C2D00 References: <0FC52A0A-4652-4709-9129-A0B6947ED078@ericsson.com> This is a multi-part message in MIME format. --Boundary_(ID_hZTIVB7nx83/NY2Ze5ZLhQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Acee and Abhay, I would like to ask for 20 minutes to present our draft as follows: http://www.ietf.org/internet-drafts/draft-boucadair-ospf-v4v6-ospfv3-mt-02.t xt Thanks Dean > -----Original Message----- > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Acee > Lindem > Sent: Sunday, February 21, 2010 12:00 PM > To: ospf@ietf.org > Subject: [OSPF] Saving the Best for Last - OSPF WG at IETF 77 > > It looks like we've drawn that last session of IETF 77 (13:00-15:15 on Friday). > Unless you can get a red-eye, this will give you all another night in Anaheim > to take advantage of all vices this great city has to offer. > > Please let us know if you have an agenda request for our session at IETF 77. > Please send Abhay and I an E-mail with the desired duration, topic/draft title, > and presenter for each slot that you request. Please let us have your requests > by Friday, March 12th. > > Key dates are at: http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF77 > > 2010-02-26 (Friday): Final agenda to be published. > 2010-03-01 (Monday): Internet Draft Cut-off for initial document (-00) > submission by 17:00 PST (01:00 Tuesday, March 2 UTC), upload using IETF ID > Submission Tool. > 2010-03-08 (Monday): Internet Draft final submission cut-off by 17:00 PST > (01:00 Tuesday, March 9 UTC), upload using IETF ID Submission Tool. > > The preliminary agenda is at: https://datatracker.ietf.org/meeting/agenda/ > > Abhay and Acee > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Boundary_(ID_hZTIVB7nx83/NY2Ze5ZLhQ) Content-type: application/ms-tnef; name=winmail.dat Content-transfer-encoding: base64 Content-disposition: attachment; filename=winmail.dat eJ8+IicSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAAqAMAAAAAAACrAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgCoLQAAJQAAAAsAAgABAAAAAwAmAAAAAAALACsAAAAAAAMA LgAAAAAAHgBwAAEAAAA1AAAAW09TUEZdIFNhdmluZyB0aGUgQmVzdCBmb3IgTGFzdCAtIE9TUEYg V0cgYXQgSUVURiA3NwAAAAACAXEAAQAAABsAAAAByrMwdPsjvOhWvXxNKKjq0yPTVR0fAC8onwAA CwABDgAAAAACAQoOAQAAABgAAAAAAAAAJB/WBgwlcUumGPmHcgb5KMKAAAADABQOAQAAAB4AKA4B AAAALQAAADAwMDAwMDAyAWNoZW5nZEBodWF3ZWkuY29tAW1haWx1cy5odWF3ZWkuY29tAAAAAB4A KQ4BAAAALQAAADAwMDAwMDAyAWNoZW5nZEBodWF3ZWkuY29tAW1haWx1cy5odWF3ZWkuY29tAAAA AAIBCRABAAAAzikAAMopAADRbAAATFpGdSfwSVoHAAYBAQtgbmcxMDIGNQBkAHJjcGc5M3I2DGBj Mg1TATQBMXMIdHNoBXBiY2gx3jMQNAkAELAQJWgOsBGGbGJpAUMNpDMQ4A11ZvJlAdA1MgH3AqQD YwIAIxCwCsBzZXQC0XBySnEUcSoKoW5vFiAgmw3wF3E2E3AUUDA0F/HzAdAX4DR9B20CgwBQA9T7 Fc8W22IXsRggF4IcxBigfwcTAoAKgAHxD1AEVRqNMfUWzDcX0TkXcxhCGCAYoH8IVQeyGbQQ4ALy GocQ0DT/Gy8XcQ3gF8AlcBfgDeAlxbB9XCdjDDAmcGUmYdEA4CdlNRbCZgdABUBCUwdwU3VufQKD M944Iv8kDyUfJiJAJm4d1bQzORVeMiiyKgIgB234IENFAoMYIC3vGBAvHzkwJXlyMKQeQRV8MTbX GgEybwOCRwnRazCkIuFvNH4eQTWvA4JUCHAd1TQzKdESsGRpAzYpKDc3QzjvMCQoSGViCXB3/ikw pA4QOy88NS8PPbYHEN8BoA6wPpUPEDfOOEMBQN/9A4JCJ7EOsDCkPKE0fiLhi0RvPeNWCJB0bmEH gf5lPpE6pC3RGjwu6AcTMHb/GABKfzInTBUzxRRgGh41WPtMFDb4NSLhT8441kwUOlN/TLI7CE/N PJdMFD4oHfM17z8IVZ5LnEIrNUMBT81EJ/tMFEW5NTyhT85HplcVSTvvTLIt0R59LuYxMHAh6DB2 /xfAYe8yFmN9M8Id8zjCHn3/NVZjfDb4R5JoPzjUY3xUZr42OwhrbjyVY3w+KzY/CP9u72MfcQJC N2ekQwFrbkQl+2N8Rbk2PKFrb0ekcF1gzp88gBoBKPobFSflIFcHkP50BJEnbzP0fP9HxCxPfsbX AoAd4wjmOwlvMISvFDD/WGCF2obxhq+HuYXEh+KGTx+KH4ndiV+Hj4XfZTEy/jiPqpDBkH+RiYXA CoGEwf+RspAflA+FxJQnkyiWr5Tb/jkPUJiUmfGR85nwAoIQQFR5bAeQaAngdAAAcfpqAzBsEsEF EAFAFyAD8JBkY3RsCrFcd0JAsnABAWF1J8AAYHMKsMedUBqwnlJudW1/cZ4QZHRvDVFqdRBABRBn vmieQAUQCgGcYAoBaQGQbHAwAzAAIGwQsBqBc/9jcABgATGiYAvwKdAHQA219iAKgSfAcqHUoXEL 4QBQsxMnE+hcawSRC4BnD1B/EVICshIColMQkqJRENFj5wnAP0Ck025wpSmpABRC4QMwc25leBsA B7AFsP8AwB3FFuCiEaFxDWA/UEXgznYXUBAwGuBtaRIArBBJCfAgRJ30IFAKwGHjCcCdwGggRgIh qyYQUO4xAFAQUANgdwswoCABgMRzVz9AdGhCEOCgILsKsKwQbA3gKMCw1HKxSK8NkLC2AYCyt2Ky t3Kwsv8mgAqwKaC0oinwtQMCYAuAZwmRtdSbcHBlsLEE8GW8bGydAbCAsCG2MXOsYP8AICexrzE+ ULHQuJYJULi0zwyxuMOdgLi0ZGe5lrsQ17qWoeC4tHajknEDIZxm/50Pnh+fL6A/oU+iV8JRo93/ waENtCnQE+TFRKbPp9+o5P/FZ8iUqjWvYKyMqsRIEAGg/5uQAoEKgaIgDhCcL74fvy//wD/BT8Jf ooM1UKL5o83TQf+k76X/xp/Hr6kvo5K4wM7Q/wmAAiDR4cnk0/GsqptSGtD9P0AzLuCZ8BDQRaIJ AAIg90gQqnGrKTar6tIdw9zOkP8I0B4wqjHa1avC3NWvYHXw9XkwOcmwSLbBuYALgDcx/atHN99P 4F/hapIw4j/jS/uugN3hdwmA5BmbQUQQvRv/zV/Ob89/0I/Rn6IzD1Gkk//Tf6QzCoHTISjA1T/W TyLCv9eFD1DYH9kvqeba3jjpL/+t0Ati3jUCkRbgC2B/AAIwM5tk7ABzZBBAB3BheP/MYNUR/kAR UdZwrREBMP0TxYTAdgJRIHtV5IDskfuDohbDZwUwAGIBcgxAAYHv8MXsB7jAECFh/8CrNd0CtwBS BHMrITk8oONDM2/g3ynQ3QIGIC3ABjU3DwAFlHdv4EeQB3U5kjAOEN0COD444+AQ4AW0bjAGxTE0 7jiSQA8Q40M1meAKcArF/jNHgt0CF4EGIOwxDEPdcf8PUAwzE2AXsAq0DdEQ0ICw+QwzNjgXcQwk B+BhwAY0/wyQD1BkwQwzCRBEIBA1IPD7QJAO1DMLIAfRElVGYAdA/5PCEnMLIKLREmQH8QWULcD9 CyA4BZQYIApgDWUYIAdA/1hhFfQJECDgFeTdgGHAF+W/YcCi0BflbjAL0BaFOAdQvyVwBHNPgAfg DzAatTkKgP8NdFhgFNEItFhgRmBmARrD/5nwZgAJVGHAfOAGJTVgILD/EjU4wJnhBZQQAg4VdfD0 4P8VFeOxCoAMxHkwDJALICJF/91AYcATtSKgNDAHUCPFCID/CUVAkAdAQJEINAsgB2UPUP0rEDgI tSsiC2QSMA9QCUX/JxAdMQi1YcBU4AzERCASAX8O1BXAGzEGNJnwHyEFlDn/C+AMgBfkLFAoUSv1 N5Af0X0tZjkHZRvQBgANZRiAM/8W8AzEDpHE0PTxBRXaUQtl/yegCKAMBSeRW8BuMBO19ND/BhFM 4eNE3VAH4AtlkjAy8e80tw9QVOHjRDhC8DGGmeD/HJEFlU4BFPALZYhhEjAKtd8IoBpgFZA3xQVw NELxN9T/B0D04A10DrHdUAy1DrHdYP/dYDuGGIAHQAWlDzEIpT4R/0QgDqAFpScQ9NA+dicQEfD/ CrXdYAfRMBUW4BARO3VGYP+vYHzgMyY/wRpgO3UUQR1A/wq3GQEJVQshDdEKxQYgKFH/RiYfITn1 R0FekAWVOQE2sf9IZhkwIqAKxQiAFvBHlhvQ/+PQBZVuMApgNKZyAF6QFvD/S2Uf0N1APzXjoQyA CVVMsf8dQDt1BhE9lxIhotAFlTaw/yegJxWZ4CegmeALZRIABYD/CIAzJgiACIA8EFFlTXEIgP9R ZQ9AQeFUhhiAmfFRdBpg/wqgUhYJEGHACrUvwSKgDtX/ZgAW8Q4l2lA5AOPQWQZkwP8Q1iegE1EO JwdQGmANhQ8w/xxhXAZU4g2FJXJddgqAFmD/C2RekTawW+dX8ThlG/AR8P88EFm1JCIGJWGSEBAT pmGR/x/QDLZjQTsxDCTdQAahCLT/JEE6kEVF3VAKoPTwDBWAkP9AcQzFLcAIoEYFotAz4GHX/2iR YnFo5mJxDtX1oA8xDiX/i7ByACklMiE6kEnFCKB84P8twGjWBhE85Q8wNfFkRhTw/wXyDuWAkHzg btYz0Fxxb6b/OcFvlgkgW7Fixh1ALpAHZf9wIU1hZRUiwDqBc3Y/EUIl/w/hEqBxxgcxGTAPhjPB dCf/T5EIBZJAX2Ez5ZJAOGBJkf8Q9RZgC9B4tjbADTAMxVHB/zhgDBUIgMxgZcYIgG0BfHb/QWBn AX4GEqB+pyWwEqAJVP8v4JnhMkUv4GfiEvX04T+R/xO2aVFGcYBFNsBfYRJU9ND/GTAcpQvgOxES Ngvw2lCZ4P+EJWBRgaYb8CeChyUv4Akg/4A1TWFGwBR13VAv4Ckl3UX/hyXj0GuhhyUKgSRVidFd If+GVTwQR1GE1RNR6hCLlQdQ/42xjpYqgB0RElQYQYSBkCf/CoCANWcBI1ETti3AWWEVJf8twUbA EkVGocTQk/c9YpQG/0FgPaWUUQkgItWUUY5xk/b/mfAIgIQVGTAb0E8FEqAMgP8jQZlHIsCEFWoB OnESVRWD/5uIQiUTUTLCE9cz0BR2cOH/JbUU0QcxmrZMsQ1lGnEKgP8FcKDFMJEVkBO2H9AwgqJm /1chhBUU8A3wMAUHUQ0wr2H/pLUdEaPWmpEwxQdQEgAzkf8SVDPBM9ASRSLAKyGANaXR/yIWNIEt wIZGEjASsRR1KkH/XSGqpXAxg0asgWoBFTU8wf8S5uoQYpELZBbgDqEKgK8m/zqQJFUW4IhBM9AV 5QVw3WD/QvYW4TOSF0YHUJqlFuAVkP9Y1hZggJEf0LSGfRG0dwkQ/xLlS9EVoRflS+EsULa3rif/ gyJjdhZgFZA2sBc1VBAkwv+5xlZxFoXdgE4hFdUf4RTw/xfmY3GdpSQwTVIJVL6SXhb/vpGRca8V cCJApWcBMgEzFv9nAZLhFdWCMTF2bTEqgEFl/zqQgKEwxTqQT3K7NSQwiTH/FoVL8TGAF+UtQDzB xRYGIP8PQRil3WAN8L71KcAGAbCV/xhxygEZVQ3wbqEZVbURXuX/NsATYrCVjxIRhSCxg+G5tf+l AXzxzuZV0c+WCoAqgBlG/znBBXCyJlExEfAXNQdAjwH/v7UlkSKg0rY6kMr3yJEpFv8tQCxRM+WU Ygvgv7U2ATPg/xXVJxAbAb71KZFCFpXhuKH/sJUKoBvwDsWWoUixF+UgAf9WlpghX3LbxRKgPlYJ 4Yqw/8aGG9CZAQtka7EYURql+cH/OpDfdlHhipAzJeFRGlE3tP/hUQiBPzTX0VTxHAU2kUFW/xKy JiHkJSjh9aEaxKHhG0b/j7FKUeclQVEFhegySLHnJf9esVIFm+G4oeoXw1HnFhvR/3NlKcAKcBW2 7LEb0BclWxH/gjIcFQvwOoEcFWzxPyUcYv9TYRwVRHEVwOHGR0E8EO9W//wQCRDulkBx4CYQEdfB 9Ab/FZEcBSEyJxUy4Q9R33UqgP8JIBGFuXFGgRwFIqCr0eKV/whxCoDjVfLxHzEatCjhDqD/HLXJ YRXA33VSgWZRHXUOEP8ZAf0GDKEbVUEx4kEe1G6x/6X2IUF88f82a7HRx+hiM9D///UnkclRHtUI oC1AAlb3gf8wxVHhCbE89E1TtSVNUYpx/x92r3FV5WNhRPIG5igxH3b/M+CAAQkmTgEGFTtB25ak Qf/8EQhVh3EcoB91oFHldhTw/wyxBIZk4X/hDmWwYWsFbFL/clEOZWrCAXeXYZYBIDUoQP851hKS 86EgNaLRCEY48T8B/yA1PxEcpTLRW6EElTegFPH/EvYL8cjFTUF/0R91NtHc4f8iRfwBAKaP0XJB IkUpwVOl/3NgWkHtBSHxgWEgJfnRDjf/wEHQNnJBicEeNktAzQED5P9SgNKRcpYqUcNR//VSgGxx /xy1oiCGIQSVLpEm0SCFIrH/O2VO8a+ROTQaIT1xJRYTgf+xRXAxWMC3ZY/RNeEw1MQh/0ZxMBTE ITkBJRVLsBUBPzT/92BeEZ8lWBFg8SsV4AFltv8s8z2lWBG4ETY0WBBgEVIF/1gQTXFrBSKx8kHx liKxAhL/K+WrAQnFMlGXgPkldvLGdv9Y0DkBnaVY0a7BKxW00FAw/+cFbeGAETN1bTFRITXFT5H/ TwU4UXJBN/bmEY3FT5F/Mv8lJJvhMdfssaIROwXi8jr2//7RZEWowBxRJQZOIUyBPsb/rgEl1VHh AhExJs9AXTEoFf/xcaX2qkCcwQdwQqZrAEkF/0OyAhFCplThKBVY0Y1xRab/UoBdZW3SJzdPkbTR RaUN8f+bZR0hoeEo1QkAcBJKJpdx/ygVqbFRAUum0BFJVsNRSIb/8xGsttYhfFFOl7aBKxWuAf+O YTEmoiCDEHNQTqVA0Y3F/yQxnNFV9CQwfeD8wVKFbzH/t2XBsYaxVLbYYLfhVYblUf9TNvCx7QVX UdcRVLWvovkl/6sCPFapsSoSWgV94MkxWsb/l4BvhewiwzFShE8RuKBatf+NgZhWTDEtJ9JyKjbY YNGi/8H2E4FvgK/FlfHFgWGX1jD/JEXZ4fahVLUZUXNBY+aV0v9hpUFxYwcX8lq1kjE/IWbm/8og XybUot9laLHOoIZF7QD/c0F05dthfNBWJmQxabfcUf8otohxJ8FedS6ijEWIcSDh/1q1f+EVoWzl aLFKcHKl/KD/7cC6QXDG/KCrRXwhnaDnBf98IXYicMSQoq5FfOGo4XF1/zYx1ZZ84cKRejQFEb4B fHT/mFFMMXR2ujHOBf2gFpD3YP949p5RnOXQMc0RhZTQMcux/3s4YvaAwZCRePYZUcRFgMH/C/F3 dZqAmnBqhdYwioDTIf9wpopwnjF/tqxxw4Wx4tlW/+8xVVD9UILmRVGC1vIRjcX/azGPwYIVxwEq wXDE19HncP9y9YuA+RF3dedwtRF6dblx/1FhiOZOUXa1ukE7cYpmv3H/h1Z2UnO18KGK+N2hqMCL 5v+68Xd1zgAqAHvm9eF5UXCm/yVxNtGQhqpAiMYnsZkWGNH/zgADBY6ieXGThvOxghVIMf8SFm+B ouF3deJxJ7GWhagh/62F2UAg8aVFmFGtQpgFuKD/IpGYBVkR0EUO4ZJxcvXfQf8FAZvG/VBHBSfB BdGrRZ2S/9hgOKUnwbTQowCiNp8y9qD/1jCf2BB2J8GRkp7WfVG7Fv+ikR6w/tGjFyiRojf9UdKl /6KR92DngaJGV1HFxaaiWmH/ntYeseh2qEHtgcRFqRIN8f+hZgvC7cWqsuiA6gUWgaHC/6v4Y5Gd Nu5xpSGqZlphz0D/n7fKIN/RrZfdEF2WsILOoP/AZXQxGLG0ZbIiYvBRpXQx/8UAbXZ0MboR1yV0 Mf2gvGH/nUWX0doWtjLWYMmFtjHiUf/zJbYx/vHLBQLBA5E95QLB/8qxp9dD8czxnUU+UX1Wu+H/ sZG3ZyBAAjG8V7jiITaScf/6keuFknHmwRdQv8jecb72/yuh/mWScZbg2sCe1vMRwSH/vvZ1kqv2 RuGgYcSmyfGth//0csgFWcKB4Z7WQbEK8cSm/ytx8AXJAlVACACdRKhBpgH/o9WoQaFAsBYWguMB y/fWYP/LCPwRFpCftsTyA7bO0tnh/8sWXZFhgJ7VFFEDkaFlNjH/63HQ5p+Ar+HPRixBwTfm4f8v MJ7Go4Ju9tVT8wHSljnR/+fFdOEkMD3W18IC53ThdxD/t/HKVVtCw7bugHrxYYXbAv+xkdDmmgL1 ZdyiHeG+x12R/yex3EcukHIQ0bbfUu0ForL/B3GylUqRKgHcR6rRn4DcVv9M4fDFfVFXUS1FfVFA AtQm/zoCDMUAgjMi5WYUEaL2KUH/SfHKRmmhw6eIop+A6JdrIf/uha1RYvCAMefWrxHm56Bh/3XR zmcaEDrQ6vhGwdw3GhD/MbHnxx6hD8XwY/2B59Zfwf/7ZTYxUYGr5iuCgeHyh+hC//KH8vL0+D0W NjFuMfDHaYH/xuDzRzrgnFb4gixw9AgHMv/khlaSoIYI8TYx0ba/YWKx/85nXJPPRkPh2AH6pl5A sWH/+qYycY4F//MvMMpGGYGiof8BRzcB4UYscF4x0bY1geeo/yERnQEC5otxGaUFolwgqxb/n4CW QeBmB1H+gZ01B1EkMP/mFiWRbvEG5yxCBudAobNW/1phgoFA9tLyHUGe1UwRJYH/C8dV8Qh3dPEz 4Q82sMH95v8QYdSiDzZi4ge2W/GxkQb1/1kRp5ETRoZQNWALxsLB8yf/H4Eb0ArnRjG1gRW3b8AT 9/8WUVzWyiGz0ebm0/Ah8bg2/6oBMdENhvMR63EMpyKh+mH/HFeSURM2OuBiARDGjcHrkf8ex30y BvVvwO4BD/Y/UUzw/yEoYFENhtTB0HEi17JRC8b/PdFhgAbmakG/YQb1V1GdoP8NhlXxSEEmFmRB sbYsYH9h/4yFLFKCsQ2GSGCBAKPGX7H/chChQAynIdHekZ1EYvBuMP9YVrzxHmHyZq1Bn2Ggla1B /xvxntUvg6PGyhF+sav1yhH/oVAuOIEAZdEuVsuxe+XcIf87cbt2gQDmsqFlNTHzwTC2/3ugYgEv 5h8hvddnUW4hL+b/iJGqEDjZq9c5Qe/Bn6dc4P8YgGXhOOaUojC2gEG3QT0Y/30xOOZT4J63XOCY UbXGdzH/wCE4BqlAZQJAVtFwYvAspv+esW/AQEav8eLHAqC5oTF3/4ThU6A4BlqRQPgigZrW2xH/ hDGLsCy1qiHCsUh2J2Gklv9JoXuiO1f38fchSUc28JYw/0lH9JJIdsBQyEEstWXxUtH/TkfUoK5W aCEEME1XJBBagf9ON4uwXkFORu4QTFFSV1dS/1JXJcEv5nXB7hBQp8kxR4f/luDrcS8WwrGPMVZn ZeEtdv+aoYZhWNfT8IsAO1dggD2S/1jW+KH2djSBqvC0Jj/yoHf/0aAPsTz2+nF4EaV1d0GEEf+e 1XdBcsGr9UDAmpKjBZ9g/3+BSrBh5oUAwsFiuJbQY3f/yVGthoNRucFh15zxc6Wiwf+uEdGmotFV YWUWszEzkK5l+y0xzVExn7YtMXCAhcXigf98cbkGbjH4AWknhlBSEWhm/1YCXpbg8STRbja7Qbdm EKH/qUFh1nBBSrBpJttQpHDiBv+pQWxhX2apUZEBXdU28OxR/19mhOB3EHdQXdX6UQAQaSb/6rHA UGA2aPLQBrtBlvF1d/+cEeoAage44RfhebedILNW/8HwdRJnhrwBkNFd1ddAtYH/X2ZA8aFH21DD kcIWuBGesf9gNs8B3ZGAN6rxXcbF4uR2/4IxqIGA94cBcvcE8SuRgDb/SbHlRqlRgaGFCLwBntVD Mv/oIYeG65FSIJ+2l9DvEddA/4eFtWGcQYoWNiGd9nIBIqH/q/WFoQkxjHipMaV10XCSgf82Vvix X9GMduoA9yGKBrJR/3YBjiY4caImlNGhMY7nupH/jgdAsPOxoWXacXBBh3buMf/q55XRoHGVZ2jx 22YCsbcg/yhAiSdeMVPH5dEcopmnBcD/D+bmoYmhiEY1UfTHxgHSQf+OFvMRHpfGACQRoIae4bqI /57huzGbNzShMhCeh8lQZqb/20HIgZ9HdiHlRl/xa4ghsv+3UJSWNwDKAYhGF+GEwaXW//2Cafdg 0ciBppcy8bQmdFH/FlGnZ+xxoafuETVQp2fOIf/yZkxhUsDohkdgcHESVgBB//fxitapwXRRrhaD 4AoHRnH/ICGLpkaCiffAMWJhsVZHcf+qtyjx4schwTOhwIU3AIQB/9dWINFQQc5XQ2F74bYn9zH/ CuamQUdgvRYX4WfxvFUX4f/2YDZWICFSENw2qNEu4bb2/9cRJrdXATiSvnZn8cFGD8H/keK+djVw 2PC+Z+EhDkZ/Iv8/AcKHyTHFZf6CVgHChr+i/7sm7kDtQbv2RnHQkbfXcUH/5gdN4AgwwYg3AEwy yFdb0P8GBk3hvILIVkqSyrcAQftW/3RiHkHNNxsgRebsYSuCztf/6gDgZuxhXMAl9lVhGiG6VgMb IAhhNn17XCpcAHhtbG5zdGJsBiDS8NMzMSBodHQAcDovL3NjaGUAbWFzLm1pY3IAb3NvZnQuY28U bS/VoGbVUGUvd9BvcmQvB1Ez1oPd8AfTQNLh0zMyIHVybqo61MUt1Uct1eE61iQL2IDVAHLUYGFn c30AfVxwYXBlcnd3AzEOQdsjaPBx+BHacWeubB8gGNHconLc93QQkcvfoNyiYt4zZ3XUYNtQCeLg bHThYGVjdCBJ7YFkZdWwYWJuoVwB1bBuYmpcYWVuEGRkb2PgQG9ubwHfUG1iZWRzeXMOZuHg3iDh yWxpbmdMZGHasN8BcmbhkWWSduFgdHP8MHZh46AN4+Fl0zHnwHNob3eYcGxh1mDmAGxk5YFSdPww aWfh8HLU8Gk+eOJQ1eDiwOTB/DBzYf/ksOOw5SPTMehB5gHTMdtQT9Vw6yDwAOKgcm3l8GGl4FBc 5gByeuGTZ9yi8+Ow62Foc9sg1mD7Aeth/nbsNFMB7AHWoOcg47D7Af/so+213kLsAuYB/QLswuYB lfQQatXhcOdgc3PfkLfh8OPA7cBk4cHf8HnbQEH0EHZpZXdr47BkbwEw8kLUwOUwZQOR7DBs8Hl0 d27jsOrQ4PHzx8/UUNUA3zDsMFx139DfoP5i5TDr4PYB04Hykd+Q89D38zHf8NOQd/bD04HakN1w QfERYnJrcnXpwFxj4fD4gXdycNOB5eBuudswdG/xYuOw1mBs+aD95TBs5hDWQPXA4FDhcPWx0lz5 UXB1+nB04UD+IP5h+Hf+4tVw4gCIIatCDJLt9CB304HTcHn4sfEA4fBv3XDmEPVB1aBp4ADg4GWL 5vDS8nfkQWZtdNZA69+g21Agt3Fm2wABQOKgz9UA8zD3ANNQdXDfg9sg9wGA5eDf4WQAIN+l35D0 EfZ4HRDhYW7U4OdgA3MEch/xYjEhA3PsMN/gaWZ5//mh3+EIo/3V5eDg89Ox0xBmcNNg3+BsduXB CQB1/dVgbQjy2rDakAmC8pHkwb8jQQjx6qDjwNOxCQB05uCSYQAgZGLU0CAu2vD/CMp5ggmi36EK DwsfDC8JBv8TMAkA4FDhsA5/D48QnwkVvxmwCQD3MA4/E28UeykM3C8lMBI/F48UVWIU1Sh9/yvA GJ8M69vBFm8bnxyv0uH/Hg8I2SrgH+IJ7yFPIl8jb/8I6DGAH+8mPydPHa8pT0/Q/yU/K58sryhv 2vPWsNsQ5kDf47AD0wMx5eBq0XHToARh9zwxNhHh8Hc4QAWRNUL5UP/bMOBR9UDfoPxh2yA28Oqg PzfyArAwMDeg/7LhQGRq3/Wg37DnINRQNjFu34E6Qv8AANswGAHagNqAB5kAINqQNfcwaODgY9Qh SuFhZn8/cD0w2CBCsOUwGFFiUTX7A9M8hDAAITWCPeTdET3itwBAjpByIWvbUPQBZ0kw7/rwPIE9 MJYhaNVQQZJJMJsU8kGkY/FjPeJucD/Zf0PQQILTsTxZPSI+br/xY/5m5wHTYAeL1NDagDt8Qg8H QAFBckHBIEhpIEGZ1mBlIPygA8BBYuqg/HksDcIDQdLhRT9GT0df/0hvPBFMn02vTr9Pz0jfSe/9 SvZJUh9TL1Q/VU9WX1dvfCAg1pD4wAPA46BA0CDz+gBL4HNrUg9ZkWoBWd9fWu9b/10PSo3qUSCO kCB31UACsN9Qc1+y8MLkwSD/XyABgP1wPTDgANUQZrH64vxzOmA/Wa9if2OPUU9p//9rD2wfbS9u Ovsj4ODmoPpQ/dqQedLydGFxUeAAbt5vgf8+i+oxPZJA1XE/ck9k5+LhD2WuXvB6v3vJSFlQRWBS TElOS3x/e7oi/27PdqyJIXeWcRJ4H3kvej9rf3/UN3eIYC7yUAEgLvnWoGcv47DfUfQg2ZBoo/+A v3avgv+ED4Ufhi97utrgf4ovYV+ML40/jk+PX3urL/+RT4svk4+Un5Wvlr97umijvC1iXyDzMOPg dKAt1YCAcGYtdjR2NqCj3HYz2QDZkL5QLhSR0uD/qEKY35nvd/+cT51fnm+AY/+nn3vKmJ+jj6Sf pa+mvNLyD+Pi+yPgEbagZDBjOeRlYf4QZjn18OxhtfDaY7UxMDkQtqA09fDzcL5ivlC2oLOS0SCz lDRxIL+zk9xQtqG+MbUzs5EzsuGeMrSBtjLEsLaYMmW00fvzcLTgNbUUyLK3c7aC1uH/z0G2I7ez t4G4M7gCuUK3gv24BTKxcLTgtUK5Qj4guGP9tTMzuZW8T7vVuUK2grgB/8VwvJW4QrzBx2C3srky u/PftoK9gbQCuHO8ATfIwcWA/8M1wuXCHsNTvYK8AsMiu8X/vYHJoMGiukXQ8LUUs5K3gPuxn7Kr YriBtL+1z7bft+//uP+6C7Eyuv+8D70f0u+/P//ATcFfwm/Df9hvxZ/Gr8e/Ac2AOTU4ODFmNKAz YjFkN9+QOD0xvbKBNefA4BBE4NvwM7Ey8bOUYTVhs2CzkTQgc9L/5qD9QAPwdZ+sTTzB7WCtNv/4 wHEBQLeuL68/p4+HP4hP/4lf42+CGuUf5i/nP+hP6V//kO/tj+Tf78/w3/Hv8v+X///1H+5f9x/4 L/k/+k+ez5/fb6DvofU0IQkhdLEQOnJltngAIESQZBgw7CBlBuPzB2JDQjMxPVAG8jgQDWC4aWZ5 /1AG8gB7c+yw+G5iauMf/W+anwAPAR//bi9vP3BPDx8QLxE/Ek8TXy8UbwGfZU9LBVQxwWtz13Nl G09KukTJEG4WPxdP/xhfGW8Vb3OiNEM0/zYPNx//OC85PzpMC68hfSL9Hd9Kq/4+IF8hbiK/I89z NC8fSsk6LTcyTyqxMzApECBN4WeAc2FnZTczMP8tH/8uLB1/Ng8wvzmvMt8z7y6/wT0PRnJvbTpC j15LSwUTBHFuyZBzQOtmIMxbbQTQ/ZBvOkaP66IOXUJ/V7uicE9uIELCZR0gbGYgT0xASd/1V8pB yZBlPj857zr/PA9/PR8+Lz8/QE9BX0JvHDxM+1ZAKGBtVA9Pv1DPUd9S779T/1UPVh9XL1g/HDxT aCE/RJ9FrGZfZUtG8LCQeSwhREBlYnJ1c6B5IK8igGpg1MDTQCAJMDrhsPggUE1f72Dwkn1cj12f /2jvX79gz2HfYu9j/xwfSED/df9Fv0dHca9bn25vb39wj/9xn3Kvc790z3XfaS4LgAcBg3fvePxb T1NQRkmwyFNhdg7BIHQIEEvheSqQIGbrsFoQKODjAC1DTFCIoSBXRyCwoCD4SUVUitDNEIAPgRyi cf98r32/h19/0Y7vj/9/z4yfb4Hvgv+ED5J/SeMAqqBvCx1QmeBpDoAgd2UndnaJgAQRd0vQiWCL IWynikIG8DgwaW9L0G9MQBmLVSAoqnBrwS0xNX46naBGcEvQRFAnkGpAKf4uk6+M343vkV+Yr5N/ n5+PlZ+Wr5e/ds5Vbmw4IfQgeQSAIASgS9A4YOMABGEgCDBkLWV5ZdtqYIlgaZowJ4BsJrA3sN+a 0arCKRAmsB0wb4lhJVCbDrAq0SCmcLBDeG37wO0JsG6u4i4QMuKByYBIMOsnkDfQbYmAcJuwyZAG wFfhMK6/r81DK7B5BsBBezfQCBBpWn97ry4dsUVj//vABvDicbc5od+pL6P/tO+/ph+nL6g/ue9I MIlQYZpx/QSwdh0wK8A4YJxyrWKJEP9HEawkCODJEOMACdCzYOqg9yjgwSKcgGbsIJ6vtR+g7/+4 38AvkS/I77q/xa+8373v977/y283EFCqcCjgiYCqcPPjACqAIGsnYa5wTECqwv8dIJrRqxHRDxxa OFFqIauR/HF1ibYEgCVQnAaLKMTv/20vxu/KX9WfzH/Nj86fz6+/0L/dv9LVBvAH4E5QYh0g12rw HTAHMEnUskUGEEgB/6xxiWCJUyhg4WCroQQA2ADfiyCcQawRsbACcC8EE4lQ+yuw0uAs3u+fz9uP 3J/j73/ev+rf4N/h7+L/1c/lkXD7CDDlcXSt8YnyH8D7QJvw3/vA6XGbcqrC1zUu0s3Uc/eqwSVQ 1zVz73/GD+w+7R9/9G/vP/tP8V/yb/N//s9i92rwnjRqYE0gMPbRa6CJYP/ZX/t//I/9vwUPyj8L b/+fvwgvAb8CzwPfDe83EEur4H+a8IsgwvEgMMGRhoDEEHRAdHA6Ly93FuAudxOPSupJNi+wgEdg iSEvVmMqEcSgLRWTLWtSLvsq4LGQI4tSi6/aXwlfDM//F78Mjx+/Dq8PvxDPEd8S70ciP0tTa1It MDIawDZ3nSCeNRZQRjfD1sXBMWLXsJGGMJpQc4lwZAdvCH//Hg8hfyjPI58t7yW/Js8n35so7yny MyoQHJAoTZxQVSrESfYibqtRROlDQ70aEC3EkYnjNJDnMGkrUXpkSyB1sIBmIJ0gKhAw/ikyXy4P Lx8wLzE/Mk8zX680bzV/No9KzHOGMG2sUJOcMwYRMTdrw1NUnSA7a2BrwlTXYQZ5Q0BVVNRDKWpg dbCwb8Gw03HziSKLU0lEQj897/yfP+//Rz9CD03fRC9FP0ZPhS9IaPNWz3cMb2ws703/Tw9QP/9a D1JfXF9Uf1WPVp83jziV9jg5HzonZiszSFkaATrj/0kKYM9cf08fXn9lz2CfbF+/Yr9jz2Tfh35J 3wbTOUtP/0xYWIpbH3G/bU9eT3XPIP//fv9wX3u/cn9zj3SfgX9atd/ngfXRmlBIgCtAcuYB1tR7 rFEWNnMWsRWRw6DpQGPvwYDE0Bj/1sQvgw98X22f/4C/iA+Af5HPgp+Ob4S/hc/vht+UTymh5chB wuC3wpXf/48PfZ+Z75Jfn8+g35WPnZ/vl6+Yv5nPdi1fqoyov6nP/62Pqoikb52/j++iH6wvpD8f sC+mX6dvqH92Hk9TUO958ObSTEIsgXS0z7Bfns//sp+zr7S/tc+237fvuP+6D/xGQIxGwV+9D74f vy/AP//BT8Jfw2/Ef8WPdjyLBhbi54xI5uHm0G4vu7LP4PZw4C9vc3Bmza/JX8pvEctyfX0A2gAA AAMA3j+fTgAAAwACWQAAFgADAAlZAwAAAAsAAoAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAA AwAEgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAALAAaBCCAGAAAAAADAAAAAAAAARgAAAAAG hQAAAAAAAAMAB4EIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAAQAALgQggBgAAAAAAwAAAAAAA AEYAAAAAYIUAAABAIw5DAAAACwASgQggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADABWBCCAG AAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAL4EIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAA HgBCgQggBgAAAAAAwAAAAAAAAEYAAAAAkYUAAAEAAAAFAAAAODM5NQAAAAALAB8OAQAAAAIB+A8B AAAAEAAAACQf1gYMJXFLphj5h3IG+SgCAfoPAQAAABAAAAAkH9YGDCVxS6YY+YdyBvkoAwD+DwUA AAADAA00/T8FAAMADzT9PwUAAgEUNAEAAAAQAAAATklUQfm/uAEAqgA32W4AAAIBfwABAAAAMQAA ADAwMDAwMDAwMjQxRkQ2MDYwQzI1NzE0QkE2MThGOTg3NzIwNkY5MjgwNDlDMkQwMAAAAAADAAYQ ivJBgAMABxDeBAAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEhJQUNFRUFOREFCSEFZLElX T1VMRExJS0VUT0FTS0ZPUjIwTUlOVVRFU1RPUFJFU0VOVE9VUkRSQUZUQVNGT0xMT1dTOkhUVFA6 Ly9XV1dJRVRGT1JHL0lOVEVSTkVULURSQUYAAAAAgIc= --Boundary_(ID_hZTIVB7nx83/NY2Ze5ZLhQ)-- ------------=_1266864282-5267-1-- From acee.lindem@ericsson.com Tue Feb 23 08:58: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 698E228C1F2 for ; Tue, 23 Feb 2010 08:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 ON46bKLf7Pzu for ; Tue, 23 Feb 2010 08:58:41 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 9272B3A6DCF for ; Tue, 23 Feb 2010 08:58:41 -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 o1NH2ftd014433; Tue, 23 Feb 2010 11:02:41 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 23 Feb 2010 12:00:36 -0500 From: Acee Lindem To: Dean Cheng Date: Tue, 23 Feb 2010 12:00:33 -0500 Thread-Topic: [OSPF] Saving the Best for Last - OSPF WG at IETF 77 Thread-Index: Acq0qbdTZlWndi6zQ5mNFcw9REOH+Q== Message-ID: <68BF272C-CA9A-49B0-A040-9AB37C1C48E4@ericsson.com> References: <0FC52A0A-4652-4709-9129-A0B6947ED078@ericsson.com> <2082A96DA14A4974BDE74138D32A05C2@china.huawei.com> In-Reply-To: <2082A96DA14A4974BDE74138D32A05C2@china.huawei.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ospf@ietf.org" , "Yiu_Lee@Cable.Comcast.com" Subject: Re: [OSPF] Saving the Best for Last - OSPF WG at IETF 77 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, 23 Feb 2010 16:58:42 -0000 SGkgRGVhbiwNClN1cmUgLSB3ZSdsbCBwdXQgeW91IG9uIHRoZSBhZ2VuZGEuDQpUaGFua3MsDQpB Y2VlDQpPbiBGZWIgMjIsIDIwMTAsIGF0IDE6NDYgUE0sIERlYW4gQ2hlbmcgd3JvdGU6DQoNCkhp IEFjZWUgYW5kIEFiaGF5LA0KDQpJIHdvdWxkIGxpa2UgdG8gYXNrIGZvciAyMCBtaW51dGVzIHRv IHByZXNlbnQgb3VyIGRyYWZ0IGFzIGZvbGxvd3M6DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWJvdWNhZGFpci1vc3BmLXY0djYtb3NwZnYzLW10LTAyLnR4dA0K DQpUaGFua3MNCkRlYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBv c3BmLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9zcGYtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0 bzpvc3BmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBY2VlDQo+IExpbmRlbQ0KPiBT ZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDIxLCAyMDEwIDEyOjAwIFBNDQo+IFRvOiBvc3BmQGlldGYu b3JnPG1haWx0bzpvc3BmQGlldGYub3JnPg0KPiBTdWJqZWN0OiBbT1NQRl0gU2F2aW5nIHRoZSBC ZXN0IGZvciBMYXN0IC0gT1NQRiBXRyBhdCBJRVRGIDc3DQo+DQo+IEl0IGxvb2tzIGxpa2Ugd2Un dmUgZHJhd24gdGhhdCBsYXN0IHNlc3Npb24gb2YgSUVURiA3NyAoMTM6MDAtMTU6MTUgb24gRnJp ZGF5KS4NCj4gVW5sZXNzIHlvdSBjYW4gZ2V0IGEgcmVkLWV5ZSwgdGhpcyB3aWxsIGdpdmUgeW91 IGFsbCBhbm90aGVyIG5pZ2h0IGluIEFuYWhlaW0NCj4gdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgYWxs IHZpY2VzIHRoaXMgZ3JlYXQgY2l0eSBoYXMgdG8gb2ZmZXIuDQo+DQo+IFBsZWFzZSBsZXQgdXMg a25vdyBpZiB5b3UgaGF2ZSBhbiBhZ2VuZGEgcmVxdWVzdCBmb3Igb3VyIHNlc3Npb24gYXQgSUVU RiA3Ny4NCj4gUGxlYXNlIHNlbmQgQWJoYXkgYW5kIEkgYW4gRS1tYWlsIHdpdGggdGhlIGRlc2ly ZWQgZHVyYXRpb24sIHRvcGljL2RyYWZ0IHRpdGxlLA0KPiBhbmQgcHJlc2VudGVyIGZvciBlYWNo IHNsb3QgdGhhdCB5b3UgcmVxdWVzdC4gUGxlYXNlIGxldCB1cyBoYXZlIHlvdXIgcmVxdWVzdHMN Cj4gYnkgRnJpZGF5LCBNYXJjaCAxMnRoLg0KPg0KPiBLZXkgZGF0ZXMgYXJlIGF0OiBodHRwOi8v d3d3LmlldGYub3JnL21lZXRpbmcvY3V0b2ZmLWRhdGVzLTIwMTAuaHRtbCNJRVRGNzcNCj4NCj4g MjAxMC0wMi0yNiAoRnJpZGF5KTogRmluYWwgYWdlbmRhIHRvIGJlIHB1Ymxpc2hlZC4NCj4gMjAx MC0wMy0wMSAoTW9uZGF5KTogSW50ZXJuZXQgRHJhZnQgQ3V0LW9mZiBmb3IgaW5pdGlhbCBkb2N1 bWVudCAoLTAwKQ0KPiBzdWJtaXNzaW9uIGJ5IDE3OjAwIFBTVCAoMDE6MDAgVHVlc2RheSwgTWFy Y2ggMiBVVEMpLCB1cGxvYWQgdXNpbmcgSUVURiBJRA0KPiBTdWJtaXNzaW9uIFRvb2wuDQo+IDIw MTAtMDMtMDggKE1vbmRheSk6IEludGVybmV0IERyYWZ0IGZpbmFsIHN1Ym1pc3Npb24gY3V0LW9m ZiBieSAxNzowMCBQU1QNCj4gKDAxOjAwIFR1ZXNkYXksIE1hcmNoIDkgVVRDKSwgdXBsb2FkIHVz aW5nIElFVEYgSUQgU3VibWlzc2lvbiBUb29sLg0KPg0KPiBUaGUgcHJlbGltaW5hcnkgYWdlbmRh IGlzIGF0OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvYWdlbmRhLw0KPg0K PiBBYmhheSBhbmQgQWNlZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBPU1BGIG1haWxpbmcgbGlzdA0KPiBPU1BGQGlldGYub3JnPG1haWx0 bzpPU1BGQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29zcGYNCg0KDQo= From mjbarnes@cisco.com Fri Feb 26 16:22:02 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 9FF013A88A4 for ; Fri, 26 Feb 2010 16:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 SyhKzxoeNQZf for ; Fri, 26 Feb 2010 16:22:00 -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 3F9EB3A88A5 for ; Fri, 26 Feb 2010 16:21:59 -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: AvsEAIP0h0urR7Ht/2dsb2JhbACbH3OIG5pxmECEeQSDFw X-IronPort-AV: E=Sophos;i="4.49,548,1262563200"; d="scan'208";a="93397689" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 27 Feb 2010 00:24:15 +0000 Received: from [10.21.145.20] (sjc-vpn7-276.cisco.com [10.21.145.20]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o1R0OFQv025727; Sat, 27 Feb 2010 00:24:15 GMT Message-ID: <4B88662F.5050605@cisco.com> Date: Fri, 26 Feb 2010 16:24:15 -0800 From: Michael Barnes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1 MIME-Version: 1.0 To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ospf@ietf.org Subject: [OSPF] Further R-Bit clarification [Fwd: [Technical Errata Reported] RFC5340 (2046)] 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, 27 Feb 2010 00:22:02 -0000 Hi Acee, Another question regarding the R-bit. If V is the root of the SPF tree (e.g. it is the router doing the SPF) with the current rules it will not install any OSPF routes into its own RIB. I don't think this is really the behavior that is desired. If V is the root then don't we want to ignore the R-bit? Thanks, Michael -------- Original Message -------- Subject: [OSPF] [Technical Errata Reported] RFC5340 (2046) Date: Wed, 17 Feb 2010 12:45:00 -0800 (PST) From: RFC Errata System To: none@rfc-editor.org, dennis@juniper.net, jmoy@sycamorenet.com, acee@redback.com, rcallon@juniper.net, adrian.farrel@huawei.com, acee@redback.com, akr@cisco.com CC: ospf@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC5340, "OSPF for IPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5340&eid=2046 -------------------------------------- Type: Technical Reported by: Acee Lindem Section: 4.8.1 Original Text ------------- o In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the Coltun, et al. Standards Track [Page 45] ^L RFC 5340 OSPF for IPv6 July 2008 router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. 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. Corrected Text -------------- o In Step 2, when a router Vertex V has just been added to the shortest-path tree and the router-LSA R-bit is not set in the LSA options, Vertex V's links are ignored and the next vertex on the candidate list should be examined as described in Step 3. Coltun, et al. Standards Track [Page 45] ^L RFC 5340 OSPF for IPv6 July 2008 o Also In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. o In Step 2b, if W is a router and the router-LSA V6-bit is not set in the LSA options, the transit link to W is ignored and V's next link is examined. Notes ----- This changes reflects the fact that the R-bit and the V6-bit should not be handled identically. The R-bit allows the router to participate in the IPv6 unicast topology but does not allow transit traffic. The V6-bit doesn't allow either. This problem was pointed out by Balaji Ganesh. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5340 (draft-ietf-ospf-ospfv3-update-23) -------------------------------------- Title : OSPF for IPv6 Publication Date : July 2008 Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf From rajeshsm@huawei.com Sun Feb 28 22:05: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 D1C203A88CA for ; Sun, 28 Feb 2010 22:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[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 i5LAtsgP9hfL for ; Sun, 28 Feb 2010 22:05:39 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8D77F3A63EB for ; Sun, 28 Feb 2010 22:05:39 -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 <0KYL00MKUA94F3@szxga04-in.huawei.com> for ospf@ietf.org; Mon, 01 Mar 2010 14:05:29 +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 <0KYL008UQA94AN@szxga04-in.huawei.com> for ospf@ietf.org; Mon, 01 Mar 2010 14:05:28 +0800 (CST) Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYL00KV5A93R7@szxml04-in.huawei.com> for ospf@ietf.org; Mon, 01 Mar 2010 14:05:28 +0800 (CST) Date: Mon, 01 Mar 2010 11:35:26 +0530 From: Rajesh Shetty In-reply-to: <4B88662F.5050605@cisco.com> To: 'Michael Barnes' , 'Acee Lindem' Message-id: <000001cab905$311adea0$1f01120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acq3Q0C4GAk+49eySsqL958OfEqfHABwNEcg References: <4B88662F.5050605@cisco.com> Cc: ospf@ietf.org Subject: Re: [OSPF] Further R-Bit clarification [Fwd: [Technical Errata Reported] RFC5340 (2046)] 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, 01 Mar 2010 06:05:41 -0000 Dear All, Irrespective of whether V is root or not V's Intra Area Prefix with reference type Router will get installed to the RIB. But V's Intra Area Prefix with reference type Network will not get installed, whether this behavior is as expected? Thanks Rajesh This e-mail and 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 herein 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 e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Michael Barnes Sent: Saturday, February 27, 2010 5:54 AM To: Acee Lindem Cc: ospf@ietf.org Subject: [OSPF] Further R-Bit clarification [Fwd: [Technical Errata Reported] RFC5340 (2046)] Hi Acee, Another question regarding the R-bit. If V is the root of the SPF tree (e.g. it is the router doing the SPF) with the current rules it will not install any OSPF routes into its own RIB. I don't think this is really the behavior that is desired. If V is the root then don't we want to ignore the R-bit? Thanks, Michael -------- Original Message -------- Subject: [OSPF] [Technical Errata Reported] RFC5340 (2046) Date: Wed, 17 Feb 2010 12:45:00 -0800 (PST) From: RFC Errata System To: none@rfc-editor.org, dennis@juniper.net, jmoy@sycamorenet.com, acee@redback.com, rcallon@juniper.net, adrian.farrel@huawei.com, acee@redback.com, akr@cisco.com CC: ospf@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC5340, "OSPF for IPv6". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5340&eid=2046 -------------------------------------- Type: Technical Reported by: Acee Lindem Section: 4.8.1 Original Text ------------- o In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the Coltun, et al. Standards Track [Page 45] ^L RFC 5340 OSPF for IPv6 July 2008 router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. 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. Corrected Text -------------- o In Step 2, when a router Vertex V has just been added to the shortest-path tree and the router-LSA R-bit is not set in the LSA options, Vertex V's links are ignored and the next vertex on the candidate list should be examined as described in Step 3. Coltun, et al. Standards Track [Page 45] ^L RFC 5340 OSPF for IPv6 July 2008 o Also In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID. o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs. o In Step 2b, if W is a router and the router-LSA V6-bit is not set in the LSA options, the transit link to W is ignored and V's next link is examined. Notes ----- This changes reflects the fact that the R-bit and the V6-bit should not be handled identically. The R-bit allows the router to participate in the IPv6 unicast topology but does not allow transit traffic. The V6-bit doesn't allow either. This problem was pointed out by Balaji Ganesh. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5340 (draft-ietf-ospf-ospfv3-update-23) -------------------------------------- Title : OSPF for IPv6 Publication Date : July 2008 Author(s) : R. Coltun, D. Ferguson, J. Moy, A. Lindem Category : PROPOSED STANDARD Source : Open Shortest Path First IGP Area : Routing Stream : IETF Verifying Party : IESG _______________________________________________ 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