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

[Acee Lindem <[e-mail]>]

Hi Lou,

Lou Berger wrote:
> 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.
> [...]
Ok - sounds good.
>
>
>>>>>>>> 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).

Great - think we are in sync.

Thanks,
Acee
>
> Thanks,
> Lou
>

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