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

Acee,
         okay.  I have a version updated based on your comments ready 
to go, so just let me/the WG know.

Lou

At 02:56 PM 11/16/2006, Acee Lindem wrote:

>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
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf