From ospf-bounces@ietf.org Mon May 01 12:18:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fab6E-0006Oo-9Y; Mon, 01 May 2006 12:18:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fab6D-0006M5-7v
	for ospf@ietf.org; Mon, 01 May 2006 12:18:13 -0400
Received: from coconut.sycamorenet.com ([12.146.0.143]
	helo=bristol.sycamorenet.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fab6C-0001Kl-0a
	for ospf@ietf.org; Mon, 01 May 2006 12:18:13 -0400
Received: by bristol.sycamorenet.com with Internet Mail Service (5.5.2658.3)
	id <JWS64DJB>; Mon, 1 May 2006 12:18:11 -0400
Message-ID: <0679BA70A2F59E49B186858B47F4595C0873E9@viper.sycamorenet.com>
From: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>
To: ospf@ietf.org
Date: Mon, 1 May 2006 12:17:12 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2658.3)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [OSPF] Correlating unnumbered point-to-point interfaces in OSPFv2
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi,

Assume there are two routers, R1 and R2, connected by two unnumbered
point-to-point interfaces, say L1 and L2. Assume also that the OSPF
adjacency is established over these two links and are listed in the Router
LSA's originated by R1 and R2. 

At a later point in time, L1 experiences a unidirectional failure such that
R2 detects the failure but not R1. R2 now re-originates its Router LSA with
L1 removed from the list of links. 

When R1 receives the new Router LSA from R2, how would it realize that L1 is
down - before the RouterDeadInterval. Since both routers advertise only
their local MIB-II IfIndex value in the  Link Data filed, how would each
routers correlate the interfaces. 

Is this an implementation specific issue? or is there additional information
available in the protocol that can be used to resolve this?
  
Regards,

Vijay

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



From ospf-bounces@ietf.org Mon May 01 13:58:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FacfB-0007KO-SI; Mon, 01 May 2006 13:58:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FacfA-0007KJ-Kw
	for ospf@ietf.org; Mon, 01 May 2006 13:58:24 -0400
Received: from [203.199.83.31] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Facf8-00059b-Jl
	for ospf@ietf.org; Mon, 01 May 2006 13:58:24 -0400
Received: (qmail 29777 invoked by uid 510); 1 May 2006 17:57:23 -0000
Date: 1 May 2006 17:57:23 -0000
Message-ID: <20060501175723.29776.qmail@webmail46.rediffmail.com>
Received: from unknown (63.80.1.198) by rediffmail.com via HTTP;
	01 may 2006 17:57:23 -0000
MIME-Version: 1.0
From: "badvel vishnu reddy" <badvel_vishnuvardhan@rediffmail.com>
To: "Acee Lindem" <acee@cisco.com>
Subject: Re: Re: [OSPF] Re:Generating type5 LSA in ospfv3
X-Spam-Score: 1.1 (+)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: ospf <ospf@ietf.org>
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: badvel vishnu reddy <badvel_vishnuvardhan@rediffmail.com>
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1755430270=="
Errors-To: ospf-bounces@ietf.org

 This is a multipart mime message


--===============1755430270==
Content-type: multipart/alternative;
	boundary="Next_1146506243---0-203.199.83.31-29771"

 This is a multipart mime message


--Next_1146506243---0-203.199.83.31-29771
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Acee,=0AThanks for the inputs. Still i am wondering what should be done =
in the following cases should i purge one of the Lsa's?=0A=0A1) Two nssa AB=
R's generating the default routes=0A=0A2) One nssa ABR and one internal rou=
ters generating the defualt =0Alsa=0A=0AThanks&Regards=0AVishnu=0A=0A=0AOn =
Thu, 27 Apr 2006 Acee Lindem wrote :=0A>badvel vishnu reddy wrote:=0A>=0A>>=
  Hi All,=0A>>In OSPFV3 since the link state ID's of an external LSA's can =
be anything if i use the address prefix with an algorithm that generates th=
e number, there is always a possibility that there exists the same network =
but with different prefix length, so in this regard OSPV2 escapes by using =
 rfc 2328 sec E. An algorithm for assigning Link State IDs.=0A>>In the cont=
ext of OSPFV3 what should be done since RFC 2740 doesn't specify anything.=
=0A>>  =0A>Nothing - Refer to section 2.2 in RFC 2740. In OSPFv3, the Link =
State ID has no=0A>addressing semantics. For inter-area prefix LSAs, inter-=
area-router-LSAs,=0A>external LSAs, and NSSA LSAs, the Link State ID is sim=
ply a number which=0A>must be unique for LSAs of the same type originated w=
ithin the same=0A>flooding scope by the same advertising router.=0A>=0A>Hop=
e this helps,=0A>Acee=0A>=0A>>Regards,=0A>>Vishnu=0A>>  =0A>>--------------=
----------------------------------------------------------=0A>>=0A>>_______=
________________________________________=0A>>OSPF mailing list=0A>>OSPF@iet=
f.org=0A>>https://www1.ietf.org/mailman/listinfo/ospf=0A>>  =0A
--Next_1146506243---0-203.199.83.31-29771
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0AHi Acee,<BR>=0AThanks for the inputs. Still i am wondering what shoul=
d be done in the following cases should i purge one of the Lsa's?<BR>=0A<BR=
>=0A1) Two nssa ABR's generating the default routes<BR>=0A<BR>=0A2) One nss=
a ABR and one internal routers generating the defualt <BR>=0Alsa<BR>=0A<BR>=
=0AThanks&amp;Regards<BR>=0AVishnu<BR>=0A<BR>=0A<BR>=0AOn Thu, 27 Apr 2006 =
Acee Lindem wrote :<BR>=0A&gt;badvel vishnu reddy wrote:<BR>=0A&gt;<BR>=0A&=
gt;&gt;&nbsp; Hi All,<BR>=0A&gt;&gt;In OSPFV3 since the link state ID's of =
an external LSA's can be anything if i use the address prefix with an algor=
ithm that generates the number, there is always a possibility that there ex=
ists the same network but with different prefix length, so in this regard O=
SPV2 escapes by using&nbsp; rfc 2328 sec E. An algorithm for assigning Link=
 State IDs.<BR>=0A&gt;&gt;In the context of OSPFV3 what should be done sinc=
e RFC 2740 doesn't specify anything.<BR>=0A&gt;&gt;&nbsp; <BR>=0A&gt;Nothin=
g - Refer to section 2.2 in RFC 2740. In OSPFv3, the Link State ID has no<B=
R>=0A&gt;addressing semantics. For inter-area prefix LSAs, inter-area-route=
r-LSAs,<BR>=0A&gt;external LSAs, and NSSA LSAs, the Link State ID is simply=
 a number which<BR>=0A&gt;must be unique for LSAs of the same type originat=
ed within the same<BR>=0A&gt;flooding scope by the same advertising router.=
<BR>=0A&gt;<BR>=0A&gt;Hope this helps,<BR>=0A&gt;Acee<BR>=0A&gt;<BR>=0A&gt;=
&gt;Regards,<BR>=0A&gt;&gt;Vishnu<BR>=0A&gt;&gt;&nbsp; <BR>=0A&gt;&gt;-----=
-------------------------------------------------------------------<BR>=0A&=
gt;&gt;<BR>=0A&gt;&gt;_______________________________________________<BR>=
=0A&gt;&gt;OSPF mailing list<BR>=0A&gt;&gt;OSPF@ietf.org<BR>=0A&gt;&gt;http=
s://www1.ietf.org/mailman/listinfo/ospf<BR>=0A&gt;&gt;&nbsp; <BR>=0A=0A</P>=
=0A<br><br>=0A<a href=3D"http://adworks.rediff.com/cgi-bin/AdWorks/sigclick=
.cgi/www.rediff.com/signature-home.htm/1507191490@Middle5?PARTNER=3D3"><IMG=
 SRC=3D"http://adworks.rediff.com/cgi-bin/AdWorks/sigimpress.cgi/www.rediff=
.com/signature-home.htm/1963059423@Middle5?OAS_query=3Dnull&PARTNER=3D3" BO=
RDER=3D0 VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1146506243---0-203.199.83.31-29771--



--===============1755430270==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1755430270==--





From ospf-bounces@ietf.org Mon May 01 14:33:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FadD0-0004Nu-L3; Mon, 01 May 2006 14:33:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FadCz-0004Nc-LG
	for ospf@ietf.org; Mon, 01 May 2006 14:33:21 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FadCy-0006SK-9O
	for ospf@ietf.org; Mon, 01 May 2006 14:33:21 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id
	k41IXH1Z063321; Mon, 1 May 2006 11:33:17 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k41IXD589481;
	Mon, 1 May 2006 11:33:13 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
In-Reply-To: <0679BA70A2F59E49B186858B47F4595C0873E9@viper.sycamorenet.com>
References: <0679BA70A2F59E49B186858B47F4595C0873E9@viper.sycamorenet.com>
Mime-Version: 1.0 (Apple Message framework v746.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <0C679430-B8F2-467B-996E-22DCBE5D359A@juniper.net>
Content-Transfer-Encoding: 7bit
From: Dave Katz <dkatz@juniper.net>
Subject: Re: [OSPF] Correlating unnumbered point-to-point interfaces in OSPFv2
Date: Mon, 1 May 2006 11:33:10 -0700
To: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>
X-Mailer: Apple Mail (2.746.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org


On May 1, 2006, at 9:17 AM, Pandian, Vijay wrote:

> Hi,
>
> Assume there are two routers, R1 and R2, connected by two unnumbered
> point-to-point interfaces, say L1 and L2. Assume also that the OSPF
> adjacency is established over these two links and are listed in the  
> Router
> LSA's originated by R1 and R2.
>
> At a later point in time, L1 experiences a unidirectional failure  
> such that
> R2 detects the failure but not R1. R2 now re-originates its Router  
> LSA with
> L1 removed from the list of links.
>
> When R1 receives the new Router LSA from R2, how would it realize  
> that L1 is
> down - before the RouterDeadInterval. Since both routers advertise  
> only
> their local MIB-II IfIndex value in the  Link Data filed, how would  
> each
> routers correlate the interfaces.

In general, you're hosed until the adjacency is seen as being down on  
both sides.  This is inherent to the protocol.  There is an  
assumption that a failure will cause a bidirectional adjacency  
failure in an acceptable amount of time.  If waiting for the dead  
timer to expire is too long, then you need a shorter dead timer (or  
use BFD.)

Your question implies that you're trying to divine adjacency state by  
looking at the LSA database;  if so, this is a bad idea, since the  
database may not be up to date and may be in flux.

--Dave


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



From ospf-bounces@ietf.org Mon May 01 14:42:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FadLB-00031F-ID; Mon, 01 May 2006 14:41:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FadLA-00031A-KZ
	for ospf@ietf.org; Mon, 01 May 2006 14:41:48 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FadLA-00070I-BU
	for ospf@ietf.org; Mon, 01 May 2006 14:41:48 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 01 May 2006 14:41:48 -0400
X-IronPort-AV: i="4.04,169,1144036800"; 
	d="scan'208"; a="87629247:sNHT30891388"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k41IfmTL013221; 
	Mon, 1 May 2006 14:41:48 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 1 May 2006 14:41:48 -0400
Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 14:41:47 -0400
Message-ID: <4456566A.1030608@cisco.com>
Date: Mon, 01 May 2006 14:41:46 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: badvel vishnu reddy <badvel_vishnuvardhan@rediffmail.com>
Subject: Re: [OSPF] Re:Generating type5 LSA in ospfv3
References: <20060501175723.29776.qmail@webmail46.rediffmail.com>
In-Reply-To: <20060501175723.29776.qmail@webmail46.rediffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 May 2006 18:41:47.0633 (UTC)
	FILETIME=[E6F4FE10:01C66D4E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: ospf <ospf@ietf.org>
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

badvel vishnu reddy wrote:

>Hi Acee,
>Thanks for the inputs. Still i am wondering what should be done in the following cases should i purge one of the Lsa's?
>
>1) Two nssa ABR's generating the default routes
>
>2) One nssa ABR and one internal routers generating the defualt 
>lsa
>  
>
Vishnu,
Wasn't this a different thread :^) The default LSAs from the ABRs will not
have a forwarding address specified so they will never be redundant (as 
specified
in  12.4.4.1).

Note that RFC 3101 says that an ABR may install a default route 
corresponding
to an NSSA LSA with the P-bit set. I think that in this situation, the 
ABR must inhibit
or flush the any NSSA default it is injecting into the NSSA area. 
However, it
doesn't appear RFC 3101 handles this case (Pat can correct me if I'm 
wrong).

Thanks,
Acee


>Thanks&Regards
>Vishnu
>
>
>On Thu, 27 Apr 2006 Acee Lindem wrote :
>  
>
>>badvel vishnu reddy wrote:
>>
>>    
>>
>>> Hi All,
>>>In OSPFV3 since the link state ID's of an external LSA's can be anything if i use the address prefix with an algorithm that generates the number, there is always a possibility that there exists the same network but with different prefix length, so in this regard OSPV2 escapes by using  rfc 2328 sec E. An algorithm for assigning Link State IDs.
>>>In the context of OSPFV3 what should be done since RFC 2740 doesn't specify anything.
>>> 
>>>      
>>>
>>Nothing - Refer to section 2.2 in RFC 2740. In OSPFv3, the Link State ID has no
>>addressing semantics. For inter-area prefix LSAs, inter-area-router-LSAs,
>>external LSAs, and NSSA LSAs, the Link State ID is simply a number which
>>must be unique for LSAs of the same type originated within the same
>>flooding scope by the same advertising router.
>>
>>Hope this helps,
>>Acee
>>
>>    
>>
>>>Regards,
>>>Vishnu
>>> 
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>OSPF mailing list
>>>OSPF@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/ospf
>>> 
>>>      
>>>
>
>  
>

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



From ospf-bounces@ietf.org Mon May 01 15:01:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fade8-0007xR-0U; Mon, 01 May 2006 15:01:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fade6-0007xM-Hf
	for ospf@ietf.org; Mon, 01 May 2006 15:01:22 -0400
Received: from pproxy.gmail.com ([64.233.166.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fade4-0007St-5M
	for ospf@ietf.org; Mon, 01 May 2006 15:01:22 -0400
Received: by pproxy.gmail.com with SMTP id t32so2866278pyc
	for <ospf@ietf.org>; Mon, 01 May 2006 12:01:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=d9mkLIGvfOJeKdtHVzxrZ8OH+lwBV/N/GZL5j3tOq5L1srS1fs5hGkLnvM6hR3rnietQusT0WSDlhh85Y+SjznOeMUu5JW5EqhYmKj9JmcUOR63ZIeya+D9Agjyx2GQ9E+RYJTbJOPMD9Gl3AntAKtcJmT8s26LNOJlp0ifvq+0=
Received: by 10.35.98.6 with SMTP id a6mr3061561pym;
	Mon, 01 May 2006 12:00:52 -0700 (PDT)
Received: by 10.35.10.2 with HTTP; Mon, 1 May 2006 12:00:52 -0700 (PDT)
Message-ID: <6280db520605011200k74f67ccbh45f33eb934ea546e@mail.gmail.com>
Date: Mon, 1 May 2006 12:00:52 -0700
From: "Alia Atlas" <akatlas@gmail.com>
To: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>
Subject: Re: [OSPF] Correlating unnumbered point-to-point interfaces in OSPFv2
In-Reply-To: <0679BA70A2F59E49B186858B47F4595C0873E9@viper.sycamorenet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <0679BA70A2F59E49B186858B47F4595C0873E9@viper.sycamorenet.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

On 5/1/06, Pandian, Vijay <Vijay.Pandian@sycamorenet.com> wrote:
> Hi,
>
> Assume there are two routers, R1 and R2, connected by two unnumbered
> point-to-point interfaces, say L1 and L2. Assume also that the OSPF
> adjacency is established over these two links and are listed in the Route=
r
> LSA's originated by R1 and R2.
>
> At a later point in time, L1 experiences a unidirectional failure such th=
at
> R2 detects the failure but not R1. R2 now re-originates its Router LSA wi=
th
> L1 removed from the list of links.
>
> When R1 receives the new Router LSA from R2, how would it realize that L1=
 is
> down - before the RouterDeadInterval. Since both routers advertise only
> their local MIB-II IfIndex value in the  Link Data filed, how would each
> routers correlate the interfaces.
>
> Is this an implementation specific issue? or is there additional informat=
ion
> available in the protocol that can be used to resolve this?

If there is only one unnumbered interface between R1 and R2, then it
is easy to match them up.  Otherwise, there is a link-local extension
in the GMPLS work, as I recall, that provides the capability to match
up the unnumbered interfaces.  The issue comes up with IP FRR as well,
because it is necessary/desirable to correctly match up the two
uni-directional links so that the potential failures are considered.

Alia
> https://www1.ietf.org/mailman/listinfo/ospf
>

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



From ospf-bounces@ietf.org Mon May 01 15:38:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FaeDe-00039E-FA; Mon, 01 May 2006 15:38:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FaeDc-00035p-Oh
	for ospf@ietf.org; Mon, 01 May 2006 15:38:04 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaeDc-0000uI-HM
	for ospf@ietf.org; Mon, 01 May 2006 15:38:04 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 01 May 2006 12:37:35 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.04,169,1144047600"; 
	d="scan'208"; a="27094959:sNHT80720262348"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k41JbZTL026505
	for <ospf@ietf.org>; Mon, 1 May 2006 15:37:35 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 1 May 2006 15:37:34 -0400
Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 15:37:34 -0400
Message-ID: <4456637E.5090601@cisco.com>
Date: Mon, 01 May 2006 15:37:34 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OSPF List <ospf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 May 2006 19:37:34.0861 (UTC)
	FILETIME=[B20F73D0:01C66D56]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Subject: [OSPF] [Fwd: IETF Meeting Survey]
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

FYI - If you attended the Dallas IETF, the administrative branch of
the IETF is looking for survey participants.

Thanks,
Acee

-------- Original Message --------
Subject: 	IETF Meeting Survey
Date: 	Mon, 01 May 2006 11:24:42 -0400
From: 	Ray Pelletier <rpelletier@isoc.org>
To: 	wgchairs@ietf.org



All;
It has been suggested that if I really wanted to get feedback on the 
Meeting Survey (and I do)  I should have it forwarded by the WG Chairs 
to the working groups - so this is a request that you ask members of the 
working groups to complete a short survey that focuses primarily, but 
not exclusively, on their meeting experience in Dallas. 

I truly want the info to make the changes members of the community want, 
if possible and greatly appreciate your assistance in this regard.

Those interested in taking the survey can find it at:
http://www.surveymonkey.com/s.asp?u=649182049947

Thanks
Ray Pelletier
IETF Admininstrative Director



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



From ospf-bounces@ietf.org Mon May 01 20:35:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Faiqw-0007NN-3e; Mon, 01 May 2006 20:34:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Faiqt-0007Lm-VE
	for OSPF@IETF.ORG; Mon, 01 May 2006 20:34:55 -0400
Received: from omega7.wr.usgs.gov ([130.118.4.3] helo=ns0.wr.usgs.gov)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faiqt-0005lc-Ll
	for OSPF@IETF.ORG; Mon, 01 May 2006 20:34:55 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392)
	id <01M1WZFWG85S001JQU@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Mon,
	01 May 2006 17:33:38 -0700 (PDT)
Date: Mon, 01 May 2006 17:33:38 -0700 (PDT)
From: "Pat Murphy - (650)329-4044" <pmurphy@noc.usgs.net>
Subject: Re: [OSPF] Re:Generating type5 LSA in ospfv3
To: OSPF@IETF.ORG
Message-id: <01M1WZFWG93M001JQU@omega7.wr.usgs.gov>
X-VMS-To: ospf@ietf.org
X-VMS-Cc: PMURPHY,acee@cisco.com,badvel_vishnuvardhan@rediffmail.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: ACEE@CISCO.COM, BADVEL_VISHNUVARDHAN@REDIFFMAIL.COM
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

>I think that in this situation, the ABR must inhibit
>or flush the any NSSA default it is injecting into the NSSA area. 
>However, it doesn't appear RFC 3101 handles this case (Pat can correct 
>me if I'm wrong).

When I re-wrote the spec the intent was that the NSSA ABR would always 
originate a default LSA unless it loses its ABR status via transit 
topological failure. Adding the no-summary option triggered this 
decision and I saw no reason to have a different behavior when summary 
routes are imported. It is the nature of a stub area. In all situations 
they must have a default or they can lose access to the full OSPF 
domain's routing environment. The last paragraph of Section 2.4, 
Originating Type-7 LSAs, states it as a "MUST" for those who adhere to 
IETF vernacular.

   NSSA border routers must originate an LSA for the default destination
   into all their directly attached NSSAs in order to support intra-AS
   routing and inter-AS routing.  This default destination is advertised
   in either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7.
   The default LSA's metric should be configurable. For Type-7 default
   LSAs, the metric type (1 or 2) should also be configurable.

Clearly an NSSA ABR's self originated type 7 default LSA can be 
configured, via metrics, as the NSSA's default path of last resort; 
hence this should not be a problem. Regardless it never factors into the 
installation of default on any NSSA ABR as describe below.

The third paragraph of RFC 3101 Section 2.4, further clarifies issues 
w.r.t. the NSSA type 7 default LSAs.

   A Type-7 default LSA for the network 0.0.0.0/0 may be originated into
   the NSSA by any NSSA router.  The Type-7 default LSA originated by an
   NSSA border router must have the P-bit clear.  An NSSA ASBR that is
   not an NSSA border router may originate a Type-7 default LSA with the
   P-bit set.  A Type-7 default LSA may be installed by NSSA border
   routers if and only if its P-bit is set.  (See Appendix E.)

Thus if an ABR must originate a default lsa into an NSSA as well as into 
the full OSPF domain, it must do so via separately self-originated type 
7 and type 5 default LSAs. It cannot set the P-bit and use type 7 
translation to generate the type 5 default LSA. This is not the case for 
non-ABRs.

Note that the installation of a Type 7 default LSA on the NSSA border 
can harm the full OSPF domain's transit topology (See Appendix E). Thus 
RFC 3101 guards against this in Section 2.5 Step 3 paragraph 2:

          ... if the destination is a Type-7 default route (destination
          ID = DefaultDestination) and one of the following is true,
          then do nothing with this LSA and consider the next in the
          list:

            o  The calculating router is a border router and the LSA has
               its P-bit clear.

Hence both RFC 3101 and RFC 1587 do not install the Type 7 default LSAs 
of other NSSA ABRS. However RFC 1587 will install a non-ABR originated 
type 7 default LSA when its p-bit is clear. RFC 3101 does not. This 
correction was due to the discussion in Appendix E.

Pat


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



From ospf-bounces@ietf.org Mon May 01 21:17:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FajW6-0005RW-Jt; Mon, 01 May 2006 21:17:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FajW4-0005RR-Vr
	for OSPF@ietf.org; Mon, 01 May 2006 21:17:28 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FajW3-00076v-MV
	for OSPF@ietf.org; Mon, 01 May 2006 21:17:28 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 01 May 2006 21:17:28 -0400
X-IronPort-AV: i="4.05,78,1146456000"; d="scan'208"; a="87655981:sNHT31417540"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k421HPvF024389; 
	Mon, 1 May 2006 21:17:25 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 1 May 2006 21:17:25 -0400
Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 21:17:24 -0400
Message-ID: <4456B324.7040300@cisco.com>
Date: Mon, 01 May 2006 21:17:24 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: [OSPF] Re:Generating type5 LSA in ospfv3
References: <01M1WZFWG93M001JQU@omega7.wr.usgs.gov>
In-Reply-To: <01M1WZFWG93M001JQU@omega7.wr.usgs.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 May 2006 01:17:24.0845 (UTC)
	FILETIME=[2B7019D0:01C66D86]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: OSPF@IETF.ORG, BADVEL_VISHNUVARDHAN@REDIFFMAIL.COM
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Pat,
See inline down at the summary.

Pat Murphy - (650)329-4044 wrote:

>>I think that in this situation, the ABR must inhibit
>>or flush the any NSSA default it is injecting into the NSSA area. 
>>However, it doesn't appear RFC 3101 handles this case (Pat can correct 
>>me if I'm wrong).
>>    
>>
>
>When I re-wrote the spec the intent was that the NSSA ABR would always 
>originate a default LSA unless it loses its ABR status via transit 
>topological failure. Adding the no-summary option triggered this 
>decision and I saw no reason to have a different behavior when summary 
>routes are imported. It is the nature of a stub area. In all situations 
>they must have a default or they can lose access to the full OSPF 
>domain's routing environment. The last paragraph of Section 2.4, 
>Originating Type-7 LSAs, states it as a "MUST" for those who adhere to 
>IETF vernacular.
>
>   NSSA border routers must originate an LSA for the default destination
>   into all their directly attached NSSAs in order to support intra-AS
>   routing and inter-AS routing.  This default destination is advertised
>   in either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7.
>   The default LSA's metric should be configurable. For Type-7 default
>   LSAs, the metric type (1 or 2) should also be configurable.
>
>Clearly an NSSA ABR's self originated type 7 default LSA can be 
>configured, via metrics, as the NSSA's default path of last resort; 
>hence this should not be a problem. Regardless it never factors into the 
>installation of default on any NSSA ABR as describe below.
>
>The third paragraph of RFC 3101 Section 2.4, further clarifies issues 
>w.r.t. the NSSA type 7 default LSAs.
>
>   A Type-7 default LSA for the network 0.0.0.0/0 may be originated into
>   the NSSA by any NSSA router.  The Type-7 default LSA originated by an
>   NSSA border router must have the P-bit clear.  An NSSA ASBR that is
>   not an NSSA border router may originate a Type-7 default LSA with the
>   P-bit set.  A Type-7 default LSA may be installed by NSSA border
>   routers if and only if its P-bit is set.  (See Appendix E.)
>
>Thus if an ABR must originate a default lsa into an NSSA as well as into 
>the full OSPF domain, it must do so via separately self-originated type 
>7 and type 5 default LSAs. It cannot set the P-bit and use type 7 
>translation to generate the type 5 default LSA. This is not the case for 
>non-ABRs.
>
>Note that the installation of a Type 7 default LSA on the NSSA border 
>can harm the full OSPF domain's transit topology (See Appendix E). Thus 
>RFC 3101 guards against this in Section 2.5 Step 3 paragraph 2:
>
>          ... if the destination is a Type-7 default route (destination
>          ID = DefaultDestination) and one of the following is true,
>          then do nothing with this LSA and consider the next in the
>          list:
>
>            o  The calculating router is a border router and the LSA has
>               its P-bit clear.
>
>Hence both RFC 3101 and RFC 1587 do not install the Type 7 default LSAs 
>of other NSSA ABRS. 
>
Agree.

>However RFC 1587 will install a non-ABR originated 
>type 7 default LSA when its p-bit is clear. RFC 3101 does not. This 
>correction was due to the discussion in Appendix E.
>  
>
In retrospect, I don't think we should depend on a configured metric to 
avoid a routing
loop in the case where the NSSA ABR is installing a default from an NSSA 
internal
router (with the P-bit set). I think that NSSA ABRs should either be 
precluded
from installing an NSSA internal default (as they are when summaries
are suppressed) or have them not advertise a type 7 default when an 
internal NSSA
default is installed.

Thanks,
Acee

>Pat
>
>  
>

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



From ospf-bounces@ietf.org Tue May 02 02:17:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FaoBW-0002j6-Uf; Tue, 02 May 2006 02:16:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FaoBU-0002bc-Ui
	for ospf@ietf.org; Tue, 02 May 2006 02:16:32 -0400
Received: from ilsmtp01.ecitele.com ([147.234.1.11])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaoBT-00019S-Cg
	for ospf@ietf.org; Tue, 02 May 2006 02:16:32 -0400
To: ospf@ietf.org
X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004
Message-ID: <OF6A7954EF.92E0BCD1-ONC2257162.0021D44F-C2257162.002276E6@ecitele.com>
From: Ilan.Bercovich@ecitele.com
Date: Tue, 2 May 2006 09:16:28 +0300
X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 |
	December 22, 2004) at 05/02/2006 09:24:18
MIME-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=4DBBFBF1DFB252DF8f9e8a93df938690918c4DBBFBF1DFB252DF"
Content-Disposition: inline
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Subject: [OSPF] inter-area routes (section 16.2)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

--0__=4DBBFBF1DFB252DF8f9e8a93df938690918c4DBBFBF1DFB252DF
Content-type: text/plain; charset=US-ASCII

In section 16.2: "If the router has active attachments to multiple areas,
only backbone summary-LSAs are examined."

What should happen in case of 2 areas without backbone?

(Embedded image moved to file: pic26187.jpg)

Regards,
Ilan
--0__=4DBBFBF1DFB252DF8f9e8a93df938690918c4DBBFBF1DFB252DF
Content-type: image/jpeg; 
	name="pic26187.jpg"
Content-Disposition: attachment; filename="pic26187.jpg"
Content-transfer-encoding: base64

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK
CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU
FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCABnALEDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KK
KACiiigAooooAK5Tx18UvDHw3+wx67qfk3+ob/sGlWdvLeajf7Nvm/ZrOBXnn8sOrP5aNsXLNhQS
MrxT4p1TxNrt14O8HXX2S/t9o1vxCsaypoiOodYo1cFJb50ZWSNgyRI6zTKytBDdavgX4Z6H4A+3
XVjB9r17U9jav4hvERtR1aRN22S5lVV3bd7BEAWOJSI4kjjVUAByv/Cc/Evxh+98KeBtP0PRZ/3c
OreNdRktrwBuVuk0yGGRni2srCGee0nLB45EgIDk/wCFd/E/Xf8AkO/Fz+yPK/1P/CC+GrWw8zP3
vP8A7QbUN+MLt8vysZfdvyuz1WigDyr/AIURear+68T/ABS+IHiiwX5ks/7St9G2SdBJ52lW9nO2
AWGxpGjO7JQsqMp/wzf4ctv3un+I/iBp9/H81vef8J5rN35Eg5WTybm6lgl2nB2TRyRtjDoykqfV
aKAPKv8AhTfi7/ou3xA/8AfD3/yqo+zfG/Qv9I/tH4f+ON37v+z/ALBfeG/L7+b9p87UN+MbfK8l
c793mDZtf1WigDyr/hoLS/C3+j/EfSdQ+HN3FxPqGpwtNoWPuiVdVjU20cTyBkjW6a3nY7N0CGRF
b1WivKv+FZ3nwl/0/wCGkHk6DB80/wAOrVLe306ZT/rZLDKr9luThWCeYtrIwk3pFJcPdIAeq0Vk
+FvFOl+NNCtdY0e6+12FxuCs0bROjoxSSKSNwHilR1dHjcK6OjKyqykDWoAKKKKACiiigAooooAK
KKKACiiigArivjR41vvh98L/ABBrWkRW9z4hWFbTRLS7VjDdapcOtvYQPhlwslzLBGWLKqhyWZAC
w7WvNP2jdJvtS+D2tXWmWVxqmpaFNZeJbXS7SJpJtRl027h1BLNAoJDTtaiEMFYqZAwV8bSAdX4A
8FWPw68G6T4c0+W4urewhEbXl6yvc3kpJaW5uHVVEk80jPLJJgF5JHY8sa6Cqmk6tY6/pVlqemXt
vqOm3sKXNreWkqywzxOoZJEdSQyspBDAkEEEVboA8U/az8WaHonw403w/wCItZ0/w/ovjHWrbw9f
6hrF0lrZLYMHuNQhmnYjyvPsra7t0Zfm82eLBQnzEwPDn7SWo6Z+zH4I8brpVx8UNXuNTsfC2o3e
g3VlDDe3v9oDTLi+gd3jiaCS4Vmh2hd4mh3CFC7xelXPwke7+MunfEKXxj4geTT7K50+20DZYjTo
4LgQecmRa/aDuktYJcmYkMmAQhZDxXiP9lY+IdV8SXf/AAtTxxp1vr3iC18TXNjaRaOYUvbVrU2p
Qyae7hYhY2gClzuEI37yzlgA+J/7Qnib4XW3hLSrzwPb6l4212G+vH03SLnU9Rsba3tZIUdvPtNL
muGY/arYjdaJGMyAyArGJanxZ/at/wCFWeFdA8T3fhb7FpV9oo16403XtQ+xa6YVQS3FvaadHFPJ
cXNtFl51kMEMQZC02wSvD6X4++GK+NdV0nWbHxHrHhDxDpkNxaW+saILV5vss7QvPAUuoJ4irvbW
7bvL3gwgKyhnDcT8Q/2VtD+Iv9sW9x4u8YaVpWs+Gbfwpqen6fqSH7bawfajA8tzNFJdNKrXkrMf
O2y4CzLKjOrgHAfFn/iYeH/2kvHVx+98W/Df7R/wiGqn/W6J5Ph+y1AfZ+y+ZcXEpm4/0iMrDN5k
KJGv1VXmmp/AjSdauUe/1nWLq2vIYYvEdhut47bxQ0UaxpJqEaQqCxVFVxB5KzRhYZllgRIl9LoA
KKKKAPKtR/4oH9oLSLqL/R9F8e2U1hdr/A+s2kYmtWRF6SzWS34lmcEFNNtI9yFUWT1WvKvHf/FV
fHb4Z6Db/wDMufbvF17cR/vPJ/0WXTba3lUf6vz/AO0LuVHY/N/Z0yqrfM0fqtABRRRQAUUUUAFF
FFABRRRQAUV5pq37QPhVNVvdE8LtcfEXxPZzPbXWheEDFdzWcqMQ8d3M0iW9kw2yYW6liLmKRY97
rsqr/wAJX8X/ABD82leAPD/hewuf3cdx4p8RNJqNl/CZZbGzglgl2nLrEl8vmLtBkhZmCAHqtFeV
f8I58b/+ih/D/wD8IO+/+XNH/Cm/F3/RdviB/wCAPh7/AOVVAB/yb/8A9kq/9RT/AO9v/pH/ANen
/Hl6VpOrWOv6VZanpl7b6jpt7Clza3lpKssM8TqGSRHUkMrKQQwJBBBFea/8IZ8X9K/0XSvih4f1
Cwj/ANXc+KfBzXeovnk+bLZ31nA2CSF2W8eFCg7mDO3mmrfCr4++DNVvdR+H+r+B59SvpnvLpbu5
1DTdDnlkYlw+kst6Ubc00xmtLu0Mss5aaOXZmQA+oKK+X5P2wfEvws0q3m+NHwg8UeDbMzSpJ4ps
HsLvSI7WJY83d0Y7uQ2TOznZa7p3ZtscL3MhCn0DSf2uvhHqWlWWp3XjO38Mabfwpc6feeL7W40C
HUYmUMJLR7+OEXKhWQloS4USRlsb1yAewUVxXgr43/Dr4larLpnhDx94X8ValFCbmSz0TWba8mSI
MqmQpG7EKGdBuxjLAdxXVatq1joGlXup6ne2+nabZQvc3V5dyrFDBEilnkd2ICqqgksSAACTQBbo
ryr/AIax+CH/AEWT4f8A/hUWP/x2uU0j9tjwJ441270D4faP4w+I3iTT702Op6Ro/h6ezfS3CzMT
dzagLaCDmCRNryBy/wAqqTnAB9AVxXjX4oWPhvVYvDWki31/x7eQiex8NRXSxzGIsy/arggMbe0V
lbfcMpGRsRZZnjik8f8AEdz+1F8SrxV0HTvB/wAIfC135kDS6jfnUvEtntmkEd0ESGWxO5BC7W26
TKl0FxEziSLoPBXwg+K3w+0qWw0Xx54HVJ5jc3FzfeENUvbu6lKqvmT3M+uPLMwRI0DSOxVI40GF
RQAD0rwL4F/4RX7dqWpX39ueK9V2NqmstF5XnbN3lwQx7m8m2i3uI4Qzbd7u7SSyzSydXXlX/Cm/
F3/RdviB/wCAPh7/AOVVH/CGfF/Sv9F0r4oeH9QsI/8AV3Pinwc13qL55Pmy2d9ZwNgkhdlvHhQo
O5gzsAeq0V5V9p+N+hf6P/Z3w/8AHG795/aH2++8N+X28r7N5Oob8Y3eb5y537fLGzc5/wANCafo
H7zx/wCF/EHwtsG/1eq+KRZtpxx1828s7i4gteSir9peHzGkVY/MbcAAeq0VU0nVrHX9KstT0y9t
9R029hS5tby0lWWGeJ1DJIjqSGVlIIYEgggirdABRRRQBk+KfFOl+C9CutY1i6+yWFvtDMsbSu7u
wSOKONAXlld2REjQM7u6qqszAHgP+Ff658Wf9K+IjfYfDcn7y18D2MrxYU8FNVnimKX2UGGtlAtR
50sbi8CxTA8H/wDFyPix4p8RXn+laL4TvRoXh6I/vLf7UsGb/UInGFaXdctYHIZoTZXSK6m4njr1
WgCppOk2OgaVZaZpllb6dptlClta2dpEsUMESKFSNEUAKqqAAoAAAAFW6K+f/wBn34ma54n8batL
rc+/RfG9k/i3wmS7uJbCK5a0/dKWPkRGyOhXJicIxn1G6OMh44QD6Aorx/wh+074d8X+GfEnitdA
8UaL4K8PQ6nLqPiLW9LNnDE1jPJHcRi3dvtTsFiaTKwFQAY2ZZ0eFanw0/aw8J/FjQvEt54dsNQ1
PU9C+zefoml3NhqtxL9pZo7bZLY3U9su+SORT5kyeUEMk3lRESEA9rorzTwn4/tPj14N8QQeH9W1
jwVrGl6m+jambY6fc32k3sJjkkgLYu7R2MboG2mTb5jIdkqMqH7MmrX2v/s2/CjU9TvbjUdSvfCW
k3N1eXcrSzTyvZxM8juxJZmYkliSSSSaAPS6801b4MQ6Tqt74g+Hl5b+BvE15M9xd4tpLjSNRkkY
maW709JoUlnckN9pRo7jdHGGlaIPE/pdFAHmkdt4V+OmlXHhr4geDNHvtY0WaKfUPDWu2sWow20r
LIsV1AZY8SwSL53lXAVSQJUZY5Y5oo8rU/gb8CvhZbJ4sl+GPgfQ30qaG4t76y8MWv2mO48xRALc
RQmRp2lMaxpGDI0jIqAsQDq/HnSb628G3PjPw7ZXF14y8JQyappsVhEz3OoRIUludMUKCWW8jh8n
BVwshhmVGkgiIyvhzq1j8Z/iJrnjWC9t9b8J6BNHpfhSe1lW5sZ5TbB73U7eZDskZjdGxyN5i+xX
Kq6/aJ46ALf/AAr/AFz4s/6V8RG+w+G5P3lr4HsZXiwp4KarPFMUvsoMNbKBajzpY3F4FimHpWk6
TY6BpVlpmmWVvp2m2UKW1rZ2kSxQwRIoVI0RQAqqoACgAAAAVbooAKK+f/2ffiZrnifxtq0utz79
F8b2T+LfCZLu4lsIrlrT90pY+REbI6FcmJwjGfUbo4yHjh6Dwh+074d8X+GfEnitdA8UaL4K8PQ6
nLqPiLW9LNnDE1jPJHcRi3dvtTsFiaTKwFQAY2ZZ0eFQD2CivFPhp+1h4T+LGheJbzw7Yahqep6F
9m8/RNLubDVbiX7SzR22yWxup7Zd8kcinzJk8oIZJvKiIkNvTPEVj+0x4ee303VtY8LW+heIJtN8
U6NbXqw33mw27H7Cb2wuSIWWSa0nZ7edj+7aCTBaZFAPYKK80+BGrX2reHtZIvbjWPCdvqbQ+Fda
vJWmn1LS/s8DLM0rHdMona5ijnYbpoYYZS83mefL6XQB5pq3wYh0nVb3xB8PLy38DeJryZ7i7xbS
XGkajJIxM0t3p6TQpLO5Ib7SjR3G6OMNK0QeJ+g8C+Ov+Eq+3abqVj/YfivSti6pozS+b5O/d5c8
Mm1fOtpdjmOYKu7Y6OscsU0UfV15p8edJvrbwbc+M/DtlcXXjLwlDJqmmxWETPc6hEhSW50xQoJZ
byOHycFXCyGGZUaSCIgA9Loryr/hrH4If9Fk+H//AIVFj/8AHaKAD9nz/iVad478MS/Nf6D4z1j7
TInMT/b7g6vDsJ5O231OBGyBiRJANyhXb1WvP/GPhbVNE8VP498K2v8AaOtGyh0/VtFaRU/teyhe
WSJIZHIWG5ia4uGjLMscnmvHKVDRz23VeFvFOl+NNCtdY0e6+12FxuCs0bROjoxSSKSNwHilR1dH
jcK6OjKyqykAAwPjF4T8VeOvAGqaB4Q8V2/gvUtRhltJNalsJbua3ikidC9v5dzAYp1ZkdJdzBSn
3DkEeaT/ALLf/CL6j4N1v4Yp8P8A4a+JNJ8xtYvdK8EeXFrW+3aIwMkF5A6229zN5LyS/vIrZt2Y
sv8AQFFAHj/hT4D30fwS8Z/Dnxj4jt9bt/FE2ttcX+h6a2mtDFqk0806Iks1wNyyXU+xicbfLBVi
pZzxX8J/Hvj34d69oXiDx9o8+pajNY+X9j8NPDpS28Fyk00E9o148twt0geCZWuRG0TKojX94ZfY
KKAPH/hB8FfEXwj0/wAdQW3inR719fmgvtOjj8OC0ttJuI9PgsxEsEVwA9oi2luIoQUkSNCjzSsf
Nrq/gp4BvvhV8I/CHgvUNWt9duPD2mQaUuo21k1ms8UCCOJjE0spVvLVAx3kFgxAUEKO1ooAK80/
ab1a+0D9m34r6npl7cadqVl4S1a5tby0laKaCVLOVkkR1IKsrAEMCCCARXpdef8A7QvhbVPHPwC+
JfhvRLX7brWseGdT0+xtvMWPzp5bWSONNzkKuWYDLEAZ5IFAHzB8EP2Or74lfBfwD4v1P9oj48Qa
lr/h/T9VuorTxuywpLPbRyuqBoWIUM5ABJOMZJ61k/Eb9g6x/Z8/Z58a6n4I+N/xo0a38LeH9S1X
TtJtvFqwWKSxQy3AUxRQIArSAlgpUncxyCc1b/Z++O37ROifA7wHo+i/su/8JDpWj6La6TbawvxB
063TUEto1gFzGrIcxSeXvR1LI6MrI7oysbfxM+Mn7R/xi+GnxB8C2n7MFvbXGp6Zd+H7y4h+JWlX
DadLc2nHmRhQdwjuI5NhKkq6HIDA0AfSn7MmrX2v/s2/CjU9TvbjUdSvfCWk3N1eXcrSzTyvZxM8
juxJZmYkliSSSSa1vjF4T8VeOvAGqaB4Q8V2/gvUtRhltJNalsJbua3ikidC9v5dzAYp1ZkdJdzB
Sn3DkEc/+yj+6/Zl+FVo/wAl3p/hnT9NvIG4e2ure3SC4t5F6pLFNHJG6HDI6MrAEEV6rQB8/wA/
7Lf/AAi+o+Ddb+GKfD/4a+JNJ8xtYvdK8EeXFrW+3aIwMkF5A6229zN5LyS/vIrZt2Ysv0HhT4D3
0fwS8Z/Dnxj4jt9bt/FE2ttcX+h6a2mtDFqk0806Iks1wNyyXU+xicbfLBVipZ/YKKAPH/Ffwn8e
+Pfh3r2heIPH2jz6lqM1j5f2Pw08OlLbwXKTTQT2jXjy3C3SB4Jla5EbRMqiNf3hl4q0/ZX8X6V4
a8R6HY+P/D40rXdas9VutKn8HlbB4ItNispNMMEF7Dmx/wBGtDHEGBEcJhna6SWQt9K0UAcp8PdF
8X6NZ6ofGfijT/FF/dXvn2zaXo50y3s4PJiQQJG087t86SSF3kY5mIGFVQOroooAK5/4heNbH4a+
APEvi/U4rifTdA0y51W6itFVpnigiaV1QMygsVQgAkDOMkda6CvKk/4v3eWF2nyfDXT7221KznXh
/EN1bzJPb3EbdUsYpo45EcYa6dFZSLYA3gB+Vf8Aw5U+N/8A0NPw/wD/AAY33/yHRX7U0UAFef8A
in4R295rt14o8J6h/wAIR4zudpu9XsLOGRNWCKFii1GFl/0mJdiAMGjnRN6QzwiSTd6BRQB5V/ws
fxx4F/5HvwX/AGhpSfu/+Eh8CmfU/u/L5s+m+ULqHzWKbYrb7bs3P5kipH5r2tJ/aU+F2rarZaQ3
jnR9J8Q3cyW0Xh3Xp/7L1fzXYLHG1hdeXcIz5UorRguroy5DKT6XVTVtJsdf0q90zU7K31HTb2F7
a6s7uJZYZ4nUq8bowIZWUkFSCCCQaALdFeVf8MnfBD/ojfw//wDCXsf/AI1R/wAM0+Ef+gv8QP8A
w4/iH/5OoA9VrivGvxv+HXw11WLTPF/j7wv4V1KWEXMdnres21nM8RZlEgSR1JUsjjdjGVI7Guf/
AOGVfhBc/vNV+HXh/wAUX7f6zVfFNmus6jP6ebeXnmzy7RhV3u21VVRhVUDtfBXw98K/DXSpdM8I
eGdH8K6bLMbmSz0Swis4XlKqpkKRqoLFUQbsZwoHYUAcV/wu3UPFf+i+APAviDWr/wD5aXPinTrz
wzp1r3Hmy3luJ33BXC/Zre4wwUSeUrq9H/Co9U+Iv734r6hp/iPTH+ceB7KzU6FGeqfaPNVpb+WM
swDyGOBisUotIpY1ceq0UAFfhX+338VfF/wb/wCCivxF8SeCfEeoeGdah/sofadPmKeag0+yk8qV
fuyxFo0LRuGRto3KRX7qV8K/Ef8A4Jj6X8ef2vfG3xR+Ius+b4Mv/wCzn03QdHnaO4unhtoIplu5
Cg8uI+Qy7YW3sJciSIphgDzX9hP9ov4k/tSeJri5m8F3HhfxMkLLqHxZ8NabCmm6tJbQW6xWmtW0
qhLpidpzbyR3EaybIBbxPNJX2/8A8LH8ceBf+R78F/2hpSfu/wDhIfApn1P7vy+bPpvlC6h81im2
K2+27Nz+ZIqR+a/z/wDsqX2qfsl/GW8/Zj8Ty6heeEL7ztT+GOu3OnqPtsGJLm/s5pojtMsLMzAs
ik4kY7Flt46+1aAPNNJ/aU+F2rarZaQ3jnR9J8Q3cyW0Xh3Xp/7L1fzXYLHG1hdeXcIz5UorRgur
oy5DKT6XVTVtJsdf0q90zU7K31HTb2F7a6s7uJZYZ4nUq8bowIZWUkFSCCCQa81/4ZO+CH/RG/h/
/wCEvY//ABqgD1WivKv+GafCP/QX+IH/AIcfxD/8nUf8Mq/CC5/ear8OvD/ii/b/AFmq+KbNdZ1G
f0828vPNnl2jCrvdtqqqjCqoAB0HjX43/Dr4a6rFpni/x94X8K6lLCLmOz1vWbazmeIsyiQJI6kq
WRxuxjKkdjXP/wDC7dQ8V/6L4A8C+INav/8Alpc+KdOvPDOnWvcebLeW4nfcFcL9mt7jDBRJ5Sur
12vgr4e+FfhrpUumeEPDOj+FdNlmNzJZ6JYRWcLylVUyFI1UFiqIN2M4UDsK6CgDyr/hUeqfEX97
8V9Q0/xHpj/OPA9lZqdCjPVPtHmq0t/LGWYB5DHAxWKUWkUsauPVaKKACiiigAooooAKKKKACiii
gAooooAKKKKACiiigDwr9sH9meH9pb4X/YdMubfQviDokyal4V8Tt5kc2l3qOj/LLEQ6LIIwjEbt
p2SBGaJBXoHwX13xr4l+F/h/UfiN4Zt/B/jaWFl1TR7S7S6hilV2TejozDbIqrIF3MUEgUsxUklF
AHa0UUUAFFFFABRRRQAUUUUAFFFFAH//2Q==

--0__=4DBBFBF1DFB252DF8f9e8a93df938690918c4DBBFBF1DFB252DF
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--0__=4DBBFBF1DFB252DF8f9e8a93df938690918c4DBBFBF1DFB252DF--





From ospf-bounces@ietf.org Tue May 02 09:07:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fauak-0002d5-T6; Tue, 02 May 2006 09:07:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fauaj-0002d0-Nm
	for ospf@ietf.org; Tue, 02 May 2006 09:07:01 -0400
Received: from coconut.sycamorenet.com ([12.146.0.143]
	helo=bristol.sycamorenet.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fauai-0002ex-Fl
	for ospf@ietf.org; Tue, 02 May 2006 09:07:01 -0400
Received: by bristol.sycamorenet.com with Internet Mail Service (5.5.2658.3)
	id <JWS6VVWS>; Tue, 2 May 2006 09:07:00 -0400
Message-ID: <0679BA70A2F59E49B186858B47F4595C0873ED@viper.sycamorenet.com>
From: "Pandian, Vijay" <Vijay.Pandian@sycamorenet.com>
To: 'Dave Katz' <dkatz@juniper.net>
Subject: RE: [OSPF] Correlating unnumbered point-to-point interfaces in OS PFv2
Date: Tue, 2 May 2006 09:06:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2658.3)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Dave,

Thanks for the response and the suggestions.

The reason behind the question is to address an issue in the route
calculation by R1. It is possible that R1 would use L1 in its forwarding
table when R2 is the next-hop. Thus we end up in a black-hole up until the
dead timer expires.

Looks like this has been a known issue (response from Alia Atlas) and BFD or
a more aggressive dead timer probably are the only solutions.

Best regards,

Vijay

> -----Original Message-----
> From: Dave Katz [mailto:dkatz@juniper.net]
> Sent: Monday, May 01, 2006 2:33 PM
> To: Pandian, Vijay
> Cc: ospf@ietf.org
> Subject: Re: [OSPF] Correlating unnumbered point-to-point 
> interfaces in
> OSPFv2
> 
> 
> 
> On May 1, 2006, at 9:17 AM, Pandian, Vijay wrote:
> 
> > Hi,
> >
> > Assume there are two routers, R1 and R2, connected by two unnumbered
> > point-to-point interfaces, say L1 and L2. Assume also that the OSPF
> > adjacency is established over these two links and are 
> listed in the  
> > Router
> > LSA's originated by R1 and R2.
> >
> > At a later point in time, L1 experiences a unidirectional failure  
> > such that
> > R2 detects the failure but not R1. R2 now re-originates its Router  
> > LSA with
> > L1 removed from the list of links.
> >
> > When R1 receives the new Router LSA from R2, how would it realize  
> > that L1 is
> > down - before the RouterDeadInterval. Since both routers advertise  
> > only
> > their local MIB-II IfIndex value in the  Link Data filed, 
> how would  
> > each
> > routers correlate the interfaces.
> 
> In general, you're hosed until the adjacency is seen as being 
> down on  
> both sides.  This is inherent to the protocol.  There is an  
> assumption that a failure will cause a bidirectional adjacency  
> failure in an acceptable amount of time.  If waiting for the dead  
> timer to expire is too long, then you need a shorter dead timer (or  
> use BFD.)
> 
> Your question implies that you're trying to divine adjacency 
> state by  
> looking at the LSA database;  if so, this is a bad idea, since the  
> database may not be up to date and may be in flux.
> 
> --Dave
> 

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



From ospf-bounces@ietf.org Tue May 02 09:42:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fav9F-0004aF-WD; Tue, 02 May 2006 09:42:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fav9F-0004a7-17
	for ospf@ietf.org; Tue, 02 May 2006 09:42:41 -0400
Received: from [203.199.83.248] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fav9D-0004Ie-6T
	for ospf@ietf.org; Tue, 02 May 2006 09:42:41 -0400
Received: (qmail 5881 invoked by uid 510); 2 May 2006 13:41:40 -0000
Date: 2 May 2006 13:41:39 -0000
Message-ID: <20060502134139.5880.qmail@webmail36.rediffmail.com>
Received: from unknown (203.126.136.220) by rediffmail.com via HTTP;
	02 may 2006 13:41:39 -0000
MIME-Version: 1.0
From: "Vivek  Dubey" <vivek_ospf@rediffmail.com>
To: ospf@ietf.org
X-Spam-Score: 2.7 (++)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Subject: [OSPF] draft-ietf-ospf-ospfv3-graceful-restart-03
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Vivek  Dubey <vivek_ospf@rediffmail.com>
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0975817661=="
Errors-To: ospf-bounces@ietf.org

 This is a multipart mime message


--===============0975817661==
Content-type: multipart/alternative;
	boundary="Next_1146577299---0-203.199.83.248-5874"

 This is a multipart mime message


--Next_1146577299---0-203.199.83.248-5874
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Section 3.2:=0AIf this were not the case, the pre-restart and post-restart =
LSAs wouldn't be the same and the restart would be disruptive.=0A=0A<vivek>=
 If "post-restart" here means "after router undergoing restart has exited/e=
xiting graceful-restart", it is supposed to reoriginate LSAs as per Section=
 2.3 RFC 3623. Description in Section 2.3 RFC 3623 does not mandate the con=
tents to be same. Than why do pre-restart and post-restart LSAs need to be =
same?=0A=0APreservation of Interface IDs have more to do with figuring out =
whether restarting router has re-established all its adjacencies.=0A=0A-Viv=
ek=0A=0A=0A =A0=0A
--Next_1146577299---0-203.199.83.248-5874
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0ASection 3.2:<BR>=0AIf this were not the case, the pre-restart and pos=
t-restart LSAs wouldn't be the same and the restart would be disruptive.<BR=
>=0A<BR>=0A&lt;vivek&gt; If &quot;post-restart&quot; here means &quot;after=
 router undergoing restart has exited/exiting graceful-restart&quot;, it is=
 supposed to reoriginate LSAs as per Section 2.3 RFC 3623. Description in S=
ection 2.3 RFC 3623 does not mandate the contents to be same. Than why do p=
re-restart and post-restart LSAs need to be same?<BR>=0A<BR>=0APreservation=
 of Interface IDs have more to do with figuring out whether restarting rout=
er has re-established all its adjacencies.<BR>=0A<BR>=0A-Vivek<BR>=0A<BR>=
=0A<BR>=0A&nbsp; <BR>=0A=0A</P>=0A<br><br>=0A<a href=3D"http://adworks.redi=
ff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature-home.htm/15071=
91490@Middle5?PARTNER=3D3"><IMG SRC=3D"http://adworks.rediff.com/cgi-bin/Ad=
Works/sigimpress.cgi/www.rediff.com/signature-home.htm/1963059423@Middle5?O=
AS_query=3Dnull&PARTNER=3D3" BORDER=3D0 VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1146577299---0-203.199.83.248-5874--



--===============0975817661==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0975817661==--





From ospf-bounces@ietf.org Tue May 02 10:58:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FawKu-00086Y-DY; Tue, 02 May 2006 10:58:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FawKt-00086T-8T
	for OSPF@IETF.ORG; Tue, 02 May 2006 10:58:47 -0400
Received: from omega7.wr.usgs.gov ([130.118.4.3] helo=ns0.wr.usgs.gov)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FawKr-0007KU-Vp
	for OSPF@IETF.ORG; Tue, 02 May 2006 10:58:47 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392)
	id <01M1XTLVPRVK001L5S@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Tue,
	02 May 2006 07:57:27 -0700 (PDT)
Date: Tue, 02 May 2006 07:57:27 -0700 (PDT)
From: "Pat Murphy - (650)329-4044" <pmurphy@noc.usgs.net>
Subject: Re: [OSPF] Re:Generating type5 LSA in ospfv3
To: OSPF@IETF.ORG
Message-id: <01M1XTLVPSTU001L5S@omega7.wr.usgs.gov>
X-VMS-To: ospf@ietf.org
X-VMS-Cc: PMURPHY,acee@cisco.com,badvel_vishnuvardhan@rediffmail.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: ACEE@CISCO.COM, BADVEL_VISHNUVARDHAN@REDIFFMAIL.COM
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Acee,

>I think that NSSA ABRs should either be precluded from installing an
>NSSA internal default (as they are when summaries are suppressed) or
>have them not advertise a type 7 default when an internal NSSA
>default is installed.

The first option would be problematic if folk are already using the 
feature of RFC 1587 and RFC 3101 that allows one to translate an NSSA 
type 7 default LSA for use by the full OSPF domain. As for the latter 
suggestion, a backup default is just too important to take away from 
an NSSA that uses an internal default; since, more often that not, the 
only backup default is the one originating from the NSSA border.

However yesterday evening I when I wrote 

>Clearly an NSSA ABR's self originated type 7 default LSA can be 
>configured, via metrics, as the NSSA's default path of last resort;

I realized that perhaps a default metric for the NSSA routers' self 
originated type 7 default LSAs was never defined. This seemed like an 
omission to me. I checked this morning and could not find one in RFC 
3101. Why not just add the following in an appropriate location:

  The default metric for any type 7 default LSA originated by any
  configured NSSA border router (regardless of its running ABR status)
  is type 2 and should have the largest possible reachable metric. The
  default metric for any type 7 default LSA originated by an NSSA
  non-border router is type 2 with a value of 1. 

I realize folk can configure around this. But if they do so it is done 
with intent and they must accept the risk. This would seem to 
accomplish what you want with minimal recoding effort. The type 2 
metric with a value of 1 seems consistent with what I have seen done 
by most implementations, so this change should just be a subtle twist 
of the spec. I could add it to another minor errata suggested sometime 
back. I actually plan to send the old errata to the working group in 
the next couple of weeks.  They are both very short and would seem 
appropriate as errata.

Pat


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



From ospf-bounces@ietf.org Tue May 02 12:59:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FayDY-0007Ta-GO; Tue, 02 May 2006 12:59:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FayDX-0007Q5-L7
	for ospf@ietf.org; Tue, 02 May 2006 12:59:19 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FayDW-0004BM-DX
	for ospf@ietf.org; Tue, 02 May 2006 12:59:19 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 02 May 2006 12:59:18 -0400
X-IronPort-AV: i="4.05,80,1146456000"; d="scan'208"; a="87707136:sNHT29442342"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k42GxDvH016580; 
	Tue, 2 May 2006 12:59:17 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 2 May 2006 12:59:13 -0400
Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 12:59:12 -0400
Message-ID: <44578FDF.7030705@cisco.com>
Date: Tue, 02 May 2006 12:59:11 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ilan.Bercovich@ecitele.com
Subject: Re: [OSPF] inter-area routes (section 16.2)
References: <OF6A7954EF.92E0BCD1-ONC2257162.0021D44F-C2257162.002276E6@ecitele.com>
In-Reply-To: <OF6A7954EF.92E0BCD1-ONC2257162.0021D44F-C2257162.002276E6@ecitele.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 May 2006 16:59:12.0940 (UTC)
	FILETIME=[BCE31EC0:01C66E09]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Ilan.Bercovich@ecitele.com wrote:

>In section 16.2: "If the router has active attachments to multiple areas,
>only backbone summary-LSAs are examined."
>
>What should happen in case of 2 areas without backbone?
>  
>
Hi Ilan,
RFC 2328 really doesn't handle this case but implementations I've seen
just pick one of the attached areas (preferring regular areas over 
stubs/NSSAs).
Implementations supporting RFC 3509 will examine the summaries from
all attached non-backbone areas. 

In general, you should design your backbone such that all ABRs are connected
to the backbone  and the backbone doesn't become partitioned.

Thanks,
Acee

>(Embedded image moved to file: pic26187.jpg)
>
>Regards,
>Ilan
>
>
> ------------------------------------------------------------------------
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>  
>

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



From ospf-bounces@ietf.org Tue May 02 20:07:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fb4tU-0004f6-Kj; Tue, 02 May 2006 20:07:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb4tS-0004f1-T0
	for ospf@ietf.org; Tue, 02 May 2006 20:07:02 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb4tR-0007Hm-H6
	for ospf@ietf.org; Tue, 02 May 2006 20:07:02 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 02 May 2006 17:07:01 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="27200640:sNHT24438568"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k43070vF014876; 
	Tue, 2 May 2006 20:07:00 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 2 May 2006 20:07:00 -0400
Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 20:07:00 -0400
Message-ID: <4457F423.4000708@cisco.com>
Date: Tue, 02 May 2006 20:06:59 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vivek Dubey <vivek_ospf@rediffmail.com>
Subject: Re: [OSPF] draft-ietf-ospf-ospfv3-graceful-restart-03
References: <20060502134139.5880.qmail@webmail36.rediffmail.com>
In-Reply-To: <20060502134139.5880.qmail@webmail36.rediffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 May 2006 00:07:00.0345 (UTC)
	FILETIME=[7FDA4E90:01C66E45]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Vivek,

Vivek Dubey wrote:

>Section 3.2:
>If this were not the case, the pre-restart and post-restart LSAs wouldn't be the same and the restart would be disruptive.
>
><vivek> If "post-restart" here means "after router undergoing restart has exited/exiting graceful-restart", it is supposed to reoriginate LSAs as per Section 2.3 RFC 3623. Description in Section 2.3 RFC 3623 does not mandate the contents to be same. Than why do pre-restart and post-restart LSAs need to be same?
>
>Preservation of Interface IDs have more to do with figuring out whether restarting router has re-established all its adjacencies.
>  
>
Since the interface ID is in the link data for OSPFv3 router LSAs, a 
change in interface ID
could result in a mismatch between neighbor adjacency state for the 
restarting router and
the pre-restart router LSA. Synchronizing the change across the 
restarting router and
the helping routers would be very difficult (if not next to impossible) 
and would probably
result in unreachability or premature graceful restart termination. It 
is much better for the
restarting router to preserve this state across restarts.

Hope this helps,
Acee

>-Vivek
>
>
>  
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>  
>

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



From ospf-bounces@ietf.org Wed May 03 00:00:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fb8Wm-0008GU-JH; Tue, 02 May 2006 23:59:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb8Wl-0008BL-59
	for ospf@ietf.org; Tue, 02 May 2006 23:59:51 -0400
Received: from [203.199.83.135] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fb8Wi-0008VW-4L
	for ospf@ietf.org; Tue, 02 May 2006 23:59:51 -0400
Received: (qmail 17007 invoked by uid 510); 3 May 2006 03:58:46 -0000
Date: 3 May 2006 03:58:46 -0000
Message-ID: <20060503035846.17006.qmail@webmail45.rediffmail.com>
Received: from unknown (203.126.136.220) by rediffmail.com via HTTP;
	03 may 2006 03:58:46 -0000
MIME-Version: 1.0
From: "Vivek  Dubey" <vivek_ospf@rediffmail.com>
To: "Acee Lindem" <acee@cisco.com>
Subject: Re: Re: [OSPF] draft-ietf-ospf-ospfv3-graceful-restart-03
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Vivek  Dubey <vivek_ospf@rediffmail.com>
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1580512786=="
Errors-To: ospf-bounces@ietf.org

 This is a multipart mime message


--===============1580512786==
Content-type: multipart/alternative;
	boundary="Next_1146628726---0-203.199.83.135-17001"

 This is a multipart mime message


--Next_1146628726---0-203.199.83.135-17001
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Acee,=0AI agree/understand the, reasons to keep Interface-Id same across re=
starts.=0ABut the current phrasing seems to imply that reason for preservin=
g Interface-Id is to keep "the pre-restart and post-restart LSAs same".=0A=
=0AThe phrasing used in explanation below is more clear.=0A=0AThanks=0AVive=
k=0A=0A=0AOn Wed, 03 May 2006 Acee Lindem wrote :=0A>Vivek,=0A>=0A>Vivek Du=
bey wrote:=0A>=0A>>Section 3.2:=0A>>If this were not the case, the pre-rest=
art and post-restart LSAs wouldn't be the same and the restart would be dis=
ruptive.=0A>>=0A>><vivek> If "post-restart" here means "after router underg=
oing restart has exited/exiting graceful-restart", it is supposed to reorig=
inate LSAs as per Section 2.3 RFC 3623. Description in Section 2.3 RFC 3623=
 does not mandate the contents to be same. Than why do pre-restart and post=
-restart LSAs need to be same?=0A>>=0A>>Preservation of Interface IDs have =
more to do with figuring out whether restarting router has re-established a=
ll its adjacencies.=0A>>  =0A>Since the interface ID is in the link data fo=
r OSPFv3 router LSAs, a change in interface ID=0A>could result in a mismatc=
h between neighbor adjacency state for the restarting router and=0A>the pre=
-restart router LSA. Synchronizing the change across the restarting router =
and=0A>the helping routers would be very difficult (if not next to impossib=
le) and would probably=0A>result in unreachability or premature graceful re=
start termination. It is much better for the=0A>restarting router to preser=
ve this state across restarts.=0A>=0A>Hope this helps,=0A>Acee=0A>=0A>>-Viv=
ek=0A>>=0A>>=0A>>  =0A>>  =0A>>--------------------------------------------=
----------------------------=0A>>=0A>>_____________________________________=
__________=0A>>OSPF mailing list=0A>>OSPF@ietf.org=0A>>https://www1.ietf.or=
g/mailman/listinfo/ospf=0A>>  =0A
--Next_1146628726---0-203.199.83.135-17001
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0AAcee,<BR>=0AI agree/understand the, reasons to keep Interface-Id same=
 across restarts.<BR>=0ABut the current phrasing seems to imply that reason=
 for preserving Interface-Id is to keep &quot;the pre-restart and post-rest=
art LSAs same&quot;.<BR>=0A<BR>=0AThe phrasing used in explanation below is=
 more clear.<BR>=0A<BR>=0AThanks<BR>=0AVivek<BR>=0A<BR>=0A<BR>=0AOn Wed, 03=
 May 2006 Acee Lindem wrote :<BR>=0A&gt;Vivek,<BR>=0A&gt;<BR>=0A&gt;Vivek D=
ubey wrote:<BR>=0A&gt;<BR>=0A&gt;&gt;Section 3.2:<BR>=0A&gt;&gt;If this wer=
e not the case, the pre-restart and post-restart LSAs wouldn't be the same =
and the restart would be disruptive.<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;&lt;vivek=
&gt; If &quot;post-restart&quot; here means &quot;after router undergoing r=
estart has exited/exiting graceful-restart&quot;, it is supposed to reorigi=
nate LSAs as per Section 2.3 RFC 3623. Description in Section 2.3 RFC 3623 =
does not mandate the contents to be same. Than why do pre-restart and post-=
restart LSAs need to be same?<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;Preservation of =
Interface IDs have more to do with figuring out whether restarting router h=
as re-established all its adjacencies.<BR>=0A&gt;&gt;&nbsp; <BR>=0A&gt;Sinc=
e the interface ID is in the link data for OSPFv3 router LSAs, a change in =
interface ID<BR>=0A&gt;could result in a mismatch between neighbor adjacenc=
y state for the restarting router and<BR>=0A&gt;the pre-restart router LSA.=
 Synchronizing the change across the restarting router and<BR>=0A&gt;the he=
lping routers would be very difficult (if not next to impossible) and would=
 probably<BR>=0A&gt;result in unreachability or premature graceful restart =
termination. It is much better for the<BR>=0A&gt;restarting router to prese=
rve this state across restarts.<BR>=0A&gt;<BR>=0A&gt;Hope this helps,<BR>=
=0A&gt;Acee<BR>=0A&gt;<BR>=0A&gt;&gt;-Vivek<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;<B=
R>=0A&gt;&gt;&nbsp; <BR>=0A&gt;&gt;&nbsp; <BR>=0A&gt;&gt;------------------=
------------------------------------------------------<BR>=0A&gt;&gt;<BR>=
=0A&gt;&gt;_______________________________________________<BR>=0A&gt;&gt;OS=
PF mailing list<BR>=0A&gt;&gt;OSPF@ietf.org<BR>=0A&gt;&gt;https://www1.ietf=
.org/mailman/listinfo/ospf<BR>=0A&gt;&gt;&nbsp; <BR>=0A=0A</P>=0A<br><br>=
=0A<a href=3D"http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.re=
diff.com/signature-home.htm/1507191490@Middle5?PARTNER=3D3"><IMG SRC=3D"htt=
p://adworks.rediff.com/cgi-bin/AdWorks/sigimpress.cgi/www.rediff.com/signat=
ure-home.htm/1963059423@Middle5?OAS_query=3Dnull&PARTNER=3D3" BORDER=3D0 VS=
PACE=3D0 HSPACE=3D0></a>=0A
--Next_1146628726---0-203.199.83.135-17001--



--===============1580512786==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1580512786==--





From ospf-bounces@ietf.org Thu May 04 18:01:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FblsL-0000lI-Rq; Thu, 04 May 2006 18:00:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FblsK-0000lD-Hr
	for ospf@ietf.org; Thu, 04 May 2006 18:00:44 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FblsK-0000pk-7d
	for ospf@ietf.org; Thu, 04 May 2006 18:00:44 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-4.cisco.com with ESMTP; 04 May 2006 15:00:43 -0700
