Re: [Lsr] AD Review of draft-ietf-ospf-ospfv2-hbit-06

["Acee Lindem (acee)" <[e-mail]>]

Hi Padma, 
Is the updated draft coming soon? 
Thanks,
Acee 

On 11/28/18, 2:31 PM, "Padmadevi Pillay Esnault" <[e-mail]> 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" <[e-mail]> 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.
        
        127        0                   1                   2                   3
        128        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        129       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        130       |            LS age             |     Options   |       1       |
        131       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        132       |                        Link State ID                          |
        133       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        134       |                     Advertising Router                        |
        135       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        136       |                     LS sequence number                        |
        137       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        138       |         LS checksum           |             length            |
        139       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        140       |H|0|0|N|W|V|E|B|        0      |            # links            |
        141       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        142       |                          Link ID                              |
        143       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        144       |                         Link Data                             |
        145       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        146       |     Type      |     # TOS     |            metric             |
        147       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        148       |                              ...                              |
        149       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        150       |      TOS      |        0      |          TOS  metric          |
        151       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        152       |                          Link ID                              |
        153       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        154       |                         Link Data                             |
        155       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        156       |                              ...                              |
        
        158      bit H
        159          When set, an OSPFv2 router is a non-transit router and is
        160          incapable of forwarding transit traffic.
        
        [nit] Please label the figure: Figure 1...
        
        [minor] Even though it seems obvious from the figure, please be explicit in
        saying that the H-bit is the first bit (or however that bit is
        identified)...
        
        162   When the H-bit is set, an OSPFv2 router is a non-transit router and
        163   should not be used to forward transit traffic.  In this mode, the
        164   other OSPFv2 routers in the area SHOULD NOT use the originating
        165   OSPFv2 router for transit traffic, but MAY use the OSPFv2 router for
        166   local traffic destined to that OSPFv2 router.
        
        [minor] The first/second sentences seem redundant: "should not be used to
        forward transit traffic...SHOULD NOT use the originating OSPFv2 router for
        transit traffic".
        
        [major] When would the non-transit router be used for transit?  IOW, why
        use "SHOULD NOT" and not "MUST NOT"?
        
        [major] "MAY use the OSPFv2 router for local traffic destined to that
        OSPFv2 router"   I'm not sure what behavior is being specified here.  The
        text sounds as if it was optional to even consider the router as a traffic
        destination.  Is that the intent?  Why?  What would make a network operator
        decide one way or the other?
        
        168   An OSPFv2 router originating a router-LSA with the H-bit set SHOULD
        169   advertise all its non-local router links with a link cost of
        170   MaxLinkMetric as defined in Section 3 of [RFC6987].  This is to
        171   increase the applicability of the H-bit to partial deployments where
        172   it is the responsibility of the operator to ensure that OSPFv2
        173   routers not supporting the H-bit do not install routes causing
        174   routing loops.
        
        [major] When would a router not advertise MaxLinkMetric?  IOW, why use
        SHOULD and not MUST?
        
        [major] What are "non-local router links"?  I always thought of links to be
        local to the router...what am I missing?
        
        [nit] s/advertise all its non-local router links with a link cost of
        MaxLinkMetric as defined in Section 3 of [RFC6987]/advertise all its
        non-local router links with a link cost of MaxLinkMetric [RFC6987]
        
        176   When the H-bit is set, IPv4 prefixes associated with local interfaces
        177   in other areas MAY be advertised in summary LSAs.  Non-local IPv4
        178   prefixes, e.g., those advertised by other routers and installed
        179   during the SPF computation, MAY be advertised in summary-LSAs if
        180   configured by policy.  Likewise, when the H-bit is set, only IPv4
        181   prefixes associated with local interfaces MAY be advertised in AS-
        182   external LSAs.  Non-local IPv4 prefixes, e.g., those exported from
        183   other routing protocols, MUST NOT be advertised in AS-external-LSAs.
        184   Finally, when the H-bit is set, an Area Border Router (ABR) MUST
        185   advertise a consistent H-bit setting in its self-originated router-
        186   LSAs for all attached areas.
        
        [minor] Some of the behavior specified in this paragraph may be non
        intuitive -- for example: "When the H-bit is set, IPv4 prefixes associated
        with local interfaces in other areas MAY be advertised in summary LSAs."
         During normal operation (aka rfc2328), these prefixes are always
        advertised (assuming normal areas, etc.)...and given that these are local
        to the router, it can be argued that one is not using the router as
        transit...on the other hand, going to a different area can be interpreted
        as transit.  In either case, it would be nice if more was said about the
        optional nature of including these prefixes in the summary LSA.  What are
        the operational considerations?
        
        [minor] The same comment for "prefixes associated with local interfaces MAY
        be advertised in AS-external LSAs".
        
        [major] "Non-local IPv4 prefixes...MAY be advertised in summary-LSAs if
        configured by policy."  Doesn't advertising result in the router being
        transit?  Doesn't it defeats the purpose of setting the H-bit?  But there
        may be operational reasons to do so -- e.g. if the router is the only ABR..