Hi Alvaro, Apologies for the delay. We will go thru the comments and get back to you.
Regards, Keyur From: Alvaro Retana <[email protected]> Date: Tuesday, February 12, 2019 at 1:26 PM To: Padmadevi Pillay Esnault <[email protected]>, "[email protected]" <[email protected]> Cc: Yingzhen Qu <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "Acee Lindem (acee)" <[email protected]> Subject: Re: AD Review of draft-ietf-ospf-ospfv2-hbit-06 Resent-From: <[email protected]> Resent-To: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]> Resent-Date: Tuesday, February 12, 2019 at 1:26 PM Ping! Any progress on this document? Thanks! Alvaro. On December 17, 2018 at 8:22:25 AM, Acee Lindem (acee) ([email protected]<mailto:[email protected]>) wrote: Hi Padma, Is the updated draft coming soon? Thanks, Acee On 11/28/18, 2:31 PM, "Padmadevi Pillay Esnault" <[email protected]<mailto:[email protected]>> wrote: Dear Alvaro Thank you for your review. We will go through the comments and work on them. Thanks Padma on behalf of my co-authors On 11/28/18, 7:53 AM, "Alvaro Retana" <[email protected]<mailto:[email protected]>> wrote: Dear authors: I just finished reading this document. Even though it is relatively short, I have significant concerns and I think it needs more work. Please take a look at the detailed comments in-line below -- I'm highlighting some of the issues here. (1) What is the Update to rfc2328? Please be specific in both the Abstract and the Introduction to indicate how rfc2328 is Updated. Also, see my question about rfc6987 in §6. (2) Operational/Deployment Considerations. There are several places (specially in §3) where the specification offers a choice (e.g. by using MAY). Some of those choices would be better informed if there was a discussion of the considerations behind them. Please take a look at rfc5706 (specially §2). Either a discussion close to where the behavior is specified or a separate section is ok. Please also keep migration in mind (see comments in §5). (3) Both the IANA and Security Considerations sections need more details. I will wait for them to be addressed before starting the IETF Last Call. Thanks! Alvaro. [The line numbers come from idnits.] ... 11 H-bit Support for OSPFv2 12 draft-ietf-ospf-ospfv2-hbit-06 [nit] Please make the title more descriptive. "non-transit router", "host mode", etc. come to mind. 14 Abstract 16 OSPFv3 defines an option bit for router-LSAs known as the R-bit in 17 RFC5340. If the R-bit is clear, an OSPFv3 router can participate in 18 OSPF topology flooding, however it will not be used as a transit 19 router. In such cases, other routers in the OSPFv3 routing domain 20 only install routes to allow local traffic delivery. This document 21 defines the H-bit functionality to prevent other OSPFv2 routers from 22 using the router for transit traffic in OSPFv2 routing domains as 23 described in RFC 2328. This document updates RFC 2328. [minor] Describing the functionality in terms of OSPFv2 would have been nice. IOW, there's no need (in the Abstract) to force the reader to go figure out what OSPFv3 already did to decide if it's worth reading this document or not. [major] What is the Update to rfc2328? Please be specific, both here and in the Introduction: don't just mention the section updated, but (more important) what is the update about. "This document updates rfc2328 by assigning a bit...changing the SPF process...creating a registry..." All/none/something else? Note that the answer to "what is the update?" doesn't have to be all. I think that the registry creation is a must. But Updating because of the SPF changes means that you expect an rfc2328 implementation to consider the H-bit when running SPF. I think you really mean that implementations of this document (i.e. not all rfc2328 implementations) have to use the modified SPF. That is my guess...please consider the answer carefully. ... 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. [major] As far as I can tell, the first version of draft-keyupate-ospf-ospfv2-hbit (the predecessor of this document) was published in 2015. So the copyright text above doesn't apply. Are we missing other predecessors? If not, then this issue should be easy to fix. In at least the XML editor that I use, there's an option to indicate pre-RFC5378 work, or not. In this case it seems like it should be No. ... 85 1. Introduction [minor] Same comment as for the Abstract: describing the functionality in terms of OSPFv2 would have been nicer. You can still make the reference to the R-bit at the end, if you really want to. 87 OSPFv3 [RFC5340] defines an option bit for router-LSAs known as the 88 R-bit. If the R-bit is clear, an OSPFv3 router can participate in 89 OSPFv3 topology flooding without acting as a transit router. In such 90 cases, other routers in the OSPFv3 routing domain only install routes 91 used for local traffic. 93 This functionality is particularly useful for BGP Route Reflectors, 94 known as virtual Route Reflectors (vRRs), that are not in the 95 forwarding path but are in central locations such as data centers. 96 Such Route Reflectors typically are used for route distribution and 97 are not capable of forwarding transit traffic. However, they need to 98 learn the OSPF topology for: 100 1. SPF computation for Optimal Route Reflection functionality as 101 defined in [I-D.ietf-idr-bgp-optimal-route-reflection] 103 2. Reachability resolution for its Route Reflector Clients. [nit] Clearly route reflection is not the only motivation for this work. The justification only related to RRs seems gratuitous. Just a nit... 105 This document defines the R-bit functionality equivalent for OSPFv2 106 defined in [RFC2328] by introducing a new router-LSA bit known as the 107 "H-bit". This document updates appendix A.4.2 of RFC 2328. [nit] s/OSPFv2 defined in [RFC2328]/OSPFv2 [RFC2328] It sounds as if "the R-bit functionality equivalent for OSPFv2" is already in rfc2328. [major] Please be specific about what the Update is. ... 117 3. H-bit Support 119 This document defines a new router-LSA bit known as the Host Bit or 120 the H-bit. An OSPFv2 router advertising a router-LSA with the H-bit 121 set indicates to other OSPFv2 routers in the area supporting the 122 functionality that it MUST NOT be used as a transit router. The bit 123 value usage of the H-bit is reversed from the R-bit defined in OSPFv3 124 [RFC5340] to support backward compatibility. The modified OSPFv2 125 router-LSA format is: [minor] "...MUST NOT be used as a transit router" Put a forward reference to §4. [nit] The text keeps making reference to the R-bit. Even though there is a relationship, the H-bit is an independent feature. IOW, I don't think there's a need to explain the relationship to OSPFv3. [minor] On the same topic: The comparison to OSPFv3 is made and the "reverse" bit setting is justified "to support backward compatibility", but that is not explained anywhere. I was hoping that §5 (Auto Discovery and Backward Compatibility) would say something, but it doesn't
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
