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

[Lou Berger <[e-mail]>]

Acee,
         see below.

At 10:21 AM 12/1/2006, Acee Lindem wrote:

>Hi Lou,
>Since no one offered objection - lets make this a WG document when
>refreshed. See below:

will do as soon as we close on items in this thread. (which I think 
we'll do as soon as you respond to this message...)

>Lou Berger wrote:
>>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.
>I think saying the LSAs are discarded is enough.

okay, changed to MUST discard.
[...]


>>>>>>>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.
>>[...]
>Not really,  the setting of the E-bit in the Hello packet Options is solely
>dependent on the area type. There is nothing about this specific to 
>opaque LSAs.

okay, will remove the reference to hellos from (1).

Thanks,
Lou


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