On Thu, Oct 31, 2019 at 11:54 AM Acee Lindem (acee) <a...@cisco.com> wrote:
> See one inline. > > > > *From: *Acee Lindem <a...@cisco.com> > *Date: *Thursday, October 31, 2019 at 2:39 PM > *To: *Padma Pillay-Esnault <padma.i...@gmail.com>, Mohit Sethi < > mohit.m.se...@ericsson.com> > *Cc: *"gen-...@ietf.org" <gen-...@ietf.org>, "last-c...@ietf.org" < > last-c...@ietf.org>, "draft-ietf-ospf-ospfv2-hbit....@ietf.org" < > draft-ietf-ospf-ospfv2-hbit....@ietf.org>, "lsr@ietf.org" <lsr@ietf.org> > *Subject: *Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10 > *Resent-From: *<alias-boun...@ietf.org> > *Resent-To: *Keyur Patel <ke...@arrcus.com>, <padma.i...@gmail.com>, < > manbh...@cisco.com>, <ser...@cisco.com>, Yingzhen Qu < > yingzhen.i...@gmail.com>, Christian Hopps <cho...@chopps.org>, Acee > Lindem <a...@cisco.com>, Martin Vigoureux <martin.vigour...@nokia.com>, > Deborah Brungard <db3...@att.com>, Alvaro Retana <aretana.i...@gmail.com>, > Yingzhen Qu <yingzhen.i...@gmail.com> > *Resent-Date: *Thursday, October 31, 2019 at 2:39 PM > > > > HI Padma, Mohit, > > > > *From: *Padma Pillay-Esnault <padma.i...@gmail.com> > *Date: *Thursday, October 31, 2019 at 2:17 PM > *To: *Mohit Sethi <mohit.m.se...@ericsson.com> > *Cc: *"gen-...@ietf.org" <gen-...@ietf.org>, "last-c...@ietf.org" < > last-c...@ietf.org>, "draft-ietf-ospf-ospfv2-hbit....@ietf.org" < > draft-ietf-ospf-ospfv2-hbit....@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, > Padma Pillay-Esnault <padma.i...@gmail.com> > *Subject: *Re: Genart last call review of draft-ietf-ospf-ospfv2-hbit-10 > *Resent-From: *<alias-boun...@ietf.org> > *Resent-To: *Keyur Patel <ke...@arrcus.com>, <padma.i...@gmail.com>, < > manbh...@cisco.com>, <ser...@cisco.com>, Yingzhen Qu < > yingzhen.i...@gmail.com>, Christian Hopps <cho...@chopps.org>, Acee > Lindem <a...@cisco.com>, Martin Vigoureux <martin.vigour...@nokia.com>, > Deborah Brungard <db3...@att.com>, Alvaro Retana <aretana.i...@gmail.com>, > Yingzhen Qu <yingzhen.i...@gmail.com> > *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 < > 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. > > > > 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. >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
