Dear Mohit Thank you for your review.
Please see below PPE for responses and suggestion. Padma On Thu, Oct 31, 2019 at 1:08 AM Mohit Sethi via Datatracker < nore...@ietf.org> wrote: > Reviewer: Mohit Sethi > Review result: Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-ospf-ospfv2-hbit-10 > Reviewer: Mohit Sethi > Review Date: 2019-10-31 > IETF LC End Date: 2019-11-07 > IESG Telechat date: Not scheduled for a telechat > > Summary: > This document uses a bit in the link state advertisement (LSA) sent from > routers to indicate that they are hosts which will not forward transit > traffic. > The document is READY for publication. > > Major issues: > > Minor issues: > I think the document would benefit from some more discussion on what > happens if > a router that is repelling traffic is on the only path to some > destinations? PPE: The router with the H-bit set will not be "on the only path" to other destinations, rather it would look that there is no path for transit traffic to other routers. CURRENT: This document describes the Host-bit (H-bit) functionality that prevents other OSPFv2 routers from using the host router for transit traffic in OSPFv2 routing domains. SUGGESTED NEW: This document describes the Host-bit (H-bit) functionality that prevents other OSPFv2 routers from using the host router by excluding it in path calculations for transit traffic in OSPFv2 routing domains. Does this address your comment? How is this handled? PPE: The changes in the SPF calculation in Section 4 ensure that the router with the H-bit set is excluded for the path calculations for transit traffic. > Is it fair to say that H-bit is only a best effort way of > repelling traffic and does not guarantee that the transit traffic is > actually > interrupted? > > PPE: No that would not be correct. The above describes the best effort that exists today with use of metrics and this is the gap that H-bit is addressing. With the H-bit functionality, the host router will not attract the transit traffic as it is excluded from route calculations other than its host destination(s). Indeed, other OSPFv2 routers in the domain should not forward any transit traffic to it as the host router will not appear on the path at all. > Any reason that this is only done for OSPFv2 and not v3? Are there ways of > achieving this functionality (of repelling transit traffic) already in v3? > > PPE: No needed in OSPFv3 as it has a similar mechanism in the standard already. Nits/editorial comments: > - Please expand acronyms like NSSA and LSAs on first usage. > PPE: Fixed OLD: In addition, this document updates RFC 6987 to advertise type-2 External and NSSA LSAs with a high cost in order to repel traffic effectively. NEW: In addition, this document updates RFC 6987 to advertise type-2 External and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a high cost in order to repel traffic effectively. - Abstract has stray " symbol. PPE: Fixed OLD: This document defines a bit (Host-bit) that enables a router to advertise that it is a non-transit router." NEW: This document defines a bit (Host-bit) that enables a router to advertise that it is a non-transit router. > > - The list in the acknowledgements section could benefit from an Oxford > comma: > Abhay Roy, David Ward, Burjiz Pithawala, and Michael Barnes for their > comments. > > PPE: Fixed OLD: Abhay Roy, David Ward, Burjiz Pithawala and Michael Barnes for their comments. NEW: Abhay Roy, David Ward, Burjiz Pithawala, and Michael Barnes for their comments.
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
