Re: [Gen-art] Genart last call review of draft-ietf-ospf-ospfv2-hbit-10

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

On Thu, Oct 31, 2019 at 11:54 AM Acee Lindem (acee) <[e-mail]> wrote:

> See one inline.
>
>
>
> *From: *Acee Lindem <[e-mail]>
> *Date: *Thursday, October 31, 2019 at 2:39 PM
> *To: *Padma Pillay-Esnault <[e-mail]>, Mohit Sethi <
> [e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
> *Resent-From: *<[e-mail]>
> *Resent-To: *Keyur Patel <[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, Yingzhen Qu <
> [e-mail]>, Christian Hopps <[e-mail]>, Acee
> Lindem <[e-mail]>, Martin Vigoureux <[e-mail]>,
> Deborah Brungard <[e-mail]>, Alvaro Retana <[e-mail]>,
> Yingzhen Qu <[e-mail]>
> *Resent-Date: *Thursday, October 31, 2019 at 2:39 PM
>
>
>
> HI Padma, Mohit,
>
>
>
> *From: *Padma Pillay-Esnault <[e-mail]>
> *Date: *Thursday, October 31, 2019 at 2:17 PM
> *To: *Mohit Sethi <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>,
> Padma Pillay-Esnault <[e-mail]>
> *Subject: *Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
> *Resent-From: *<[e-mail]>
> *Resent-To: *Keyur Patel <[e-mail]>, <[e-mail]>, <
> [e-mail]>, <[e-mail]>, Yingzhen Qu <
> [e-mail]>, Christian Hopps <[e-mail]>, Acee
> Lindem <[e-mail]>, Martin Vigoureux <[e-mail]>,
> Deborah Brungard <[e-mail]>, Alvaro Retana <[e-mail]>,
> Yingzhen Qu <[e-mail]>
> *Resent-Date: *Thursday, October 31, 2019 at 2:17 PM
>
>
>
> 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 <
> [e-mail]> 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.
>
>
>
> This sounds fine to me. However, I was surprised that this was apparent
> from the original abstract and first paragraph of the introduction.
>
>
>
> I meant “not apparent”…
>
>
>
> Acee
>


Also felt that this was apparent but do not mind adding this small change
if it is helpful.

Padma

>
> 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.
>
>
>
> A little more background for Mohit… OSPFv3 followed OSPFv2 by about 5+
> years and preventing transit traffic was recognized as a requirement. In
> OSPFv3 (RFC 5340), the corollary function is provided by the R-bit which
> must be set in order for a Router’s Router-LSA to be used in path
> computations for transit traffic. We would have liked to have used the same
> R-bit in OSPFv2 but it would not have been backward compatible since you
> can’t mandate that a bit be set for an existing LSA to be used. Hence, the
> OSPFv2 H-bit is the corollary of the OSPFv3 R-bit.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
> 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.
>