X-IronPort-AV: i="4.05,89,1146466800"; 
	d="scan'208"; a="1801551533:sNHT26817012"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k44M08ZG022640;
	Thu, 4 May 2006 15:00:43 -0700 (PDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 4 May 2006 18:00:38 -0400
Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 18:00:37 -0400
Message-ID: <445A7985.80408@cisco.com>
Date: Thu, 04 May 2006 18:00:37 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vivek Dubey <vivek_ospf@rediffmail.com>
Subject: Re: [OSPF] draft-ietf-ospf-ospfv3-graceful-restart-03
References: <20060503035846.17006.qmail@webmail45.rediffmail.com>
In-Reply-To: <20060503035846.17006.qmail@webmail45.rediffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 May 2006 22:00:38.0041 (UTC)
	FILETIME=[2D460890:01C66FC6]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Vivek,

Ok - if I explain the problem in section 2.3 as I did below (only more
elegantly :^), will that eliminate your concern? Since, heretofore, this 
is are
only WG Last Call comment, I'm compelled to address it.

Thanks,
Acee

Vivek Dubey wrote:

>Acee,
>I agree/understand the, reasons to keep Interface-Id same across restarts.
>But the current phrasing seems to imply that reason for preserving Interface-Id is to keep "the pre-restart and post-restart LSAs same".
>
>The phrasing used in explanation below is more clear.
>
>Thanks
>Vivek
>
>
>On Wed, 03 May 2006 Acee Lindem wrote :
>  
>
>>Vivek,
>>
>>Vivek Dubey wrote:
>>
>>    
>>
>>>Section 3.2:
>>>If this were not the case, the pre-restart and post-restart LSAs wouldn't be the same and the restart would be disruptive.
>>>
>>><vivek> If "post-restart" here means "after router undergoing restart has exited/exiting graceful-restart", it is supposed to reoriginate LSAs as per Section 2.3 RFC 3623. Description in Section 2.3 RFC 3623 does not mandate the contents to be same. Than why do pre-restart and post-restart LSAs need to be same?
>>>
>>>Preservation of Interface IDs have more to do with figuring out whether restarting router has re-established all its adjacencies.
>>> 
>>>      
>>>
>>Since the interface ID is in the link data for OSPFv3 router LSAs, a change in interface ID
>>could result in a mismatch between neighbor adjacency state for the restarting router and
>>the pre-restart router LSA. Synchronizing the change across the restarting router and
>>the helping routers would be very difficult (if not next to impossible) and would probably
>>result in unreachability or premature graceful restart termination. It is much better for the
>>restarting router to preserve this state across restarts.
>>
>>Hope this helps,
>>Acee
>>
>>    
>>
>>>-Vivek
>>>
>>>
>>> 
>>> 
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>OSPF mailing list
>>>OSPF@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/ospf
>>> 
>>>      
>>>
>
>  
>

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



From ospf-bounces@ietf.org Thu May 04 18:03:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fbluf-0000wH-Nf; Thu, 04 May 2006 18:03:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fblue-0000wC-BH
	for ospf@ietf.org; Thu, 04 May 2006 18:03:08 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fblud-0000uv-3M
	for ospf@ietf.org; Thu, 04 May 2006 18:03:08 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 04 May 2006 15:03:07 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="27382861:sNHT22126184"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k44M36TL005628
	for <ospf@ietf.org>; Thu, 4 May 2006 18:03:06 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 4 May 2006 18:03:06 -0400
Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 18:03:06 -0400
Message-ID: <445A7A19.7060901@cisco.com>
Date: Thu, 04 May 2006 18:03:05 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Acee Lindem <acee@cisco.com>
Subject: Re: [OSPF] OSPFv3 Graceful Restart
	-	draft-ietf-ospf-ospfv3-graceful-restart-03.txt
References: <4443B32E.7050501@cisco.com>
In-Reply-To: <4443B32E.7050501@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 May 2006 22:03:06.0352 (UTC)
	FILETIME=[85AC7F00:01C66FC6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: OSPF List <ospf@ietf.org>
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Acee Lindem wrote:

> As I indicated at the list OSPF WG meeting in Dallas, there are 2 
> implementations
> of this document and we plan to WG last call it. Hence, without 
> further ado, this
> is start of the WG Last Call for OSPFv3 Graceful Restart. All comments 
> should be
> received prior to 12:00 AM (EDT), May 2nd, 2006.

The WG Last Call has ended. I only received one comment from Vivek Dubey and
this will be addressed in the 04 version which will be submitted to the 
IESG.

Thanks,
Acee

>
> Thanks,
> Acee
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www1.ietf.org/mailman/listinfo/ospf
>

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



From ospf-bounces@ietf.org Fri May 05 09:37:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fc0V5-0007m1-1c; Fri, 05 May 2006 09:37:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0V4-0007iS-43
	for ospf@ietf.org; Fri, 05 May 2006 09:37:42 -0400
Received: from py-out-1112.google.com ([64.233.166.183])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0V3-0004QD-PQ
	for ospf@ietf.org; Fri, 05 May 2006 09:37:41 -0400
Received: by py-out-1112.google.com with SMTP id e30so786406pya
	for <ospf@ietf.org>; Fri, 05 May 2006 06:37:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=jGBretsETlVPnip3DWI/MgrQ1BlQsCnT1LqNtGRNTCQYJDJ1Cvx9pSlW6gLlHbEiYiSEksNtp5963tIU+SW8J7uk/Ugb3PyrnzoO4uaw1oKzYdQ1k3KI0O9NXkuL9CdOl224hBKX4WKXvb6ASeFn82y1i1oh2L/LANgUtI/p9s0=
Received: by 10.35.8.1 with SMTP id l1mr241719pyi;
	Fri, 05 May 2006 06:37:41 -0700 (PDT)
Received: by 10.35.105.19 with HTTP; Fri, 5 May 2006 06:37:41 -0700 (PDT)
Message-ID: <96a9156a0605050637q52b8ad40g69d9241733698070@mail.gmail.com>
Date: Fri, 5 May 2006 15:37:41 +0200
From: "U. Nilrebmorf" <nilrebmorfunam@googlemail.com>
To: ospf@ietf.org
MIME-Version: 1.0
X-Spam-Score: 0.2 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Subject: [OSPF] transit traffic bypassing the designated router
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1723762638=="
Errors-To: ospf-bounces@ietf.org

--===============1723762638==
Content-Type: multipart/alternative; 
	boundary="----=_Part_84939_14097676.1146836261461"

------=_Part_84939_14097676.1146836261461
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi all,

I have a question about OSPFv2 and RFC 2328. In some cases, the adjacency
graph may not contain the shortest paths, especial in broadcast networks
with DR mechanisms. So it may be beneficial to forward transit traffic
bypassing the designated router. Does RFC 2328 allow such a thing: a router
to forward user traffic on a link that is not an adjacency?

Thanks for your precise response,
U. Nilrebmorf

------=_Part_84939_14097676.1146836261461
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi all,<br><br>I have a question about OSPFv2 and RFC 2328. In some cases, =
the adjacency graph may not contain the shortest paths, especial in broadca=
st networks with DR mechanisms. So it may be beneficial to forward transit =
traffic bypassing the designated router. Does RFC 2328 allow such a thing: =
a router to forward user traffic on a link that is not an adjacency?
<br><br>Thanks for your precise response,<br>U. Nilrebmorf<br>=20


------=_Part_84939_14097676.1146836261461--


--===============1723762638==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1723762638==--




From ospf-bounces@ietf.org Fri May 05 09:49:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fc0gU-0006gF-4s; Fri, 05 May 2006 09:49:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0gS-0006gA-MX
	for ospf@ietf.org; Fri, 05 May 2006 09:49:28 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0gR-0004ye-F1
	for ospf@ietf.org; Fri, 05 May 2006 09:49:28 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 05 May 2006 09:49:27 -0400
X-IronPort-AV: i="4.05,93,1146456000"; d="scan'208"; a="87959144:sNHT28691072"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k45DnRvF007401; 
	Fri, 5 May 2006 09:49:27 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 5 May 2006 09:49:27 -0400
Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 May 2006 09:49:26 -0400
Message-ID: <445B57E5.5040202@cisco.com>
Date: Fri, 05 May 2006 09:49:25 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "U. Nilrebmorf" <nilrebmorfunam@googlemail.com>
Subject: Re: [OSPF] transit traffic bypassing the designated router
References: <96a9156a0605050637q52b8ad40g69d9241733698070@mail.gmail.com>
In-Reply-To: <96a9156a0605050637q52b8ad40g69d9241733698070@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 May 2006 13:49:26.0843 (UTC)
	FILETIME=[B97BD8B0:01C6704A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

U. Nilrebmorf wrote:

> Hi all,
>
> I have a question about OSPFv2 and RFC 2328. In some cases, the adjacency
> graph may not contain the shortest paths, especial in broadcast networks
> with DR mechanisms. So it may be beneficial to forward transit traffic
> bypassing the designated router. Does RFC 2328 allow such a thing: a 
> router
> to forward user traffic on a link that is not an adjacency?

Hi U,
The short answer is "Yes". This is clearly stated in section 2.1 of RFC 
2328.
Thanks,
Acee

>
> Thanks for your precise response,
> U. Nilrebmorf
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>  
>

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



From ospf-bounces@ietf.org Mon May 08 01:16:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fcy4Y-0004qs-2A; Mon, 08 May 2006 01:14:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fcy4V-0004oG-Qt
	for ospf@ietf.org; Mon, 08 May 2006 01:14:15 -0400
Received: from [203.199.83.135] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fcy4Q-0003JI-Sm
	for ospf@ietf.org; Mon, 08 May 2006 01:14:15 -0400
Received: (qmail 8929 invoked by uid 510); 8 May 2006 05:13:09 -0000
Date: 8 May 2006 05:13:09 -0000
Message-ID: <20060508051309.8928.qmail@webmail45.rediffmail.com>
Received: from unknown (203.126.136.220) by rediffmail.com via HTTP;
	08 may 2006 05:13:09 -0000
MIME-Version: 1.0
From: "Vivek  Dubey" <vivek_ospf@rediffmail.com>
To: "Acee Lindem" <acee@cisco.com>
Subject: Re: Re: [OSPF] draft-ietf-ospf-ospfv3-graceful-restart-03
X-Spam-Score: 1.2 (+)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Vivek  Dubey <vivek_ospf@rediffmail.com>
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1413650962=="
Errors-To: ospf-bounces@ietf.org

 This is a multipart mime message


--===============1413650962==
Content-type: multipart/alternative;
	boundary="Next_1147065189---0-203.199.83.135-8924"

 This is a multipart mime message


--Next_1147065189---0-203.199.83.135-8924
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Acee,=0AIt takes care of my concern.=0A=0AThanks=0AVivek=0A=0A=0A=0AOn F=
ri, 05 May 2006 Acee Lindem wrote :=0A>Hi Vivek,=0A>=0A>Ok - if I explain t=
he problem in section 2.3 as I did below (only more=0A>elegantly :^), will =
that eliminate your concern? Since, heretofore, this is are=0A>only WG Last=
 Call comment, I'm compelled to address it.=0A>=0A>Thanks,=0A>Acee=0A>=0A>V=
ivek Dubey wrote:=0A>=0A>>Acee,=0A>>I agree/understand the, reasons to keep=
 Interface-Id same across restarts.=0A>>But the current phrasing seems to i=
mply that reason for preserving Interface-Id is to keep "the pre-restart an=
d post-restart LSAs same".=0A>>=0A>>The phrasing used in explanation below =
is more clear.=0A>>=0A>>Thanks=0A>>Vivek=0A>>=0A>>=0A>>On Wed, 03 May 2006 =
Acee Lindem wrote :=0A>>  =0A>>>Vivek,=0A>>>=0A>>>Vivek Dubey wrote:=0A>>>=
=0A>>>    =0A>>>>Section 3.2:=0A>>>>If this were not the case, the pre-rest=
art and post-restart LSAs wouldn't be the same and the restart would be dis=
ruptive.=0A>>>>=0A>>>><vivek> If "post-restart" here means "after router un=
dergoing restart has exited/exiting graceful-restart", it is supposed to re=
originate LSAs as per Section 2.3 RFC 3623. Description in Section 2.3 RFC =
3623 does not mandate the contents to be same. Than why do pre-restart and =
post-restart LSAs need to be same?=0A>>>>=0A>>>>Preservation of Interface I=
Ds have more to do with figuring out whether restarting router has re-estab=
lished all its adjacencies.=0A>>>>=0A>>>>      =0A>>>Since the interface ID=
 is in the link data for OSPFv3 router LSAs, a change in interface ID=0A>>>=
could result in a mismatch between neighbor adjacency state for the restart=
ing router and=0A>>>the pre-restart router LSA. Synchronizing the change ac=
ross the restarting router and=0A>>>the helping routers would be very diffi=
cult (if not next to impossible) and would probably=0A>>>result in unreacha=
bility or premature graceful restart termination. It is much better for the=
=0A>>>restarting router to preserve this state across restarts.=0A>>>=0A>>>=
Hope this helps,=0A>>>Acee=0A>>>=0A>>>    =0A>>>>-Vivek=0A>>>>=0A>>>>=0A>>>=
>=0A>>>>=0A>>>>------------------------------------------------------------=
------------=0A>>>>=0A>>>>_______________________________________________=
=0A>>>>OSPF mailing list=0A>>>>OSPF@ietf.org=0A>>>>https://www1.ietf.org/ma=
ilman/listinfo/ospf=0A>>>>=0A>>>>      =0A>>=0A>>  =0A
--Next_1147065189---0-203.199.83.135-8924
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0AHi Acee,<BR>=0AIt takes care of my concern.<BR>=0A<BR>=0AThanks<BR>=
=0AVivek<BR>=0A<BR>=0A<BR>=0A<BR>=0AOn Fri, 05 May 2006 Acee Lindem wrote :=
<BR>=0A&gt;Hi Vivek,<BR>=0A&gt;<BR>=0A&gt;Ok - if I explain the problem in =
section 2.3 as I did below (only more<BR>=0A&gt;elegantly :^), will that el=
iminate your concern? Since, heretofore, this is are<BR>=0A&gt;only WG Last=
 Call comment, I'm compelled to address it.<BR>=0A&gt;<BR>=0A&gt;Thanks,<BR=
>=0A&gt;Acee<BR>=0A&gt;<BR>=0A&gt;Vivek Dubey wrote:<BR>=0A&gt;<BR>=0A&gt;&=
gt;Acee,<BR>=0A&gt;&gt;I agree/understand the, reasons to keep Interface-Id=
 same across restarts.<BR>=0A&gt;&gt;But the current phrasing seems to impl=
y that reason for preserving Interface-Id is to keep &quot;the pre-restart =
and post-restart LSAs same&quot;.<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;The phrasing=
 used in explanation below is more clear.<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;Than=
ks<BR>=0A&gt;&gt;Vivek<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;On Wed, =
03 May 2006 Acee Lindem wrote :<BR>=0A&gt;&gt;&nbsp; <BR>=0A&gt;&gt;&gt;Viv=
ek,<BR>=0A&gt;&gt;&gt;<BR>=0A&gt;&gt;&gt;Vivek Dubey wrote:<BR>=0A&gt;&gt;&=
gt;<BR>=0A&gt;&gt;&gt;&nbsp; &nbsp; <BR>=0A&gt;&gt;&gt;&gt;Section 3.2:<BR>=
=0A&gt;&gt;&gt;&gt;If this were not the case, the pre-restart and post-rest=
art LSAs wouldn't be the same and the restart would be disruptive.<BR>=0A&g=
t;&gt;&gt;&gt;<BR>=0A&gt;&gt;&gt;&gt;&lt;vivek&gt; If &quot;post-restart&qu=
ot; here means &quot;after router undergoing restart has exited/exiting gra=
ceful-restart&quot;, it is supposed to reoriginate LSAs as per Section 2.3 =
RFC 3623. Description in Section 2.3 RFC 3623 does not mandate the contents=
 to be same. Than why do pre-restart and post-restart LSAs need to be same?=
<BR>=0A&gt;&gt;&gt;&gt;<BR>=0A&gt;&gt;&gt;&gt;Preservation of Interface IDs=
 have more to do with figuring out whether restarting router has re-establi=
shed all its adjacencies.<BR>=0A&gt;&gt;&gt;&gt;<BR>=0A&gt;&gt;&gt;&gt;&nbs=
p; &nbsp; &nbsp; <BR>=0A&gt;&gt;&gt;Since the interface ID is in the link d=
ata for OSPFv3 router LSAs, a change in interface ID<BR>=0A&gt;&gt;&gt;coul=
d result in a mismatch between neighbor adjacency state for the restarting =
router and<BR>=0A&gt;&gt;&gt;the pre-restart router LSA. Synchronizing the =
change across the restarting router and<BR>=0A&gt;&gt;&gt;the helping route=
rs would be very difficult (if not next to impossible) and would probably<B=
R>=0A&gt;&gt;&gt;result in unreachability or premature graceful restart ter=
mination. It is much better for the<BR>=0A&gt;&gt;&gt;restarting router to =
preserve this state across restarts.<BR>=0A&gt;&gt;&gt;<BR>=0A&gt;&gt;&gt;H=
ope this helps,<BR>=0A&gt;&gt;&gt;Acee<BR>=0A&gt;&gt;&gt;<BR>=0A&gt;&gt;&gt=
;&nbsp; &nbsp; <BR>=0A&gt;&gt;&gt;&gt;-Vivek<BR>=0A&gt;&gt;&gt;&gt;<BR>=0A&=
gt;&gt;&gt;&gt;<BR>=0A&gt;&gt;&gt;&gt;<BR>=0A&gt;&gt;&gt;&gt;<BR>=0A&gt;&gt=
;&gt;&gt;------------------------------------------------------------------=
------<BR>=0A&gt;&gt;&gt;&gt;<BR>=0A&gt;&gt;&gt;&gt;_______________________=
________________________<BR>=0A&gt;&gt;&gt;&gt;OSPF mailing list<BR>=0A&gt;=
&gt;&gt;&gt;OSPF@ietf.org<BR>=0A&gt;&gt;&gt;&gt;https://www1.ietf.org/mailm=
an/listinfo/ospf<BR>=0A&gt;&gt;&gt;&gt;<BR>=0A&gt;&gt;&gt;&gt;&nbsp; &nbsp;=
 &nbsp; <BR>=0A&gt;&gt;<BR>=0A&gt;&gt;&nbsp; <BR>=0A=0A</P>=0A<br><br>=0A<a=
 href=3D"http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.=
com/signature-home.htm/1507191490@Middle5?PARTNER=3D3"><IMG SRC=3D"http://a=
dworks.rediff.com/cgi-bin/AdWorks/sigimpress.cgi/www.rediff.com/signature-h=
ome.htm/1963059423@Middle5?OAS_query=3Dnull&PARTNER=3D3" BORDER=3D0 VSPACE=
=3D0 HSPACE=3D0></a>=0A
--Next_1147065189---0-203.199.83.135-8924--



--===============1413650962==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1413650962==--





From ospf-bounces@ietf.org Wed May 10 09:30:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fdol3-0004JZ-9n; Wed, 10 May 2006 09:29:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdol2-0004Hj-Pq
	for ospf@ietf.org; Wed, 10 May 2006 09:29:40 -0400
Received: from motgate2.mot.com ([144.189.100.101])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdol1-0005Wz-Dw
	for ospf@ietf.org; Wed, 10 May 2006 09:29:40 -0400
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232])
	by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k4ADpRbJ028308
	for <ospf@ietf.org>; Wed, 10 May 2006 06:51:27 -0700 (MST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k4ADhQKV009538
	for <ospf@ietf.org>; Wed, 10 May 2006 08:43:28 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 10 May 2006 21:25:24 +0800
Message-ID: <D6831742F069304FB1924B4160A493519D55FD@ZMY16EXM66.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Unnumbered Interfaces in OSPF for IPv6
Thread-Index: AcZ0NTHKRbOhBtqoSY+2bG7e8QtTPw==
From: "Ramana Koppula-G20085" <ramanakumar@motorola.com>
To: <ospf@ietf.org>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Subject: [OSPF] Unnumbered Interfaces in OSPF for IPv6
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0735177779=="
Errors-To: ospf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0735177779==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C67435.C53B7FC3"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C67435.C53B7FC3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

hi all,

In section 2.5 of "draft-ietf-ospf-ospfv3-update-08.txt", there is some
assumption about link-local unicast addresses that OSPF makes:

"OSPF for IPv6 assumes that each router has been assigned link-local
unicast addresses on each of the router's attached physical links." Does
it mean that OSPF for IPv6 does not Unnumbered Interfaces. But in some
writings that I googled, i found that Unnumbered support is there in
OSPF for IPv6.

I have two doubts on this:

1) As we donot have shortage of addresses in IPv6, why should be support
Unnumbered interfaces in IPv6 at all?

2) If it is supported, how can we make OSPF for IPv6 assumption true?

thanx

ramana


------_=_NextPart_001_01C67435.C53B7FC3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<P><SPAN class=3D531561013-10052006><FONT face=3DArial size=3D2>hi=20
all,</FONT></SPAN></P>
<P><SPAN class=3D531561013-10052006><FONT face=3DArial size=3D2>In =
section 2.5 of=20
"<FONT size=3D2>draft-ietf-ospf-ospfv3-update-08.txt", there is some =
assumption=20
about link-local unicast addresses that OSPF =
makes:</P></FONT></FONT></SPAN>
<P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D531561013-10052006>"</SPAN>OSPF for=20
IPv6 assumes that each router has been assigned link-local<SPAN=20
class=3D531561013-10052006> </SPAN>unicast addresses on each of the =
router's=20
attached physical links.<SPAN class=3D531561013-10052006>" Does it mean =
that OSPF=20
for IPv6 does not Unnumbered Interfaces. But in some writings that I =
googled, i=20
found that Unnumbered support is there in OSPF for=20
IPv6.</SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2><SPAN class=3D531561013-10052006>I =
have two=20
doubts on this:</SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2><SPAN class=3D531561013-10052006>1) =
As&nbsp;we=20
donot have shortage of addresses in IPv6, why should be support =
Unnumbered=20
interfaces in IPv6 at all?</SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2><SPAN class=3D531561013-10052006>2) =
If it is=20
supported, how&nbsp;can we&nbsp;make OSPF for IPv6 assumption=20
true?</SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D531561013-10052006>thanx</SPAN></FONT></FONT></P>
<P><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D531561013-10052006></SPAN></FONT></FONT><FONT face=3DArial><FONT =

size=3D2><SPAN=20
class=3D531561013-10052006>ramana</SPAN></FONT></FONT></P></DIV></BODY></=
HTML>

------_=_NextPart_001_01C67435.C53B7FC3--


--===============0735177779==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0735177779==--




From ospf-bounces@ietf.org Wed May 10 11:04:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FdqE6-0004kC-Eh; Wed, 10 May 2006 11:03:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqDp-0004VB-Ks
	for ospf@ietf.org; Wed, 10 May 2006 11:03:29 -0400
Received: from motgate4.mot.com ([144.189.100.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdq0T-000113-3A
	for ospf@ietf.org; Wed, 10 May 2006 10:49:43 -0400
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232])
	by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k4AF3BJN016732
	for <ospf@ietf.org>; Wed, 10 May 2006 08:03:12 -0700 (MST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k4AF3UEi004991
	for <ospf@ietf.org>; Wed, 10 May 2006 10:03:31 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 10 May 2006 22:45:28 +0800
Message-ID: <D6831742F069304FB1924B4160A493519D562B@ZMY16EXM66.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Multiple Interfaces to a Single Link
Thread-Index: AcZ0QGEHjU8PD8WtQv2qMYG7nY41ig==
From: "Ramana Koppula-G20085" <ramanakumar@motorola.com>
To: <ospf@ietf.org>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
Subject: [OSPF] Multiple Interfaces to a Single Link
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0319252430=="
Errors-To: ospf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0319252430==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C67440.F48159B8"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C67440.F48159B8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,
=20
Statement 1) From section 3.2.2 of OSPF for IPv6, "Locally originated
packets SHOULD NOT be passed on to OSPF. That is, the source IPv6
address should be examined to make sure this is not a multicast packet
that the router itself generated." This is one of the checks that need
to be done before the packet is sent for OSPF processing."
=20
Statement 2) From section 3.9 of OSPF for IPv6, "This allows the router
to automatically detect that multiple router interfaces attach to the
same link, when a Hello packet is received with the router's link-local
address as the source address but with an Interface ID other than the
Interface ID for the receiving interface."
=20
Doesn't the above two statements conflict in the case of Multiple
Interfaces to the same broadcast link. And also first condition is
checked for at IPv6 level while the other is at OSPF level. If the first
statement is true, the packet would be dropped at the IP level and is
not passed to OSPF.
=20
I doubt the first statement if it should be re-written as "Locally
originated packets SHOULD NOT be passed on to OSPF. That is, the source
IPv6 address should be examined to make sure this is not a multicast
packet that the router itself generated from same interface" This is one
of the checks that need to be done before the packet is sent for OSPF
processing."
=20
thanx
ramana

------_=_NextPart_001_01C67440.F48159B8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTFrom ospf-bounces@ietf.org Wed May 10 11:04:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FdqE6-0004kC-Eh; Wed, 10 May 2006 11:03:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqDp-0004VB-Ks
	for ospf@ietf.org; Wed, 10 May 2006 11:03:29 -0400
Received: from motgate4.mot.com ([144.189.100.102])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdq0T-000113-3A
	for ospf@ietf.org; Wed, 10 May 2006 10:49:43 -0400
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232])
	by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k4AF3BJN016732
	for <ospf@ietf.org>; Wed, 10 May 2006 08:03:12 -0700 (MST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k4AF3UEi004991
	for <ospf@ietf.org>; Wed, 10 May 2006 10:03:31 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 10 May 2006 22:45:28 +0800
Message-ID: <D6831742F069304FB1924B4160A493519D562B@ZMY16EXM66.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Multiple Interfaces to a Single Link
Thread-Index: AcZ0QGEHjU8PD8WtQv2qMYG7nY41ig==
From: "Ramana Koppula-G20085" <ramanakumar@motorola.com>
To: <ospf@ietf.org>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
Subject: [OSPF] Multiple Interfaces to a Single Link
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0319252430=="
Errors-To: ospf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0319252430==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C67440.F48159B8"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C67440.F48159B8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,
=20
Statement 1) From section 3.2.2 of OSPF for IPv6, "Locally originated
packets SHOULD NOT be passed on to OSPF. That is, the source IPv6
address should be examined to make sure this is not a multicast packet
that the router itself generated." This is one of the checks that need
to be done before the packet is sent for OSPF processing."
=20
Statement 2) From section 3.9 of OSPF for IPv6, "This allows the router
to automatically detect that multiple router interfaces attach to the
same link, when a Hello packet is received with the router's link-local
address as the source address but with an Interface ID other than the
Interface ID for the receiving interface."
=20
Doesn't the above two statements conflict in the case of Multiple
Interfaces to the same broadcast link. And also first condition is
checked for at IPv6 level while the other is at OSPF level. If the first
statement is true, the packet would be dropped at the IP level and is
not passed to OSPF.
=20
I doubt the first statement if it should be re-written as "Locally
originated packets SHOULD NOT be passed on to OSPF. That is, the source
IPv6 address should be examined to make sure this is not a multicast
packet that the router itself generated from same interface" This is one
of the checks that need to be done before the packet is sent for OSPF
processing."
=20
thanx
ramana

------_=_NextPart_001_01C67440.F48159B8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006>Hi=20
all,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D359382914-10052006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D359382914-10052006>Statement 1)=20
</SPAN>From section 3.2.2 of OSPF for IPv6<SPAN=20
class=3D359382914-10052006>,</SPAN> "Locally originated packets SHOULD =
NOT be=20
passed on to OSPF. That is, the source IPv6 address should be examined =
to make=20
sure this is not a multicast packet that the router itself =
generated."<SPAN=20
class=3D359382914-10052006> This is one of the checks that need to be =
done before=20
the packet is sent for OSPF processing."</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D359382914-10052006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D359382914-10052006><FONT face=3DArial =
size=3D2>Statement 2) From=20
section 3.9 of OSPF for IPv6, "This allows the router to automatically =
detect=20
that multiple<SPAN class=3D359382914-10052006> </SPAN>router interfaces =
attach to=20
the same link, when a Hello packet is<SPAN class=3D359382914-10052006>=20
</SPAN>received with the router's link-local address as the source<SPAN=20
class=3D359382914-10052006> </SPAN>address but with an Interface ID =
other than the=20
Interface ID for<SPAN class=3D359382914-10052006> </SPAN>the receiving=20
interface."</FONT></DIV></SPAN>
<DIV><FONT size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006><FONT face=3DArial=20
size=3D2></FONT></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006><FONT face=3DArial size=3D2>Doesn't the above =
two=20
statements&nbsp;conflict in the case of Multiple Interfaces to the same=20
broadcast link. And also first condition is checked for at IPv6 level =
while the=20
other is at OSPF level. If the first statement is true, the packet would =
be=20
dropped at the IP level and is not passed to=20
OSPF.</FONT></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006>I doubt the first statement if it should be =
re-written=20
as "Locally originated packets SHOULD NOT be passed on to OSPF. That is, =
the=20
source IPv6 address should be examined to make sure this is not a =
multicast=20
packet that the router itself generated&nbsp;from =
same&nbsp;interface"<SPAN=20
class=3D359382914-10052006> This is one of the checks that need to be =
done before=20
the packet is sent for OSPF =
processing."</SPAN></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006></SPAN></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006>thanx</SPAN></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006>ramana</SPAN></SPAN></SPAN></FONT></DIV></BODY=
></HTML>

------_=_NextPart_001_01C67440.F48159B8--


--===============0319252430==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0319252430==--


From ospf-bounces@ietf.org Wed May 10 11:04:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FdqE4-0004eX-Rb; Wed, 10 May 2006 11:03:44 -0400
ReceivD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006>Hi=20
all,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D359382914-10052006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D359382914-10052006>Statement 1)=20
</SPAN>From section 3.2.2 of OSPF for IPv6<SPAN=20
class=3D359382914-10052006>,</SPAN> "Locally originated packets SHOULD =
NOT be=20
passed on to OSPF. That is, the source IPv6 address should be examined =
to make=20
sure this is not a multicast packet that the router itself =
generated."<SPAN=20
class=3D359382914-10052006> This is one of the checks that need to be =
done before=20
the packet is sent for OSPF processing."</SPAN></FONT></FONT></DIV>
<DIV><SPAN class=3D359382914-10052006><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D359382914-10052006><FONT face=3DArial =
size=3D2>Statement 2) From=20
section 3.9 of OSPF for IPv6, "This allows the router to automatically =
detect=20
that multiple<SPAN class=3D359382914-10052006> </SPAN>router interfaces =
attach to=20
the same link, when a Hello packet is<SPAN class=3D359382914-10052006>=20
</SPAN>received with the router's link-local address as the source<SPAN=20
class=3D359382914-10052006> </SPAN>address but with an Interface ID =
other than the=20
Interface ID for<SPAN class=3D359382914-10052006> </SPAN>the receiving=20
interface."</FONT></DIV></SPAN>
<DIV><FONT size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006><FONT face=3DArial=20
size=3D2></FONT></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006><FONT face=3DArial size=3D2>Doesn't the above =
two=20
statements&nbsp;conflict in the case of Multiple Interfaces to the same=20
broadcast link. And also first condition is checked for at IPv6 level =
while the=20
other is at OSPF level. If the first statement is true, the packet would =
be=20
dropped at the IP level and is not passed to=20
OSPF.</FONT></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006>I doubt the first statement if it should be =
re-written=20
as "Locally originated packets SHOULD NOT be passed on to OSPF. That is, =
the=20
source IPv6 address should be examined to make sure this is not a =
multicast=20
packet that the router itself generated&nbsp;from =
same&nbsp;interface"<SPAN=20
class=3D359382914-10052006> This is one of the checks that need to be =
done before=20
the packet is sent for OSPF =
processing."</SPAN></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006></SPAN></SPAN></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006>thanx</SPAN></SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006><SPAN=20
class=3D359382914-10052006>ramana</SPAN></SPAN></SPAN></FONT></DIV></BODY=
></HTML>

------_=_NextPart_001_01C67440.F48159B8--


--===============0319252430==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0319252430==--


From ospf-bounces@ietf.org Wed May 10 11:04:50 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FdqE4-0004eX-Rb; Wed, 10 May 2006 11:03:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqDp-0004VB-BQ
	for ospf@ietf.org; Wed, 10 May 2006 11:03:29 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdq1C-00012W-AU
	for ospf@ietf.org; Wed, 10 May 2006 10:50:28 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 10 May 2006 10:50:24 -0400
X-IronPort-AV: i="4.05,110,1146456000"; 
	d="scan'208"; a="88274167:sNHT30072896"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4AEoOvF027250; 
	Wed, 10 May 2006 10:50:24 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 10 May 2006 10:50:23 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 10 May 2006 10:50:23 -0400
Message-ID: <4461FDAE.9010808@cisco.com>
Date: Wed, 10 May 2006 10:50:22 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ramana Koppula-G20085 <ramanakumar@motorola.com>
Subject: Re: [OSPF] Unnumbered Interfaces in OSPF for IPv6
References: <D6831742F069304FB1924B4160A493519D55FD@ZMY16EXM66.ds.mot.com>
In-Reply-To: <D6831742F069304FB1924B4160A493519D55FD@ZMY16EXM66.ds.mot.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 May 2006 14:50:23.0617 (UTC)
	FILETIME=[11280710:01C67441]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Ramana,

Ramana Koppula-G20085 wrote:

>hi all,
>
>In section 2.5 of "draft-ietf-ospf-ospfv3-update-08.txt", there is some
>assumption about link-local unicast addresses that OSPF makes:
>
>"OSPF for IPv6 assumes that each router has been assigned link-local
>unicast addresses on each of the router's attached physical links." Does
>it mean that OSPF for IPv6 does not Unnumbered Interfaces. But in some
>writings that I googled, i found that Unnumbered support is there in
>OSPF for IPv6.
>  
>
While some implementations have chosen to support configuration, IMHO 
there should be
not be the concept of an unnumbered link in IPv6. Hence, you have 
interfaces with global
addresses and interfaces without global addresses. Every IPv6 interface 
should have a
link-local address.

>I have two doubts on this:
>
>1) As we donot have shortage of addresses in IPv6, why should be support
>Unnumbered interfaces in IPv6 at all?
>  
>
We shouldn't - see above.

>2) If it is supported, how can we make OSPF for IPv6 assumption true?
>  
>
That's an implementation problem.

Hope this helps,
Acee
P.S. There is only one reference to "an unnumbered point-to-point link" in
draft-ietf-ospf-ospfv3-update-08.txt. I'll change this to "a 
point-to-point link
with no global IPv6 addresses" to avoid confusion.

>thanx
>
>ramana
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>  
>

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





ed: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FdqDp-0004VB-BQ
	for ospf@ietf.org; Wed, 10 May 2006 11:03:29 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdq1C-00012W-AU
	for ospf@ietf.org; Wed, 10 May 2006 10:50:28 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 10 May 2006 10:50:24 -0400
X-IronPort-AV: i="4.05,110,1146456000"; 
	d="scan'208"; a="88274167:sNHT30072896"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4AEoOvF027250; 
	Wed, 10 May 2006 10:50:24 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 10 May 2006 10:50:23 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 10 May 2006 10:50:23 -0400
Message-ID: <4461FDAE.9010808@cisco.com>
Date: Wed, 10 May 2006 10:50:22 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ramana Koppula-G20085 <ramanakumar@motorola.com>
Subject: Re: [OSPF] Unnumbered Interfaces in OSPF for IPv6
References: <D6831742F069304FB1924B4160A493519D55FD@ZMY16EXM66.ds.mot.com>
In-Reply-To: <D6831742F069304FB1924B4160A493519D55FD@ZMY16EXM66.ds.mot.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 May 2006 14:50:23.0617 (UTC)
	FILETIME=[11280710:01C67441]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Ramana,

Ramana Koppula-G20085 wrote:

>hi all,
>
>In section 2.5 of "draft-ietf-ospf-ospfv3-update-08.txt", there is some
>assumption about link-local unicast addresses that OSPF makes:
>
>"OSPF for IPv6 assumes that each router has been assigned link-local
>unicast addresses on each of the router's attached physical links." Does
>it mean that OSPF for IPv6 does not Unnumbered Interfaces. But in some
>writings that I googled, i found that Unnumbered support is there in
>OSPF for IPv6.
>  
>
While some implementations have chosen to support configuration, IMHO 
there should be
not be the concept of an unnumbered link in IPv6. Hence, you have 
interfaces with global
addresses and interfaces without global addresses. Every IPv6 interface 
should have a
link-local address.

>I have two doubts on this:
>
>1) As we donot have shortage of addresses in IPv6, why should be support
>Unnumbered interfaces in IPv6 at all?
>  
>
We shouldn't - see above.

>2) If it is supported, how can we make OSPF for IPv6 assumption true?
>  
>
That's an implementation problem.

Hope this helps,
Acee
P.S. There is only one reference to "an unnumbered point-to-point link" in
draft-ietf-ospf-ospfv3-update-08.txt. I'll change this to "a 
point-to-point link
with no global IPv6 addresses" to avoid confusion.

>thanx
>
>ramana
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>  
>

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





From ospf-bounces@ietf.org Thu May 11 11:10:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeCmZ-0001Sa-ID; Thu, 11 May 2006 11:08:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCmX-0001SV-Vc
	for ospf@ietf.org; Thu, 11 May 2006 11:08:49 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FeCmW-0005y4-Ma
	for ospf@ietf.org; Thu, 11 May 2006 11:08:49 -0400
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-3.cisco.com with ESMTP; 11 May 2006 08:08:49 -0700
X-IronPort-AV: i="4.05,116,1146466800"; 
	d="scan'208"; a="427064114:sNHT27993300"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id k4BF8lES020951
	for <ospf@ietf.org>; Thu, 11 May 2006 08:08:47 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4BF8gsZ007215
	for <ospf@ietf.org>; Thu, 11 May 2006 08:08:47 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 11 May 2006 11:08:47 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 11 May 2006 11:08:46 -0400
Message-ID: <4463537E.2010909@cisco.com>
Date: Thu, 11 May 2006 11:08:46 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ospf@ietf.org
X-Priority: 3)
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 May 2006 15:08:46.0829 (UTC)
	FILETIME=[CD2291D0:01C6750C]
DKIM-Signature: a=rsa-sha1; q=dns; l=468; t=1147360128; x=1148224128;
	c=relaxed/simple; s=sjdkim5001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com>
	|Subject:draft-bryskin-ospf-lsa-type11-validation-00.txt=20-=20Resending=20to=20l
	ist=0A=20for=20Igor;
	X=v=3Dcisco.com=3B=20h=3DLDlRoVTmhfmbCS8M9MODukYdai4=3D;
	b=rxu/tfstCL3saTO28aByuy9ZcYwiN9GRHDpuqN2YAtMWUPQBSa3FD776rkbZlK/F+XASAta1
	36oe3EKRW7BD442zRviM3BUIyvRGOdPiCEoJEnFEKrWDdniAy3LZoLzP;
Authentication-Results: sj-dkim-5.cisco.com; header.From=acee@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Subject: [OSPF] draft-bryskin-ospf-lsa-type11-validation-00.txt - Resending
 to list for Igor
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Igor Bryskin <ibryskin@movaz.com>
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi,

This draft has been recently submitted. It is concerned with originating and processing of type-11 opaque LSAs. Currently there is 
no way for an OSPF speaker that receives a type-11 opaque LSA to check the availability of the LSA originator in case the latter 
is located in a remote OSPF area. The draft introduces simple procedures that would enable such check and, thus, protect from 
using of potentially stale information.

Igor (and Alex and Lou).

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



From ospf-bounces@ietf.org Fri May 12 01:07:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FePql-0004Wr-1H; Fri, 12 May 2006 01:06:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FePqj-0004Wm-Nh
	for ospf@ietf.org; Fri, 12 May 2006 01:06:01 -0400
Received: from [203.199.83.147] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FePqg-0003Ed-ES
	for ospf@ietf.org; Fri, 12 May 2006 01:06:01 -0400
Received: (qmail 23751 invoked by uid 510); 12 May 2006 05:04:54 -0000
Date: 12 May 2006 05:04:54 -0000
Message-ID: <20060512050454.23750.qmail@webmail25.rediffmail.com>
Received: from unknown (203.126.136.220) by rediffmail.com via HTTP;
	12 may 2006 05:04:54 -0000
MIME-Version: 1.0
From: "Vivek  Dubey" <vivek_ospf@rediffmail.com>
To: ospf@ietf.org
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Subject: [OSPF] Route Calculation: Ospf for Ipv6
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Vivek  Dubey <vivek_ospf@rediffmail.com>
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1643414487=="
Errors-To: ospf-bounces@ietf.org

 This is a multipart mime message


--===============1643414487==
Content-type: multipart/alternative;
	boundary="Next_1147410294---0-203.199.83.147-23744"

 This is a multipart mime message


--Next_1147410294---0-203.199.83.147-23744
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

draft-ietf-ospf-ospfv3-update-08:=0ASection 3.8.1:=0A- In Step 2b, if V is =
a router and the router LSA V6-bit or R-bit are not set in the LSA options,=
 the transit link W is ignored and V's next link is examined=0A=0A<vivek>=
=0AAre we referring to V's router LSA or W's router LSA?=0AIf V: Than it sh=
ould not be part of IPv6 calculation=0AIf W: Than we should rephrase =0A"In=
 Step 2b, if w is a router and the router LSA V6-bit or R-bit are not set i=
n the LSA options, the transit link W is ignored and V's next link is exami=
ned"=0A=0AThanks=0AVivek=0A
--Next_1147410294---0-203.199.83.147-23744
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0Adraft-ietf-ospf-ospfv3-update-08:<BR>=0ASection 3.8.1:<BR>=0A- In Ste=
p 2b, if V is a router and the router LSA V6-bit or R-bit are not set in th=
e LSA options, the transit link W is ignored and V's next link is examined<=
BR>=0A<BR>=0A&lt;vivek&gt;<BR>=0AAre we referring to V's router LSA or W's =
router LSA?<BR>=0AIf V: Than it should not be part of IPv6 calculation<BR>=
=0AIf W: Than we should rephrase <BR>=0A&quot;In Step 2b, if w is a router =
and the router LSA V6-bit or R-bit are not set in the LSA options, the tran=
sit link W is ignored and V's next link is examined&quot;<BR>=0A<BR>=0AThan=
ks<BR>=0AVivek<BR>=0A=0A</P>=0A<br><br>=0A<a href=3D"http://adworks.rediff.=
com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature-home.htm/15071914=
90@Middle5?PARTNER=3D3"><IMG SRC=3D"http://adworks.rediff.com/cgi-bin/AdWor=
ks/sigimpress.cgi/www.rediff.com/signature-home.htm/1963059423@Middle5?OAS_=
query=3Dnull&PARTNER=3D3" BORDER=3D0 VSPACE=3D0 HSPACE=3D0></a>=0A
--Next_1147410294---0-203.199.83.147-23744--



--===============1643414487==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1643414487==--





From ospf-bounces@ietf.org Fri May 12 11:30:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FeZYv-0000P6-FP; Fri, 12 May 2006 11:28:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FeZYu-0000P1-LN
	for ospf@ietf.org; Fri, 12 May 2006 11:28:16 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeXqt-0004Oc-C6
	for ospf@ietf.org; Fri, 12 May 2006 09:38:43 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FeXg8-0006EC-9Y
	for ospf@ietf.org; Fri, 12 May 2006 09:27:37 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 12 May 2006 06:27:34 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,122,1146466800"; 
	d="scan'208"; a="27892728:sNHT21115062"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4CDRXTN020444; 
	Fri, 12 May 2006 09:27:33 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 12 May 2006 09:27:33 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 12 May 2006 09:27:32 -0400
Message-ID: <44648D44.6070004@cisco.com>
Date: Fri, 12 May 2006 09:27:32 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vivek Dubey <vivek_ospf@rediffmail.com>
Subject: Re: [OSPF] Route Calculation: Ospf for Ipv6
References: <20060512050454.23750.qmail@webmail25.rediffmail.com>
In-Reply-To: <20060512050454.23750.qmail@webmail25.rediffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 May 2006 13:27:32.0777 (UTC)
	FILETIME=[D3218990:01C675C7]
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Vivek,

Vivek Dubey wrote:

>draft-ietf-ospf-ospfv3-update-08:
>Section 3.8.1:
>- In Step 2b, if V is a router and the router LSA V6-bit or R-bit are not set in the LSA options, the transit link W is ignored and V's next link is examined
>
><vivek>
>Are we referring to V's router LSA or W's router LSA?
>If V: Than it should not be part of IPv6 calculation
>If W: Than we should rephrase 
>"In Step 2b, if w is a router and the router LSA V6-bit or R-bit are not set in the LSA options, the transit link W is ignored and V's next link is examined"
>  
>
It should be W. I'll update in the 09 version. Thanks for catching this.

Acee

>Thanks
>Vivek
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>  
>

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



From ospf-bounces@ietf.org Fri May 12 16:06:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FedtR-0003U3-Vx; Fri, 12 May 2006 16:05:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FedtR-0003Tx-LA
	for ospf@ietf.org; Fri, 12 May 2006 16:05:45 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FedtR-0007fh-Cn
	for ospf@ietf.org; Fri, 12 May 2006 16:05:45 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-2.cisco.com with ESMTP; 12 May 2006 16:05:43 -0400
X-IronPort-AV: i="4.05,122,1146456000"; 
	d="scan'208"; a="88470127:sNHT30826748"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4CK5hTL018551; 
	Fri, 12 May 2006 16:05:43 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 12 May 2006 16:05:42 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 12 May 2006 16:05:42 -0400
Message-ID: <4464EA95.1010909@cisco.com>
Date: Fri, 12 May 2006 16:05:41 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ramana Koppula-G20085 <ramanakumar@motorola.com>
Subject: Re: [OSPF] Multiple Interfaces to a Single Link
References: <D6831742F069304FB1924B4160A493519D562B@ZMY16EXM66.ds.mot.com>
In-Reply-To: <D6831742F069304FB1924B4160A493519D562B@ZMY16EXM66.ds.mot.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 May 2006 20:05:42.0513 (UTC)
	FILETIME=[7285F610:01C675FF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Ramana,

I've updated the 3.2.2 text as follows. I believe this addresses your 
concern.

 o  Locally originated packets SHOULD NOT be processed by OSPF except
      for support of multiple interfaces attached to the same link as
      described in Section 3.9.  A locally originated packet is
      identified as packet with a source address equal to one of the
      router's local addresses.

I'd be interested in opinions on multi-interface per link support in 
general.

Thanks,
Acee


Ramana Koppula-G20085 wrote:

>Hi all,
> 
>Statement 1) From section 3.2.2 of OSPF for IPv6, "Locally originated
>packets SHOULD NOT be passed on to OSPF. That is, the source IPv6
>address should be examined to make sure this is not a multicast packet
>that the router itself generated." This is one of the checks that need
>to be done before the packet is sent for OSPF processing."
> 
>Statement 2) From section 3.9 of OSPF for IPv6, "This allows the router
>to automatically detect that multiple router interfaces attach to the
>same link, when a Hello packet is received with the router's link-local
>address as the source address but with an Interface ID other than the
>Interface ID for the receiving interface."
> 
>Doesn't the above two statements conflict in the case of Multiple
>Interfaces to the same broadcast link. And also first condition is
>checked for at IPv6 level while the other is at OSPF level. If the first
>statement is true, the packet would be dropped at the IP level and is
>not passed to OSPF.
> 
>I doubt the first statement if it should be re-written as "Locally
>originated packets SHOULD NOT be passed on to OSPF. That is, the source
>IPv6 address should be examined to make sure this is not a multicast
>packet that the router itself generated from same interface" This is one
>of the checks that need to be done before the packet is sent for OSPF
>processing."
> 
>thanx
>ramana
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>  
>

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



From ospf-bounces@ietf.org Sat May 13 14:48:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fez8k-0002ub-Cn; Sat, 13 May 2006 14:46:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fez8j-0002uW-CK
	for ospf@ietf.org; Sat, 13 May 2006 14:46:57 -0400
Received: from mail1.noc.data.net.uk ([80.68.34.48])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fez8h-0005dh-Vq
	for ospf@ietf.org; Sat, 13 May 2006 14:46:57 -0400
Received: from 57-99.dsl.data.net.uk ([80.68.57.99]
	helo=cortex.aria-networks.com)
	by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2)
	id 1Fez90-0005Uf-00
	for ospf@ietf.org; Sat, 13 May 2006 19:47:14 +0100
Received: from your029b8cecfe ([217.158.132.10] RDNS failed) by
	cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 13 May 2006 19:46:54 +0100
Message-ID: <00e401c676bc$fa61f210$0a23fea9@your029b8cecfe>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ospf@ietf.org>,
	<ccamp@ops.ietf.org>
Date: Sat, 13 May 2006 15:25:48 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 13 May 2006 18:46:55.0013 (UTC)
	FILETIME=[9B207550:01C676BD]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: Hamid Ould-Brahim <hbrahim@nortel.com>, takeda.tomonori@lab.ntt.co.jp
Subject: [OSPF] draft-ietf-ccamp-automesh-01.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi,

There is a draft in CCAMP that I want to bounce off the OSPF working group.

draft-ietf-ccamp-automesh-01.txt uses the new opaque LSA defined in 
draft-ietf-ospf-cap-08.txt in order to carry information about "mesh 
groups". Members of mesh groups would be connected together by tunnels to 
provide a sub-mesh across the network.

There are many applicabilities of this feature, but it is wanted in CCAMP to 
allow the construction of a mesh of MPLS-TE tunnels between a set of MPLS 
label switching routers (LSRs) within the network. This set might be a 
sub-set of the PEs, or might be a sub-set of the P-routers used to build a 
hierarchical network.

The management of the mesh membership information is not the responsibility 
of the IGP. Rather, this is opaque information that is delivered to an 
application. Thus, SPF is acting as a transport for routing-related 
information.

Any router may be a member of more than one mesh group, and many routers 
might not be in any mesh group (consider the PE mesh case where all 
P-routers are not in the group).

My questions to you:
1. Is it a concern that P-routers are being used to store and forward
   opaque information only needed by a small subset of the routers
   in the network?
2. Is there a scaling concern that there is no control on the number of
   mesh groups that may exist, nor the number of mesh groups to
   which any router can belong?

Context:
This question arises in the context of 
draft-bryskin-l1vpn-ospf-auto-discovery-01.txt that is being discussed in 
the L1VPN working group. This I-D proposes to use the IGPs (specifically 
OSPF) to distribute information about which VPNs can be accessed through the 
PEs (not general VPN membership or reachability information, but just a list 
of VPN IDs and the link I-Ds that are used to reach them). Loud voices have 
been raised in L1VPN about the scalability and appropriateness of such an 
idea, and since it seems to be very similar to automesh, I want to see 
whether you all think there is a problem with automesh.

many thanks,
Adrian





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



From ospf-bounces@ietf.org Sat May 13 19:40:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ff3hB-0008Cu-Sj; Sat, 13 May 2006 19:38:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff3hB-0008Co-0O
	for ospf@ietf.org; Sat, 13 May 2006 19:38:49 -0400
Received: from [203.199.83.42] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ff3h7-00037L-S7
	for ospf@ietf.org; Sat, 13 May 2006 19:38:48 -0400
Received: (qmail 16620 invoked by uid 510); 13 May 2006 23:37:41 -0000
Date: 13 May 2006 23:37:41 -0000
Message-ID: <20060513233741.16619.qmail@webmail55.rediffmail.com>
Received: from unknown (63.80.1.198) by rediffmail.com via HTTP;
	13 may 2006 23:37:41 -0000
MIME-Version: 1.0
From: "badvel vishnu reddy" <badvel_vishnuvardhan@rediffmail.com>
To: ospf@ietf.org
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Subject: [OSPF] Re : IPV6 Adress Prefixes 
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: badvel vishnu reddy <badvel_vishnuvardhan@rediffmail.com>
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1890609379=="
Errors-To: ospf-bounces@ietf.org

 This is a multipart mime message


--===============1890609379==
Content-type: multipart/alternative;
	boundary="Next_1147563461---0-203.199.83.42-16617"

 This is a multipart mime message


--Next_1147563461---0-203.199.83.42-16617
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

 =A0=0AHi All,=0ARfc 2740 section A.4.1 says Address Prefix is an=0A   enco=
ding of the prefix itself as an even multiple of 32-bit words,=0A   padding=
 with zero bits as necessary; this encoding consumes=0A   (PrefixLength + 3=
1) / 32) 32-bit words.=0ASo if i use this approach for example my prefixLen=
gth is 64 i need to fill 3 32 bit words? is this correct i feel i can fill =
2 32 bit words for this prefix length. Can someone give pointers on how man=
y 32 bit words do i need to fill=0ARegards=0AVishnu =20
--Next_1147563461---0-203.199.83.42-16617
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0A&nbsp; <BR>=0AHi All,<BR>=0ARfc 2740 section A.4.1 says Address Prefi=
x is an<BR>=0A&nbsp;  encoding of the prefix itself as an even multiple of =
32-bit words,<BR>=0A&nbsp;  padding with zero bits as necessary; this encod=
ing consumes<BR>=0A&nbsp;  (PrefixLength + 31) / 32) 32-bit words.<BR>=0ASo=
 if i use this approach for example my prefixLength is 64 i need to fill 3 =
32 bit words? is this correct i feel i can fill 2 32 bit words for this pre=
fix length. Can someone give pointers on how many 32 bit words do i need to=
 fill<BR>=0ARegards<BR>=0AVishnu&nbsp; =0A</P>=0A<br><br>=0A<a href=3D"http=
://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature=
-home.htm/1507191490@Middle5?PARTNER=3D3"><IMG SRC=3D"http://adworks.rediff=
.com/cgi-bin/AdWorks/sigimpress.cgi/www.rediff.com/signature-home.htm/19630=
59423@Middle5?OAS_query=3Dnull&PARTNER=3D3" BORDER=3D0 VSPACE=3D0 HSPACE=3D=
0></a>=0A
--Next_1147563461---0-203.199.83.42-16617--



--===============1890609379==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1890609379==--





From ospf-bounces@ietf.org Sat May 13 23:56:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ff7h7-00006s-Qo; Sat, 13 May 2006 23:55:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff7h6-00006l-UM
	for ospf@ietf.org; Sat, 13 May 2006 23:55:00 -0400
Received: from colo-dns-ext2.juniper.net ([207.17.137.64])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ff7h4-0007XX-Gt
	for ospf@ietf.org; Sat, 13 May 2006 23:55:00 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id
	k4E3sv1Z060216; Sat, 13 May 2006 20:54:57 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k4E3sv524950;
	Sat, 13 May 2006 20:54:57 -0700 (PDT)
	(envelope-from dkatz@juniper.net)
In-Reply-To: <20060513233741.16619.qmail@webmail55.rediffmail.com>
References: <20060513233741.16619.qmail@webmail55.rediffmail.com>
Mime-Version: 1.0 (Apple Message framework v746.3)
Message-Id: <39DEDAF7-9DC7-4D19-931B-CAF5EAE0ADD5@juniper.net>
From: Dave Katz <dkatz@juniper.net>
Subject: Re: [OSPF] Re : IPV6 Adress Prefixes 
Date: Sat, 13 May 2006 21:54:55 -0600
To: badvel vishnu reddy <badvel_vishnuvardhan@rediffmail.com>
X-Mailer: Apple Mail (2.746.3)
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0173697419=="
Errors-To: ospf-bounces@ietf.org


--===============0173697419==
Content-Type: multipart/alternative; boundary=Apple-Mail-86--379512810


--Apple-Mail-86--379512810
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

(64+31)/32 = 95/32 = 2

On May 13, 2006, at 5:37 PM, badvel vishnu reddy wrote:

>
> Hi All,
> Rfc 2740 section A.4.1 says Address Prefix is an
>   encoding of the prefix itself as an even multiple of 32-bit words,
>   padding with zero bits as necessary; this encoding consumes
>   (PrefixLength + 31) / 32) 32-bit words.
> So if i use this approach for example my prefixLength is 64 i need  
> to fill 3 32 bit words? is this correct i feel i can fill 2 32 bit  
> words for this prefix length. Can someone give pointers on how many  
> 32 bit words do i need to fill
> Regards
> Vishnu
>
>
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www1.ietf.org/mailman/listinfo/ospf


--Apple-Mail-86--379512810
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=ISO-8859-1

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">(64+31)/32 =3D 95/32 =3D =
2<DIV><BR><DIV><DIV>On May 13, 2006, at 5:37 PM, badvel vishnu reddy =
wrote:</DIV><BR class=3D"Apple-interchange-newline"><BLOCKQUOTE =
type=3D"cite"><P> =A0 <BR> Hi All,<BR> Rfc 2740 section A.4.1 says =
Address Prefix is an<BR> =A0  encoding of the prefix itself as an even =
multiple of 32-bit words,<BR> =A0  padding with zero bits as necessary; =
this encoding consumes<BR> =A0  (PrefixLength + 31) / 32) 32-bit =
words.<BR> So if i use this approach for example my prefixLength is 64 i =
need to fill 3 32 bit words? is this correct i feel i can fill 2 32 bit =
words for this prefix length. Can someone give pointers on how many 32 =
bit words do i need to fill<BR> Regards<BR> Vishnu=A0 </P> <BR><BR> <A =
href=3D"http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.=
com/signature-home.htm/1507191490@Middle5?PARTNER=3D3"><IMG =
src=3D"http://adworks.rediff.com/cgi-bin/AdWorks/sigimpress.cgi/www.rediff=
.com/signature-home.htm/1963059423@Middle5?OAS_query=3Dnull&PARTNER=3D3" =
border=3D"0" vspace=3D"0" hspace=3D"0"></A><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">OSPF mailing list</DIV><DIV style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A =
href=3D"mailto:OSPF@ietf.org">OSPF@ietf.org</A></DIV><DIV =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><A =
href=3D"https://www1.ietf.org/mailman/listinfo/ospf">https://www1.ietf.org=
/mailman/listinfo/ospf</A></DIV> =
</BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>=

--Apple-Mail-86--379512810--


--===============0173697419==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0173697419==--




From ospf-bounces@ietf.org Mon May 15 00:23:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FfUaH-0003t2-FE; Mon, 15 May 2006 00:21:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FfUaG-0003sx-6z
	for ospf@ietf.org; Mon, 15 May 2006 00:21:28 -0400
Received: from [203.199.83.245] (helo=rediffmail.com)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FfUaD-000279-LP
	for ospf@ietf.org; Mon, 15 May 2006 00:21:28 -0400
Received: (qmail 19542 invoked by uid 510); 15 May 2006 04:20:20 -0000
Date: 15 May 2006 04:20:20 -0000
Message-ID: <20060515042020.19541.qmail@webmail33.rediffmail.com>
Received: from unknown (203.126.136.220) by rediffmail.com via HTTP;
	15 may 2006 04:20:20 -0000
MIME-Version: 1.0
From: "Vivek  Dubey" <vivek_ospf@rediffmail.com>
To: ospf@ietf.org
Subject: Re: [OSPF] Unnumbered Interfaces in OSPF for IPv6
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Vivek  Dubey <vivek_ospf@rediffmail.com>
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1350103583=="
Errors-To: ospf-bounces@ietf.org

 This is a multipart mime message


--===============1350103583==
Content-type: multipart/alternative;
	boundary="Next_1147666820---0-203.199.83.245-19537"

 This is a multipart mime message


--Next_1147666820---0-203.199.83.245-19537
Content-type: text/plain;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Acee,=0AFew points:=0A1) Ipv6 standard does not mandate that each Ipv6 i=
nterface should be=0A   assigned Ipv6 address (global or non-global) (RFC 4=
293)=0A2) Ospfv3 interfaces take same ifIndex in there interface definition=
=0A=0ADo you forsee any issues in allowing un-numbered p2p interfaces in OS=
PF?=0A=0AFurther based on above two points, OSPF WG should(IMHO):=0A1) Eith=
er let un-numbered P2P interfaces be configured at Ospf level=0A2) Or make =
a stronger case i.e use "SHOULD". "Assumption" is leaving too much scope fo=
r interpretations.=0A=0A-Vivek=0A=0AOn Wed, 10 May 2006 Acee Lindem wrote :=
=0A>Hi Ramana,=0A>=0A>Ramana Koppula-G20085 wrote:=0A>=0A>>hi all,=0A>>=0A>=
>In section 2.5 of "draft-ietf-ospf-ospfv3-update-08.txt", there is some=0A=
>>assumption about link-local unicast addresses that OSPF makes:=0A>>=0A>>"=
OSPF for IPv6 assumes that each router has been assigned link-local=0A>>uni=
cast addresses on each of the router's attached physical links." Does=0A>>i=
t mean that OSPF for IPv6 does not Unnumbered Interfaces. But in some=0A>>w=
ritings that I googled, i found that Unnumbered support is there in=0A>>OSP=
F for IPv6.=0A>>  =0A>While some implementations have chosen to support con=
figuration, IMHO there should be=0A>not be the concept of an unnumbered lin=
k in IPv6. Hence, you have interfaces with global=0A>addresses and interfac=
es without global addresses. Every IPv6 interface should have a=0A>link-loc=
al address.=0A>=0A>>I have two doubts on this:=0A>>=0A>>1) As we donot have=
 shortage of addresses in IPv6, why should be support=0A>>Unnumbered interf=
aces in IPv6 at all?=0A>>  =0A>We shouldn't - see above.=0A>=0A>>2) If it i=
s supported, how can we make OSPF for IPv6 assumption true?=0A>>  =0A>That'=
s an implementation problem.=0A>=0A>Hope this helps,=0A>Acee=0A>P.S. There =
is only one reference to "an unnumbered point-to-point link" in=0A>draft-ie=
tf-ospf-ospfv3-update-08.txt. I'll change this to "a point-to-point link=0A=
>with no global IPv6 addresses" to avoid confusion.=0A>=0A>>thanx=0A>>=0A>>=
ramana=0A>>=0A>>=0A>>  =0A>>-----------------------------------------------=
-------------------------=0A>>=0A>>________________________________________=
_______=0A>>OSPF mailing list=0A>>OSPF@ietf.org=0A>>https://www1.ietf.org/m=
ailman/listinfo/ospf=0A>>  =0A>=0A>________________________________________=
_______=0A>OSPF mailing list=0A>OSPF@ietf.org=0A>https://www1.ietf.org/mail=
man/listinfo/ospf=0A
--Next_1147666820---0-203.199.83.245-19537
Content-type: text/html;
	charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<P>=0AHi Acee,<BR>=0AFew points:<BR>=0A1) Ipv6 standard does not mandate th=
at each Ipv6 interface should be<BR>=0A&nbsp;  assigned Ipv6 address (globa=
l or non-global) (RFC 4293)<BR>=0A2) Ospfv3 interfaces take same ifIndex in=
 there interface definition<BR>=0A<BR>=0ADo you forsee any issues in allowi=
ng un-numbered p2p interfaces in OSPF?<BR>=0A<BR>=0AFurther based on above =
two points, OSPF WG should(IMHO):<BR>=0A1) Either let un-numbered P2P inter=
faces be configured at Ospf level<BR>=0A2) Or make a stronger case i.e use =
&quot;SHOULD&quot;. &quot;Assumption&quot; is leaving too much scope for in=
terpretations.<BR>=0A<BR>=0A-Vivek<BR>=0A<BR>=0AOn Wed, 10 May 2006 Acee Li=
ndem wrote :<BR>=0A&gt;Hi Ramana,<BR>=0A&gt;<BR>=0A&gt;Ramana Koppula-G2008=
5 wrote:<BR>=0A&gt;<BR>=0A&gt;&gt;hi all,<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;In s=
ection 2.5 of &quot;draft-ietf-ospf-ospfv3-update-08.txt&quot;, there is so=
me<BR>=0A&gt;&gt;assumption about link-local unicast addresses that OSPF ma=
kes:<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;&quot;OSPF for IPv6 assumes that each rou=
ter has been assigned link-local<BR>=0A&gt;&gt;unicast addresses on each of=
 the router's attached physical links.&quot; Does<BR>=0A&gt;&gt;it mean tha=
t OSPF for IPv6 does not Unnumbered Interfaces. But in some<BR>=0A&gt;&gt;w=
ritings that I googled, i found that Unnumbered support is there in<BR>=0A&=
gt;&gt;OSPF for IPv6.<BR>=0A&gt;&gt;&nbsp; <BR>=0A&gt;While some implementa=
tions have chosen to support configuration, IMHO there should be<BR>=0A&gt;=
not be the concept of an unnumbered link in IPv6. Hence, you have interface=
s with global<BR>=0A&gt;addresses and interfaces without global addresses. =
Every IPv6 interface should have a<BR>=0A&gt;link-local address.<BR>=0A&gt;=
<BR>=0A&gt;&gt;I have two doubts on this:<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;1) A=
s we donot have shortage of addresses in IPv6, why should be support<BR>=0A=
&gt;&gt;Unnumbered interfaces in IPv6 at all?<BR>=0A&gt;&gt;&nbsp; <BR>=0A&=
gt;We shouldn't - see above.<BR>=0A&gt;<BR>=0A&gt;&gt;2) If it is supported=
, how can we make OSPF for IPv6 assumption true?<BR>=0A&gt;&gt;&nbsp; <BR>=
=0A&gt;That's an implementation problem.<BR>=0A&gt;<BR>=0A&gt;Hope this hel=
ps,<BR>=0A&gt;Acee<BR>=0A&gt;P.S. There is only one reference to &quot;an u=
nnumbered point-to-point link&quot; in<BR>=0A&gt;draft-ietf-ospf-ospfv3-upd=
ate-08.txt. I'll change this to &quot;a point-to-point link<BR>=0A&gt;with =
no global IPv6 addresses&quot; to avoid confusion.<BR>=0A&gt;<BR>=0A&gt;&gt=
;thanx<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;ramana<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;<BR=
>=0A&gt;&gt;&nbsp; <BR>=0A&gt;&gt;-----------------------------------------=
-------------------------------<BR>=0A&gt;&gt;<BR>=0A&gt;&gt;______________=
_________________________________<BR>=0A&gt;&gt;OSPF mailing list<BR>=0A&gt=
;&gt;OSPF@ietf.org<BR>=0A&gt;&gt;https://www1.ietf.org/mailman/listinfo/osp=
f<BR>=0A&gt;&gt;&nbsp; <BR>=0A&gt;<BR>=0A&gt;______________________________=
_________________<BR>=0A&gt;OSPF mailing list<BR>=0A&gt;OSPF@ietf.org<BR>=
=0A&gt;https://www1.ietf.org/mailman/listinfo/ospf<BR>=0A=0A</P>=0A<br><br>=
=0A<a href=3D"http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.re=
diff.com/signature-home.htm/1507191490@Middle5?PARTNER=3D3"><IMG SRC=3D"htt=
p://adworks.rediff.com/cgi-bin/AdWorks/sigimpress.cgi/www.rediff.com/signat=
ure-home.htm/1963059423@Middle5?OAS_query=3Dnull&PARTNER=3D3" BORDER=3D0 VS=
PACE=3D0 HSPACE=3D0></a>=0A
--Next_1147666820---0-203.199.83.245-19537--



--===============1350103583==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1350103583==--





From ospf-bounces@ietf.org Mon May 15 09:44:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FfdMA-0000zO-L4; Mon, 15 May 2006 09:43:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FfdM9-0000zJ-Bo
	for ospf@ietf.org; Mon, 15 May 2006 09:43:29 -0400
Received: from stl-smtpout-01.boeing.com ([130.76.96.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfdM8-0004T8-3s
	for ospf@ietf.org; Mon, 15 May 2006 09:43:29 -0400
Received: from blv-av-01.boeing.com ([192.42.227.216])
	by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id
	IAA25160; Mon, 15 May 2006 08:43:27 -0500 (CDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id
	k4FDhQr01930; Mon, 15 May 2006 06:43:26 -0700 (PDT)
Received: from XCH-NW-7V1.nw.nos.boeing.com ([130.247.54.34]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 15 May 2006 06:43:23 -0700
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, 15 May 2006 06:43:23 -0700
Message-ID: <2DA8DC77664C2B4C8804BF46498E141F01BFBC3C@XCH-NW-7V1.nw.nos.boeing.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OSPF Version 2 MIB for Multi-Topology (MT) Routing
Thread-Index: AcZ4JYje2/x+ZdDcQNO1kIbxMbemFg==
From: "Kushi, David M" <david.m.kushi@boeing.com>
To: <ospf@ietf.org>
X-OriginalArrivalTime: 15 May 2006 13:43:23.0859 (UTC)
	FILETIME=[89426230:01C67825]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: "Rashmi Shrivastava \(rashi\)" <rashi@cisco.com>
Subject: [OSPF] OSPF Version 2 MIB for Multi-Topology (MT) Routing
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: OSPF Version 2 MIB for Multi-Topology (MT)
Routing
	Author(s)	: N. Rawat, et al.
	Filename	: draft-rawat-ospf-mt-mib-00.txt
	Pages		: 36
	Date		: 2006-5-3
=09
   This memo defines an extension to the Open Shortest Path First
   version 2 Management Information Base (OSPFv2 MIB) for use with
   network management protocols in the Internet community.  In
   particular it describes objects and lists considerations for the
   management of OSPF Multi-Topology routing.  At present, the OSPF
   Multi-Topology extensions are defined within a standards track
   internet draft [5].


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rawat-ospf-mt-mib-00.txt

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



From ospf-bounces@ietf.org Mon May 15 10:12:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FfdoB-0008Mr-5B; Mon, 15 May 2006 10:12:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffdo9-0008KH-EX
	for ospf@ietf.org; Mon, 15 May 2006 10:12:25 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffdo7-00058O-1L
	for ospf@ietf.org; Mon, 15 May 2006 10:12:25 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10])
	by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k4FECMX14100; 
	Mon, 15 May 2006 07:12:22 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k4FECH530180;
	Mon, 15 May 2006 07:12:17 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: from kummer.juniper.net (localhost [127.0.0.1])
	by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id k4FECF7v002555;
	Mon, 15 May 2006 07:12:15 -0700 (PDT)
	(envelope-from kireeti@juniper.net)
Received: from localhost (kireeti@localhost)
	by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id
	k4FECEIU002552; Mon, 15 May 2006 07:12:15 -0700 (PDT)
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
Date: Mon, 15 May 2006 07:12:14 -0700 (PDT)
From: Kireeti Kompella <kireeti@juniper.net>
To: Adrian Farrel <adrian@olddog.co.uk>
Subject: Re: [OSPF] draft-ietf-ccamp-automesh-01.txt
In-Reply-To: <00e401c676bc$fa61f210$0a23fea9@your029b8cecfe>
Message-ID: <20060515063712.H2426@kummer.juniper.net>
References: <00e401c676bc$fa61f210$0a23fea9@your029b8cecfe>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: ccamp@ops.ietf.org, ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Adrian,

On Sat, 13 May 2006, Adrian Farrel wrote:

> There is a draft in CCAMP that I want to bounce off the OSPF working group.
...
> My questions to you:
> 1. Is it a concern that P-routers are being used to store and forward
>  opaque information only needed by a small subset of the routers
>  in the network?

Necessary evil (i.e., No; see below)

(I would reconsider the use of the word "small" -- in most networks I 
have seen, the number of PE routers vastly outnumber the number of P 
routers.)

> 2. Is there a scaling concern that there is no control on the number of
>  mesh groups that may exist, nor the number of mesh groups to
>  which any router can belong?

I guess an implementation could go berserk and advertise 65536 bytes 
worth of mesh groups, but no, this doesn't concern me too much.

> Context:
> This question arises in the context of 
> draft-bryskin-l1vpn-ospf-auto-discovery-01.txt that is being discussed in the 
> L1VPN working group. This I-D proposes to use the IGPs (specifically OSPF) to 
> distribute information about which VPNs can be accessed through the PEs (not 
> general VPN membership or reachability information, but just a list of VPN 
> IDs and the link I-Ds that are used to reach them). Loud voices have been 
> raised in L1VPN about the scalability and appropriateness of such an idea, 
> and since it seems to be very similar to automesh, I want to see whether you 
> all think there is a problem with automesh.

I have the same issues with using ISIS/OSPF for auto-mesh as I do for 
autodiscovery in L1VPNs -- OSPF and ISIS are not ideal vehicles for 
such information.  However, there are two very important differences 
in these two cases:

1) BGP is often not present on "interior" routers (consider the case
    of "P" routers fully meshed with TE LSPs, and PEs running LDP; and
    BGP running only on PEs -- "BGP-free core")

2) It is vital for VPNs that a good policy mechanism be available to
    control the distribution of information -- otherwise, there could
    be serious breaches of privacy.

