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

[Acee Lindem <[e-mail]>]

Hi Lou,

Lou Berger wrote:
> Acee,
>         See responses in-line below.
>
> Should the corrected version go in as draft-berger or draft-ietf?
Let me poll the WG right now in a separate thread. I'll look at this more
deeply later.

Thanks,
Acee
>
> Lou
>
> 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?
>
>> Detailed comments:
>>
>> Section 2, third paragraph - "aligned" rather than "qaligned".
>
> yes.
>
>> Section 3, "Section 7" rather than "Section 7."
> okay.
>
>
>> 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.
>
>
>> 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 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...
>
>> Section 3.1, 2nd to last paragraph: "An opaque" rather than "a opaque".
>
> okay.
>
>> Swap sections 5 and 6 since "inter-area" is more the "meat" of the 
>> draft.
>
> done.
>
>> In fact, if the opaque MIB objects are all covered in the new MIB, we 
>> can
>> probably remove the "management section".
>
> done, section will read:
>
>   The updated OSPF MIB provides explicit support for opaque LSAs and
>   SHOULD be used to support implementations of this document.  See
>   Section 12.3 of [MIB-UPDATE] for details.  In addition to this section,
>   implementation supporting [MIB-UPDATE] will include opaque LSAs in
>   all appropriate generic LSA objects, e.g., ospfOriginateNewLsas,
>   ospfOriginateNewLsas and ospfLsdbTable.
>
> BTW just sent WG mail on one inconsistency between 2370 and the 
> updated MIB.
>
>> Section 6 (will be 5)
>>
>> 5. Opaque LSA Validation
>>
>> Opaque LSAs are not processed during the SPF calculation as described in
>> section 16 of [OSPF]. However, they are subject to the same reachability
>> constraints as the base LSA types. This implies that originating router
>> MUST be reachable for the advertised application specific data to be
>> considered valid.
>>
>> 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.
>
>
>> 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 ....
>
>> Section 10.1 - Correct NSSA reference to RFC 3101.
>
> thanks.
>
>> Section 12.1 - Add D and MT bits with informative references to [RFC 
>> 4576]
>> and the [OSPF-MT] drafts. "All eight bit ..." rather than "Six bits..".
>
> done.
>
>
>> General - Replace "stub area" with "stub or NSSA areas".
> sure.
>
>> Thanks,
>> Acee
>>
>
> Great comments.
>
> Much thanks.
> Lou

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf