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

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

Thanks again for the comments,
Lou

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf