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

Lou Berger <lberger@labn.net> Wed, 22 November 2006 21:07 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmzJL-0004R9-7q; Wed, 22 Nov 2006 16:07:15 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmzJK-0004Qs-9G for ospf@ietf.org; Wed, 22 Nov 2006 16:07:14 -0500
Received: from [] (helo=esc91.midphase.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmz6P-0006Cz-1D for ospf@ietf.org; Wed, 22 Nov 2006 15:54:17 -0500
Received: from [] (helo=LC1.labn.net) by esc91.midphase.com with esmtpa (Exim 4.52) id 1Gmz6B-0006KP-Av; Wed, 22 Nov 2006 15:53:40 -0500
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 22 Nov 2006 15:49:54 -0500
To: Acee Lindem <acee@cisco.com>
From: Lou Berger <lberger@labn.net>
In-Reply-To: <45623C49.7070207@cisco.com>
References: <455907D0.5010706@cisco.com> <5bg6vi$2pimgv@sj-inbound-f.cisco.com> <45623C49.7070207@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: cdb443e3957ca9b4c5b55e78cfcf4b26
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: <E1GmzJL-0004R9-7q@megatron.ietf.org>

         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:
>>>Hi Lou,
>>>My main comment is on section 5 (6 is your draft). The draft adds
>>>mandatory reachability checking for AS scoped opaque LSAs.
>>>If we add mandatory reachability checking, it should be for all
>>>opaque types rather reading like the constraint is unique to AS scoped
>>>opaque LSAs (type 11s).
>>valid point.
>>>I also think we should put the question as to whether the checking
>>>should be madatory or relaxed a bit to allow an application to check
>>>less frequently if the opaque data is stale.
>>What benefit would this have?
>This would allow applications that don't require the opaque data to
>strictly track the SPF to discontinue using the information less frequently
>than the SPF. This would be useful if OSPF and the application using the
>opaque data were not tightly coupled. Here is what I put in the OSPFv3
>update draft:
>3.4.4.  Future LSA Validation
>   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].  In
>   general, the new information advertised in future LSAs should not be
>   used unless the OSPFv3 router originating the LSA is reachable.
>   However, depending on the application and the data advertised, this
>   reachability validation MAY be done less frequently than every SPF
>   calculation.
>   To facilitate inter-area reachability validation, any OSPFv3 router
>   orginating AS scoped LSAs is considered an AS Boundary Router (ASBR).
>On the other hand, there is a school of thought that would consider this an
>implementation detail. I, however, think it is better if it is 
>explicitly stated.
>If, for no other reason, to provide guidance to the people testing 
>the protocols.

Consistency between v2 and v3 is goodness where possible, so I'll add 
a comment (to the end of 3.1) and reference.

>>>Detailed comments:
>>>Section 2, third paragraph - "aligned" rather than "qaligned".
>>>Section 3, "Section 7" rather than "Section 7."
>>>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.

>>>Section 3.1, Since the area ID is not in the LSA header, the bullet on
>>>                   area flooding is confusing. It should say 
>>> something to the
>>>                   effect of only flooding type 10 LSAs out 
>>> interfaces in the
>>>                   LSA's associated area.
>>okay, updated as follows:
>>   o If the Opaque LSA is type 10 (the flooding scope is area-local)
>>     and the area associated with Opaque LSA (as identified during
>>     origination or from a received LSA's associated OSPF packet
>>     header) is not the same as the area associated with the target
>>     interface, the Opaque LSA MUST NOT be flooded out the interface.
>>     An implementation SHOULD keep track of the OSPF area associated
>>     with each Opaque LSA having an area-local flooding scope.
>I think the action should be same as above. In any case, this can never
>happen as the entire Link State Update packet would be discarded.

okay, language is a hold-over from 2230.  will update to match above. 
Same fore type 11.

>>>I don't care if it said this in RFC 2370
>>>                   and everyone knew what it implied.
>>I don't know how to interpret the text otherwise...
>RFC 2328 specifically state that packets whose Area ID cannot
>be matched to the receiving interfaces are discarded. See section 8.2.

I was agreeing with you...

>>>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.

>>>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.

Thanks again for the comments,

OSPF mailing list