HI Padma, Mohit,
From:
Padma Pillay-Esnault <padma.ietf@xxxxxxxxx>
Date: Thursday, October 31, 2019 at 2:17 PM
To: Mohit Sethi <mohit.m.sethi@xxxxxxxxxxxx>
Cc: "gen-art@xxxxxxxx" <gen-art@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>, "draft-ietf-ospf-ospfv2-hbit.all@xxxxxxxx" <draft-ietf-ospf-ospfv2-hbit.all@xxxxxxxx>, "lsr@xxxxxxxx" <lsr@xxxxxxxx>, Padma Pillay-Esnault <padma.ietf@xxxxxxxxx>
Subject: Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10
Resent-From: <alias-bounces@xxxxxxxx>
Resent-To: Keyur Patel <keyur@xxxxxxxxxx>, <padma.ietf@xxxxxxxxx>, <manbhard@xxxxxxxxx>, <serpil@xxxxxxxxx>, Yingzhen Qu <yingzhen.ietf@xxxxxxxxx>, Christian Hopps <chopps@xxxxxxxxxx>, Acee Lindem <acee@xxxxxxxxx>, Martin Vigoureux <martin.vigoureux@xxxxxxxxx>,
Deborah Brungard <db3546@xxxxxxx>, Alvaro Retana <aretana.ietf@xxxxxxxxx>, Yingzhen Qu <yingzhen.ietf@xxxxxxxxx>
Resent-Date: Thursday, October 31, 2019 at 2:17 PM
Thank you for your review.
Please see below PPE for responses and suggestion.
On Thu, Oct 31, 2019 at 1:08 AM Mohit Sethi via Datatracker <noreply@xxxxxxxx> 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.
Does this address your comment?
How is this handled?
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?
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?
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.
|
