Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf-ospfv3-lsa-extend-21: (with COMMENT)

[Alia Atlas <[e-mail]>]

Hi Acee,

Thanks for your quick responses.  On the point about the N-flag, I also
found it was
a bit underspecified in my AD review.  Could you please spend a bit of time
thinking
about how to make it clearer.

Thanks,
Alia

On Wed, Jan 24, 2018 at 6:12 PM, Acee Lindem (acee) <[e-mail]> wrote:

> HI Alvaro,
>
> Thanks for the detailed review.  I've resolved almost all of your
> comments.  I'm going to issue a new version.
>
> On 1/24/18, 9:47 AM, "Alvaro Retana" <[e-mail]> wrote:
>
>     Alvaro Retana has entered the following ballot position for
>     draft-ietf-ospf-ospfv3-lsa-extend-21: Yes
>
>     When responding, please keep the subject line intact and reply to all
>     email addresses included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.)
>
>
>     Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
>     for more information about IESG DISCUSS and COMMENT positions.
>
>
>     The document, along with other ballot positions, can be found here:
>     https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend/
>
>
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     Thanks for doing this work!!
>
>     All my comments (below) are non-blocking, but I would like to see them
>     addressed before publication.
>
>     (1) Please include in an explicit indication of what in
> rfc5340/rfc5838 is
>     Updated by this document.
>
> Ok - while it is obvious once the draft has been consumed, I'll state it
> in the Abstract and Introduction explicitly.
>
>
>     (2) It seems to me that the setting of the U-bit is treated too
> lightly: "the
>     U-bit will be set"; maybe be more prescriptive: "the U-bit MUST be
> set".
>
> Sure. Although the U-bit is included in the full LSA type so this was
> really more informative than normative. However, I don't have a strong
> opinion.
>
>     (3) I'm confused, why is the N-bit needed?  The description indicates
> when to
> s    use it, but is also says that the "advertising router MAY choose NOT
> to set
>     [it]", so it doesn't sound that important.  Further down, there are
> other
>     conditions when it is set...but no other text in the document about
> checking
>     it, or what happens if it is not set. Finally, the text gives an
> application
>     example: "identifying the prefixes corresponding to Node Segment
> Identifiers
>     (SIDs) in Segment Routing" -- I checked the reference, but didn't find
> a
>     mention of the N-bit there either.
>
> I'm going to defer this one. However, it should be noted that it is also
> specified RFC 7684 as the Node-Flag with the same description.
>
>     (4) s/The IPv4 Forwarding Address TLV is The IPv4 Forwarding Address
> TLV/The
>     IPv4 Forwarding Address TLV
>
> Fixed.
>
>
>     (5) s/IPv3/IPv4
>
> Fixed.
>
>
>     (6) The figures in 3.10 and 3.11 have the wrong tittle.
>
> Fixed.
>
>
>     (7) From 4.1:
>        Depending on the implementation, it is perfectly valid for an E-
>        Router-LSA to not contain any Router-Link TLVs.  However, this would
>        imply that the OSPFv3 router doesn't have any active interfaces in
>        the corresponding area and such E-Router-LSA would never be flooded
>        to other OSPFv3 routers in the area.
>
>
>     I can imagine that a starting/restarting router could have a local
> E-Router-LSA
>     with no active interfaces, are there other cases?
>
> I was going to say it would never happen. However, if you have a single
> unnumbered interface (no stub link) and an adjacency (>= Exchange state) is
> being formed, you could have an E-Router-LSA with no links. I'll fix the
> text.
>
>     What should a router do if
>     it receives an E-Router-LSA with no Router-Link TLVs?
>
>  The same thing happens as in OSPFv2 and OSPFv3 today. The OSPFv3 router
> is not reachable via an OSPFv3 route.  Do you want me to add something
> other than fixing the above?
>
>
>     (8) s/Inter-Area-Router-LSAE/Inter-Area-Router-LSA
>
> Fixed.
>
>     (9) sparse mode is called "spare mode" in a couple of places...or
> maybe it's
>     the other way around. ;-)
>
> Fixed.
>
>     (10) In many OSPF-related documents the Appendixes are Normative, so
> I'm
>     assuming they are Normative here too.  Only A and B are referenced
> from the
>     main text -- C is titled "Deprecated LSA Extension Backward
> Compatibility";
>     deprecated??  Does that mean that C is an old behavior that lived at
> some point
>     in the history of this document?  The content of C doesn't seem to
> conflict
>     with what is in A and B, and there is some important information there
> -- for
>     example the transition process in C.1.  But C.2. and C.3. clearly
> overlap with
>     A and B.  Please clarify the role of the Appendixes.
>
>     [The following comments are related to the Appendixes and their
> relevance
>     depends on my comment above.]
>
> I think I'm going to remove Appendix C. It was made non-normative since we
> had an extended drought on implementation and this was assessed by me to be
> the greatest implementation barrier. I think it would be better to describe
> this in a new draft normatively. I've never been a fan of programmers
> adding code that MAY be used in the future. I'll see if any of the
> implementers are interested in this effort.
>
>
>     (11) The appendixes contain several places where the text says that a
> new
>     parameter "will be added" -- in reality this document adds those
> parameters.
>     Please update.
>
> Fixed.
>
>
>     (12) In Appendix B: s/If ExtendedLSASupport is enabled/If
>     AreaExtendedLSASupport is enabled
>
> Fixed.
>
>     (13) "...disabling AreaExtendedLSASupport when ExtendedLSASupport is
> enabled is
>     contradictory and MAY be prohibited by the implementation."  I'm not
> sure I
>     understand this text.
>
>     Can AreaExtendedLSASupport be enabled without enabling
> ExtendedLSASupport?  I'm
>     assuming that's the case (from 6.1: "Individual OSPF Areas can be
> migrated
>     separately...accomplished by enabled AreaExtendedLSASupport").  If so,
> then the
>     text above is confusing...
>
>     If not prohibited by the implementation, what if it happens
>     (AreaExtendedLSASupport is disabled while ExtendedLSASupport is
> enabled)?  From
>     the previous paragraphs, it seems to me that the network could lose
> external
>     routes (if only Legacy LSAs have that information)-- is that true?
>
>     OTOH, what if the implementation does prohibit the state -- does that
> mean that
>     external routes will not be used if they're not derived from Legacy
> LSAs?  I
>     think the text could use some clarification.
>
> If I add, "disabling AreaExtendedLSASupport for a regular area"? What this
> was meant to capture is the case where Extended-AS-External LSAs would be
> flooded into an area without AreaExtendedLSASupport.
>
>
>
>     (14) C.1.1. says that "The configuration of ExtendedLSASupport will
> apply to
>     AS-External LSAs even when AreaExtendedLSASupport takes precedence."
> But
>     Appendix B says that "Legacy AS-Scoped LSAs will still be originated
> and used
>     for the AS External LSA computation."  That seems like a contradiction
> to me.
>
> That is why it is disallowed in 13. I changed "MAY" to "SHOULD".
>
>
>     (15) In C.1.1 s/MixedModeOriginate/MixedModeOriginateOnly
>
> Fixed.
>
> Thanks,
> Acee
>
>
>
>
>