That said, I would like to see automesh information carried in BGP, 
to be used in preference to ISIS/OSPF whenever possible.

Kireeti.
-------

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



From ospf-bounces@ietf.org Mon May 15 11:44:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FffDp-0000nj-KV; Mon, 15 May 2006 11:43:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FffDo-0000ne-QB
	for ospf@ietf.org; Mon, 15 May 2006 11:43:00 -0400
Received: from webmail.movaz.com ([70.158.43.219] helo=jera.movaz.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FffDn-0001Rh-GV
	for ospf@ietf.org; Mon, 15 May 2006 11:43:00 -0400
Received: from ib (unknown [172.16.24.125])
	by jera.movaz.com (Postfix) with SMTP
	id B973E1477A; Mon, 15 May 2006 11:42:58 -0400 (EDT)
Message-ID: <017a01c67836$3dea9a30$7d1810ac@movaz.com>
From: "Igor Bryskin" <ibryskin@movaz.com>
To: "Kireeti Kompella" <kireeti@juniper.net>,
	"Adrian Farrel" <adrian@olddog.co.uk>
References: <00e401c676bc$fa61f210$0a23fea9@your029b8cecfe>
	<20060515063712.H2426@kummer.juniper.net>
Subject: Re: [OSPF] draft-ietf-ccamp-automesh-01.txt
Date: Mon, 15 May 2006 11:42:58 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
Cc: ccamp@ops.ietf.org, ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Kireeti,

Good to hear from you.

Please, see in-line.

Igor

----- Original Message ----- 
From: "Kireeti Kompella" <kireeti@juniper.net>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ospf@ietf.org>; <ccamp@ops.ietf.org>
Sent: Monday, May 15, 2006 10:12 AM
Subject: Re: [OSPF] draft-ietf-ccamp-automesh-01.txt


> Hi Adrian,
>
> On Sat, 13 May 2006, Adrian Farrel wrote:
>
> > There is a draft in CCAMP that I want to bounce off the OSPF working
group.
> ...
> > My questions to you:
> > 1. Is it a concern that P-routers are being used to store and forward
> >  opaque information only needed by a small subset of the routers
> >  in the network?
>
> Necessary evil (i.e., No; see below)
>
> (I would reconsider the use of the word "small" -- in most networks I
> have seen, the number of PE routers vastly outnumber the number of P
> routers.)

IB>> I think it is even more true in the context of L1 networks which in
most of the cases are bunch of interconnected rings of PEs with zero or very
few Ps.

>
> > 2. Is there a scaling concern that there is no control on the number of
> >  mesh groups that may exist, nor the number of mesh groups to
> >  which any router can belong?
>
> I guess an implementation could go berserk and advertise 65536 bytes
> worth of mesh groups, but no, this doesn't concern me too much.
>
> > Context:
> > This question arises in the context of
> > draft-bryskin-l1vpn-ospf-auto-discovery-01.txt that is being discussed
in the
> > L1VPN working group. This I-D proposes to use the IGPs (specifically
OSPF) to
> > distribute information about which VPNs can be accessed through the PEs
(not
> > general VPN membership or reachability information, but just a list of
VPN
> > IDs and the link I-Ds that are used to reach them). Loud voices have
been
> > raised in L1VPN about the scalability and appropriateness of such an
idea,
> > and since it seems to be very similar to automesh, I want to see whether
you
> > all think there is a problem with automesh.
>
> I have the same issues with using ISIS/OSPF for auto-mesh as I do for
> autodiscovery in L1VPNs -- OSPF and ISIS are not ideal vehicles for
> such information.  However, there are two very important differences
> in these two cases:
>
> 1) BGP is often not present on "interior" routers (consider the case
>     of "P" routers fully meshed with TE LSPs, and PEs running LDP; and
>     BGP running only on PEs -- "BGP-free core")
>
> 2) It is vital for VPNs that a good policy mechanism be available to
>     control the distribution of information -- otherwise, there could
>     be serious breaches of privacy.

IB>> Note, that what we are suggesting to advertise in L1VPN opaque LSAs are
locally configured CE-PE links and their association with VPNs. I am sure
that I am missing something, so could you help me understand:
a) what scenarios of "serious breaches of privacy" you have in mind?
b) how the BGP approach can help in this regard?

Thanks,
Igor

>
> That said, I would like to see automesh information carried in BGP,
> to be used in preference to ISIS/OSPF whenever possible.
>
> Kireeti.
> -------
>


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



From ospf-bounces@ietf.org Mon May 15 11:44:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FffFI-0000wI-7S; Mon, 15 May 2006 11:44:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FffFG-0000wD-Ji
	for ospf@ietf.org; Mon, 15 May 2006 11:44:30 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FffFG-0001uW-AJ
	for ospf@ietf.org; Mon, 15 May 2006 11:44:30 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 15 May 2006 08:44:30 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,130,1146466800"; 
	d="scan'208"; a="28046787:sNHT25664372"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4FFiTTN011551; 
	Mon, 15 May 2006 11:44:29 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 15 May 2006 11:44:29 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 15 May 2006 11:44:29 -0400
Message-ID: <4468A1DC.90506@cisco.com>
Date: Mon, 15 May 2006 11:44:28 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vivek Dubey <vivek_ospf@rediffmail.com>
Subject: Re: [OSPF] Unnumbered Interfaces in OSPF for IPv6
References: <20060515042020.19541.qmail@webmail33.rediffmail.com>
In-Reply-To: <20060515042020.19541.qmail@webmail33.rediffmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 May 2006 15:44:29.0455 (UTC)
	FILETIME=[73E459F0:01C67836]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Vivek Dubey wrote:

>Hi Acee,
>Few points:
>1) Ipv6 standard does not mandate that each Ipv6 interface should be
>   assigned Ipv6 address (global or non-global) (RFC 4293)
>2) Ospfv3 interfaces take same ifIndex in there interface definition
>  
>
Vivek,
Refer to section 2.1 of RFC 4291. It clearly states that "All interfaces 
are required
to have at least one link-local address (see Section 2.8 for additional 
required addresses)."

Thanks,
Acee

>Do you forsee any issues in allowing un-numbered p2p interfaces in OSPF?
>
>Further based on above two points, OSPF WG should(IMHO):
>1) Either let un-numbered P2P interfaces be configured at Ospf level
>2) Or make a stronger case i.e use "SHOULD". "Assumption" is leaving too much scope for interpretations.
>
>-Vivek
>
>On Wed, 10 May 2006 Acee Lindem wrote :
>  
>
>>Hi Ramana,
>>
>>Ramana Koppula-G20085 wrote:
>>
>>    
>>
>>>hi all,
>>>
>>>In section 2.5 of "draft-ietf-ospf-ospfv3-update-08.txt", there is some
>>>assumption about link-local unicast addresses that OSPF makes:
>>>
>>>"OSPF for IPv6 assumes that each router has been assigned link-local
>>>unicast addresses on each of the router's attached physical links." Does
>>>it mean that OSPF for IPv6 does not Unnumbered Interfaces. But in some
>>>writings that I googled, i found that Unnumbered support is there in
>>>OSPF for IPv6.
>>> 
>>>      
>>>
>>While some implementations have chosen to support configuration, IMHO there should be
>>not be the concept of an unnumbered link in IPv6. Hence, you have interfaces with global
>>addresses and interfaces without global addresses. Every IPv6 interface should have a
>>link-local address.
>>
>>    
>>
>>>I have two doubts on this:
>>>
>>>1) As we donot have shortage of addresses in IPv6, why should be support
>>>Unnumbered interfaces in IPv6 at all?
>>> 
>>>      
>>>
>>We shouldn't - see above.
>>
>>    
>>
>>>2) If it is supported, how can we make OSPF for IPv6 assumption true?
>>> 
>>>      
>>>
>>That's an implementation problem.
>>
>>Hope this helps,
>>Acee
>>P.S. There is only one reference to "an unnumbered point-to-point link" in
>>draft-ietf-ospf-ospfv3-update-08.txt. I'll change this to "a point-to-point link
>>with no global IPv6 addresses" to avoid confusion.
>>
>>    
>>
>>>thanx
>>>
>>>ramana
>>>
>>>
>>> 
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>OSPF mailing list
>>>OSPF@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/ospf
>>> 
>>>      
>>>
>>_______________________________________________
>>OSPF mailing list
>>OSPF@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ospf
>>    
>>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>  
>

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



From ospf-bounces@ietf.org Tue May 16 03:35:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Ffu4T-0004o4-Nf; Tue, 16 May 2006 03:34:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffu4R-0004ny-Qh
	for ospf@ietf.org; Tue, 16 May 2006 03:34:19 -0400
Received: from smtp1.mail.atosorigin.com ([160.92.103.80])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffu4P-0005xO-Dj
	for ospf@ietf.org; Tue, 16 May 2006 03:34:19 -0400
Received: from AOFR11476 (localhost [127.0.0.1])
	by mwumf0101.mail.fr.ww.atosorigin.com (Postfix) with ESMTP id
	860EA1C000A7
	for <ospf@ietf.org>; Tue, 16 May 2006 09:34:10 +0200 (CEST)
Message-ID: <002e01c678bb$0b0ce610$38600337@AOFR11476>
From: "fabien.verhaeghe" <fabien.verhaeghe@atosorigin.com>
To: <ospf@ietf.org>
Date: Tue, 16 May 2006 09:33:35 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Subject: [OSPF] Link prefix in OSPFv3 MIB
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0711264931=="
Errors-To: ospf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0711264931==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002B_01C678CB.CE317600"

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01C678CB.CE317600
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all,

I was little surprised to see that there is no table for link prefixes =
in OSPFv3 MIB.
I understand from section 2.1 of =
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-10.txt
that that information is reachable/configurable  "via the IPV6-MIB =
[RFC2465]".=20

But the OSPFv3 prefix option field does not appear in IPv6MIB.
Isn't it a problem?

Thanks
Fabien Verhaeghe
Atos Origin=20

------=_NextPart_000_002B_01C678CB.CE317600
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2873" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello all,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I was little surprised to see that =
there is no=20
table for link prefixes in OSPFv3 MIB.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I understand from section 2.1 of <A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-10=
.txt">http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-10.t=
xt</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>that that information is =
reachable/configurable=20
</FONT><FONT face=3DArial size=3D2>&nbsp;"via the IPV6-MIB [RFC2465]". =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>But the OSPFv3 prefix option field does =
not appear=20
in IPv6MIB.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Isn't it a problem?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Fabien Verhaeghe</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Atos Origin</FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_002B_01C678CB.CE317600--



--===============0711264931==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0711264931==--





From ospf-bounces@ietf.org Tue May 16 10:07:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg0Bf-0007Zz-7e; Tue, 16 May 2006 10:06:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0Bd-0007Zu-AK
	for ospf@ietf.org; Tue, 16 May 2006 10:06:09 -0400
Received: from zrtps0kp.nortel.com ([47.140.192.56])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0Bc-00085p-Ur
	for ospf@ietf.org; Tue, 16 May 2006 10:06:09 -0400
Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com
	[47.140.202.50])
	by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	k4GE60m04249; Tue, 16 May 2006 10:06:01 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [OSPF] Link prefix in OSPFv3 MIB
Date: Tue, 16 May 2006 10:06:00 -0400
Message-ID: <4B7DAC3FEFD35D4A96BDD0116990501403365EEE@zrtphxm1.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OSPF] Link prefix in OSPFv3 MIB
Thread-Index: AcZ4u0cecTb4b1g2RVOqNb0yAGeLagAMvXkQ
From: "Daniel Joyal" <djoyal@nortel.com>
To: "fabien.verhaeghe" <fabien.verhaeghe@atosorigin.com>, <ospf@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Cc: 
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1249052289=="
Errors-To: ospf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1249052289==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C678F1.DC4C4B1B"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C678F1.DC4C4B1B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In general, there is no direct access in any OSPF MIB for a user to set
options bits
to be advertised in protocol packets. The bit settings are determined by
other configuration
parameters or internal state information. As for reading prefix options
bit settings, they are available
as part of relevant LSDB table entries (e.g.
ospfv3AreaLsdbAdvertisement).
=20
-Dan

	-----Original Message-----
	From: fabien.verhaeghe [mailto:fabien.verhaeghe@atosorigin.com]=20
	Sent: Tuesday, May 16, 2006 3:34 AM
	To: ospf@ietf.org
	Subject: [OSPF] Link prefix in OSPFv3 MIB
=09
=09
	Hello all,
	=20
	I was little surprised to see that there is no table for link
prefixes in OSPFv3 MIB.
	I understand from section 2.1 of
http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-10.txt
	that that information is reachable/configurable  "via the
IPV6-MIB [RFC2465]".=20
	=20
	But the OSPFv3 prefix option field does not appear in IPv6MIB.
	Isn't it a problem?
	=20
	Thanks
	Fabien Verhaeghe
	Atos Origin=20
	=20


------_=_NextPart_001_01C678F1.DC4C4B1B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1543" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D804044013-16052006><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
general, there is no direct access in any OSPF MIB for a user to set =
options=20
bits</FONT></SPAN></DIV>
<DIV><SPAN class=3D804044013-16052006><FONT face=3DArial color=3D#0000ff =
size=3D2>to be=20
advertised in protocol packets. The bit settings are determined by other =

configuration</FONT></SPAN></DIV>
<DIV><SPAN class=3D804044013-16052006><FONT face=3DArial color=3D#0000ff =

size=3D2>parameters or&nbsp;internal state information. As for reading =
prefix=20
options bit settings, they are available</FONT></SPAN></DIV>
<DIV><SPAN class=3D804044013-16052006><FONT face=3DArial color=3D#0000ff =
size=3D2>as=20
part of relevant LSDB table entries (e.g.=20
ospfv3AreaLsdbAdvertisement).</FONT></SPAN></DIV>
<DIV><SPAN class=3D804044013-16052006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D804044013-16052006><FONT face=3DArial color=3D#0000ff =

size=3D2>-Dan</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
fabien.verhaeghe=20
  [mailto:fabien.verhaeghe@atosorigin.com] <BR><B>Sent:</B> Tuesday, May =
16,=20
  2006 3:34 AM<BR><B>To:</B> ospf@ietf.org<BR><B>Subject:</B> [OSPF] =
Link prefix=20
  in OSPFv3 MIB<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Hello all,</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>I was little surprised to see that =
there is no=20
  table for link prefixes in OSPFv3 MIB.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>I understand from section 2.1 of <A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-10=
.txt">http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-10.t=
xt</A></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>that that information is =
reachable/configurable=20
  </FONT><FONT face=3DArial size=3D2>&nbsp;"via the IPV6-MIB [RFC2465]". =

  </FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>But the OSPFv3 prefix option field =
does not=20
  appear in IPv6MIB.</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Isn't it a problem?</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Fabien Verhaeghe</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>Atos Origin</FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial =
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C678F1.DC4C4B1B--


--===============1249052289==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1249052289==--




From ospf-bounces@ietf.org Tue May 16 14:54:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg4fu-0007Ya-QD; Tue, 16 May 2006 14:53:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg4ft-0007Xr-Cf; Tue, 16 May 2006 14:53:41 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Fg4fr-0006cY-3l; Tue, 16 May 2006 14:53:41 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 16 May 2006 14:53:39 -0400
X-IronPort-AV: i="4.05,134,1146456000"; 
	d="scan'208"; a="88689477:sNHT28470500"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4GIrcvF011905; 
	Tue, 16 May 2006 14:53:38 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 16 May 2006 14:53:38 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 16 May 2006 14:53:37 -0400
Message-ID: <446A1FB1.5060909@cisco.com>
Date: Tue, 16 May 2006 14:53:37 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bill Fenner <fenner@research.att.com>, Ross Callon <rcallon@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2006 18:53:37.0861 (UTC)
	FILETIME=[0A7B6F50:01C6791A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Cc: OSPF List <ospf@ietf.org>, IESG Secretary <iesg-secretary@ietf.org>,
	rtg-dir@ietf.org
Subject: [OSPF] OSPFv3 Graceful Restart -
	draft-ietf-ospf-ospfv3-graceful-restart-04.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

The OSPF WG last call has ended and the comments have been addressed.

http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-04.txt

Please begin the AD evaluation on this document.

Thanks,
Acee

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



From ospf-bounces@ietf.org Tue May 16 14:57:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fg4jt-0000JR-1o; Tue, 16 May 2006 14:57:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4jr-0000JD-Sf
	for ospf@ietf.org; Tue, 16 May 2006 14:57:47 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4jq-000701-K6
	for ospf@ietf.org; Tue, 16 May 2006 14:57:47 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 16 May 2006 11:57:46 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,134,1146466800"; 
	d="scan'208"; a="28150480:sNHT20410012"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4GIvkTN021850
	for <ospf@ietf.org>; Tue, 16 May 2006 14:57:46 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 16 May 2006 14:57:45 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 16 May 2006 14:57:45 -0400
Message-ID: <446A20A9.9090004@cisco.com>
Date: Tue, 16 May 2006 14:57:45 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OSPF List <ospf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 May 2006 18:57:45.0688 (UTC)
	FILETIME=[9E32D580:01C6791A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Subject: [OSPF] OSPF Multi-Area Adjacency -
	draft-ietf-ospf-multi-area-adj-05.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

This document was previously WG last called as an informational document.
Since that time, there has been implementation interest from multiple 
vendors
and we would now like WG last call it again as a standards track document.

This is the start of the WG last. All comments must be received by 12:00 AM,
May 31st, 2006.

Thanks,
Acee

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



From ospf-bounces@ietf.org Wed May 17 02:03:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgF6h-00076j-Kx; Wed, 17 May 2006 02:02:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgF6g-00076e-9p
	for ospf@ietf.org; Wed, 17 May 2006 02:02:02 -0400
Received: from [203.196.196.74] (helo=BLR-MAIL.NETD.COM)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgF6d-0002ER-Ad
	for ospf@ietf.org; Wed, 17 May 2006 02:02:02 -0400
Received: from netd.com ([10.91.2.5]) (authenticated bits=0)
	by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id k4H67uAE021607;
	Wed, 17 May 2006 11:38:01 +0530
Message-ID: <446ABB82.1060706@netd.com>
Date: Wed, 17 May 2006 11:28:26 +0530
From: AJAY THAKUR <tajay@netd.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ospf@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin
	for more information
X-NetD-India-MailScanner: Found to be clean
X-MailScanner-From: tajay@netd.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Subject: [OSPF] calculating next hop
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi,
I am facing some problem in the rfc2328.

16.1.1. The next hop calculation

If the destination is a router connected to the calculating router via a
virtual link, the setting of the next hop should be deferred until the 
calculation in Section 16.3.


But in the setion 16.3 it is not clear when to set the next how for this
route.

Any help ?

Ajay


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



From ospf-bounces@ietf.org Wed May 17 03:23:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgGMN-0001nM-Oy; Wed, 17 May 2006 03:22:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgGML-0001mk-Tk
	for ospf@ietf.org; Wed, 17 May 2006 03:22:17 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgGML-0005dg-Qx
	for ospf@ietf.org; Wed, 17 May 2006 03:22:17 -0400
Received: from ind-iport-1.cisco.com ([64.104.129.195])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgGFh-0000x1-Qa
	for ospf@ietf.org; Wed, 17 May 2006 03:15:27 -0400
Received: from india-core-1.cisco.com ([64.104.129.221])
	by ind-iport-1.cisco.com with ESMTP; 17 May 2006 13:01:45 -0700
X-IronPort-AV: i="4.05,136,1146466800"; 
	d="scan'208,217"; a="67874140:sNHT141044326"
Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com
	[64.104.140.149])
	by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4H7Eqoe006706
	for <ospf@ietf.org>; Wed, 17 May 2006 07:14:52 GMT
Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by
	xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); 
	Wed, 17 May 2006 12:45:18 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 17 May 2006 12:45:17 +0530
Message-ID: <A547B532685E6C488A983A5B47FCEEFCA998A7@xmb-blr-417.apac.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: ASBR election
Thread-Index: AcZ5gaZzMykClwu1QR6AJcRQmF9j+w==
X-Priority: 1
Priority: Urgent
Importance: high
From: "Pradeep BG \(pradg\)" <pradg@cisco.com>
To: <ospf@ietf.org>
X-OriginalArrivalTime: 17 May 2006 07:15:18.0166 (UTC)
	FILETIME=[A6BB1B60:01C67981]
X-Spam-Score: -2.5 (--)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Subject: [OSPF] ASBR election
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1906959252=="
Errors-To: ospf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1906959252==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C67981.A6A26209"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C67981.A6A26209
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi
=20
Guys
=20
I am stuck with a problem
=20
1:If we are adversting the same route from 2 ASBR  What does RFC say for
this ? think it should be highest ip address  if yes can u tell me which
RFC says that and the section pleases :-)?
=20
in SS-3 in the routing table which will be selceted as the best path
(the link cost to reach both the ASBR is same for SS-3)
=20
if area 0 is connected let us assume it is conected to SS-3 area 0 is
getting updates from SS-3 ,=20
=20
=20
=20
SS-1 ASBR 11.11.11.1
SS-3 ASBR 12.12.12.1
=20

                           area1               area1
        (ASBR)SS-1----------------SS-3----------SS-2(ASBR)
                                             |
                                             |(Area 0)
                                             |
                                             |
                                          SS-4 =20

------_=_NextPart_001_01C67981.A6A26209
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1528" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D236450007-17052006>Hi</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D236450007-17052006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D236450007-17052006>Guys</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D236450007-17052006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D236450007-17052006>I am =
stuck with a=20
problem</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D236450007-17052006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=3D236450007-17052006>
<DIV><FONT face=3DArial><FONT size=3D2>1:If we are adversting the same =
route from 2=20
ASBR&nbsp;<SPAN =
class=3D236450007-17052006>&nbsp;</SPAN></FONT></FONT><FONT=20
face=3DArial><FONT size=3D2><SPAN class=3D236450007-17052006>What does =
RFC say for=20
this ? think it should be highest ip address&nbsp; if yes can u tell me =
which=20
RFC says that and the section pleases :-)?</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D236450007-17052006></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D236450007-17052006>in SS-3 in the=20
routing table which will be selceted as the best path (the link cost to =
reach=20
both the ASBR is same for SS-3)</SPAN></FONT></FONT></DIV>
<DIV><FONT size=3D2><SPAN =
class=3D236450007-17052006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><SPAN class=3D236450007-17052006>if area 0 is =
connected let=20
us&nbsp;assume it is conected to SS-3 area 0 is getting updates from =
SS-3&nbsp;,=20
</SPAN></FONT><FONT face=3DArial size=3D2></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D2><SPAN=20
class=3D236450007-17052006>SS-1</SPAN>&nbsp;ASBR 11.11.11.1<BR><SPAN=20
class=3D236450007-17052006>SS-3</SPAN>&nbsp;ASBR =
12.12.12.1</FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><BR><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
area1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<S=
PAN=20
class=3D236450007-17052006>&nbsp;&nbsp;&nbsp;=20
</SPAN>area1<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (ASBR)<SPAN=20
class=3D236450007-17052006>SS-1</SPAN>----------------<SPAN=20
class=3D236450007-17052006>SS-3</SPAN>----------<SPAN=20
class=3D236450007-17052006>SS</SPAN><SPAN=20
class=3D236450007-17052006>-2</SPAN>(ASBR)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D236450007-17052006>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

|</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D236450007-17052006>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

|(Area 0)</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D236450007-17052006>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

|</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D236450007-17052006>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;|</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D236450007-17052006>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SS-4&nbsp;=20
</SPAN></FONT></DIV></SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C67981.A6A26209--


--===============1906959252==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1906959252==--




From ospf-bounces@ietf.org Wed May 17 06:14:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgJ1V-0000gk-CV; Wed, 17 May 2006 06:12:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgJ1U-0000fP-3E
	for ospf@ietf.org; Wed, 17 May 2006 06:12:56 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgJ1U-0006sw-1k
	for ospf@ietf.org; Wed, 17 May 2006 06:12:56 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgInx-0002Z5-6w
	for ospf@ietf.org; Wed, 17 May 2006 05:59:01 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 17 May 2006 05:58:57 -0400
X-IronPort-AV: i="4.05,136,1146456000"; 
	d="scan'208"; a="88732158:sNHT31439696"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4H9wuvF024792
	for <ospf@ietf.org>; Wed, 17 May 2006 05:58:56 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 17 May 2006 05:58:56 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 17 May 2006 05:58:56 -0400
Message-ID: <446AF3DF.7040004@cisco.com>
Date: Wed, 17 May 2006 05:58:55 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Pradeep BG (pradg)" <pradg@cisco.com>
Subject: Re: [OSPF] ASBR election
References: <A547B532685E6C488A983A5B47FCEEFCA998A7@xmb-blr-417.apac.cisco.com>
In-Reply-To: <A547B532685E6C488A983A5B47FCEEFCA998A7@xmb-blr-417.apac.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 May 2006 09:58:56.0361 (UTC)
	FILETIME=[82D4C590:01C67998]
X-Spam-Score: -2.6 (--)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Pradeep,

Pradeep BG (pradg) wrote:

>Hi
> 
>Guys
> 
>I am stuck with a problem
> 
>1:If we are adversting the same route from 2 ASBR  What does RFC say for
>this ? think it should be highest ip address  if yes can u tell me which
>RFC says that and the section pleases :-)?
>  
>
 From RFC 2328, section 12.4.4.1:

                    In figure 16, suppose instead that both RTA and RTB
                    exchange BGP information with RTX.  In this case,           
                    RTA and RTB would originate the same set of AS-
                    external-LSAs.  These LSAs, if they specify the same
                    metric, would be functionally equivalent since they
                    would specify the same destination and forwarding
                    address (RTX).  This leads to a clear duplication of
                    effort.  If only one of RTA or RTB originated the
                    set of AS-external-LSAs, the routing would remain
                    the same, and the size of the link state database
                    would decrease.  However, it must be unambiguously
                    defined as to which router originates the LSAs
                    (otherwise neither may, or the identity of the
                    originator may oscillate).  The following rule is
                    thereby established: if two routers, both reachable
                    from one another, originate functionally equivalent
                    AS-external-LSAs (i.e., same destination, cost and
                    non-zero forwarding address), then the LSA
                    originated by the router having the highest OSPF
                    Router ID is used.  The router having the lower OSPF
                    Router ID can then flush its LSA.  Flushing an LSA
                    is discussed in Section 14.1.


> 
>in SS-3 in the routing table which will be selceted as the best path
>(the link cost to reach both the ASBR is same for SS-3)
> 
>if area 0 is connected let us assume it is conected to SS-3 area 0 is
>getting updates from SS-3 , 
>  
>
The rule above only applies to AS external LSA (type 5s). I'm not sure I
understand your scenario.

Hope this helps,
Acee

> 
> 
> 
>SS-1 ASBR 11.11.11.1
>SS-3 ASBR 12.12.12.1
> 
>
>                           area1               area1
>        (ASBR)SS-1----------------SS-3----------SS-2(ASBR)
>                                             |
>                                             |(Area 0)
>                                             |
>                                             |
>                                          SS-4  
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>  
>

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



From ospf-bounces@ietf.org Wed May 17 08:56:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgLYO-0007Ar-WA; Wed, 17 May 2006 08:55:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgLYN-0007Al-O4
	for OSPF@IETF.ORG; Wed, 17 May 2006 08:55:03 -0400
Received: from omega7.wr.usgs.gov ([130.118.4.3] helo=ns0.wr.usgs.gov)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgLYL-0007cs-Fe
	for OSPF@IETF.ORG; Wed, 17 May 2006 08:55:03 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392)
	id <01M2INMYLS80001TGV@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Wed,
	17 May 2006 05:53:10 -0700 (PDT)
Date: Wed, 17 May 2006 05:53:10 -0700 (PDT)
From: "Pat Murphy - (650)329-4044" <pmurphy@noc.usgs.net>
Subject: Re: [OSPF] ASBR election
To: PRADG@CISCO.COM
Message-id: <01M2INMYLS82001TGV@omega7.wr.usgs.gov>
X-VMS-To: pradg@cisco.com
X-VMS-Cc: PMURPHY,ospf@ietf.org
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: OSPF@IETF.ORG
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Pradeep,

>The rule above only applies to AS external LSA (type 5s).

A similar rule applies to external type 7 LSAs. From RFC 3101, Section 
2.4.

   ...If two NSSA routers, both
   reachable from one another over the NSSA, originate functionally
   equivalent Type-7 LSAs (i.e., same destination, cost and non-zero
   forwarding address), then the router having the least preferred LSA
   should flush its LSA.  (See [OSPF] Section 12.4.4.1.)  Preference
   between two Type-7 LSAs is determined by the following tie breaker
   rules:

      1. An LSA with the P-bit set is preferred over one with the P-bit
         clear.

      2. If the P-bit settings are the same, the LSA with the higher
         router ID is preferred.

Note that Type 5 LSAs that are not translations of Type 7 LSAs must 
never have forwarding addresses from a stub area or NSSA. Similarly Type 
7 LSAs must always have forwarding addresses from their respective NSSA. 
Hence there should be no issues with a functionally equivalent Type 5 
and Type 7 LSA pair. When this occurs the Type 5 LSA should be a 
translation of the Type 7 LSA.

Pat


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



From ospf-bounces@ietf.org Wed May 17 10:28:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgMzc-00085I-Bn; Wed, 17 May 2006 10:27:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMza-00084g-V1
	for ospf@ietf.org; Wed, 17 May 2006 10:27:14 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMzX-0003Po-MX
	for ospf@ietf.org; Wed, 17 May 2006 10:27:14 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 17 May 2006 07:27:12 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,138,1146466800"; 
	d="scan'208"; a="28210698:sNHT22004096"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4HER5vF010815; 
	Wed, 17 May 2006 10:27:11 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 17 May 2006 10:27:05 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 17 May 2006 10:27:04 -0400
Message-ID: <446B32B8.8010405@cisco.com>
Date: Wed, 17 May 2006 10:27:04 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: AJAY THAKUR <tajay@netd.com>
Subject: Re: [OSPF] calculating next hop
References: <446ABB82.1060706@netd.com>
In-Reply-To: <446ABB82.1060706@netd.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 May 2006 14:27:04.0939 (UTC)
	FILETIME=[F85EF3B0:01C679BD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

AJAY THAKUR wrote:

> Hi,
> I am facing some problem in the rfc2328.
>
> 16.1.1. The next hop calculation
>
> If the destination is a router connected to the calculating router via a
> virtual link, the setting of the next hop should be deferred until the 
> calculation in Section 16.3.
>
>
> But in the setion 16.3 it is not clear when to set the next how for this
> route.

Ajay,

Section 16.3 describes how to select the best path through a transit area
which is possibly not though the virtual link endpoint ABR. One way to 
implement
this would be to defer setting the next-hop during SPF. Another would be
to install the virtual link ABR next-hop during the backbone intra-area 
SPF (16.1)
and inter-area summary (16.2) processing. Then, possibly update these 
next hops during
transit area processing as described in 16.3.

Hope this helps,
Acee

>
> Any help ?
>
> Ajay
>
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www1.ietf.org/mailman/listinfo/ospf
>

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



From ospf-bounces@ietf.org Wed May 17 11:01:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgNWX-0006wN-QY; Wed, 17 May 2006 11:01:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNWW-0006wH-0L
	for ospf@ietf.org; Wed, 17 May 2006 11:01:16 -0400
Received: from hoemail1.lucent.com ([192.11.226.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNWU-0005oj-PK
	for ospf@ietf.org; Wed, 17 May 2006 11:01:15 -0400
Received: from ii0015exch002u.wins.lucent.com (h135-254-246-205.lucent.com
	[135.254.246.205])
	by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k4HF18op020334
	for <ospf@ietf.org>; Wed, 17 May 2006 10:01:09 -0500 (CDT)
Received: by ii0015exch002u.iprc.lucent.com with Internet Mail Service
	(5.5.2657.72) id <KYA6833Y>; Wed, 17 May 2006 20:31:07 +0530
Message-ID: <3BE48DD0EC7D3948BC183931D9150C2102FB9B3C@ii0015exch001u.iprc.lucent.com>
From: "C D, Prashant Kumar (Prashant)" <cdprashanth@lucent.com>
To: "'ospf@ietf.org'" <ospf@ietf.org>
Date: Wed, 17 May 2006 19:30:27 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Subject: [OSPF] TOS field in Rtr-LSA
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi

What is the expected behavior if a Router-LSA is received with unknown TOS
field.

- Prashanth


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



From ospf-bounces@ietf.org Wed May 17 11:10:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgNfp-0001Co-Gi; Wed, 17 May 2006 11:10:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNfn-00016T-SA
	for ospf@ietf.org; Wed, 17 May 2006 11:10:51 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNfm-0006NJ-L3
	for ospf@ietf.org; Wed, 17 May 2006 11:10:51 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-1.cisco.com with ESMTP; 17 May 2006 08:10:50 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,138,1146466800"; 
	d="scan'208"; a="28216175:sNHT22059868"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4HFAnvF021314; 
	Wed, 17 May 2006 11:10:50 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 17 May 2006 11:10:49 -0400
Received: from [10.82.216.18] ([10.82.216.18]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 17 May 2006 11:10:49 -0400
Message-ID: <446B3CF9.3010206@cisco.com>
Date: Wed, 17 May 2006 11:10:49 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "C D, Prashant Kumar (Prashant)" <cdprashanth@lucent.com>
Subject: Re: [OSPF] TOS field in Rtr-LSA
References: <3BE48DD0EC7D3948BC183931D9150C2102FB9B3C@ii0015exch001u.iprc.lucent.com>
In-Reply-To: <3BE48DD0EC7D3948BC183931D9150C2102FB9B3C@ii0015exch001u.iprc.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 May 2006 15:10:49.0619 (UTC)
	FILETIME=[14CD5630:01C679C4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: "'ospf@ietf.org'" <ospf@ietf.org>
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

C D, Prashant Kumar (Prashant) wrote:

>Hi
>
>What is the expected behavior if a Router-LSA is received with unknown TOS
>field.
>  
>
Hi Prashanth,

I'm assuming you mean an unknown TOS for one of the link metrics.
You'd ignore it like any other deprecated field unless you
support draft-ietf-ospf-mt-06.txt. If you support 
draft-ietf-ospf-mt-06.txt,
you process it as defined in that document.

Hope this helps,
Acee

>- Prashanth
>
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>
>  
>

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



From ospf-bounces@ietf.org Wed May 17 11:23:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgNsI-00085t-P8; Wed, 17 May 2006 11:23:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNsI-00085o-2P
	for ospf@ietf.org; Wed, 17 May 2006 11:23:46 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNsG-0006xG-Ob
	for ospf@ietf.org; Wed, 17 May 2006 11:23:46 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
	by sj-iport-5.cisco.com with ESMTP; 17 May 2006 08:23:44 -0700
X-IronPort-AV: i="4.05,138,1146466800"; 
	d="scan'208"; a="278318736:sNHT39907344"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id k4HFNiq6003593; 
	Wed, 17 May 2006 08:23:44 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k4HFNhsF023060;
	Wed, 17 May 2006 08:23:43 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 17 May 2006 08:23:43 -0700
Received: from [192.168.1.104] ([10.21.115.40]) by xfe-sjc-212.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 17 May 2006 08:23:43 -0700
Message-ID: <446B4000.1040302@cisco.com>
Date: Wed, 17 May 2006 08:23:44 -0700
From: Padma Pillay-Esnault <ppe@cisco.com>
User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "C D, Prashant Kumar (Prashant)" <cdprashanth@lucent.com>
Subject: Re: [OSPF] TOS field in Rtr-LSA
References: <3BE48DD0EC7D3948BC183931D9150C2102FB9B3C@ii0015exch001u.iprc.lucent.com>
In-Reply-To: <3BE48DD0EC7D3948BC183931D9150C2102FB9B3C@ii0015exch001u.iprc.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 May 2006 15:23:43.0304 (UTC)
	FILETIME=[E1F44C80:01C679C5]
DKIM-Signature: a=rsa-sha1; q=dns; l=469; t=1147879424; x=1148743424;
	c=relaxed/simple; s=sjdkim7001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=ppe@cisco.com;
	z=From:Padma=20Pillay-Esnault=20<ppe@cisco.com>
	|Subject:Re=3A=20[OSPF]=20TOS=20field=20in=20Rtr-LSA;
	X=v=3Dcisco.com=3B=20h=3DFv7mkVhp3bWigdF/X+e2p/6Mfis=3D;
	b=DC/1ZAD1eZL1Y8BXJHQ6lKqYcAKZdADKkpmXJiE2/ZxaWqILNYpO/jFua1D/m4vJShx2cGXV
	xhclc3A1oTgJCE3xVIURlICNpXs/4knMPAs5rjVU8VMS11VGXfrvPhMd;
Authentication-Results: sj-dkim-7.cisco.com; header.From=ppe@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: "'ospf@ietf.org'" <ospf@ietf.org>
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

C D, Prashant Kumar (Prashant) wrote:

>Hi
>
>What is the expected behavior if a Router-LSA is received with unknown TOS
>field.
>  
>
Liberal in what you accept :-)

I think for good code resiliency you should silently ignore it and 
should have the same behavior
for unknown TLVs

Padma

>- Prashanth
>
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>
>  
>

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



From ospf-bounces@ietf.org Wed May 17 12:24:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgOoS-0006IZ-Id; Wed, 17 May 2006 12:23:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOoQ-0006IU-R8
	for OSPF@IETF.ORG; Wed, 17 May 2006 12:23:50 -0400
Received: from omega7.wr.usgs.gov ([130.118.4.3] helo=ns0.wr.usgs.gov)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOoP-00015u-Iq
	for OSPF@IETF.ORG; Wed, 17 May 2006 12:23:50 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392)
	id <01M2IUXUZHM8001SX4@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Wed,
	17 May 2006 09:22:00 -0700 (PDT)
Date: Wed, 17 May 2006 09:21:59 -0700 (PDT)
From: "Pat Murphy - (650)329-4044" <pmurphy@noc.usgs.net>
Subject: Re: [OSPF] ASBR election
To: HASMIT@CISCO.COM
Message-id: <01M2IUXUZIK2001SX4@omega7.wr.usgs.gov>
X-VMS-To: hasmit@cisco.com
X-VMS-Cc: PMURPHY,OSPF@ietf.org,pradg@cisco.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: OSPF@IETF.ORG, PRADG@CISCO.COM
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

>If we follow the behavior specified in RFC 3101, Section 2.4

>" NSSA border routers must originate an LSA for the default destination
>   into all their directly attached NSSAs in order to support intra-AS
>   routing and inter-AS routing.  This default destination is advertised
>   in either a Type-3 LSA or a Type-7 LSA, as described in Section 2.7.
>   The default LSA's metric should be configurable. For Type-7 default
>   LSAs, the metric type (1 or 2) should also be configurable."

>there could be multiple type-7 defaults which are functionally same

>This would lead to ECMP for the default route.

Normally a Type 7 default LSA originated by an NSSA ABR will have a 0.0.0.0 
forwarding address and, as such, is not pruned as described in Section 2.4. 
When the forwarding address of the default LSA is non-zero the above text 
would seem to indicate that pruning should not occur. Admittedly the two 
texts do conflict. However it is clear that when the forwarding address of 
the default LSA is non-zero only one is installed, per the tie breaker rule 
in Section 2.5 Step 6(e):

          (e) If the current LSA is functionally the same as an
              installed LSA (i.e., same destination, cost and non-zero
              forwarding address) then apply the following priorities in
              deciding which LSA is preferred:

                 1. A Type-7 LSA with the P-bit set.

                 2. A Type-5 LSA.

                 3. The LSA with the higher router ID.

Hence I can't see an ECMP (equal cost multi-path?) in this case. This LSA 
pruning only limits the effect on the size of the LSDB. It has no effect on 
the external route calculation of type 5 and type 7 LSAs.

Pat


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



From ospf-bounces@ietf.org Wed May 17 14:19:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgQbY-0007dS-Db; Wed, 17 May 2006 14:18:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQbX-0007dN-60
	for OSPF@ietf.org; Wed, 17 May 2006 14:18:39 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQbU-000841-Rg
	for OSPF@ietf.org; Wed, 17 May 2006 14:18:39 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-5.cisco.com with ESMTP; 17 May 2006 11:18:36 -0700
X-IronPort-AV: i="4.05,138,1146466800"; 
	d="scan'208"; a="278443736:sNHT67402412"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4HIIaIa029406; 
	Wed, 17 May 2006 11:18:36 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4HIIaB9004785;
	Wed, 17 May 2006 11:18:36 -0700 (PDT)
Received: from xmb-sjc-21d.amer.cisco.com ([171.70.151.140]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 17 May 2006 11:18:36 -0700
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
Subject: RE: [OSPF] ASBR election
Date: Wed, 17 May 2006 11:18:33 -0700
Message-ID: <C45024B55D8B9846BEDB9D66BA69ABAC02484958@xmb-sjc-21d.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OSPF] ASBR election
Thread-Index: AcZ5zmUfXAwPagKeSWyLrYTDLUQjYgADJiZw
From: "Hasmit Grover \(hasmit\)" <hasmit@cisco.com>
To: "Pat Murphy - \(650\)329-4044" <pmurphy@omega7.wr.usgs.gov>
X-OriginalArrivalTime: 17 May 2006 18:18:36.0071 (UTC)
	FILETIME=[50217B70:01C679DE]
DKIM-Signature: a=rsa-sha1; q=dns; l=2412; t=1147889916; x=1148753916;
	c=relaxed/simple; s=sjdkim4001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=hasmit@cisco.com;
	z=From:=22Hasmit=20Grover=20\(hasmit\)=22=20<hasmit@cisco.com>
	|Subject:RE=3A=20[OSPF]=20ASBR=20election;
	X=v=3Dcisco.com=3B=20h=3DD3Hq38lKXQh0TJMiC90tMrcfcsE=3D;
	b=CgaTlW/a8me1O62YN5u7PGDgc/dU/c+xzabutylMk8ylyKTdd6lsUfEtDXjT5mhs1mY0ubR7
	bVw2/dUdrXNHA2mMp52QvSKWFBrk+AH6JuofnHGODHtcDOm1YM4PbWH3;
Authentication-Results: sj-dkim-4.cisco.com; header.From=hasmit@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: OSPF@IETF.ORG
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

=20

> -----Original Message-----
> From: Pat Murphy - (650)329-4044 [mailto:pmurphy@omega7.wr.usgs.gov]=20
> Sent: Wednesday, May 17, 2006 9:22 AM
> To: Hasmit Grover (hasmit)
> Cc: OSPF@IETF.ORG; Pradeep BG (pradg)
> Subject: Re: [OSPF] ASBR election
>=20
> >If we follow the behavior specified in RFC 3101, Section 2.4
>=20
> >" NSSA border routers must originate an LSA for the default=20
> destination
> >   into all their directly attached NSSAs in order to=20
> support intra-AS
> >   routing and inter-AS routing.  This default destination=20
> is advertised
> >   in either a Type-3 LSA or a Type-7 LSA, as described in=20
> Section 2.7.
> >   The default LSA's metric should be configurable. For=20
> Type-7 default
> >   LSAs, the metric type (1 or 2) should also be configurable."
>=20
> >there could be multiple type-7 defaults which are functionally same
>=20
> >This would lead to ECMP for the default route.
>=20
> Normally a Type 7 default LSA originated by an NSSA ABR will=20
> have a 0.0.0.0 forwarding address and, as such, is not pruned=20
> as described in Section 2.4.=20
> When the forwarding address of the default LSA is non-zero=20
> the above text would seem to indicate that pruning should not=20
> occur. Admittedly the two texts do conflict. However it is=20
> clear that when the forwarding address of the default LSA is=20
> non-zero only one is installed, per the tie breaker rule in=20
> Section 2.5 Step 6(e):
>=20
>           (e) If the current LSA is functionally the same as an
>               installed LSA (i.e., same destination, cost and non-zero
>               forwarding address) then apply the following=20
> priorities in
>               deciding which LSA is preferred:
>=20
>                  1. A Type-7 LSA with the P-bit set.
>=20
>                  2. A Type-5 LSA.
>=20
>                  3. The LSA with the higher router ID.
>=20
> Hence I can't see an ECMP (equal cost multi-path?) in this=20
> case. This LSA pruning only limits the effect on the size of=20
> the LSDB. It has no effect on the external route calculation=20
> of type 5 and type 7 LSAs.
>=20

I agree there won't be ECMP in case of default LSA with forwarding
address.=20

I was referring to ECMP because normally type 7 default LSA originated
by an NSSA ABR will have 0.0.0.0 forwarding address.

- Hasmit


> Pat
>=20

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



From ospf-bounces@ietf.org Wed May 17 14:38:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgQuT-0006DG-3I; Wed, 17 May 2006 14:38:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQuS-0006B3-21
	for OSPF@IETF.ORG; Wed, 17 May 2006 14:38:12 -0400
Received: from omega7.wr.usgs.gov ([130.118.4.3] helo=ns0.wr.usgs.gov)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQuN-0000Ut-PO
	for OSPF@IETF.ORG; Wed, 17 May 2006 14:38:12 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392)
	id <01M2IZMEROHO001SX4@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Wed,
	17 May 2006 11:36:19 -0700 (PDT)
Date: Wed, 17 May 2006 11:36:19 -0700 (PDT)
From: "Pat Murphy - (650)329-4044" <pmurphy@noc.usgs.net>
Subject: Re: [OSPF] ASBR election
To: HASMIT@CISCO.COM
Message-id: <01M2IZMEROHQ001SX4@omega7.wr.usgs.gov>
X-VMS-To: hasmit@cisco.com
X-VMS-Cc: PMURPHY,ospf@ietf.org,pradg@cisco.com
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: OSPF@IETF.ORG, PRADG@CISCO.COM
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

>I agree there won't be ECMP in case of default LSA with forwarding
>address.

>I was referring to ECMP because normally type 7 default LSA originated
>by an NSSA ABR will have 0.0.0.0 forwarding address.

The default LSAs of stub areas and NSSAs with multiple border routers may 
load balance unless network implementers manually set the metrics of these 
advertisements to be different. Nowadays, with symmetric flow such a big 
deal for the successful stateful analysis of security appliances, it is 
almost imperative that this be done. From a routing perspective there is no 
requirement to change the spec. It is my hope that security will take a 
completely different more distributed architectural approach someday. I have 
seen indications that this is happening.

Pat


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



From ospf-bounces@ietf.org Thu May 18 11:16:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgkEW-0002du-SU; Thu, 18 May 2006 11:16:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgkEV-0002dp-FH
	for OSPF@ietf.org; Thu, 18 May 2006 11:16:11 -0400
Received: from ind-iport-1.cisco.com ([64.104.129.195])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgkES-0007p4-QP
	for OSPF@ietf.org; Thu, 18 May 2006 11:16:11 -0400
Received: from india-core-1.cisco.com ([64.104.129.221])
	by ind-iport-1.cisco.com with ESMTP; 18 May 2006 21:02:47 -0700
X-IronPort-AV: i="4.05,142,1146466800"; 
	d="gif'147?scan'147,208,217,147,32?doc'147,208,217,147,32,32";
	a="68010323:sNHT115956192"
Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com
	[64.104.140.150])
	by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4IFFdoe007948;
	Thu, 18 May 2006 15:15:39 GMT
Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by
	xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); 
	Thu, 18 May 2006 20:46:05 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C67A8D.FB45B8E1"
Subject: RE: RE: [OSPF] ASBR election
Date: Thu, 18 May 2006 20:46:02 +0530
Message-ID: <A547B532685E6C488A983A5B47FCEEFCA99BB5@xmb-blr-417.apac.cisco.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: RE: [OSPF] ASBR election
Thread-Index: AcZ6jdyt979j7T6WQeKql+hJ5C6ddQAAAloA
From: "Pradeep BG \(pradg\)" <pradg@cisco.com>
To: "Pradeep BG \(pradg\)" <pradg@cisco.com>,
	"Hasmit Grover \(hasmit\)" <hasmit@cisco.com>,
	"Pat Murphy - \(650\)329-4044" <pmurphy@omega7.wr.usgs.gov>
X-OriginalArrivalTime: 18 May 2006 15:16:05.0633 (UTC)
	FILETIME=[FB92FF10:01C67A8D]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: b07d3562102db4977d20bd3dd0ddf804
Cc: OSPF@IETF.ORG
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C67A8D.FB45B8E1
Content-Type: multipart/related;
	boundary="----_=_NextPart_002_01C67A8D.FB45B8E1";
	type="multipart/alternative"


------_=_NextPart_002_01C67A8D.FB45B8E1
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_003_01C67A8D.FB45B8E1"


------_=_NextPart_003_01C67A8D.FB45B8E1
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attaching Topology map

________________________________

From: Pradeep BG (pradg)=20
Sent: Thursday, May 18, 2006 8:45 PM
To: Hasmit Grover (hasmit); 'Pat Murphy - (650)329-4044'
Cc: 'OSPF@IETF.ORG'
Subject: RE: [OSPF] ASBR election


=20
Area 0 is connected to 2/3 on the SS-3

=20

=20

=20

 =20

                               =20

                             2/1
2/1

=20


=20

=20

=20

=20

INTERNET

=20
=20

=20

=20

=20

=20


Hi

GUYS

WE Are INTERLINKING THIS PROBLEM with another scenario

My question is very simple

Have 3 routers , 2 routers ss-2 and ss-1 they are in area 1(Normal area)
and both of the routers 2/1 link is connected to internet so they are
now ASBR=20

have one more router SS-3 which is ABR for area 0 and area 1 , if the 2
routers learn a prefix say (88.88.88.0) , in the routing table of ss-3
what should be displayed

1:whether it should load balance across 2 routers to the destination ?

2:or there is election b/t ss-1 and ss-2 where one router is selected as
the best to forward

3:if yes what is the criteria for selecting the best router

=20

Does RFC say anything for such a problem :-) ?

1:If all the routers are connected through a hub like broadcast access
in the area 1=20

or

2: if there is a pt to pt link b/t SS-2 and SS-3 and SS-1 and SS-3

What will be the routing table in ss-3 for both the above questions (how
to reach)

Thanks

-BG

=20


------_=_NextPart_003_01C67A8D.FB45B8E1
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D579291515-18052006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Attaching Topology map</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Pradeep BG (pradg) =
<BR><B>Sent:</B>=20
Thursday, May 18, 2006 8:45 PM<BR><B>To:</B> Hasmit Grover (hasmit); =
'Pat Murphy=20
- (650)329-4044'<BR><B>Cc:</B> 'OSPF@IETF.ORG'<BR><B>Subject:</B> RE: =
[OSPF]=20
ASBR election<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 8pt"><SPAN=20
class=3D400430915-18052006>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Area 0 is connected to 2/3 on the SS-3</SPAN></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 8pt"></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 8pt"></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 8pt"></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN =
style=3D"FONT-SIZE: 8pt"><IMG=20
height=3D339 src=3D"cid:579291515@18052006-1FAF" width=3D579=20
v:shapes=3D"_x0000_s1026 _x0000_s1027 _x0000_s1028 _x0000_s1029 =
_x0000_s1030 _x0000_s1031 _x0000_s1032 _x0000_s1033 _x0000_s1034 =
_x0000_s1035 _x0000_s1036"><SPAN=20
class=3D400430915-18052006>&nbsp;</SPAN></SPAN><SPAN=20
style=3D"FONT-SIZE: 8pt"><o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"Z-INDEX: 3; MARGIN: 4px auto auto 107px; WIDTH: 2px; POSITION: =
absolute; HEIGHT: 134px; mso-ignore: vglayout"><IMG=20
height=3D134 src=3D"cid:579291515@18052006-1FB6" width=3D2=20
v:shapes=3D"_x0000_s1038"></SPAN><SPAN=20
style=3D"Z-INDEX: 4; MARGIN: 4px auto auto 491px; WIDTH: 2px; POSITION: =
absolute; HEIGHT: 134px; mso-ignore: vglayout"><IMG=20
height=3D134 src=3D"cid:579291515@18052006-1FB6" width=3D2=20
v:shapes=3D"_x0000_s1039"></SPAN><SPAN=20
style=3D"Z-INDEX: 2; POSITION: relative; mso-ignore: vglayout"><SPAN=20
style=3D"LEFT: 95px; WIDTH: 98px; POSITION: absolute; TOP: -254px; =
HEIGHT: 146px"><IMG=20
height=3D146 src=3D"cid:579291515@18052006-1FBD" width=3D98=20
v:shapes=3D"_x0000_s1037"></SPAN></SPAN><SPAN style=3D"FONT-SIZE: =
8pt"><FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN><o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D400430915-18052006>2/1</SPAN></SPAN><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>2=
/1</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT><SPAN=20
style=3D"FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 8pt"><o:p><FONT=20
face=3D"Times New Roman">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"Z-INDEX: 5; LEFT: -25px; WIDTH: 618px; POSITION: relative; TOP: =
7px; HEIGHT: 121px; mso-ignore: vglayout">
<TABLE cellSpacing=3D0 cellPadding=3D0>
  <TBODY>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: black 0.75pt solid; BORDER-TOP: black 0.75pt =
solid; BACKGROUND: white; VERTICAL-ALIGN: top; BORDER-LEFT: black 0.75pt =
solid; BORDER-BOTTOM: black 0.75pt solid"=20
    width=3D618 bgColor=3Dwhite height=3D114><SPAN=20
      style=3D"Z-INDEX: 5; POSITION: absolute; mso-ignore: vglayout">
      <TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%">
        <TBODY>
        <TR>
          <TD=20
          style=3D"BORDER-RIGHT: #ece9d8; BORDER-TOP: #ece9d8; =
BORDER-LEFT: #ece9d8; BORDER-BOTTOM: #ece9d8; BACKGROUND-COLOR: =
transparent">
            <DIV class=3Dshape=20
            style=3D"PADDING-RIGHT: 7.95pt; PADDING-LEFT: 7.95pt; =
PADDING-BOTTOM: 4.35pt; PADDING-TOP: 4.35pt"=20
            v:shape=3D"_x0000_s1040">
            <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; =
TEXT-ALIGN: center"=20
            align=3Dcenter><o:p><FONT=20
            face=3D"Times New Roman">&nbsp;</FONT></o:p></P>
            <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; =
TEXT-ALIGN: center"=20
            align=3Dcenter><FONT=20
          face=3D"Times New =
Roman">INTERNET</FONT></P></DIV></TD></TR></TBODY></TABLE></SPAN><FONT=20
      face=3D"Times New =
Roman">&nbsp;</FONT></TD></TR></TBODY></TABLE></SPAN><o:p><FONT=20
face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P><BR style=3D"mso-ignore: vglayout" =
clear=3Dall><FONT=20
face=3D"Times New Roman" size=3D3><FONT size=3D2>
<P><FONT size=3D4>Hi</FONT></P>
<P><FONT size=3D4>GUYS</FONT></P>
<P><FONT size=3D4>WE Are INTERLINKING THIS PROBLEM with another=20
scenario</FONT></P>
<P><FONT size=3D4>My question is very simple</FONT></P>
<P><FONT size=3D4>Have 3 routers , 2 routers ss-2 and ss-1 they are in =
area=20
1(Normal area) and both of the routers 2/1 link is connected to internet =
so they=20
are now ASBR </FONT></P>
<P><FONT size=3D4>have one more router SS-3 which is ABR for area 0 and =
area 1 ,=20
if the 2 routers learn a prefix say (88.88.88.0) , in the routing table =
of ss-3=20
what should be displayed</FONT></P>
<P><FONT size=3D4>1:whether it should load balance across 2 routers to =
the=20
destination ?</FONT></P>
<P><FONT size=3D4>2:or there is election b/t ss-1 and ss-2 where one =
router is=20
selected as the best to forward</FONT></P>
<P><FONT size=3D4>3:if yes what is the criteria for selecting the best=20
router</FONT></P>
<P></FONT><FONT size=3D4></FONT>&nbsp;</P>
<P><FONT size=3D4>Does RFC say anything for such a problem <FONT=20
face=3DWingdings>J</FONT> ?</FONT></P>
<P><FONT size=3D4>1:If all the routers are connected through a hub like =
broadcast=20
access in the area 1 </FONT></P>
<P><FONT size=3D4>or</FONT></P>
<P><FONT size=3D4>2: if there is a pt to pt link b/t SS-2 and SS-3 and =
SS-1 and=20
SS-3</FONT></P>
<P><FONT size=3D4>What will be the routing table in ss-3 for both the =
above=20
questions (how to reach)</FONT></P>
<P><FONT size=3D4>Thanks</FONT></P>
<P><FONT size=3D4>-BG</FONT></P></FONT>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P></FONT></DIV></BODY></HTML>

------_=_NextPart_003_01C67A8D.FB45B8E1--

------_=_NextPart_002_01C67A8D.FB45B8E1
Content-Type: image/gif;
	name="clip_image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <579291515@18052006-1FAF>
Content-Description: clip_image001.gif
Content-Location: clip_image001.gif

R0lGODlhAgBEAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAQAB
AEIAgAAAAAAAAAIGjI+py+1fADs=

------_=_NextPart_002_01C67A8D.FB45B8E1
Content-Type: image/gif;
	name="clip_image002.gif"
Content-Transfer-Encoding: base64
Content-ID: <579291515@18052006-1FB6>
Content-Description: clip_image002.gif
Content-Location: clip_image002.gif

R0lGODlhQwJTAXcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAsAIwA1
Ai0BgQAAAAAAAP///wECAwL/hI+py+0Po5y0hYuz3rz7D4biSJbmiaaqV7XuC8fyTNf2jdOBwPf+
DwwKh8Si8YhMKpfMpvMpDOSm1Kr1is1qWzuo9wsOi8fksk+6TavX7LYb1zXL5/S63Y5+6/f8vn8a
dyc4SFhYmPeXqLjI6BdoCBkpOZmE2HiJmampQ9np+SlpuTlKWlr6CJqquvolavoKG7uHylprexvk
KrvL2wuICxyMq+tbbHwsQSu8zAxJjAwdjazcXG099yytvQ1Lff0N7pXNTV5+6R2ern40bu7+Prsu
P4/UDn+Pr4VOz69unw8w4I19/Qpe+ycwoUIuBhvOQ7gwokQGBB1aHDYxo8YJ/xUvelwFcaNIgR0/
mvQUcqTKeyVPuoyUcqXMci1f2hwUc6ZOaTVv+qSTc6dQYz1/GiUTdKjSXUWPOm21NOq7pk+rNkkq
Nesmqla71tMKlqfXsXKwhj2biGtVtU7YhkILt5dbhxmGUEP14UyHXN/Mxv3bZq7BLhj4RlF24Udi
vYyBCCbkF7DkLY/5BVp8hkhhx3gvP8KcuVrkyaStVG4IWkDqzKtVd27co3VrjKVrMzoNMnGcwhXx
auaxOrhnxYhF2z6e1uJuwrH3Cf/tmjPx6c3t4saGPDuf66AuAw9tfTPwu9WJb+CsQTN3M6O1u6+w
HuVrJeKjR4E93nzj2eWXtf9/DyAE8XWS3njiFahffrlwQJ1eyxmoXjP/BUjhAgMSWJeBiyHY4Gyf
fbhgf/zZ51+FJlZx4SfP1fOgYyH2Bxto/I3IyoQnmphiKKF5Vw9+sb2oYIeeIZYjGDbeSGGRzuwW
5F0twkiig1BGmVp9P0qIZJac0OUak1aaJ9uQH47QXIYa+hjMkVq6pyRZNqm5ZnZtuukSnHEeNyed
Jtl5Z2156ukRn31qtUKhhh6KaKKKLsroCQI2msGgKq2XjaB3BkWppCNlaoGmWOTEqacZhWqhqFfE
RKqpC6WKgKWapsSqqiTVoYurnoYUq6wA5WrrrQjlqis+sfZq6j/ABguPczL/gpeLAsSqao+y3n2p
GLIKocPkd0E2m8Cz0EaA7ZUkeuOttX90xNx35HZrbhrjoKuuuNy2mw+8qv247gHl6lppJdpSewa9
u/p7b8H5GrAvvw70duUO2Apcb4/xahuFvhCrQQxB08rr2MUsscMah9UCkLC1tRrBXLoFV+zxVChP
zGzHJLeMsYVFpLfcwzSbg21dvtk1887uOkur0DTRWrLAF7RatNHcUJo0xHkc67QvVFdNBRpXYy3L
1lzDQXLTX08j9tj6eG02KWinvSV2bBez9tsxxC13I5BqUPenZecdUdRV340B3xP5/TXhgkdjONeJ
Hw4342ws7fhZi5s9eeSm/1Q+NuaWa6J55psv1Tnlnw8Vuuijz1R62qmf7sbqqrO+KeyzyD4q7bPb
fi3ut+u+K+96QO77VMHvPvzTxRN/POLJ/7688s2/4frzC0vPPPW8RD869tYjvH313av9vffhZ6I9
7OUvf77545+z/nbp+/4+7fHbPr/87fdRP/33I78///3r87+0BHBoAzxXAbOQv+AlUHALVOABs/bA
RTTwbRMcXgU9F8HbXPBvGcTEBo32weOFsGUjFGEH4XPCraQwGSvkXAun90LyxdBZM3RhDbl3Qw/e
sITd46GofNjDGAKxh0OMUxG/d0QkJRGJHVwiEx/oxPBFkU05tFoBpzg+LP/aRotZ7B8X1/dFwISx
i2CsIk/IaEbEjZFQadzGGqPyRi9SL47/o6NO7ChH9LVReCbcIx8t6MdkATKQguQdHjN4yFURsl64
S2QTHSmsRSYEkoWUZEAsBTjgoYWSK+QT3VbCyRba6ZOTsqRE4ERKkYRSiKbZW1ZWOcMjpVIjsIxl
1lwJR1PGLgezPKUuSwkHXCqlllXU5Ax6qchfyiQy0gqZzqRCzD36JVwUw8zBzpHJYypzJ2axl8M4
NrJzCJMj2xQKVrwJIc2Qb5zgKifpZMCwf62MZeIEytzc+U4YaIw14AyYB9n5gGiaElQvu5fKrnkb
gHYKn6B7Qc94U6abrdP/ni4Q6C9hpdB4UBSFDIUmQzZqt4yyq6Ov/JVIoXdSi5GUjclIaWBQtiyK
0ZOFKwVLtFz6uJuJizDPbGdNw9IOZOpNYimTKDl/ClQB4XQN6DSoUX2K1KQubKkYk5hT5zmvgEYV
Ls8Q6qlAhi8zZRWGW5WcBajqroJ+M2Yy02pZuUoRtFLmZj5TzFMX+la4Eg2kCeVrqfIaF1F4tZV+
HSlgA4uIwaKInRY9LA0RJld9MNaxk9FaZBE4zsZSloaKvWVhg7bZynb2F5/VLL8yidrUqvZuGnWb
YTf7J0BB5XeuNC2/ZNuX1pblsaENG26tkbBU2fa2vzUObUE6XOIWlxnB/y1bcmUV2+UyobkbfS50
pctc3bIHh71lGnaFQV23Wfe6302TdssghfGSt7y0QSlQ1Lte9toivautr33va4LTRVe+dOXvLeD7
iv369zADrgWAL1fgGgk4wf783IIZvC0IE0i/Eu7OgyF84FNUWEUXZnCG1bZh+YR4wtkbMSVoZOLL
gjDFoehwgj88ChcXGMUs3m2Ja2wIGuMYKRTeMWRkPGAYb8XHPyYyTnpsZDwA2b9C5lyS76DjJ0Oh
yROVMjaWzF8q/5MdupESNaFTpvrsxUUF7UeUrXwVJIPZmlOKqE7JjFUe2VU9WJ5yndmr5XqCWZ5s
nbNdsDpPOd/HOYO5c/958xzSN8PZqoNetKD5QuiCnBnNS0B0X/srHUZDGs6f6eda90yPSVO6EmrG
dINA7ecxdeZL2fqzpA39XUtLsNL3UbRh4izTanLa1qGGNXZlrYiaFKdLnQ5PlThGLrHe2jK+li6w
k8NrleV60X6WaatzfW1A93kdoh41O0oNpCdFetmBZpagi11rMzd7uc8+18vE3CWYrjpn59FQvc2k
7HQy29voBTe/xbHu4rbbEf8eQ7cLPlPLBfy3OoZoRJ00bnuLKd/apvZD/I3wq+yzSW1e2ZfBg25t
P3QwGM94pSNusGqb+88/s7ZOUX7xG5vczmVWuab5We1Huwjm8hg4/mb/DnAuA+nm+No1yDfN65g7
GOg0Z9HQUb1TMKEnOP3ctj9KznSY0prcXD/6jozudVebGetZj9DWySzWhx4b23Sm0cK/LfOy0wfl
0q643dke9Zhlm1wkj7vcnW5qcYtd5DlfubxCbvGek/3vmf4NvAEmcalL/EAeOJPlE2SZxTMeTZsH
mt87bx3Qw33pojd16RMeubfL9uBZ9/l2Tm922I819bIncO3bujnVA4r1THf9eW/Pe6D7/ri353zt
h+/e4ndc9shvnfKNz3zNgz74M2/+S58f4eJbP6fYj5Lyt8/U7ntf+9LvPPVNDv6qdv/8GU9/Wtev
ez25f67wF//8JVv///WXf/PsR/j9MZt/2Pd/QyWA8UcnA/hVAfh8CEhYBWh/+8d4/VdwDLhYCvh9
EPh3EvhvFOhZDqh/nwd8BugmHEhaHiiAGCh3GshvJMhL9ieCZMGCwWSB5AeCx/eCYxGDA+GCD1iD
zHeDXpGDNvCDXaGC3haENTCEVlGEo3aEbbOASbgWKFh2S0hpTXhMO/iBpGeCCyiFrQeFT2GF8ISF
J9iDsEeFaBaGczOGXFiGp3eGVpaG+rSGF9iGpfeGUhaHDjWHNKiFT8iDffh9X+gUeVhRewh8Xdh7
gngUhPhRW0iHgKh9imgUjAgfhnh8iCh8kvgTlEgBmugTd/hknMgRljsYfXUoeqCYZKLYUjN4iKY4
fZ54E6oILqRohphYfbD4JraIfrj4ErKoVPCHX8EojMNoTKlHjMeIjKhVAAA7

------_=_NextPart_002_01C67A8D.FB45B8E1
Content-Type: image/gif;
	name="clip_image003.gif"
Content-Transfer-Encoding: base64
Content-ID: <579291515@18052006-1FBD>
Content-Description: clip_image003.gif
Content-Location: clip_image003.gif

R0lGODlhAgCGAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAQAB
AIQAgAAAAAAAAAIKjI+py+0Po5ywAAA7

------_=_NextPart_002_01C67A8D.FB45B8E1--

------_=_NextPart_001_01C67A8D.FB45B8E1
Content-Type: application/msword;
	name="Toploogy.doc"
Content-Transfer-Encoding: base64
Content-Description: Toploogy.doc
Content-Disposition: attachment;
	filename="Toploogy.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAQAAAAAAAAAAA
