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

Acee Lindem <acee@cisco.com> Fri, 01 December 2006 15:21 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqACv-0004uP-2i; Fri, 01 Dec 2006 10:21:45 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqACt-0004sa-69 for ospf@ietf.org; Fri, 01 Dec 2006 10:21:43 -0500
Received: from sj-iport-4.cisco.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqACr-0002rj-Hb for ospf@ietf.org; Fri, 01 Dec 2006 10:21:43 -0500
Received: from rtp-dkim-2.cisco.com ([]) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2006 07:21:40 -0800
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com []) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB1FLeK5016651; Fri, 1 Dec 2006 10:21:40 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com []) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB1FLeYJ011971; Fri, 1 Dec 2006 10:21:40 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 10:21:40 -0500
Received: from [] ([]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 10:21:39 -0500
Message-ID: <45704882.4010405@cisco.com>
Date: Fri, 01 Dec 2006 10:21:38 -0500
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird (Windows/20061025)
MIME-Version: 1.0
To: Lou Berger <lberger@labn.net>
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>
In-Reply-To: <5g70f5$8oceu@sj-inbound-b.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Dec 2006 15:21:39.0750 (UTC) FILETIME=[6619F460:01C7155C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6488; t=1164986500; x=1165850500; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20<acee@cisco.com> |Subject:=20Re=3A=20Comments=20on=20draft-berger-ospf-rfc2370bis-00.txt |Sender:=20 |To:=20Lou=20Berger=20<lberger@labn.net>; bh=lEt8CF2xidHOdNVhYn7P309m9cqPFARJizSl15Q9eew=; b=mNGYCT4ITWAamy0mylnGU6tFXoIjWWIwX9C2+E0YR+689pb2FwzwWJeNmMx2YRUM++Dc6Q7p 4sgylhEDvvvgGrJuue25UkpjrTjzovnjKZYkj8+FbD9kVWh6IkTY+eNb;
Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc
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

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

Lou Berger wrote:
> Hi Acee,
> See below.
> At 04:47 PM 11/28/2006, Acee Lindem wrote:
>> Hi Lou,
>> Lou Berger wrote:
>>> Acee,
>>>         See below.
>>> At 06:37 PM 11/20/2006, Acee Lindem wrote:
>>>> Hi Lou,
>>>> See inline.
>>>> Lou Berger wrote:
>>>>> Acee,
>>>>>         See responses in-line below.
>>>>> Should the corrected version go in as draft-berger or draft-ietf?
>>>>> Lou
>>>>> 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.

> [...]
>>>>>> 5.1 Inter-Area Considerations
>>>>>> ......
>>>>>> Section 5.1
>>>>>>   Type-9 opaque LSAs and type-10 opaque LSAs do not have this 
>>>>>> problem
>>>>>>   as a receiving router can detect an a loss of reachability 
>>>>>> through the intra-area
>>>>>>   SPF calculation.
>>>>>> Section 5.1
>>>>>>   To enable OSPF routers in remote areas to check availability of 
>>>>>> the
>>>>>>   originator of link-state type 11 opaque LSAs, the orignators of
>>>>>>    type-11 opaque LSAs are considered Autonomous System Border
>>>>>>    Routers (ASBRs) and will advertise themselves as such.
>>>>>> Section 5.1 - Remove "It is important to note that this solution 
>>>>>> MUST NOT ..."
>>>>>> This is redundant.
>>>>> which part is redundant, just the sentence you are asking to be 
>>>>> removed?  I agree that it is redundant with 2328, but I thin 
>>>>> mentioning it is still useful.  Will rephrase to remove directive.
>>>> This part of the specification doesn't modify stub area behavior.
>>>> Here, we are talking about validating AS scoped opaque LSA.
>>>> I guess you could say, "Note that AS scoped opaque LSA
>>>> validation is not applicable to stub and NSSA areas since LSAs
>>>> with AS scope are not flooded into these areas types." However,
>>>> I don't see it as necessary.
>>> here's what I have now: "It is important to note that per
>>> [OSPF] this solution does not apply to OSPF stub areas or NSSAs as
>>> neither type-11 LSAs are flooded nor are type-4 LSAs originated into
>>> such areas."
>>> As you mentioned above, it is worth explicitly stating things 
>>> sometimes.
>> Okay - I'll concede though I don't think it is necessary. Can we
>> call say "AS scoped opaque LSAs" rather than type-11s.
> sure.
>>  Also, do
>> we have to add the detail about the ASBR-summary-LSAs (as they
>> are referred to RFC 2328).
> This is just an informative statement on an issue that was previously 
> missed.  I'd prefer to keep it.  That said, if you really feel 
> strongly about it, we can remove the whole thing as it's just 
> informative.
>>>>>> Remove numbered items (1) and (2), these actions ARE NOT new to
>>>>>> opaque LSAs. Make (3) a separate paragraph rather than numbered
>>>>>> item.
>>>>> 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.


> Much thanks,
> Lou

OSPF mailing list