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

[Lou Berger <[e-mail]>]

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.

[...]

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

Much thanks,
Lou



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