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

From: Alvaro Retana <[email-masked]>
Date: Wed, 24 Jan 2018 06:47:37 -0800

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.

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

(3) I'm confused, why is the N-bit needed?  The description indicates when to
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.

(4) s/The IPv4 Forwarding Address TLV is The IPv4 Forwarding Address TLV/The
IPv4 Forwarding Address TLV

(5) s/IPv3/IPv4

(6) The figures in 3.10 and 3.11 have the wrong tittle.

(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?  What should a router do if
it receives an E-Router-LSA with no Router-Link TLVs?

(8) s/Inter-Area-Router-LSAE/Inter-Area-Router-LSA

(9) sparse mode is called "spare mode" in a couple of places...or maybe it's
the other way around. ;-)

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

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

(12) In Appendix B: s/If ExtendedLSASupport is enabled/If
AreaExtendedLSASupport is enabled

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

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

(15) In C.1.1 s/MixedModeOriginate/MixedModeOriginateOnly

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 24 Jan 2018 23:12:59 +0000

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" <[email-masked]> wrote:

    

    

Ok - while it is obvious once the draft has been consumed, I'll state it in the Abstract and Introduction explicitly. 

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. 
    
s    use it, but is also says that the "advertising router MAY choose NOT to set

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. 

Fixed.

    (5) s/IPv3/IPv4

Fixed.

Fixed. 

    (7) From 4.1:

    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? 

Fixed. 

Fixed. 

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. 

Fixed. 

Fixed. 

    

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. 

That is why it is disallowed in 13. I changed "MAY" to "SHOULD". 

Fixed. 

Thanks,
Acee

---

From: Alia Atlas <[email-masked]>
Date: Wed, 24 Jan 2018 18:51:00 -0500

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) <[email-masked]> wrote:

> HI Alvaro,
>
> Thanks for the detailed review.  I've resolved almost all of your
> comments.  I'm going to issue a new version.
>
> Ok - while it is obvious once the draft has been consumed, I'll state it
> in the Abstract and Introduction explicitly.
>
>
> 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.
>
> 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.
>
> 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.
>
>  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?
>
>
> 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.
>
>
> 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.
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 25 Jan 2018 16:21:33 +0000

Hi Alia, Alvaro,
I believe the -23 version clarifies the usage of the N-bit in prefix advertisements.
Thanks,
Acee

From: Alia Atlas <[email-masked]>
Date: Wednesday, January 24, 2018 at 6:51 PM
To: Acee Lindem <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, The IESG <[email-masked]>, OSPF WG List <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>
Subject: Re: Alvaro Retana's Yes on draft-ietf-ospf-ospfv3-lsa-extend-21: (with COMMENT)

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) <[email-masked]<mailto:[email-masked]>> wrote:
HI Alvaro,

On 1/24/18, 9:47 AM, "Alvaro Retana" <[email-masked]<mailto:[email-masked]>> wrote:

Fixed.

    (5) s/IPv3/IPv4

Fixed.

Fixed.

    (7) From 4.1:

Fixed.

Fixed.

Fixed.

Fixed.

Fixed.

Thanks,
Acee

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 25 Jan 2018 13:44:12 -0500

Thanks!!

On January 25, 2018 at 11:21:36 AM, Acee Lindem (acee) ([email-masked])
wrote:

I believe the -23 version clarifies the usage of the N-bit in prefix
advertisements.