[OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.txt

Lou Berger <lberger@labn.net> Mon, 04 December 2006 17:11 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrHLq-00053Z-31; Mon, 04 Dec 2006 12:11:34 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrHLp-00053S-2H for ospf@ietf.org; Mon, 04 Dec 2006 12:11:33 -0500
Received: from [] (helo=esc91.midphase.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrHLR-000351-HI for ospf@ietf.org; Mon, 04 Dec 2006 12:11:33 -0500
Received: from [] (helo=LC1.labn.net) by esc91.midphase.com with esmtpa (Exim 4.52) id 1GrHLL-0006je-UJ; Mon, 04 Dec 2006 12:11:04 -0500
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 04 Dec 2006 12:11:00 -0500
To: Acee Lindem <acee@cisco.com>
From: Lou Berger <lberger@labn.net>
In-Reply-To: <45704882.4010405@cisco.com>
References: <455907D0.5010706@cisco.com> <5bg6vi$2pimgv@sj-inbound-f.cisco.com> <45623C49.7070207@cisco.com> <5c02hq$ajidoq@sj-inbound-d.cisco.com> <456CAE87.1030209@cisco.com> <5g70f5$8oceu@sj-inbound-b.cisco.com> <45704882.4010405@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - esc91.midphase.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 093efd19b5f651b2707595638f6c4003
Cc: OSPF List <ospf@ietf.org>
Subject: [OSPF] Re: Comments on draft-berger-ospf-rfc2370bis-00.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
Message-Id: <E1GrHLq-00053Z-31@megatron.ietf.org>

         see below.

At 10:21 AM 12/1/2006, Acee Lindem wrote:

>Hi Lou,
>Since no one offered objection - lets make this a WG document when
>refreshed. See below:

will do as soon as we close on items in this thread. (which I think 
we'll do as soon as you respond to this message...)

>Lou Berger wrote:
>>Hi Acee,
>>See below.
>>At 04:47 PM 11/28/2006, Acee Lindem wrote:
>>>Hi Lou,
>>>Lou Berger wrote:
>>>>         See below.
>>>>At 06:37 PM 11/20/2006, Acee Lindem wrote:
>>>>>Hi Lou,
>>>>>See inline.
>>>>>Lou Berger wrote:
>>>>>>         See responses in-line below.
>>>>>>Should the corrected version go in as draft-berger or draft-ietf?
>>>>>>At 07:03 PM 11/13/2006, Acee Lindem wrote:
>>>>>>>Section 3.1 - Type 9  LSA - "keep" rather than "keepk".
>>>>>>yes.  Also I added the following to the beginning of the section:
>>>>>>  Section 13 of [OSPF] describes the OSPF flooding procedure.
>>>>>>  Those procedures MUST be followed as defined except where
>>>>>>  modified in this section.
>>>>>>>I believe we
>>>>>>>                    should discard a link-local LSA received 
>>>>>>> from a neighbor not
>>>>>>>                    on the interface (text similiar to type 11).
>>>>>>okay, updated as follows:
>>>>>>   o If the Opaque LSA is type 9 (the flooding scope is link-local)
>>>>>>     and the interface that the LSA was received on is not the same
>>>>>>     as the target interface (e.g., the interface associated with a
>>>>>>     particular target neighbor), the Opaque LSA SHOULD be discarded
>>>>>>     and not acknowledged, and MUST NOT be flooded out that interface
>>>>>>     (or to that neighbor).  An implementation SHOULD keep track of
>>>>>>     the IP interface associated with each Opaque LSA having a
>>>>>>     link-local flooding scope.
>>>>>I guess I think that if you discard an LSA, it is implied that you won't
>>>>>reflood it.
>>>>it does say "and MUST NOT be flooded".  I'm open to alternate wording.
>>>In every other instance where an LSA is discarded in RFC 2328 we don't
>>>explicitly state that we don't reflood them. In other words, why would
>>>anybody get the misconcept we'd ever reflood anything that was discarded.
>>ahh, I thought you *wanted* the explicit text.  The primary reason 
>>for the seemingly redundant directives is that's how it was done in 
>>2370 (see type 11).  Also, for type 9 and 10, one is a SHOULD 
>>(ignore) and the other is a MUST NOT(flood).  The ignore part is 
>>IMO implicit in OSPF/2370, but isn't explicit so I've put it as a 
>>SHOULD.  I have no issue changing this a MUST.
>I think saying the LSAs are discarded is enough.

okay, changed to MUST discard.

>>>>>>>Remove numbered items (1) and (2), these actions ARE NOT new to
>>>>>>>opaque LSAs. Make (3) a separate paragraph rather than numbered
>>>>>>But inclusion of type-11 originate routers as ASBR is 
>>>>>>new.  Will rephrase to make clear that existing ospf requirements apply.
>>>>>>How about:
>>>>>>The procedures related to inter-area opaque LSAs are as follows:
>>>>>>(1) An OSPF router that is configured to originate AS-scope opaque
>>>>>>     LSAs advertise themselves as ASBRs and MUST follow the related
>>>>>>     requirements related to setting of the  Options field E-bit in
>>>>>>     OSPF Hello packets and LSA headers as specified in [OSPF].
>>>>>>(2) When ....
>>>>>I don't think these points need to be restated even if they reference
>>>>>RFC 2328. Opaque LSAs don't modify these conditions. Hence,
>>>>>I don't see them to be required any more than stating the version field
>>>>>the OSPF packet header should be set to 2.
>>>>huh? opaque LSAs aren't present in 2328 and the specification of 
>>>>E-bit setting/handling in 2328 is largely relative to AS-external-LSAs.
>>>The E options bit must be set in hellos for any regular (not stub 
>>>or NSSA) area
>>>independent of any opaque support. Opaque LSAs don't change this at all.
>>yes, but the use of the E-bit due to Opaque LSAs is novel/unique to 
>>this document.
>Not really,  the setting of the E-bit in the Hello packet Options is solely
>dependent on the area type. There is nothing about this specific to 
>opaque LSAs.

okay, will remove the reference to hellos from (1).


OSPF mailing list