Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf-ospfv3-lsa-extend-21: (with COMMENT)
Alia Atlas <akatlas@gmail.com> Wed, 24 January 2018 23:51 UTC
Return-Path: <akatlas@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753E112D850; Wed, 24 Jan 2018 15:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuDWo6StOGSG; Wed, 24 Jan 2018 15:51:01 -0800 (PST)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642C612AF6E; Wed, 24 Jan 2018 15:51:01 -0800 (PST)
Received: by mail-oi0-x22a.google.com with SMTP id s11so4074122oih.11; Wed, 24 Jan 2018 15:51:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vvnM5LLFN5XuWn9UuRzbhHXPeSzO6yrrH/yw9Inyf+k=; b=BB7DCxVM2qC451lxGIZaYiBTIicoHLolMX/GsPJVF1XEcsYD6kawmSlWefiF6sJ0wW T0KoEBkMkAEXh/YGkbuzeob0LzawEYDYj7M4uBEV8wTxCn4sAEwhHj3OQ64KnqrJ4qZB pqlj17M8aHfBMeljapXniL6NHGhf2PV/HCiDWg5Sz5zUkNkY7ry6eTWohs6KKixo52fe 23B9B9AdbnphquPIOvHpKccNDFjc5dUd9Qb6b2pd+SrnFdUEPb9TZS8So2Ca/SVCeINq XG+xWopPopIY+C9D6mIREsFLs/eoj3QjcaT8AfI44PXN9UQrmDDesnYCsi0mFvAM9hCl d7xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vvnM5LLFN5XuWn9UuRzbhHXPeSzO6yrrH/yw9Inyf+k=; b=b32BwndZ4B6Zc9JTeq1JBNaItZLJOsU0etjwTrKQkmFDRJw4AuJvcp8N3QZZzZU3Q8 Hiz+oiRNMApCfzRjV/fdj8WZtUTBbp45PAlt+5i+HYdg07uTWAs8UpN9mn0XqlR/ZM6j clORzcNHT+nut6KsXWvjl9fGDv44mdQsty+JqMXShhhv3VaNMRgNGmFnTxRQAMhsgUxQ R7JR4Mf1i1dEliXUB+jXUpRhh0OMPkI6fJcy/yj+FTYhFUkuJuAO+6XUCZbhIVmpN8za qI5GPGrxCFh3/HEet2CRgdPNKFtlFfko9WPyCoqz/91TmSACHX1uh0/0Ycd2z6jrG3of GkoQ==
X-Gm-Message-State: AKwxytezd0Jlc79HFHkHJlW1wLrZKOFy5wkS2kf/ZdKEYT7ioptuFtVB x9Ubt2KUmbGSk1NZNkM6Kpn8aZ8NrXB9k8hLz2Q=
X-Google-Smtp-Source: AH8x225uoC3oYxECIG6S8P3gjVqQA9KolfmA4b9k6lXxnQv6FcF65srgIO02GYIwIpEPpYva3kMKnys57dJQyO9aOxQ=
X-Received: by 10.202.75.15 with SMTP id y15mr9030511oia.5.1516837860549; Wed, 24 Jan 2018 15:51:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.21.103 with HTTP; Wed, 24 Jan 2018 15:51:00 -0800 (PST)
In-Reply-To: <5C0BFC49-7442-4108-B3EA-B7BBD5E2A959@cisco.com>
References: <151680525796.25656.8973774628355392577.idtracker@ietfa.amsl.com> <5C0BFC49-7442-4108-B3EA-B7BBD5E2A959@cisco.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Wed, 24 Jan 2018 18:51:00 -0500
Message-ID: <CAG4d1rddCcfXwGye3WfhjmOShMGaZHwBrAu2r_7OvPbkJK5Aeg@mail.gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>, "draft-ietf-ospf-ospfv3-lsa-extend@ietf.org" <draft-ietf-ospf-ospfv3-lsa-extend@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
Content-Type: multipart/alternative; boundary="001a11c17f54dc295805638e55eb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/5C-pkxqRFh_LOJJMA_bCCeGKfTo>
Subject: Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf-ospfv3-lsa-extend-21: (with COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2018 23:51:04 -0000
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) <acee@cisco.com> 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" <aretana.ietf@gmail.com> 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 > > > > >
- [OSPF] Alvaro Retana's Yes on draft-ietf-ospf-osp… Alvaro Retana
- Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf… Acee Lindem (acee)
- Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf… Alia Atlas
- Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf… Acee Lindem (acee)
- Re: [OSPF] Alvaro Retana's Yes on draft-ietf-ospf… Alvaro Retana