Lou
At 07:03 PM 11/13/2006, Acee Lindem wrote:
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).
valid point.
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.
What benefit would this have?
Detailed comments:
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
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.
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.
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
and everyone knew what it implied.
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.
In fact, if the opaque MIB objects are all covered in the new MIB, we can
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.
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.
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.
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 ....
Section 10.1 - Correct NSSA reference to RFC 3101.
thanks.
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..".
done.
General - Replace "stub area" with "stub or NSSA areas".
sure.
Thanks,
Acee
Great comments.
Much thanks.
Lou
