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

From: Acee Lindem <[email-masked]>
Date: Mon, 13 Nov 2006 19:03:28 -0500

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). 

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.

Detailed comments:

Section 2, third paragraph - "aligned" rather than "qaligned".

Section 3, "Section 7" rather than "Section 7."

Section 3.1 - Type 9  LSA - "keep" rather than "keepk". I believe we
                    should discard a link-local LSA received from a 
neighbor not
                    on the interface (text similiar to type 11).

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. I don't care if it said this 
in RFC 2370
                   and everyone knew what it implied.
Section 3.1, 2nd to last paragraph: "An opaque" rather than "a opaque".

Swap sections 5 and 6 since "inter-area" is more the "meat" of the draft.
In fact, if the opaque MIB objects are all covered in the new MIB, we can
probably remove the "management section".

Section 6 (will be 5)

5. Opaque LSA Validation

Opaque LSAs are not processed during the SPF calculation as described in
section 16 of [OSPF]. However, they are subject to the same reachability
constraints as the base LSA types. This implies that originating router
MUST be reachable for the advertised application specific data to be
considered valid.

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.

Remove numbered items (1) and (2), these actions ARE NOT new to
opaque LSAs. Make (3) a separate paragraph rather than numbered
item.

Section 10.1 - Correct NSSA reference to RFC 3101.

Section 12.1 - Add D and MT bits with informative references to [RFC 4576]
and the [OSPF-MT] drafts. "All eight bit ..." rather than "Six bits..".

General - Replace "stub area" with "stub or NSSA areas".

Thanks,
Acee

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Nov 2006 14:53:16 -0500

Acee,
         See responses in-line below.

Should the corrected version go in as draft-berger or draft-ietf?

Lou

>opaque types rather reading like the constraint is unique to AS scoped

valid point.

>less frequently if the opaque data is stale.

What benefit would this have?

>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

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.

>                   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 don't care if it said this in RFC 2370

I don't know how to interpret the text otherwise...

>Section 3.1, 2nd to last paragraph: "An opaque" rather than "a opaque".

okay.

>Swap sections 5 and 6 since "inter-area" is more the "meat" of the draft.

done.

>probably remove the "management section".

done, section will read:

   The updated OSPF MIB provides explicit support for opaque LSAs and
   SHOULD be used to support implementations of this document.  See
   Section 12.3 of [MIB-UPDATE] for details.  In addition to this section,
   implementation supporting [MIB-UPDATE] will include opaque LSAs in
   all appropriate generic LSA objects, e.g., ospfOriginateNewLsas,
   ospfOriginateNewLsas and ospfLsdbTable.

BTW just sent WG mail on one inconsistency between 2370 and the updated MIB.

>   as a receiving router can detect an a loss of reachability 
> through the intra-area
>   SPF calculation.
>
>Section 5.1
>

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

>opaque LSAs. Make (3) a separate paragraph rather than numbered

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

>Section 10.1 - Correct NSSA reference to RFC 3101.

thanks.

>and the [OSPF-MT] drafts. "All eight bit ..." rather than "Six bits..".

done.

>General - Replace "stub area" with "stub or NSSA areas".
sure.

>Acee

Great comments.

Much thanks.
Lou

---

From: Acee Lindem <[email-masked]>
Date: Thu, 16 Nov 2006 14:56:26 -0500

Hi Lou,

> Should the corrected version go in as draft-berger or draft-ietf?
Let me poll the WG right now in a separate thread. I'll look at this more
deeply later.

Thanks,
Acee

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Nov 2006 15:03:09 -0500

Acee,
         okay.  I have a version updated based on your comments ready 
to go, so just let me/the WG know.

Lou

At 02:56 PM 11/16/2006, Acee Lindem wrote:

>>>                    should discard a link-local LSA received from 
>>> a neighbor not

---

From: Acee Lindem <[email-masked]>
Date: Mon, 20 Nov 2006 18:37:45 -0500

Hi Lou,
See inline.

> 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.
>     link-local flooding scope.
I guess I think that if you discard an LSA, it is implied that you won't
reflood it.

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

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

> BTW just sent WG mail on one inconsistency between 2370 and the 
thanks
> 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.

>     OSPF Hello packets and LSA headers as specified in [OSPF].
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.
Thanks,
Acee

---

From: Lou Berger <[email-masked]>
Date: Wed, 22 Nov 2006 15:49:54 -0500

Acee,
         See below.

At 06:37 PM 11/20/2006, Acee Lindem wrote:

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

>I guess I think that if you discard an LSA, it is implied that you won't

it does say "and MUST NOT be flooded".  I'm open to alternate wording.

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

>be matched to the receiving interfaces are discarded. See section 8.2.

I was agreeing with you...

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

>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

---

From: Acee Lindem <[email-masked]>
Date: Tue, 28 Nov 2006 16:47:51 -0500

Hi Lou,
> a comment (to the end of 3.1) and reference.
Great.
> 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.
> okay, language is a hold-over from 2230.  will update to match above. 
Great.
> I was agreeing with you...
Ok.
> 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. Also, do
we have to add the detail about the ASBR-summary-LSAs (as they
are referred to RFC 2328).

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

Thanks,
Acee