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
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
