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

[Acee Lindem <[e-mail]>]

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

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.


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

Thanks,
Acee

>
> Much thanks,
> Lou
>

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