RE: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt

"Nitin Kakkar" <nkakkar@force10networks.com> Wed, 10 October 2007 18:29 UTC

Return-path: <ospf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgJV-0005Mj-Hl; Wed, 10 Oct 2007 14:29:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfgJU-0005MR-TY for ospf@ietf.org; Wed, 10 Oct 2007 14:29:44 -0400
Received: from corp.force10networks.com ([64.186.164.204] helo=mx.force10networks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfgJN-0003hn-Pl for ospf@ietf.org; Wed, 10 Oct 2007 14:29:44 -0400
Received: from EXCH-CLUSTER-03.force10networks.com ([10.11.0.54]) by mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 11:29:26 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt
Date: Wed, 10 Oct 2007 11:29:26 -0700
Message-ID: <44ED058B21DF294ABE394CABE5C1B521E19850@EXCH-CLUSTER-03.force10networks.com>
In-Reply-To: <7F019337-CE1E-4AA1-A95A-7D4D0F8E5D35@redback.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OSPF] Question on flodding scope indraft-ietf-ospf-ospfv3-update-17.txt
Thread-Index: AcgLal5KLQ0DEtMoQjCS1PejXO/bVgAANo2w
References: <098901c80b42$a122ab10$5102010a@your029b8cecfe> <039A6B88-D28C-479E-B6D5-B83D499A203F@redback.com> <44ED058B21DF294ABE394CABE5C1B521E1984F@EXCH-CLUSTER-03.force10networks.com> <7F019337-CE1E-4AA1-A95A-7D4D0F8E5D35@redback.com>
From: Nitin Kakkar <nkakkar@force10networks.com>
To: Acee Lindem <acee@redback.com>
X-OriginalArrivalTime: 10 Oct 2007 18:29:26.0287 (UTC) FILETIME=[7CC6D1F0:01C80B6B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d20755f70c178b57c076995ecfb1501
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="===============0441569513=="
Errors-To: ospf-bounces@ietf.org

 

 

________________________________

From: Acee Lindem [mailto:acee@redback.com] 
Sent: Wednesday, October 10, 2007 11:20 AM
To: Nitin Kakkar
Cc: Adrian Farrel; ospf@ietf.org
Subject: Re: [OSPF] Question on flodding scope
indraft-ietf-ospf-ospfv3-update-17.txt

 

Hi Nitin,

 

On Oct 10, 2007, at 2:02 PM, Nitin Kakkar wrote:





Adrian> You are saying that the only router that cause AS scoped
flooding is an ASBR. This limit seems to be unnecessary and overly
restrictive.

Adrian> Can you clarify why a non-ASBR is not allowed to originate an
AS-scoped LSA?

 

Acee> This is necessary to enforce the "condition of reachability" for
all LSAs. In other words, in order for an LSA to be considered valid,
you need to verify that the advertising router is reachable. Hence, a
router advertising an AS scoped LSA must advertise itself as ASBR so
that Inter-Area-Router-LSAs are advertised into all regular areas. 

 

IMHO> It is quite possible in many scenario's that  a router originated
AS scope LSA's and then changed from ASBR to Non ASBR, leaving older ASE
LSA's in domain. 

1)     This statement also tries to prevent unnecessary origination of
unusable lsa's (If router originate ASE lsa's and does not advertise it
self as ASBR, what would be the use of those LSA's?  these LSA's will
only occupy space in LSDB & result into unnecessary flooding but won't
contribute to routing, this is very similar to  )  

 

So, I'll take this as agreement. 

 

Nitin> Yes Sir, Agreement to your Statement.

           My statement was in explanation to Adrian's mention  that
ASBR definition is overly restrictive. I tried to point out that
restrictive ASBR definition was necessary for maintaining sanity in ospf
& tried to explain what happen when non asbr's originate ASE lsa's.

 

Regards

Nitin

 

Thanks,

Acee



 

Regards

Nitin

________________________________

From: Acee Lindem [mailto:acee@redback.com] 
Sent: Wednesday, October 10, 2007 8:19 AM
To: Adrian Farrel
Cc: ospf@ietf.org <mailto:ospf@ietf.org> 
Subject: Re: [OSPF] Question on flodding scope
indraft-ietf-ospf-ospfv3-update-17.txt

 

Hi Adrian,

 

On Oct 10, 2007, at 9:30 AM, Adrian Farrel wrote:






Hi,

 

In section 2.3...

 

  o  AS scope.  LSA is flooded throughout the routing domain.  Used for

     AS-external-LSAs.  A router that originates AS scoped LSAs is

     considered an AS Boundary Router (ASBR) and will set its E-bit in

     Router-LSAs for regular areas.

 

I'm concerned about the impact of this statement for future application
of text in 3.4.4

 

  It is expected that new LSAs will be defined that will not be

  processed during the Shortest Path First (SPF) calculation as

  described in Section 3.8.  For example, OSPFv3 LSAs corresponding to

  information advertised in OSPFv2 using opaque LSAs [OPAQUE].

 

But in 3.4.4 it also says

 

  To facilitate inter-area reachability validation, any OSPFv3 router

  originating AS scoped LSAs is considered an AS Boundary Router

  (ASBR).

 

You are saying that the only router that cause AS scoped flooding is an
ASBR. This limit seems to be unnecessary and overly restrictive.

 

Further, this seems to be a change from RFC2740 where section 2.3 had
only

  o   AS scope. LSA is flooded throughout the routing domain. Used

      for AS-external-LSAs.

 

Can you clarify why a non-ASBR is not allowed to originate an AS-scoped
LSA?

 

This is necessary to enforce the "condition of reachability" for all
LSAs. In other words, in order for an LSA to be considered valid, you
need to verify that the advertising router is reachable. Hence, a router
advertising an AS scoped LSA must advertise itself as ASBR so that
Inter-Area-Router-LSAs are advertised into all regular areas. 

 

We are also respinning RFC 2370 (Opaque LSAs) to enforce this. This is
draft-ietf-ospf-rfc2370bis-01.txt.

 

Thanks,

Acee






 

Thanks,

Adrian

 

PS. I think the I-D header should include "Obsoletes RFC2740" 

 

 

_______________________________________________

OSPF mailing list

OSPF@ietf.org <mailto:OSPF@ietf.org> 

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

 





 

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