Hello Jia
Thank you for your review.
On Mon, Oct 7, 2019 at 5:08 PM Hejia (Jia) 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
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