EAAAQgAAAAEAAAD+////AAAAAEEAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAe2AJBAAA+BK/AAAAAAAAEAAAAAAABgAAEQ4AAA4AYmpiau5G7kYAAAAAAAAAAAAAAAAAAAAA
AAAJBBYALiAAAIwsAACMLAAAlQUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAewAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAANADAAAAAAAA0AMAANAD
AAAAAAAA0AMAAAAAAAB8CAAAAAAAAHwIAAAAAAAAfAgAABQAAAAAAAAAAAAAAJAIAAAAAAAA+BMA
AAAAAAD4EwAAAAAAAPgTAAAAAAAA+BMAABwAAAAUFAAAJAAAAJAIAAAAAAAAmR4AAPIAAABEFAAA
FgAAAFoUAAAAAAAAWhQAAAAAAABaFAAAAAAAAFoUAAAAAAAAhxsAAAAAAACHGwAAAAAAAIcbAAAA
AAAAGB4AAAIAAAAaHgAAAAAAABoeAAAAAAAAGh4AAAAAAAAaHgAAAAAAABoeAAAAAAAAGh4AACQA
AACLHwAAaAIAAPMhAABgAAAAPh4AABUAAAAAAAAAAAAAAAAAAAAAAAAAfAgAAAAAAAAIHAAAAAAA
AAAAAAAAAAAAAAAAAAAAAADPGgAAuAAAAIcbAAAAAAAACBwAAAAAAAAIHAAAAAAAAD4eAAAAAAAA
AAAAAAAAAADQAwAAAAAAANADAAAAAAAAWhQAAAAAAAAAAAAAAAAAAFoUAAB1BgAAUx4AABYAAAAs
HQAAAAAAACwdAAAAAAAALB0AAAAAAAAIHAAAHAAAANADAABeAwAAWhQAAAAAAAB8CAAAAAAAAFoU
AAAAAAAAGB4AAAAAAAAAAAAAAAAAACwdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAACBwAAAAAAAAYHgAAAAAAAAAAAAAAAAAALB0AAAAAAAAAAAAA
AAAAACwdAAAAAAAALgcAAE4BAAB8CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALB0AAAAAAABaFAAAAAAAADgUAAAMAAAAYKy8Yox6
xgEAAAAAAAAAAPgTAAAAAAAAJBwAAIgAAAAsHQAAAAAAAAAAAAAAAAAAGB4AAAAAAABpHgAAMAAA
AJkeAAAAAAAALB0AAAAAAABTIgAAAAAAAKwcAABkAAAAUyIAAAAAAAAsHQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAs
HQAAgAAAAFMiAAAAAAAAAAAAAAAAAAB8CAAAAAAAAKwdAABsAAAAhxsAABQAAACbGwAADgAAACwd
AAAAAAAAqRsAAAwAAAC1GwAAUwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhxsA
AAAAAACHGwAAAAAAAIcbAAAAAAAAPh4AAAAAAAA+HgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAEB0AABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIcbAAAA
AAAAhxsAAAAAAACHGwAAAAAAAJkeAAAAAAAACBwAAAAAAAAIHAAAAAAAAAgcAAAAAAAACBwAAAAA
AAAAAAAAAAAAAJAIAAAAAAAAkAgAAAAAAACQCAAAJAsAALQTAABEAAAAkAgAAAAAAACQCAAAAAAA
AJAIAAAAAAAAtBMAAAAAAACQCAAAAAAAAJAIAAAAAAAAkAgAAAAAAADQAwAAAAAAANADAAAAAAAA
0AMAAAAAAADQAwAAAAAAANADAAAAAAAA0AMAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAggICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIEFSRUEwIBMgU0hBUEUgIFwqIE1FUkdFRk9STUFUIBQIARUNCAgIICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAyLzENICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyLzENDQ0NDQgNDQ0NDUludGVy
bmV0DQ0NSGkNDUdVWVMNDVdFIEFyZSBJTlRFUkxJTktJTkcgVEhJUyBQUk9CTEVNIHdpdGggYW5v
dGhlciBzY2VuYXJpbw0NTXkgcXVlc3Rpb24gaXMgdmVyeSBzaW1wbGUNDUhhdmUgMyByb3V0ZXJz
ICwgMiByb3V0ZXJzIHNzLTIgYW5kIHNzLTEgdGhleSBhcmUgaW4gYXJlYSAxKE5vcm1hbCBhcmVh
KSBhbmQgYm90aCBvZiB0aGUgcm91dGVycyAyLzEgbGluayBpcyBjb25uZWN0ZWQgdG8gaW50ZXJu
ZXQgc28gdGhleSBhcmUgbm93IEFTQlIgDQ1oYXZlIG9uZSBtb3JlIHJvdXRlciBTUy0zIHdoaWNo
IGlzIEFCUiBmb3IgYXJlYSAwIGFuZCBhcmVhIDEgLCBpZiB0aGUgMiByb3V0ZXJzIGxlYXJuIGEg
cHJlZml4IHNheSAoODguODguODguMCkgLCBpbiB0aGUgcm91dGluZyB0YWJsZSBvZiBzcy0zIHdo
YXQgc2hvdWxkIGJlIGRpc3BsYXllZA0NMTp3aGV0aGVyIGl0IHNob3VsZCBsb2FkIGJhbGFuY2Ug
YWNyb3NzIDIgcm91dGVycyB0byB0aGUgZGVzdGluYXRpb24gPw0yOm9yIHRoZXJlIGlzIGVsZWN0
aW9uIGIvdCBzcy0xIGFuZCBzcy0yIHdoZXJlIG9uZSByb3V0ZXIgaXMgc2VsZWN0ZWQgYXMgdGhl
IGJlc3QgdG8gZm9yd2FyZA0zOmlmIHllcyB3aGF0IGlzIHRoZSBjcml0ZXJpYSBmb3Igc2VsZWN0
aW5nIHRoZSBiZXN0IHJvdXRlcg0NRG9lcyBSRkMgc2F5IGFueXRoaW5nIGZvciBzdWNoIGEgcHJv
YmxlbSAoID8NDTE6SWYgYWxsIHRoZSByb3V0ZXJzIGFyZSBjb25uZWN0ZWQgdGhyb3VnaCBhIGh1
YiBsaWtlIGJyb2FkY2FzdCBhY2Nlc3MgaW4gdGhlIGFyZWEgMSANICAgICAgICAgICAgICAgICAg
ICAgb3INMjogaWYgdGhlcmUgaXMgYSBwdCB0byBwdCBsaW5rIGIvdCBTUy0yIGFuZCBTUy0zIGFu
ZCBTUy0xIGFuZCBTUy0zDQ1XaGF0IHdpbGwgYmUgdGhlIHJvdXRpbmcgdGFibGUgaW4gc3MtMyBm
b3IgYm90aCB0aGUgYWJvdmUgcXVlc3Rpb25zIChob3cgdG8gcmVhY2gpDQ1UaGFua3MNLUJHDQ0N
U1MtMiBBUkVBIDENDSAgICAgICAgDVNTLTEgQVJFQSAxDQ0NDSAgICAgICAgICAgICAgICAgIHNz
LTMoQUJSKQ0NMi80DQ0NDTIvOA0NMi80DQ0NDQ0NDQ0yLzgNDQ0NDQ0NDQ0NDQ0NDQ0NDUlOVEVS
TkVUDQ0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAEIAABI
CAAATQgAAE4IAABPCAAAZggAAGcIAABoCAAAaggAAGsIAABsCAAAbQgAAG4IAACMCAAAjQgAAKoI
AAAACQAAAwkAAAQJAACrCQAAugkAAL4JAADACQAAwQkAAMIJAADu5uLXyL3IqMig7o58dGxlYVpT
WmFaS0dDAAAAAAAGFmgMceoAAAYWaFg6pwAADhZozSfzAENKEABhShAAAAwVaKJ5XgAWaAMYaQAA
DBVoonleABZoDHHqAAAGFmiieV4AAAwVaKJ5XgAWaKJ5XgAADhZoAxhpAENKEABhShAAAA4WaAxx
6gBDShAAYUoQAAAiA2oAAAAAFmgMceoAQ0oQAFUIAWFKEABtSAAEbkgABHUIAQAiA2oAAAAAFmhS
dXIAQ0oQAFUIAWFKEABtSAAEbkgABHUIAQAOFmiZXiwAQ0oQAGFKEAAAKANqAAAAABVomV4sABZo
mV4sAENKEABVCAFhShAAbUgABG5IAAR1CAEAFBVomV4sABZomV4sAENKEABhShAAAB0DagAAAAAV
aJleLAAWaJleLABDShAAVQgBYUoQABQVaJleLAAWaA0gcABDShAAYUoQAAAGFmgNIHAAAA4WaA0g
cABDShAAYUoQAAAiA2oAAAAAFmiieV4AQ0oQAFUIAWFKEABtSAAEbkgABHUIARkABgAAawgAAI0I
AAAECQAAvgkAAL8JAADACQAAwQkAAMIJAADECQAAxQkAAMYJAADHCQAAyAkAANEJAADSCQAA0wkA
ANYJAADXCQAA3AkAAN0JAAAUCgAAFQoAADAKAAAxCgAAygoAAMsKAABzCwAAdAsAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAGdkDHHqAAABAAAAHAAGAACVDQAAEA4A
AP39AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQECwgkAAMMJAADRCQAA
CwoAABMKAABsCgAAlgoAAMkKAADLCgAAcwsAAHQLAABUDAAAfgwAAH8MAACCDAAAgwwAAIUMAADJ
DAAA2AwAANkMAADwDAAA8QwAADQNAACIDQAAlA0AAJUNAACWDQAAoQ0AAKwNAACwDQAAuA0AALsN
AADNDQAA0Q0AANYNAADXDQAA2A0AANsNAADcDQAA3w0AAOINAADjDQAA5A0AAOcNAADoDQAA7w0A
APINAADzDQAA9A0AAPLu6ubq5urm6ubq5t/m29fb19vT19vX5urPy8/my8/HvLGmz56Tz4uAz4uA
z4uAzwAAAAAAAAAAAAAAABQVaJleLAAWaJleLABDShAAYUoQAAAOFmi3I40AQ0oQAGFKEAAAFBVo
mV4sABZomV4sAENKEgBhShIAAA4WaLcjjQBDShIAYUoSAAAUFWhBZukAFmiZXiwAQ0ogAGFKIAAA
FBVoQWbpABZoQWbpAENKIABhSiAAABQVaEFm6QAWaFJ1cgBDSiAAYUogAAAGFmhSdXIAAAYWaEFm
6QAABhZomV4sAAAGFmigffgAAAYWaIojbAAABhZoj0EDAAAMCWoDAErwFmjDAAUAAAYWaMMABQAA
BhZoyRSAAAAGFmgMceoAABoDagAAAAAWaCBM6ABVCAFtSAAEbkgABHUIATB0CwAAuwsAABgMAABU
DAAAVQwAAIIMAACDDAAA2QwAAPEMAAA0DQAANQ0AAIgNAACJDQAAkA0AAJQNAACVDQAAlg0AAKIN
AACjDQAArA0AALgNAAC5DQAAug0AALsNAADXDQAA2A0AANwNAADdDQAA3g0AAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAA
AAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAA
AAAA+AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAAAAAAAAAAABAAAZ2RBZukAAAQAAGdkonleAAABAAAAHN4NAADfDQAA4w0AAOQN
AADoDQAA6Q0AAOoNAADrDQAA7A0AAO0NAADuDQAA7w0AAPMNAAD0DQAA9Q0AAPYNAAD3DQAA+A0A
APkNAAD6DQAA+w0AAPwNAAD9DQAA/g0AAP8NAAAADgAAAQ4AAAIOAAD9AAAAAAAAAAAAAAAA+AAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAEAABnZLFbXAAABAAAZ2SieV4AAAEAAAAb9A0AAAIOAAADDgAADA4A
AA0OAAAPDgAAEA4AABEOAAD8+PT88Oz4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAYWaMReMQAABhZozSfzAAAGFmggTOgAAAYWaMkUgAAABhZoWDqnAAcCDgAAAw4AAAwOAAANDgAA
Dg4AAA8OAAAQDgAAEQ4AAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPAA
AAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAQAAAAQAAGdkIEzoAAAHAAADJAFhJAFnZMkUgAAABywAMZBoAR+w0C8gsOA9IbAI
ByKwCAcjkKAFJJCgBSWwAAAXsNACGLDQAgyQ0AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAAAAEQAZAAAAAAAAAACAAAA
AAAAAAAAAAAAACAc4BCwBI8EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwRAAA
ALIECvAIAAAAAQQAAAAKAAAzAAvwEgAAAH8AQAFAAQABEAD//wEB8P8AABMAIvEGAAAAPwUBAAEA
AAAQ8AQAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYCEAASAAEAnAAPAAQAAAAAAAAAAAAEAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAEDx
/wIAQAAMAAAAAAAAAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAYAENKGABfSAEEYUoYAG1ICQRzSAkE
dEgJBAAAAAAAAAAAAAAAAAAAAAAAAEQAQUDy/6EARAAMAQAAAAAAAAAAFgBEAGUAZgBhAHUAbAB0
ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABSAGlA8/+zAFIADAEAAAAAAAAAAAwA
VABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAAYfYDAAAC
AAsAAAAoAGsA9P/BACgAAAEAAAAAAAAAAAcATgBvACAATABpAHMAdAAAAAIAAAAAAAAAKgBXQKIA
8QAqAAwAAAADGGkAAAAGAFMAdAByAG8AbgBnAAAABgA1CIFcCIEAAAAADgAAACUAAABDAAAASAAA
AEkAAABKAAAATwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABfAAAAYAAAAGEAAABiAAAA
YwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAAB4AAAAeQAAAHoAAAAR
BgAAAQAAAAAAAAAAAP////8FBAAAAAAAAAEAAAAAAAAAAAD/////BgQAAAAAAAABAAAAAAAAAAAA
/////wQEAAAAAAAAAQAAAAAAAAAAAP////8RBAAAAAAAAAUAAAABAAAAAQD/////AAAAAAAAAAD/
////AAAAAAEA/////wAAAAAAAAAAAQAAAAAAAAAAAP////8ZBAAAAAAAAAEAAAAAAAAAAAD/////
EwQAAAAAAAAEAAAAAgAAAAEA/////wAAAAAAAAAADQAAAAQAAAABAP////8AAAAAAAAAAAsAAAAG
AAAAAQD/////AAAAAAAAAAAJAAAABQAAAAEA/////wAAAAAAAAAACgAAAAcAAAABAP////8AAAAA
AAAAAAgAAAADAAAAAQD/////AAAAAAAAAAABAAAAAAAAAAAA/////xwEAAAAAAAAHwAAAAoAAAAB
AP////8AAAAAAAAAAA8AAAALAAAAAQD/////AAAAAAAAAAAQAAAADAAAAAEA/////wAAAAAAAAAA
EQAAAA0AAAABAP////8AAAAAAAAAABIAAAAOAAAAAQD/////AAAAAAAAAAATAAAADwAAAAEA////
/wAAAAAAAAAAFAAAABAAAAABAP////8AAAAAAAAAABUAAAARAAAAAQD/////AAAAAAAAAAAWAAAA
EgAAAAEA/////wAAAAAAAAAAFwAAABMAAAABAP////8AAAAAAAAAABgAAAAUAAAAAQD/////AAAA
AAAAAAAZAAAAFQAAAAEA/////wAAAAAAAAAAGgAAABYAAAABAP////8AAAAAAAAAABsAAAAXAAAA
AQD/////AAAAAAAAAAABAAAAAAAAAAAA/////zwEAAAAAAAADAAAAAgAAAABAP////8AAAAAAAAA
AB4AAAAJAAAAAQD/////AAAAAAAAAAAcAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAlAAAA
QwAAAEgAAABJAAAASgAAAE8AAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAXwAAAGAAAABh
AAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAeAAAAHkA
AAB6AAAAfQAAAAAAAAAAAAEAAAAAAAIAAAAAEAMAAAAAEAQAAAAACAUAAAAACAYAAAAAAAcAAAAA
AAgAAAAACAkAAAAACAoAAAAACAsAAAAACAwAAAAACA0AAAAACA4AAAAAAA8AAAAACBAAAAAACBEA
AAAACBIAAAAACBMAAAAACBQAAAAACBUAAAAACBYAAAAACBcAAAAACBgAAAAACBkAAAAACBoAAAAA
CBsAAAAACBwAAAAACB0AAAAAAB4AAAAACB8AAAAACP//AAAAAAAAAAARBgAABAAAIAAAAAD/////
AAAAAGsAAACNAAAABAEAAL4BAAC/AQAAwAEAAMEBAADCAQAAxAEAAMUBAADGAQAAxwEAAMgBAADR
AQAA0gEAANMBAADWAQAA1wEAANwBAADdAQAAFAIAABUCAAAwAgAAMQIAAMoCAADLAgAAcwMAAHQD
AAC7AwAAGAQAAFQEAABVBAAAggQAAIMEAADZBAAA8QQAADQFAAA1BQAAiAUAAIkFAACQBQAAlAUA
AJUFAACWBQAAogUAAKMFAACsBQAAuAUAALkFAAC6BQAAuwUAANcFAADYBQAA3AUAAN0FAADeBQAA
3wUAAOMFAADkBQAA6AUAAOkFAADqBQAA6wUAAOwFAADtBQAA7gUAAO8FAADzBQAA9AUAAPUFAAD2
BQAA9wUAAPgFAAD5BQAA+gUAAPsFAAD8BQAA/QUAAP4FAAD/BQAAAAYAAAEGAAACBgAAAwYAAAwG
AAANBgAADgYAAA8GAAASBgAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA
AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA
gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA
AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA
gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA
AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA
AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA
AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA
AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA
AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAH
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY
AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA
AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAA
MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAA
AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA
AAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA
AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAA
gAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAA
AACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAA
gAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA
AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA
AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA
AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA
AIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
gAAAAAAAjQAAABIGAABqiwAwADAAAAAAAAACAAAABgAAAAEAAADos70HCgAAAAAwAAAAAAAAAAAA
AAAABjBBAQAAAAAABwAGAADCCQAA9A0AABEOAAAIAAAACwAAAA4AAAAABgAAdAsAAN4NAAACDgAA
EQ4AAAkAAAAMAAAADQAAAA8AAAAABgAAEA4AAAoAAABOAAAAZgAAAGkAAAARBgAAk18U/xWcDwAA
8DgAAAAAAAbwGAAAAAIIAAACAAAAPAAAAAEAAAABAAAAPQAAAEAAHvEQAAAA//8AAAAA/wCAgIAA
9wAAEAAPAALwLAYAABAACPAIAAAAEQAAADwEAAAPAAPwygUAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA
AAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8AA/AIBAAADwAE8IYAAAABAAnwEAAAAAgHAACg
BQAAyCgAAFAZAAACAArwCAAAAAMEAAABAgAAIwAL8AwAAAB/AMABwAG/AwAAIABzACLxKgAAAI8D
AAAAAJADAwAAAJEDAAAAAJIDAwAAAL8DAAIAAgAFAAAAAD8FAQABAAAAEPAEAAAAAQAAAAAAEfAE
AAAAAQAAAA8ABPBgAAAAsgQK8AgAAAACBAAAAgoAAGMAC/AkAAAAfwAEAAQAWAEAAAAAfwE5ADkA
vwEBABEA/wEAAAgAPwMAABAAAAAP8BAAAAAIBwAAoAUAAMgoAABQGQAAAAAR8AQAAAABAAAADwAE
8E4AAAASAArwCAAAAAQEAAACCgAAEwAL8AYAAACAAAAAAwAAAA/wEAAAACwQAAC8BwAAPB4AAIwK
AAAAABHwBAAAAAEAAAAAAA3wBAAAAAAAAwAPAATwTgAAABIACvAIAAAABQQAAAIKAAATAAvwBgAA
AIAAAAABAAAAD/AQAAAAvAcAAPwSAABIEgAAUBkAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAABAA8A
BPBOAAAAEgAK8AgAAAAGBAAAAgoAABMAC/AGAAAAgAAAAAIAAAAP8BAAAAA8HgAASBIAAMgoAABQ
GQAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAAIADwAE8FQAAABCAQrwCAAAAAcEAABCCgAAQwAL8BgA
AABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAAA/wEAAAAKgMAACMCgAASBIAAPwSAAAAABHwBAAA
AAEAAAAPAATwVAAAAEIBCvAIAAAADwQAAAIKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8B
EAAQAAAAD/AQAAAAiB0AAIwKAAD4JQAASBIAAAAAEfAEAAAAAQAAAA8ABPBOAAAAEgAK8AgAAAAR
BAAAAgoAABMAC/AGAAAAgAAAAAQAAAAP8BAAAAB4DwAAjAoAAJQRAAD0CwAAAAAR8AQAAAABAAAA
AAAN8AQAAAAAAAQADwAE8E4AAAASAArwCAAAABMEAAACCgAAEwAL8AYAAACAAAAACAAAAA/wEAAA
AIwKAADgEAAAqAwAAPwSAAAAABHwBAAAAAEAAAAAAA3wBAAAAAAACAAPAATwTgAAABIACvAIAAAA
GQQAAAIKAAATAAvwBgAAAIAAAAAHAAAAD/AQAAAA8B4AAIwKAAAMIQAA9QsAAAAAEfAEAAAAAQAA
AAAADfAEAAAAAAAHAA8ABPBOAAAAEgAK8AgAAAAcBAAAAgoAABMAC/AGAAAAgAAAAA8AAAAP8BAA
AAD4JQAALBAAABQoAABIEgAAAAAR8AQAAAABAAAAAAAN8AQAAAAAAA8ADwAE8EgAAABCAQrwCAAA
ADgEAABACgAAQwAL8BgAAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAAQAAAAAABHw
BAAAAAEAAAAPAATwSAAAAEIBCvAIAAAAOQQAAEAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQ
AP8BEAAQAAAAEPAEAAAAAgAAAAAAEfAEAAAAAQAAAA8ABPBIAAAAQgEK8AgAAAA6BAAAQAoAAEMA
C/AYAAAARAEEAAAAfwEAAAEAvwEAABAA/wEQABAAAAAQ8AQAAAADAAAAAAAR8AQAAAABAAAADwAE
8EgAAABCAQrwCAAAADsEAABACgAAQwAL8BgAAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDw
BAAAAAAAAAAAABHwBAAAAAEAAAAPAATwQgAAABIACvAIAAAAPAQAAAAKAAATAAvwBgAAAIAAAAAe
AAAAEPAEAAAABQAAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAAeAA8ABPBCAAAAEgAK8AgAAAABBAAA
AA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAAAAAA
AGcAAABrAAAAbAAAAG0AAADCAQAAEQYAADsEAAB4DwAATP///3gPAAAwAwAAdAAAAAAAAwQAAAAA
AAAAAAAAwCEAALATAAB0gAAAAAA5BAAAVAYAAEQAAABUBgAAAAgAAHQAAAAAADoEAADUHAAARAAA
ANQcAAAACAAAdAAAAAAAOAQAAKAFAAAs8f//QAsAAJz5//90AAAAAAA8BAAAmP7//3QAAAB0IgAA
yAYAAHQAAAAAAP//AQAAAAYAIVVrABAAAQDkVKEGbQIAABIGAAAAAAAAAQBzAgAAEgYAAAAAAAAB
AAAAOQAAAAEAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwWA
cGxhY2UAgAwAAAFkGK8GAAAAAAEAAAAAAAAAAADuBAAA8AQAAJUFAAASBgAABwAEAAcABwAAAAAA
OAIAAEECAADLAgAAzwIAAHUDAAB9AwAAvAMAAL8DAAAZBAAAHAQAAHYEAAB/BAAAhAQAAIcEAADZ
BAAA8QQAAIEFAACGBQAAlQUAAM0FAADSBQAAEgYAAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHAAQABwAzAAcABwAzAAcAAAAAAIMEAACFBAAAyQQAANgEAADZBAAA8QQAAPIEAACHBQAAlAUA
AJUFAAChBQAAogUAAKIFAACjBQAADwYAABIGAAADAAQAAwAEAAMABAADAAQAAwAHAAQAAwAEAAMA
BAAHAAAAAADuBAAA8AQAAJUFAAASBgAABwAEAAcABwAHABwPtQmSQvYcAAAAAAAA/zxCFZJC9hwA
AAAAAACSQvYcFDQ4bgAAAAAdARYAVAAAAGQAAABkAAAAAAD/AAwBBAABAIJYlx2SQvYcAAAAAAAA
TyGgQ5JC9hwAAAAAAAABPPxWkkL2HAAAAAAAABQ0OG4AAAAAAAAAAAABAgACABUAAAAEAAAACAAA
AOUAAAAAAAAAFAAAAI9BAwDDAAUAmV4sAIUlMADEXjEAJ2A3ALFbXACieV4AAxhpAIojbAANIHAA
UnVyAMkUgAC3I40AWDqnACBM6ABBZukADHHqAM0n8wCgffgABlT7AP9AA4ABAPAEAADwBAAAPI2C
BQEAAQDwBAAAAAAAAPAEAAAAAAAAAhAAAAAAAAAAEQYAAEAAABAAQAAA//8BAAAABwBVAG4AawBu
AG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAQA
AABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBl
AHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAA
UwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQBy
AGkAYQBsAAAAOwaQAQIABQAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFcAaQBuAGcA
ZABpAG4AZwBzAAAAIgAEADEIiBgA8NACAABoAQAAAACP46JGIpWlhgAAAAAnAKsAAADVAAAAwAQA
AAEAAgAAAAQAAxAKAAAA1QAAAMAEAAABAAIAAAAKAAAAAAAAANECAPAQAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAgHoAW0ALQAgYESNAAAEAAZAGQAAAAZAAAAkwUAAJMFAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAA
AAAAADKDUQDwEAAIAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWAAAAAAJ8P8PAQABPwAA
5AQAAP///3////9/////f////3////9/////f////3+ZXiwAAAAAADIAAAAAAAAAAAAAAAAAAQAA
AP//EgAAAAAAAAABACAAAAAAAAAAEwBDAGkAcwBjAG8AIABTAHkAcwB0AGUAbQBzACwAIABJAG4A
YwAuAAcAUAByAGEAZABlAGUAcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ
MAAAAHgBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAACkAAAABAAAALAAAAAFAAAAzAAAAAYAAADY
AAAABwAAAOQAAAAIAAAA+AAAAAkAAAAIAQAAEgAAABQBAAAKAAAANAEAAAwAAABAAQAADQAAAEwB
AAAOAAAAWAEAAA8AAABgAQAAEAAAAGgBAAATAAAAcAEAAAIAAADkBAAAHgAAAAQAAAAgAAAAHgAA
AAQAAAAAAAAAHgAAABQAAABDaXNjbyBTeXN0ZW1zLCBJbmMuAB4AAAAEAAAAAAAAAB4AAAAEAAAA
AAAAAB4AAAAMAAAATm9ybWFsLmRvdAAAHgAAAAgAAABQcmFkZWVwAB4AAAAEAAAAMzkAAB4AAAAY
AAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAADCb+MXAAAAQAAAAABOVUJDPMYBQAAAAAAw
EEuMesYBAwAAAAEAAAADAAAA1QAAAAMAAADABAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3V
nC4bEJOXCAArLPmuPAEAAPgAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACMAAAABgAAAJQAAAAR
AAAAnAAAABcAAACkAAAACwAAAKwAAAAQAAAAtAAAABMAAAC8AAAAFgAAAMQAAAANAAAAzAAAAAwA
AADaAAAAAgAAAOQEAAAeAAAAFAAAAENpc2NvIFN5c3RlbXMsIEluYy4AAwAAAAoAAAADAAAAAgAA
AAMAAACTBQAAAwAAAEcWCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAA
AgAAACAADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAVAEAAAgAAAAAAAAASAAAAAEAAADs
AAAAAgAAAPQAAAADAAAA/AAAAAQAAAAIAQAABQAAABQBAAAGAAAALAEAAAcAAABIAQAABgAAAAIA
AAAUAAAAX0FkSG9jUmV2aWV3Q3ljbGVJRAADAAAAEAAAAF9OZXdSZXZpZXdDeWNsZQAEAAAADgAA
AF9FbWFpbFN1YmplY3QABQAAAA0AAABfQXV0aG9yRW1haWwABgAAABgAAABfQXV0aG9yRW1haWxE
aXNwbGF5TmFtZQAHAAAAGQAAAF9SZXZpZXdpbmdUb29sc1Nob3duT25jZQACAAAA5AQAAAMAAADo
YrOcHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAAHgAAABAAAABwcmFkZ0BjaXNjby5jb20AHgAAABQA
AABQcmFkZWVwIEJHIChwcmFkZykAAB4AAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA
AAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA
EAAAAP7///8SAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAA/v///xoAAAAbAAAAHAAAAB0AAAAe
AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAA/v///ywA
AAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAD+////NAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAA
AP7////9////PQAAAP7////+/////v//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////9SAG8A
bwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAABAk8hijHrGAT8A
AACAAAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAEQAAAAAQAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAUyIAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBl
AG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA
/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuIAAAAAAAAAUAUwB1
AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKwAA
AAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA
aQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAzAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////
////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7/
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////8BAP7/AwoA
AP////8GCQIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAK
AAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIAbwBvAHQA
IABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAW
AAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAADA6t/mNesYBRQAAAMAC
AAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAARAAAAABAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAABkAAABTIgAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAgAAAAUAAAD/////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4gAAAAAAAAAQAAAAIAAAAD
AAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAAP7/
//8SAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAA/v///xoAAAAbAAAAHAAAAB0AAAAeAAAAHwAA
ACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAA/v///ywAAAAtAAAA
LgAAAC8AAAAwAAAAMQAAADIAAAD+////////////////////////////////////////////////
/////////////////////////0QAAAD9/////v////7////+////QwAAAP//////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////8BAAAA/v///wMA
AAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAA/v//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////xAAAABfTmV3UmV2
aWV3Q3ljbGUABAAAAA4AAABfRW1haWxTdWJqZWN0AAUAAAANAAAAX0F1dGhvckVtYWlsAAYAAAAY
AAAAX0F1dGhvckVtYWlsRGlzcGxheU5hbWUABwAAABkAAABfUmV2aWV3aW5nVG9vbHNTaG93bk9u
Y2UAAgAAAOQEAAAeAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBTAHUAbQBtAGEA
cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH/
//////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArAAAAABAAAAAA
AAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAA
AAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAIAAAAUAgAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8G
CQIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAKAAAATVNX
b3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQ
k5cIACss+a48AQAA+AAAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAIwAAAAGAAAAlAAAABEAAACc
AAAAFwAAAKQAAAALAAAArAAAABAAAAC0AAAAEwAAALwAAAAWAAAAxAAAAA0AAADMAAAADAAAANoA
AAACAAAA5AQAAB4AAAAUAAAAQ2lzY28gU3lzdGVtcywgSW5jLgADAAAACgAAAAMAAAACAAAAAwAA
AJMFAAADAAAARxYLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAACAAAA
IAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAADYAAAAAwAAAAAAAAAgAAAAAQAAAMQAAAAD
AAAAzAAAAAYAAAACAAAAFAAAAF9BZEhvY1Jldmlld0N5Y2xlSUQAAwAAAA==

------_=_NextPart_001_01C67A8D.FB45B8E1
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------_=_NextPart_001_01C67A8D.FB45B8E1--




From ospf-bounces@ietf.org Thu May 18 11:16:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FgkDp-0002VE-Al; Thu, 18 May 2006 11:15:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FgkDo-0002V9-Ls
	for OSPF@ietf.org; Thu, 18 May 2006 11:15:28 -0400
Received: from ind-iport-1.cisco.com ([64.104.129.195])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgkDn-0007ma-1H
	for OSPF@ietf.org; Thu, 18 May 2006 11:15:28 -0400
Received: from india-core-1.cisco.com ([64.104.129.221])
	by ind-iport-1.cisco.com with ESMTP; 18 May 2006 21:02:02 -0700
X-IronPort-AV: i="4.05,142,1146466800"; 
	d="gif'147?scan'147,208,217,147"; a="68010295:sNHT86950072"
Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com
	[64.104.140.150])
	by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4IFEooe007898;
	Thu, 18 May 2006 15:14:54 GMT
Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by
	xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); 
	Thu, 18 May 2006 20:45:16 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [OSPF] ASBR election
Date: Thu, 18 May 2006 20:45:13 +0530
Message-ID: <A547B532685E6C488A983A5B47FCEEFCA99BB4@xmb-blr-417.apac.cisco.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: RE: [OSPF] ASBR election
Thread-Index: AcZ6jdyt979j7T6WQeKql+hJ5C6ddQ==
From: "Pradeep BG \(pradg\)" <pradg@cisco.com>
To: "Hasmit Grover \(hasmit\)" <hasmit@cisco.com>,
	"Pat Murphy - \(650\)329-4044" <pmurphy@omega7.wr.usgs.gov>
X-OriginalArrivalTime: 18 May 2006 15:15:16.0634 (UTC)
	FILETIME=[DE5E57A0:01C67A8D]
X-Spam-Score: 0.9 (/)
X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6
Cc: OSPF@IETF.ORG
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0285831577=="
Errors-To: ospf-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0285831577==
Content-class: urn:content-classes:message
Content-Type: multipart/related;
	boundary="----_=_NextPart_001_01C67A8D.DE1CEE99";
	type="multipart/alternative"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C67A8D.DE1CEE99
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C67A8D.DE1CEE99"


------_=_NextPart_002_01C67A8D.DE1CEE99
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
Area 0 is connected to 2/3 on the SS-3

=20

=20

=20

 =20

                               =20

                             2/1
2/1

=20


=20

=20

=20

=20

INTERNET

=20
=20

=20

=20

=20

=20


Hi

GUYS

WE Are INTERLINKING THIS PROBLEM with another scenario

My question is very simple

Have 3 routers , 2 routers ss-2 and ss-1 they are in area 1(Normal area)
and both of the routers 2/1 link is connected to internet so they are
now ASBR=20

have one more router SS-3 which is ABR for area 0 and area 1 , if the 2
routers learn a prefix say (88.88.88.0) , in the routing table of ss-3
what should be displayed

1:whether it should load balance across 2 routers to the destination ?

2:or there is election b/t ss-1 and ss-2 where one router is selected as
the best to forward

3:if yes what is the criteria for selecting the best router

=20

Does RFC say anything for such a problem :-) ?

1:If all the routers are connected through a hub like broadcast access
in the area 1=20

or

2: if there is a pt to pt link b/t SS-2 and SS-3 and SS-1 and SS-3

What will be the routing table in ss-3 for both the above questions (how
to reach)

Thanks

-BG

=20


------_=_NextPart_002_01C67A8D.DE1CEE99
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 8pt"><SPAN=20
class=3D400430915-18052006>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Area 0 is connected to 2/3 on the SS-3</SPAN></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 8pt"></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 8pt"></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 8pt"></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN =
style=3D"FONT-SIZE: 8pt"><IMG=20
height=3D339 src=3D"cid:400430915@18052006-1F9A" width=3D579=20
v:shapes=3D"_x0000_s1026 _x0000_s1027 _x0000_s1028 _x0000_s1029 =
_x0000_s1030 _x0000_s1031 _x0000_s1032 _x0000_s1033 _x0000_s1034 =
_x0000_s1035 _x0000_s1036"><SPAN=20
class=3D400430915-18052006>&nbsp;</SPAN></SPAN><SPAN=20
style=3D"FONT-SIZE: 8pt"><?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"Z-INDEX: 3; MARGIN: 4px auto auto 107px; WIDTH: 2px; POSITION: =
absolute; HEIGHT: 134px; mso-ignore: vglayout"><IMG=20
height=3D134 src=3D"cid:400430915@18052006-1FA1" width=3D2=20
v:shapes=3D"_x0000_s1038"></SPAN><SPAN=20
style=3D"Z-INDEX: 4; MARGIN: 4px auto auto 491px; WIDTH: 2px; POSITION: =
absolute; HEIGHT: 134px; mso-ignore: vglayout"><IMG=20
height=3D134 src=3D"cid:400430915@18052006-1FA1" width=3D2=20
v:shapes=3D"_x0000_s1039"></SPAN><SPAN=20
style=3D"Z-INDEX: 2; POSITION: relative; mso-ignore: vglayout"><SPAN=20
style=3D"LEFT: 95px; WIDTH: 98px; POSITION: absolute; TOP: -254px; =
HEIGHT: 146px"><IMG=20
height=3D146 src=3D"cid:400430915@18052006-1FA8" width=3D98=20
v:shapes=3D"_x0000_s1037"></SPAN></SPAN><SPAN style=3D"FONT-SIZE: =
8pt"><FONT=20
face=3D"Times New Roman"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN><o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<SPAN=20
class=3D400430915-18052006>2/1</SPAN></SPAN><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>2=
/1</FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;</SPAN></FONT><SPAN=20
style=3D"FONT-SIZE: 8pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"FONT-SIZE: 8pt"><o:p><FONT=20
face=3D"Times New Roman">&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
style=3D"Z-INDEX: 5; LEFT: -25px; WIDTH: 618px; POSITION: relative; TOP: =
7px; HEIGHT: 121px; mso-ignore: vglayout">
<TABLE cellSpacing=3D0 cellPadding=3D0>
  <TBODY>
  <TR>
    <TD=20
    style=3D"BORDER-RIGHT: black 0.75pt solid; BORDER-TOP: black 0.75pt =
