Subject: [Last-Call] Genart last call review of draft-ietf-ospf-ospfv2-hbit-10

From: Mohit Sethi via Datatracker <[email-masked]>
Date: Thu, 31 Oct 2019 01:08:39 -0700

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?
How is this handled? 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?

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?

Nits/editorial comments:
- Please expand acronyms like NSSA and LSAs on first usage.
- Abstract has stray " symbol.
-  The list in the acknowledgements section could benefit from an Oxford comma:
Abhay Roy, David Ward, Burjiz Pithawala, and Michael Barnes for their comments.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 31 Oct 2019 11:17:17 -0700

Dear Mohit

Thank you for your review.

Please see below PPE for responses and suggestion.

Padma

> a router that is repelling traffic is on the only path to some

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
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.

> 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.

> - 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.

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.

> 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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 31 Oct 2019 18:39:02 +0000

HI Padma, Mohit,

From: Padma Pillay-Esnault <[email-masked]>
Date: Thursday, October 31, 2019 at 2:17 PM
To: Mohit Sethi <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Padma Pillay-Esnault <[email-masked]>
Subject: Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
Resent-From: <[email-masked]>
Resent-To: Keyur Patel <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Yingzhen Qu <[email-masked]>, Christian Hopps <[email-masked]>, Acee Lindem <[email-masked]>, Martin Vigoureux <[email-masked]>, Deborah Brungard <[email-masked]>, Alvaro Retana <[email-masked]>, Yingzhen Qu <[email-masked]>
Resent-Date: Thursday, October 31, 2019 at 2:17 PM

Dear Mohit

Padma

On Thu, Oct 31, 2019 at 1:08 AM Mohit Sethi via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer: Mohit Sethi
Review result: Ready

Summary:

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.

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.

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.

PPE:

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:

OLD:

NEW:

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.

OLD:
Abhay Roy, David Ward, Burjiz Pithawala and Michael Barnes for their comments.

NEW:

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 31 Oct 2019 18:54:12 +0000

See one inline.

From: Acee Lindem <[email-masked]>
Date: Thursday, October 31, 2019 at 2:39 PM
To: Padma Pillay-Esnault <[email-masked]>, Mohit Sethi <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
Resent-From: <[email-masked]>
Resent-To: Keyur Patel <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Yingzhen Qu <[email-masked]>, Christian Hopps <[email-masked]>, Acee Lindem <[email-masked]>, Martin Vigoureux <[email-masked]>, Deborah Brungard <[email-masked]>, Alvaro Retana <[email-masked]>, Yingzhen Qu <[email-masked]>
Resent-Date: Thursday, October 31, 2019 at 2:39 PM

HI Padma, Mohit,

Dear Mohit

Padma

Summary:

Major issues:

Minor issues:

CURRENT:

SUGGESTED NEW:

I meant “not apparent”…

Acee

PPE:

PPE:

PPE:

Thanks,
Acee

Nits/editorial comments:

OLD:

NEW:

OLD:

NEW:

OLD:

NEW:

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 31 Oct 2019 11:57:22 -0700

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

> See one inline.
>
>
>
> *From: *Acee Lindem <[email-masked]>
> *Date: *Thursday, October 31, 2019 at 2:39 PM
> *To: *Padma Pillay-Esnault <[email-masked]>, Mohit Sethi <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
> *Resent-From: *<[email-masked]>
> *Resent-To: *Keyur Patel <[email-masked]>, <[email-masked]>, <
> [email-masked]>, <[email-masked]>, Yingzhen Qu <
> [email-masked]>, Christian Hopps <[email-masked]>, Acee
> Lindem <[email-masked]>, Martin Vigoureux <[email-masked]>,
> Deborah Brungard <[email-masked]>, Alvaro Retana <[email-masked]>,
> Yingzhen Qu <[email-masked]>
> *Resent-Date: *Thursday, October 31, 2019 at 2:39 PM
>
>
>
> HI Padma, Mohit,
>
>
>
> *From: *Padma Pillay-Esnault <[email-masked]>
> *Date: *Thursday, October 31, 2019 at 2:17 PM
> *To: *Mohit Sethi <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>,
> Padma Pillay-Esnault <[email-masked]>
> *Subject: *Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
> *Resent-From: *<[email-masked]>
> *Resent-To: *Keyur Patel <[email-masked]>, <[email-masked]>, <
> [email-masked]>, <[email-masked]>, Yingzhen Qu <
> [email-masked]>, Christian Hopps <[email-masked]>, Acee
> Lindem <[email-masked]>, Martin Vigoureux <[email-masked]>,
> Deborah Brungard <[email-masked]>, Alvaro Retana <[email-masked]>,
> Yingzhen Qu <[email-masked]>
> *Resent-Date: *Thursday, October 31, 2019 at 2:17 PM
>
>
>
> Dear Mohit
>
>
>
> 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

> 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: