Re: [Lsr] Subject: RtgDir review: draft-ietf-ospf-ospfv2-hbit-09.txt

[Padma Pillay-Esnault <[e-mail]>]

Hello Jia

Thank you for your review.

On Mon, Oct 7, 2019 at 5:08 PM Hejia (Jia) <[e-mail]> wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The
>
> Routing Directorate seeks to review all routing or routing-related drafts
> as
>
> they pass through IETF last call and IESG review, and sometimes on special
>
> request. The purpose of the review is to provide assistance to the Routing
> ADs.
>
> For more information about the Routing Directorate, please see
>
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would
>
> be helpful if you could consider them along with any other IETF Last Call
>
> comments that you receive, and strive to resolve them through discussion
> or by
>
> updating the draft.
>
> Document: draft-ietf-ospf-ospfv2-hbit-09.txt
> Reviewer: Jia He
> Review Date: 07 October 2019
> IETF LC End Date: date-if-known
> Intended Status: Standards Track
>
> Summary:
>
>
> This document is basically ready for publication, but has nits that should
> be
>
> considered prior to publication.
>
>
> Comments:
>
> The draft is short and the problem to be solved is clear, however, some
> nits
>
> could be fixed to improve the readability.
>
> Major Issues:
> None
>
> Minor Issues:
> 1) The current version updates RFC6987 only. However, there are
> modifications to
>
> RFC2328 as described in the draft. Any thought of adding RFC2328 in the
> update?
>
>
> PPE> This has been discussed with the AD and it was deemed that changes
are additions to RFC2328 but does not require a change in RFC2328. The
conclusion of those discussion are NOT to add RFC2328 in the update.


> Nits:
>
> 1) There are several forms of h-bit throughout the document, e.g. Host-Bit
> (H-
>
> bit),H-Bit, Host Bit.... It is better that they are aligned.
>

PPE> OK will made the modifications

>
> 2) Introduction,
>
>    This document describes the Host-bit (H-Bit)functionality that
>    prevents other OSPFv2 routers from using the router for transit
>    traffic in OSPFv2 routing domains.
>
> The difference between "other OSPFv2 routers" and "the router" is not
> clearly
>
> described. How about replacing "the router" with "the host router" or "the
>
> router with H-bit set"?
>

PPE> Agree to this suggestion for clarity.

>
> 3) Section 3,
>    If the host-bit is NOT set routers MUST act transit routers as
>    described in [RFC2328] ensuring backward compatibility.
>
> s/act transit routers/act as transit routers
>

PPE> Agree to the change

>
> 4) Section 4,
>
>                    If this is a router-LSA, and the H-bit
>                    of the router-LSA is set, and
>                    vertex V is not the root, then the
>                    router should not be used for transit
>
> s/used for transit/used for transit traffic
>
> PPE> in this context we meant not to be used as a transit router.

>
> 5) Section 5,
>
>    To avoid the possibility of any routing loops due to partial
>    deployment, this document defines a OSPF Router Information (RI) LSA
>    [RFC7770] with and an area flooding scope and a new bit assigned in
>    the OSPF Router Informational Capability Bits Registry.
>
> s/with and/within
>
> ppe> agree

>
> 6) Section 5,
> "  Auto Discovery via announcement of the Host Support Functional
>    Capability",
>
> To get aligned with the naming in the OSPF Router Informational Capability
> Bits
>
> Registry, s/Host Support Functional Capability/Host Router Support
> capability
>
>
PPE> Agree to this change

> 7) Section 5,
>
>    For example, in a new router
>    joins an area which previous had only H-bit capable routers with
>    H-bit set then it may take some time for the RI to propagate to all
>    routers.
>
> s/in a new router joins an area which previous had only H-bit capable
> routers
>
> with H-bit set /when a new router joins an area which previously had only
> H-bit
>
> capable routers with H-bit set
>
> PPE> Agree to the change

> 8) Section 5,
>
>       All routers, with the H-bit set, MUST advertise all of the
>       router's non-local links with a metric equal to MaxLinkMetric in
>       its LSAs in order to avoid OSPFv2 (unless last resort) routers not
>       supporting the H-bit from attempting to use it for transit
>       traffic.
>
> s/avoid/prevent
>
> PPE> we believe avoid is the correct term as for last resort it will not
"prevent" the router being used.

Thanks

Padma

>
> B.R.
> Jia
>
>
>