solid; BACKGROUND: white; VERTICAL-ALIGN: top; BORDER-LEFT: black 0.75pt =
solid; BORDER-BOTTOM: black 0.75pt solid"=20
    width=3D618 bgColor=3Dwhite height=3D114><SPAN=20
      style=3D"Z-INDEX: 5; POSITION: absolute; mso-ignore: vglayout">
      <TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%">
        <TBODY>
        <TR>
          <TD=20
          style=3D"BORDER-RIGHT: #ece9d8; BORDER-TOP: #ece9d8; =
BORDER-LEFT: #ece9d8; BORDER-BOTTOM: #ece9d8; BACKGROUND-COLOR: =
transparent">
            <DIV class=3Dshape=20
            style=3D"PADDING-RIGHT: 7.95pt; PADDING-LEFT: 7.95pt; =
PADDING-BOTTOM: 4.35pt; PADDING-TOP: 4.35pt"=20
            v:shape=3D"_x0000_s1040">
            <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; =
TEXT-ALIGN: center"=20
            align=3Dcenter><o:p><FONT=20
            face=3D"Times New Roman">&nbsp;</FONT></o:p></P>
            <P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt; =
TEXT-ALIGN: center"=20
            align=3Dcenter><FONT=20
          face=3D"Times New =
Roman">INTERNET</FONT></P></DIV></TD></TR></TBODY></TABLE></SPAN><FONT=20
      face=3D"Times New =
Roman">&nbsp;</FONT></TD></TR></TBODY></TABLE></SPAN><o:p><FONT=20
face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P><BR style=3D"mso-ignore: vglayout" =
clear=3Dall><FONT=20
face=3D"Times New Roman" size=3D3><FONT size=3D2>
<P><FONT size=3D4>Hi</FONT></P>
<P><FONT size=3D4>GUYS</FONT></P>
<P><FONT size=3D4>WE Are INTERLINKING THIS PROBLEM with another=20
scenario</FONT></P>
<P><FONT size=3D4>My question is very simple</FONT></P>
<P><FONT size=3D4>Have 3 routers , 2 routers ss-2 and ss-1 they are in =
area=20
1(Normal area) and both of the routers 2/1 link is connected to internet =
so they=20
are now ASBR </FONT></P>
<P><FONT size=3D4>have one more router SS-3 which is ABR for area 0 and =
area 1 ,=20
if the 2 routers learn a prefix say (88.88.88.0) , in the routing table =
of ss-3=20
what should be displayed</FONT></P>
<P><FONT size=3D4>1:whether it should load balance across 2 routers to =
the=20
destination ?</FONT></P>
<P><FONT size=3D4>2:or there is election b/t ss-1 and ss-2 where one =
router is=20
selected as the best to forward</FONT></P>
<P><FONT size=3D4>3:if yes what is the criteria for selecting the best=20
router</FONT></P>
<P></FONT><FONT size=3D4></FONT>&nbsp;</P>
<P><FONT size=3D4>Does RFC say anything for such a problem <FONT=20
face=3DWingdings>J</FONT> ?</FONT></P>
<P><FONT size=3D4>1:If all the routers are connected through a hub like =
broadcast=20
access in the area 1 </FONT></P>
<P><FONT size=3D4>or</FONT></P>
<P><FONT size=3D4>2: if there is a pt to pt link b/t SS-2 and SS-3 and =
SS-1 and=20
SS-3</FONT></P>
<P><FONT size=3D4>What will be the routing table in ss-3 for both the =
above=20
questions (how to reach)</FONT></P>
<P><FONT size=3D4>Thanks</FONT></P>
<P><FONT size=3D4>-BG</FONT></P></FONT>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></P></FONT></DIV></BODY></HTML>

------_=_NextPart_002_01C67A8D.DE1CEE99--

------_=_NextPart_001_01C67A8D.DE1CEE99
Content-Type: image/gif;
	name="clip_image001.gif"
Content-Transfer-Encoding: base64
Content-ID: <400430915@18052006-1F9A>
Content-Description: clip_image001.gif
Content-Location: clip_image001.gif

R0lGODlhAgBEAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAQAB
AEIAgAAAAAAAAAIGjI+py+1fADs=

------_=_NextPart_001_01C67A8D.DE1CEE99
Content-Type: image/gif;
	name="clip_image002.gif"
Content-Transfer-Encoding: base64
Content-ID: <400430915@18052006-1FA1>
Content-Description: clip_image002.gif
Content-Location: clip_image002.gif

R0lGODlhQwJTAXcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAsAIwA1
Ai0BgQAAAAAAAP///wECAwL/hI+py+0Po5y0hYuz3rz7D4biSJbmiaaqV7XuC8fyTNf2jdOBwPf+
DwwKh8Si8YhMKpfMpvMpDOSm1Kr1is1qWzuo9wsOi8fksk+6TavX7LYb1zXL5/S63Y5+6/f8vn8a
dyc4SFhYmPeXqLjI6BdoCBkpOZmE2HiJmampQ9np+SlpuTlKWlr6CJqquvolavoKG7uHylprexvk
KrvL2wuICxyMq+tbbHwsQSu8zAxJjAwdjazcXG099yytvQ1Lff0N7pXNTV5+6R2ern40bu7+Prsu
P4/UDn+Pr4VOz69unw8w4I19/Qpe+ycwoUIuBhvOQ7gwokQGBB1aHDYxo8YJ/xUvelwFcaNIgR0/
mvQUcqTKeyVPuoyUcqXMci1f2hwUc6ZOaTVv+qSTc6dQYz1/GiUTdKjSXUWPOm21NOq7pk+rNkkq
Nesmqla71tMKlqfXsXKwhj2biGtVtU7YhkILt5dbhxmGUEP14UyHXN/Mxv3bZq7BLhj4RlF24Udi
vYyBCCbkF7DkLY/5BVp8hkhhx3gvP8KcuVrkyaStVG4IWkDqzKtVd27co3VrjKVrMzoNMnGcwhXx
auaxOrhnxYhF2z6e1uJuwrH3Cf/tmjPx6c3t4saGPDuf66AuAw9tfTPwu9WJb+CsQTN3M6O1u6+w
HuVrJeKjR4E93nzj2eWXtf9/DyAE8XWS3njiFahffrlwQJ1eyxmoXjP/BUjhAgMSWJeBiyHY4Gyf
fbhgf/zZ51+FJlZx4SfP1fOgYyH2Bxto/I3IyoQnmphiKKF5Vw9+sb2oYIeeIZYjGDbeSGGRzuwW
5F0twkiig1BGmVp9P0qIZJac0OUak1aaJ9uQH47QXIYa+hjMkVq6pyRZNqm5ZnZtuukSnHEeNyed
Jtl5Z2156ukRn31qtUKhhh6KaKKKLsroCQI2msGgKq2XjaB3BkWppCNlaoGmWOTEqacZhWqhqFfE
RKqpC6WKgKWapsSqqiTVoYurnoYUq6wA5WrrrQjlqis+sfZq6j/ABguPczL/gpeLAsSqao+y3n2p
GLIKocPkd0E2m8Cz0EaA7ZUkeuOttX90xNx35HZrbhrjoKuuuNy2mw+8qv247gHl6lppJdpSewa9
u/p7b8H5GrAvvw70duUO2Apcb4/xahuFvhCrQQxB08rr2MUsscMah9UCkLC1tRrBXLoFV+zxVChP
zGzHJLeMsYVFpLfcwzSbg21dvtk1887uOkur0DTRWrLAF7RatNHcUJo0xHkc67QvVFdNBRpXYy3L
1lzDQXLTX08j9tj6eG02KWinvSV2bBez9tsxxC13I5BqUPenZecdUdRV340B3xP5/TXhgkdjONeJ
Hw4342ws7fhZi5s9eeSm/1Q+NuaWa6J55psv1Tnlnw8Vuuijz1R62qmf7sbqqrO+KeyzyD4q7bPb
fi3ut+u+K+96QO77VMHvPvzTxRN/POLJ/7688s2/4frzC0vPPPW8RD869tYjvH313av9vffhZ6I9
7OUvf77545+z/nbp+/4+7fHbPr/87fdRP/33I78///3r87+0BHBoAzxXAbOQv+AlUHALVOABs/bA
RTTwbRMcXgU9F8HbXPBvGcTEBo32weOFsGUjFGEH4XPCraQwGSvkXAun90LyxdBZM3RhDbl3Qw/e
sITd46GofNjDGAKxh0OMUxG/d0QkJRGJHVwiEx/oxPBFkU05tFoBpzg+LP/aRotZ7B8X1/dFwISx
i2CsIk/IaEbEjZFQadzGGqPyRi9SL47/o6NO7ChH9LVReCbcIx8t6MdkATKQguQdHjN4yFURsl64
S2QTHSmsRSYEkoWUZEAsBTjgoYWSK+QT3VbCyRba6ZOTsqRE4ERKkYRSiKbZW1ZWOcMjpVIjsIxl
1lwJR1PGLgezPKUuSwkHXCqlllXU5Ax6qchfyiQy0gqZzqRCzD36JVwUw8zBzpHJYypzJ2axl8M4
NrJzCJMj2xQKVrwJIc2Qb5zgKifpZMCwf62MZeIEytzc+U4YaIw14AyYB9n5gGiaElQvu5fKrnkb
gHYKn6B7Qc94U6abrdP/ni4Q6C9hpdB4UBSFDIUmQzZqt4yyq6Ov/JVIoXdSi5GUjclIaWBQtiyK
0ZOFKwVLtFz6uJuJizDPbGdNw9IOZOpNYimTKDl/ClQB4XQN6DSoUX2K1KQubKkYk5hT5zmvgEYV
Ls8Q6qlAhi8zZRWGW5WcBajqroJ+M2Yy02pZuUoRtFLmZj5TzFMX+la4Eg2kCeVrqfIaF1F4tZV+
HSlgA4uIwaKInRY9LA0RJld9MNaxk9FaZBE4zsZSloaKvWVhg7bZynb2F5/VLL8yidrUqvZuGnWb
YTf7J0BB5XeuNC2/ZNuX1pblsaENG26tkbBU2fa2vzUObUE6XOIWlxnB/y1bcmUV2+UyobkbfS50
pctc3bIHh71lGnaFQV23Wfe6302TdssghfGSt7y0QSlQ1Lte9toivautr33va4LTRVe+dOXvLeD7
iv369zADrgWAL1fgGgk4wf783IIZvC0IE0i/Eu7OgyF84FNUWEUXZnCG1bZh+YR4wtkbMSVoZOLL
gjDFoehwgj88ChcXGMUs3m2Ja2wIGuMYKRTeMWRkPGAYb8XHPyYyTnpsZDwA2b9C5lyS76DjJ0Oh
yROVMjaWzF8q/5MdupESNaFTpvrsxUUF7UeUrXwVJIPZmlOKqE7JjFUe2VU9WJ5yndmr5XqCWZ5s
nbNdsDpPOd/HOYO5c/958xzSN8PZqoNetKD5QuiCnBnNS0B0X/srHUZDGs6f6eda90yPSVO6EmrG
dINA7ecxdeZL2fqzpA39XUtLsNL3UbRh4izTanLa1qGGNXZlrYiaFKdLnQ5PlThGLrHe2jK+li6w
k8NrleV60X6WaatzfW1A93kdoh41O0oNpCdFetmBZpagi11rMzd7uc8+18vE3CWYrjpn59FQvc2k
7HQy29voBTe/xbHu4rbbEf8eQ7cLPlPLBfy3OoZoRJ00bnuLKd/apvZD/I3wq+yzSW1e2ZfBg25t
P3QwGM94pSNusGqb+88/s7ZOUX7xG5vczmVWuab5We1Huwjm8hg4/mb/DnAuA+nm+No1yDfN65g7
GOg0Z9HQUb1TMKEnOP3ctj9KznSY0prcXD/6jozudVebGetZj9DWySzWhx4b23Sm0cK/LfOy0wfl
0q643dke9Zhlm1wkj7vcnW5qcYtd5DlfubxCbvGek/3vmf4NvAEmcalL/EAeOJPlE2SZxTMeTZsH
mt87bx3Qw33pojd16RMeubfL9uBZ9/l2Tm922I819bIncO3bujnVA4r1THf9eW/Pe6D7/ri353zt
h+/e4ndc9shvnfKNz3zNgz74M2/+S58f4eJbP6fYj5Lyt8/U7ntf+9LvPPVNDv6qdv/8GU9/Wtev
ez25f67wF//8JVv///WXf/PsR/j9MZt/2Pd/QyWA8UcnA/hVAfh8CEhYBWh/+8d4/VdwDLhYCvh9
EPh3EvhvFOhZDqh/nwd8BugmHEhaHiiAGCh3GshvJMhL9ieCZMGCwWSB5AeCx/eCYxGDA+GCD1iD
zHeDXpGDNvCDXaGC3haENTCEVlGEo3aEbbOASbgWKFh2S0hpTXhMO/iBpGeCCyiFrQeFT2GF8ISF
J9iDsEeFaBaGczOGXFiGp3eGVpaG+rSGF9iGpfeGUhaHDjWHNKiFT8iDffh9X+gUeVhRewh8Xdh7
gngUhPhRW0iHgKh9imgUjAgfhnh8iCh8kvgTlEgBmugTd/hknMgRljsYfXUoeqCYZKLYUjN4iKY4
fZ54E6oILqRohphYfbD4JraIfrj4ErKoVPCHX8EojMNoTKlHjMeIjKhVAAA7

------_=_NextPart_001_01C67A8D.DE1CEE99
Content-Type: image/gif;
	name="clip_image003.gif"
Content-Transfer-Encoding: base64
Content-ID: <400430915@18052006-1FA8>
Content-Description: clip_image003.gif
Content-Location: clip_image003.gif

R0lGODlhAgCGAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAQAB
AIQAgAAAAAAAAAIKjI+py+0Po5ywAAA7

------_=_NextPart_001_01C67A8D.DE1CEE99--


--===============0285831577==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0285831577==--




From ospf-bounces@ietf.org Fri May 19 07:49:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fh3Su-0003hl-Bj; Fri, 19 May 2006 07:48:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh3St-0003hg-Kj
	for OSPF@ietf.org; Fri, 19 May 2006 07:48:19 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh3Ss-0001lr-BC
	for OSPF@ietf.org; Fri, 19 May 2006 07:48:19 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 19 May 2006 04:48:18 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,145,1146466800"; 
	d="scan'208"; a="28400828:sNHT23654316"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4JBmFTN013206; 
	Fri, 19 May 2006 07:48:17 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 19 May 2006 07:48:15 -0400
Received: from [10.82.217.16] ([10.82.217.16]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 19 May 2006 07:48:15 -0400
Message-ID: <446DB07E.3080005@cisco.com>
Date: Fri, 19 May 2006 07:48:14 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Pradeep BG (pradg)" <pradg@cisco.com>
Subject: Re: [OSPF] ASBR election
References: <A547B532685E6C488A983A5B47FCEEFCA99BB5@xmb-blr-417.apac.cisco.com>
In-Reply-To: <A547B532685E6C488A983A5B47FCEEFCA99BB5@xmb-blr-417.apac.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 May 2006 11:48:15.0321 (UTC)
	FILETIME=[1D1A2490:01C67B3A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Cc: "Pat Murphy - \(650\)329-4044" <pmurphy@omega7.wr.usgs.gov>, OSPF@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Pradeep,

In the future, please do not post MS Word documents to this list. With
respect to your question, RFC 2328 doesn't really say what to do
when you have equal cost paths through the same area. As Pat noted,
RFC 3101 adds the highest router ID as a tie breaker which force
picking the two ASBRs.

However, I can't really see anything magical about a single exit point
for an external route and I would even go so far as to say that it
is an implementation decision (as long as the other path preference
criteria are honored).

Good Luck,
Acee


Pradeep BG (pradg) wrote:

>Attaching Topology map
>
>________________________________
>
>From: Pradeep BG (pradg) 
>Sent: Thursday, May 18, 2006 8:45 PM
>To: Hasmit Grover (hasmit); 'Pat Murphy - (650)329-4044'
>Cc: 'OSPF@IETF.ORG'
>Subject: RE: [OSPF] ASBR election
>
>
> 
>Area 0 is connected to 2/3 on the SS-3
>
> 
>
> 
>
> 
>
>  
>
>                                
>
>                             2/1
>2/1
>
> 
>
>
> 
>
> 
>
> 
>
> 
>
>INTERNET
>
> 
> 
>
> 
>
> 
>
> 
>
> 
>
>
>Hi
>
>GUYS
>
>WE Are INTERLINKING THIS PROBLEM with another scenario
>
>My question is very simple
>
>Have 3 routers , 2 routers ss-2 and ss-1 they are in area 1(Normal area)
>and both of the routers 2/1 link is connected to internet so they are
>now ASBR 
>
>have one more router SS-3 which is ABR for area 0 and area 1 , if the 2
>routers learn a prefix say (88.88.88.0) , in the routing table of ss-3
>what should be displayed
>
>1:whether it should load balance across 2 routers to the destination ?
>
>2:or there is election b/t ss-1 and ss-2 where one router is selected as
>the best to forward
>
>3:if yes what is the criteria for selecting the best router
>
> 
>
>Does RFC say anything for such a problem :-) ?
>
>1:If all the routers are connected through a hub like broadcast access
>in the area 1 
>
>or
>
>2: if there is a pt to pt link b/t SS-2 and SS-3 and SS-1 and SS-3
>
>What will be the routing table in ss-3 for both the above questions (how
>to reach)
>
>Thanks
>
>-BG
>
> 
>
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>  
>

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



From ospf-bounces@ietf.org Fri May 19 11:06:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fh6Xu-0004CB-Aw; Fri, 19 May 2006 11:05:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6Xt-0004C3-5U
	for OSPF@IETF.ORG; Fri, 19 May 2006 11:05:41 -0400
Received: from omega7.wr.usgs.gov ([130.118.4.3] helo=ns0.wr.usgs.gov)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh6Xp-0006nc-Ss
	for OSPF@IETF.ORG; Fri, 19 May 2006 11:05:41 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392)
	id <01M2LKSHBI8W001TAK@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Fri,
	19 May 2006 08:03:42 -0700 (PDT)
Date: Fri, 19 May 2006 08:03:42 -0700 (PDT)
From: "Pat Murphy - (650)329-4044" <pmurphy@noc.usgs.net>
Subject: Re: [OSPF] ASBR election
To: PRADG@CISCO.COM
Message-id: <01M2LKSHBI8Y001TAK@omega7.wr.usgs.gov>
X-VMS-To: pradg@cisco.com
X-VMS-Cc: PMURPHY,hasmit@cisco.com,OSPF@ietf.org
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: OSPF@IETF.ORG, HASMIT@CISCO.COM
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Pradeep,

>As Pat noted,
>RFC 3101 adds the highest router ID as a tie breaker which force
>picking the two ASBRs.

And this happens only when comparing functionally equivalent LSAs with 
the same non-zero forwarding address.

OSPF has always built a routing table of multiple-equal cost paths. When 
dealing with external LSAs the external path preference rules prune them 
to a single area, including the default prefix 0.0.0.0/0. When two equal 
cost external default LSAs have a zero forwarding address (or different 
non-zero forwarding addresses) the OSPF routing table installation 
algorithm must assume that these routes are separate equal cost paths 
and it may install them. OSPF makes no recommendations about how 
implementations balance load over multiple equal cost paths. Most 
implementations allow the configuration of administrative metrics to 
define a preference pecking order of multiple paths, ala cisco's 
distance metrics (which I have seen used for the default route); but 
lacking any specifically configured administrative metrics or traffic 
engineering, it has been my experience that implementations simply 
balance the load over the multiple paths.

Pat


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



From ospf-bounces@ietf.org Fri May 19 11:17:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fh6ir-0007bC-RM; Fri, 19 May 2006 11:17:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6iq-0007b6-AT
	for OSPF@ietf.org; Fri, 19 May 2006 11:17:00 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh6il-0007Ou-UV
	for OSPF@ietf.org; Fri, 19 May 2006 11:17:00 -0400
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-4.cisco.com with ESMTP; 19 May 2006 08:16:55 -0700
X-IronPort-AV: i="4.05,146,1146466800"; 
	d="scan'208"; a="1809273102:sNHT36610480"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k4JFGtMn010360; 
	Fri, 19 May 2006 08:16:55 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4JFGsJl023351;
	Fri, 19 May 2006 08:16:55 -0700 (PDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 19 May 2006 11:16:54 -0400
Received: from [10.82.217.16] ([10.82.217.16]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Fri, 19 May 2006 11:16:53 -0400
Message-ID: <446DE165.4080700@cisco.com>
Date: Fri, 19 May 2006 11:16:53 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Pat Murphy - (650)329-4044" <pmurphy@omega7.wr.usgs.gov>
Subject: Re: [OSPF] ASBR election
References: <01M2LKSHBI8Y001TAK@omega7.wr.usgs.gov>
In-Reply-To: <01M2LKSHBI8Y001TAK@omega7.wr.usgs.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 May 2006 15:16:54.0004 (UTC)
	FILETIME=[42D19340:01C67B57]
DKIM-Signature: a=rsa-sha1; q=dns; l=1795; t=1148051815; x=1148915815;
	c=relaxed/simple; s=sjdkim6001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=acee@cisco.com; z=From:Acee=20Lindem=20<acee@cisco.com>
	|Subject:Re=3A=20[OSPF]=20ASBR=20election;
	X=v=3Dcisco.com=3B=20h=3D7X6L+qfx0Slbpii8D7PwXLpyrr8=3D;
	b=iZG90H3gMUYzZ6Mla1HkuumcYRo3NbvzrXnjbLtrNJyxvbwU74nJ6/+P90b9p7NJUw/myDvP
	q3kEZd+CQZ6PExt3NcZY7els/pQ+DcEiATA7loCidHVR9rf+DIimfFJn;
Authentication-Results: sj-dkim-6.cisco.com; header.From=acee@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: OSPF@ietf.org, HASMIT@cisco.com, PRADG@cisco.com
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Pat Murphy - (650)329-4044 wrote:

>Pradeep,
>
>  
>
>>As Pat noted,
>>RFC 3101 adds the highest router ID as a tie breaker which force
>>picking the two ASBRs.
>>    
>>
>
>And this happens only when comparing functionally equivalent LSAs with 
>the same non-zero forwarding address.
>
>OSPF has always built a routing table of multiple-equal cost paths. When 
>dealing with external LSAs the external path preference rules prune them 
>to a single area, including the default prefix 0.0.0.0/0. When two equal 
>cost external default LSAs have a zero forwarding address (or different 
>non-zero forwarding addresses) the OSPF routing table installation 
>algorithm must assume that these routes are separate equal cost paths 
>and it may install them. OSPF makes no recommendations about how 
>implementations balance load over multiple equal cost paths. Most 
>implementations allow the configuration of administrative metrics to 
>define a preference pecking order of multiple paths, ala cisco's 
>distance metrics (which I have seen used for the default route); but 
>lacking any specifically configured administrative metrics or traffic 
>engineering, it has been my experience that implementations simply 
>balance the load over the multiple paths.
>  
>
Thanks Pat - I guess I missed the part about the LSA being functionally 
the same. In this case, it
really shouldn't matter which LSA you use since they are functionally 
the same (although I
could envision an implementation doing something stupid like flapping 
the route when the
functionally equivalent LSA is purged ;^).

Acee




>Pat
>
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
>
>  
>

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



From ospf-bounces@ietf.org Fri May 19 13:29:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fh8mO-0001CN-3H; Fri, 19 May 2006 13:28:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8mM-0001CI-W5
	for OSPF@IETF.ORG; Fri, 19 May 2006 13:28:46 -0400
Received: from omega7.wr.usgs.gov ([130.118.4.3] helo=ns0.wr.usgs.gov)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8mL-0007Ma-NO
	for OSPF@IETF.ORG; Fri, 19 May 2006 13:28:46 -0400
Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392)
	id <01M2LPS028K8001UB1@omega7.wr.usgs.gov> for OSPF@IETF.ORG; Fri,
	19 May 2006 10:26:53 -0700 (PDT)
Date: Fri, 19 May 2006 10:26:52 -0700 (PDT)
From: "Pat Murphy - (650)329-4044" <pmurphy@noc.usgs.net>
Subject: Re: [OSPF] ASBR election
To: PRADG@CISCO.COM
Message-id: <01M2LPS028KA001UB1@omega7.wr.usgs.gov>
X-VMS-To: pradg@cisco.com
X-VMS-Cc: PMURPHY,hasmit@cisco.com,OSPF@ietf.org,acee@usgs.gov
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=us-ascii
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: OSPF@IETF.ORG, HASMIT@CISCO.COM, ACEE@USGS.GOV
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Pradeep,

I suspect our diversion into the subtleties of the OSPF external route 
calculation may be a bit too much. Regarding you question, see inline:

>My question is very simple
>
>Have 3 routers , 2 routers ss-2 and ss-1 they are in area 1(Normal area)
>and both of the routers 2/1 link is connected to internet so they are
>now ASBR 
>
>have one more router SS-3 which is ABR for area 0 and area 1 , if the 2
>routers learn a prefix say (88.88.88.0) , in the routing table of ss-3
>what should be displayed
>
>1:whether it should load balance across 2 routers to the destination ?
>
>2:or there is election b/t ss-1 and ss-2 where one router is selected as
>the best to forward
>
>3:if yes what is the criteria for selecting the best router
>
> 
>
>Does RFC say anything for such a problem :-) ?

If the advertisements are of equal cost and functionally different, OSPF may 
install both. If it does, whether or not or how the traffic is load balanced 
across the two paths is unspecified. Most major implementations, without 
explicit configuration or traffic engineering to the contrary, will load 
balance.

>1:If all the routers are connected through a hub like broadcast access
>in the area 1 
>
>or
>
>2: if there is a pt to pt link b/t SS-2 and SS-3 and SS-1 and SS-3
>
>What will be the routing table in ss-3 for both the above questions (how
>to reach)
>

Here it sounds like you are implying equal cost paths from ss-3 to 88.88.88.0. 
Again, what is stated above is correct. If you want preference defined between 
the advertisements of ss-1 and ss-2 then you must tweak, via configuration, the 
advertisements' Type 1 or Type 2 metrics when these external routes, ala 
88.88.88.0, are imported into the OSPF environments' of ss-1 and ss-2.

Pat


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



From ospf-bounces@ietf.org Thu May 25 06:08:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FjCkX-0000Cx-Qb; Thu, 25 May 2006 06:07:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FjCkW-0000Cr-4t
	for ospf@ietf.org; Thu, 25 May 2006 06:07:24 -0400
Received: from motgate2.mot.com ([144.189.100.101])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjCkT-0001Bz-Ns
	for ospf@ietf.org; Thu, 25 May 2006 06:07:24 -0400
Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232])
	by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k4PA7IHL019649
	for <ospf@ietf.org>; Thu, 25 May 2006 03:07:19 -0700 (MST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k4PA7G28001896
	for <ospf@ietf.org>; Thu, 25 May 2006 05:07:17 -0500 (CDT)
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
Subject: RE: [OSPF] Multiple Interfaces to a Single Link
Date: Thu, 25 May 2006 18:02:49 +0800
Message-ID: <D6831742F069304FB1924B4160A49351A9F5D5@ZMY16EXM66.ds.mot.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OSPF] Multiple Interfaces to a Single Link
Thread-Index: AcZ1/4A/TG2gFw0xTSKJvayREsP6DgJ3U9rQ
From: "Ramana Koppula-G20085" <ramanakumar@motorola.com>
To: "Acee Lindem" <acee@cisco.com>
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Acee,
At the very outset, I regret the delay in expressing my concern.

The text you updated was "Locally originated packets SHOULD NOT be
processed by OSPF".

Earlier it was "not passed" and now you changed it to "not processed".
Does it mean that the check is moved from the IP level to OSPF level
validations of receiving protocol packets?

If it is so, I too would support the idea. Because it make sense at OSPF
level. Else, I may have some concern regarding the wording.

Thanx
Ramana

-----Original Message-----
From: Acee Lindem [mailto:acee@cisco.com]=20
Sent: Saturday, May 13, 2006 1:36 AM
To: Ramana Koppula-G20085
Cc: ospf@ietf.org
Subject: Re: [OSPF] Multiple Interfaces to a Single Link

Ramana,

I've updated the 3.2.2 text as follows. I believe this addresses your
concern.

 o  Locally originated packets SHOULD NOT be processed by OSPF except
      for support of multiple interfaces attached to the same link as
      described in Section 3.9.  A locally originated packet is
      identified as packet with a source address equal to one of the
      router's local addresses.

I'd be interested in opinions on multi-interface per link support in
general.

Thanks,
Acee


Ramana Koppula-G20085 wrote:

>Hi all,
>=20
>Statement 1) From section 3.2.2 of OSPF for IPv6, "Locally originated=20
>packets SHOULD NOT be passed on to OSPF. That is, the source IPv6=20
>address should be examined to make sure this is not a multicast packet=20
>that the router itself generated." This is one of the checks that need=20
>to be done before the packet is sent for OSPF processing."
>=20
>Statement 2) From section 3.9 of OSPF for IPv6, "This allows the router

>to automatically detect that multiple router interfaces attach to the=20
>same link, when a Hello packet is received with the router's link-local

>address as the source address but with an Interface ID other than the=20
>Interface ID for the receiving interface."
>=20
>Doesn't the above two statements conflict in the case of Multiple=20
>Interfaces to the same broadcast link. And also first condition is=20
>checked for at IPv6 level while the other is at OSPF level. If the=20
>first statement is true, the packet would be dropped at the IP level=20
>and is not passed to OSPF.
>=20
>I doubt the first statement if it should be re-written as "Locally=20
>originated packets SHOULD NOT be passed on to OSPF. That is, the source
>IPv6 address should be examined to make sure this is not a multicast=20
>packet that the router itself generated from same interface" This is=20
>one of the checks that need to be done before the packet is sent for=20
>OSPF processing."
>=20
>thanx
>ramana
>
> =20
>
>-----------------------------------------------------------------------
>-
>
>_______________________________________________
>OSPF mailing list
>OSPF@ietf.org
>https://www1.ietf.org/mailman/listinfo/ospf
> =20
>

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



From ospf-bounces@ietf.org Thu May 25 14:44:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FjKnh-0003al-Du; Thu, 25 May 2006 14:43:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKng-0003ag-LR
	for ospf@ietf.org; Thu, 25 May 2006 14:43:12 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjKnf-0002y6-Bp
	for ospf@ietf.org; Thu, 25 May 2006 14:43:12 -0400
Received: from rtp-core-1.cisco.com ([64.102.124.12])
	by rtp-iport-1.cisco.com with ESMTP; 25 May 2006 11:43:11 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,173,1146466800"; 
	d="scan'208"; a="28940551:sNHT23715124"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4PIhATL026915; 
	Thu, 25 May 2006 14:43:10 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 25 May 2006 14:43:10 -0400
Received: from [10.82.240.29] ([10.82.240.29]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 25 May 2006 14:43:10 -0400
Message-ID: <4475FABD.6070902@cisco.com>
Date: Thu, 25 May 2006 14:43:09 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ramana Koppula-G20085 <ramanakumar@motorola.com>
Subject: Re: [OSPF] Multiple Interfaces to a Single Link
References: <D6831742F069304FB1924B4160A49351A9F5D5@ZMY16EXM66.ds.mot.com>
In-Reply-To: <D6831742F069304FB1924B4160A49351A9F5D5@ZMY16EXM66.ds.mot.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 May 2006 18:43:10.0234 (UTC)
	FILETIME=[121AE7A0:01C6802B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>,
	<mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Ramana,

Ramana Koppula-G20085 wrote:

>Hi Acee,
>At the very outset, I regret the delay in expressing my concern.
>
>The text you updated was "Locally originated packets SHOULD NOT be
>processed by OSPF".
>
>Earlier it was "not passed" and now you changed it to "not processed".
>Does it mean that the check is moved from the IP level to OSPF level
>validations of receiving protocol packets?
>  
>
I don't think the text was ever meant to dictate where the check is 
implemented. However,
with support to "multiple interfaces on a single link" elaborated, I 
can' t see it being possible
at the IP level.

>If it is so, I too would support the idea. Because it make sense at OSPF
>level. Else, I may have some concern regarding the wording.
>  
>
Great. The version with this change should published soon.

Thanks,
Acee

>Thanx
>Ramana
>
>-----Original Message-----
>From: Acee Lindem [mailto:acee@cisco.com] 
>Sent: Saturday, May 13, 2006 1:36 AM
>To: Ramana Koppula-G20085
>Cc: ospf@ietf.org
>Subject: Re: [OSPF] Multiple Interfaces to a Single Link
>
>Ramana,
>
>I've updated the 3.2.2 text as follows. I believe this addresses your
>concern.
>
> o  Locally originated packets SHOULD NOT be processed by OSPF except
>      for support of multiple interfaces attached to the same link as
>      described in Section 3.9.  A locally originated packet is
>      identified as packet with a source address equal to one of the
>      router's local addresses.
>
>I'd be interested in opinions on multi-interface per link support in
>general.
>
>Thanks,
>Acee
>
>
>Ramana Koppula-G20085 wrote:
>
>  
>
>>Hi all,
>>
>>Statement 1) From section 3.2.2 of OSPF for IPv6, "Locally originated 
>>packets SHOULD NOT be passed on to OSPF. That is, the source IPv6 
>>address should be examined to make sure this is not a multicast packet 
>>that the router itself generated." This is one of the checks that need 
>>to be done before the packet is sent for OSPF processing."
>>
>>Statement 2) From section 3.9 of OSPF for IPv6, "This allows the router
>>    
>>
>
>  
>
>>to automatically detect that multiple router interfaces attach to the 
>>same link, when a Hello packet is received with the router's link-local
>>    
>>
>
>  
>
>>address as the source address but with an Interface ID other than the 
>>Interface ID for the receiving interface."
>>
>>Doesn't the above two statements conflict in the case of Multiple 
>>Interfaces to the same broadcast link. And also first condition is 
>>checked for at IPv6 level while the other is at OSPF level. If the 
>>first statement is true, the packet would be dropped at the IP level 
>>and is not passed to OSPF.
>>
>>I doubt the first statement if it should be re-written as "Locally 
>>originated packets SHOULD NOT be passed on to OSPF. That is, the source
>>IPv6 address should be examined to make sure this is not a multicast 
>>packet that the router itself generated from same interface" This is 
>>one of the checks that need to be done before the packet is sent for 
>>OSPF processing."
>>
>>thanx
>>ramana
>>
>> 
>>
>>-----------------------------------------------------------------------
>>-
>>
>>_______________________________________________
>>OSPF mailing list
>>OSPF@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ospf
>> 
>>
>>    
>>
>
>  
>

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