Skip to main content

Host Router Support for OSPFv2
RFC 8770

Revision differences

Document history

Date Rev. By Action
2020-04-09
12 (System)
Received changes through RFC Editor sync (created alias RFC 8770, changed abstract to 'The Open Shortest Path First Version 2 (OSPFv2) protocol does not …
Received changes through RFC Editor sync (created alias RFC 8770, changed abstract to 'The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path.  This document defines a bit called the Host-bit (H-bit).  This bit enables a router to advertise that it is a non-transit router.  This document also describes the changes needed to support the H-bit in the domain.  In addition, this document updates RFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA) Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively.', changed pages to 8, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-04-09, changed IESG state to RFC Published, created updates relation between draft-ietf-ospf-ospfv2-hbit and RFC 6987)
2020-04-09
12 (System) RFC published
2020-04-06
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-03-23
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-02-14
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-12-26
12 (System) IANA Action state changed to RFC-Ed-Ack from In Progress
2019-12-26
12 (System) IANA Action state changed to In Progress from Waiting on RFC Editor
2019-12-26
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2019-12-26
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2019-12-24
12 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2019-12-24
12 Tero Kivinen Assignment of request for Last Call review by SECDIR to Sean Turner was marked no-response
2019-12-23
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-12-20
12 (System) RFC Editor state changed to EDIT
2019-12-20
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-12-20
12 (System) Announcement was received by RFC Editor
2019-12-20
12 (System) IANA Action state changed to In Progress
2019-12-20
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-12-20
12 Amy Vezza IESG has approved the document
2019-12-20
12 Amy Vezza Closed "Approve" ballot
2019-12-19
12 Alvaro Retana IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2019-12-19
12 Alvaro Retana Ballot approval text was generated
2019-12-18
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-12-18
12 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-12.txt
2019-12-18
12 (System) New version approved
2019-12-18
12 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Padma Pillay-Esnault , Manish Bhardwaj , Keyur Patel
2019-12-18
12 Padma Pillay-Esnault Uploaded new revision
2019-12-05
11 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2019-12-04
11 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2019-12-04
11 Barry Leiba
[Ballot comment]
I'm going to complain about some wording in Section 5 that Ben already called out, but I'll try to put in some specific …
[Ballot comment]
I'm going to complain about some wording in Section 5 that Ben already called out, but I'll try to put in some specific suggestions for corrections here:

  In normal operation, there is no guarantee that the RI LSA will reach
  all routers in an area in a timely manner, which may result in
  forwarding loops in partial deployments.

This wording makes it sound exactly the opposite of what you mean, that if the RI LSA *does* reach all routers in a timely manner it can cause forwarding loops.  I suggest this:

NEW
  In normal operation, it is possible that the RI LSA will fail to
  reach all routers in an area in a timely manner.  That can result
  in forwarding loops in partial deployments.
END

  For example, if a new
  router joins an area, which previously had only H-bit capable routers
  with H-bit set then it may take some time for the RI to propagate to
  all routers.

First, change "area, which" to "area that" (no comma).  That fixes a usage problem.

But second, Ben and I are both unsure whether you mean that the new router does or doesn't support the H bit, or whether it matters.  Maybe the right approach here is to say a little more about what happens.  Something like this (adjust as needed to make it correct):

NEW
  For example, if a new
  router joins an area that previously had only H-bit capable routers
  with H-bit set then it may take some time for the RI to propagate to
  all routers.  While it is propagating, the area as a whole is unsure of
  the status of the new router, and that can cause
END

  o  All routers, with the H-bit set, MUST advertise all of the
      router's non-stub links with a metric equal to MaxLinkMetric

Both commas need to be removed here.

  o  All routers supporting H-Bit MUST check all the RI LSAs of nodes
      in the area before actively running the modified SPF to account
      for the H-bit in order to verify that all routers are in routing
      capability.

This is very awkwardly worded and is really hard to decipher.  I *think* you mean to say this:

NEW
  o  All routers supporting the H-Bit MUST check the RI LSAs of all
      nodes in the area to verify that all nodes support the H-Bit before
      actively using the H-Bit feature.
END

Did I get that right?
2019-12-04
11 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-12-04
11 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-12-04
11 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-12-04
11 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-12-03
11 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-12-03
11 Benjamin Kaduk
[Ballot comment]
Abstract

  The Open Shortest Path First Version 2 (OSPFv2) does not have a
  mechanism for a node to repel transit traffic …
[Ballot comment]
Abstract

  The Open Shortest Path First Version 2 (OSPFv2) does not have a
  mechanism for a node to repel transit traffic if it is on the
  shortest path.  This document defines a bit (Host-bit) that enables a

nit: I suggest to add "protocol" after "(OSPFv2)" to match the definite
article "The".

Section 1

  The OSPFv2 specifies a Shortest Path First (SPF) algorithm that

(same nit about adding "protocol")

  This functionality is particularly useful for a number of use cases:

nit: "this functionality" seems to refer to "the SPF algorithm that
identifies transit verticies based on their adjacencies", so I suggest
rewording to "such functionality would be useful" or "A mechanism to
move traffic away from the shortest path" or similar.

Section 4

I suggest noting that the (lettered) sub-procedures of step (2) remain
unchanged.

Section 5

  In normal operation, there is no guarantee that the RI LSA will reach
  all routers in an area in a timely manner, which may result in
  forwarding loops in partial deployments.  For example, if a new
  router joins an area, which previously had only H-bit capable routers
  with H-bit set then it may take some time for the RI to propagate to
  all routers.

It's currently only implicit that this new router does not support the
H-bit; shall we make it explicit?

  o  All routers supporting H-Bit MUST check all the RI LSAs of nodes
      in the area before actively running the modified SPF to account
      for the H-bit in order to verify that all routers are in routing
      capability.  If any router does not advertise the Host Router

nit: the grammar here is a little wonky, particularly for "all routers
are in routing capability" but perhaps also for "to account for the
H-bit".

Section 6

  When calculating the path to an OSPF AS-External-LSA or NSSA-LSA
  [RFC3101] with a Type-2 metric, [...]

nit: is this saying "calculating the path to [an LSA]"?  That's not a
usage I'm familiar with; can the AS-External-LSA or NSSA-LSA really
serve as a destination in this sense?

Section 7

Thank you for phrasing this as "this document requests the IANA to
assign", since until these specific values are officially assigned we
are technically "squatting" on them.  (The respective registration
policies of Standards Action and IETF Review give us pretty good control
that nothing else is going to swoop in on them, though.)
2019-12-03
11 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2019-12-03
11 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-12-03
11 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. The short document is easy to read even if I wonder whether it is …
[Ballot comment]
Thank you for the work put into this document. The short document is easy to read even if I wonder whether it is useful to spend time on IPv4-only protocol ;-)

The deployment issue (section 5) had raised a DISCUSS of mine and I appreciated your reply, so, I have cleared this DISCUSS.

Feel free to ignore my COMMENTs and NIT.

== COMMENTS ==

-- Generic --
Mentioning that the H-bit of OSPFv2 is the reverse of the R-bit of OSPFv3 would be useful.

-- Section 1 --
A description of "Closet Switches" would be welcome.

-- Section 3 --
Isn't the wording "host router" an oxymoron ?


== NITS ==

-- Section 8 --
I recommend reading and following the suggestions of RFC 8126 (how to write the IANA considerations)
2019-12-03
11 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2019-12-02
11 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-12-02
11 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2019-12-02
11 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from No Record
2019-12-02
11 Mirja Kühlewind
[Ballot comment]
Three comments/questions:

1) This sentence in section 3:
"An OSPFv2 router advertising a router-LSA with the H-bit
  set indicates that it MUST …
[Ballot comment]
Three comments/questions:

1) This sentence in section 3:
"An OSPFv2 router advertising a router-LSA with the H-bit
  set indicates that it MUST NOT be used as a transit router (see
  Section 4) by other OSPFv2 routers in the area supporting the
  functionality."
Isn't the MUST here too restrictive? What if the router is the part of the only path to a certain host?
Or is the assumption that this host is some kind of endhost/deadend, but then it should never be on the shortest path anyway, or?

Later on you say
"When the H-bit is set, the OSPFv2 router is a Host (non-transit)
  router and is incapable of forwarding transit traffic."
However, there might also be routers that don't understand the H bit and therefore will route traffic over this host anyway, no?

2) Shouldn't this document update RFC2328, given section 4 and this sentence in section 2:
"If the H-bit is set then the calculation of the shortest-
  path tree for an area, as described in section 16.1 of [RFC2328], is
  modified by including a check to verify that transit vertices DO NOT
  have the H-bit set (see Section 4)."
(And why is DO NOT in upper letters?)

3) Is there an attack that by spoofing the H-bit an attacker could influence the routing such that traffic is router over a malicious node instead? I guess there are multiple ways to impact the routing that way and this might not be specific to the H bit but maybe still worth thinking about it once more...?

Nit:
Section 5: "The RI LSA MUST be area-scoped.  Bit:" -> I guess the "Bit:" should be removed.
2019-12-02
11 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2019-11-30
11 Éric Vyncke
[Ballot discuss]
Thank you for the work put into this document. The short document is easy to read even if I wonder whether it is …
[Ballot discuss]
Thank you for the work put into this document. The short document is easy to read even if I wonder whether it is useful to spend time on IPv4-only protocol ;-)

The deployment issue (section 5) has raised a DISCUSS of mine and I would appreciate a reply on this DISCUSS.

Regards,

-éric

== DISCUSS ==

-- Section 5 --
The risk of having inconsistent view of the topology with H-bit aware and unaware routers seems possible to me (albeit perhaps only transient). Has this feature been tested / simulated in large scale networks?
2019-11-30
11 Éric Vyncke
[Ballot comment]
Feel free to ignore my COMMENTs and NIT.

== COMMENTS ==

-- Generic --
Mentioning that the H-bit of OSPFv2 is the reverse …
[Ballot comment]
Feel free to ignore my COMMENTs and NIT.

== COMMENTS ==

-- Generic --
Mentioning that the H-bit of OSPFv2 is the reverse of the R-bit of OSPFv3 would be useful.

-- Section 1 --
A description of "Closet Switches" would be welcome.

-- Section 3 --
Isn't the wording "host router" an oxymoron ?


== NITS ==

-- Section 8 --
I recommend reading and following the suggestions of RFC 8126 (how to write the IANA considerations)
2019-11-30
11 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2019-11-29
11 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-11-16
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-11-16
11 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-11.txt
2019-11-16
11 (System) New version approved
2019-11-16
11 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Padma Pillay-Esnault , Manish Bhardwaj , Keyur Patel
2019-11-16
11 Padma Pillay-Esnault Uploaded new revision
2019-11-07
10 Tim Chown Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tim Chown. Sent review to list.
2019-11-07
10 Amy Vezza Placed on agenda for telechat - 2019-12-05
2019-11-07
10 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2019-11-07
10 Alvaro Retana Ballot has been issued
2019-11-07
10 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2019-11-07
10 Alvaro Retana Created "Approve" ballot
2019-11-07
10 Alvaro Retana Ballot writeup was changed
2019-11-07
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-11-06
10 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2019-11-06
10 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ospf-ospfv2-hbit-10. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ospf-ospfv2-hbit-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the OSPFv2 Router Properties Registry on the Open Shortest Path First v2 (OSPFv2) Parameters registry page located at:

https://www.iana.org/assignments/ospfv2-parameters/

a single, new value is to be registered as follows:

Value: 0x80
Description: Host (H-bit)
Reference: [ RFC-to-be ]

Second, in the OSPF Router Informational Capability Bits registry on the Open Shortest Path First (OSPF) Parameters registry page located at:

https://www.iana.org/assignments/ospf-parameters/

a single, new registration will be made as follows:

Bit Number: 7
Capability Name: OSPF Host Router
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-10-31
10 Kyle Rose Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Kyle Rose. Sent review to list.
2019-10-31
10 Mohit Sethi Request for Last Call review by GENART Completed: Ready. Reviewer: Mohit Sethi. Sent review to list.
2019-10-28
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2019-10-28
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2019-10-27
10 Wesley Eddy Request for Last Call review by TSVART is assigned to Kyle Rose
2019-10-27
10 Wesley Eddy Request for Last Call review by TSVART is assigned to Kyle Rose
2019-10-25
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sean Turner
2019-10-25
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Sean Turner
2019-10-24
10 Jean Mahoney Request for Last Call review by GENART is assigned to Mohit Sethi
2019-10-24
10 Jean Mahoney Request for Last Call review by GENART is assigned to Mohit Sethi
2019-10-24
10 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-10-24
10 Amy Vezza
The following Last Call announcement was sent out (ends 2019-11-07):

From: The IESG
To: IETF-Announce
CC: Yingzhen Qu , draft-ietf-ospf-ospfv2-hbit@ietf.org, aretana.ietf@gmail.com, lsr-chairs@ietf.org, …
The following Last Call announcement was sent out (ends 2019-11-07):

From: The IESG
To: IETF-Announce
CC: Yingzhen Qu , draft-ietf-ospf-ospfv2-hbit@ietf.org, aretana.ietf@gmail.com, lsr-chairs@ietf.org, yingzhen.ietf@gmail.com, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Host Router Support for OSPFv2) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Host Router Support for OSPFv2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-11-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Open Shortest Path First Version 2 (OSPFv2) does not have a
  mechanism for a node to repel transit traffic if it is on the
  shortest path.  This document defines a bit (Host-bit) that enables a
  router to advertise that it is a non-transit router."  It also
  describes the changes needed to support the H-bit in the domain.  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-10-24
10 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-10-24
10 Alvaro Retana Last call was requested
2019-10-24
10 Alvaro Retana Ballot approval text was generated
2019-10-24
10 Alvaro Retana Ballot writeup was generated
2019-10-24
10 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-10-24
10 Alvaro Retana Last call announcement was generated
2019-10-24
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-10-24
10 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-10.txt
2019-10-24
10 (System) New version approved
2019-10-24
10 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Padma Pillay-Esnault , Manish Bhardwaj , Keyur Patel
2019-10-24
10 Padma Pillay-Esnault Uploaded new revision
2019-10-07
09 Min Ye Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: He Jia.
2019-09-20
09 Alvaro Retana === Review of -09 ===
https://mailarchive.ietf.org/arch/msg/lsr/zs4cfS9z7vXbK_sNHku4-66nEQg
2019-09-20
09 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2019-09-18
09 Min Ye Request for Last Call review by RTGDIR is assigned to He Jia
2019-09-18
09 Min Ye Request for Last Call review by RTGDIR is assigned to He Jia
2019-09-15
09 Acee Lindem Requested Last Call review by RTGDIR
2019-09-13
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-09-13
09 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-09.txt
2019-09-13
09 (System) New version approved
2019-09-13
09 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Padma Pillay-Esnault , Manish Bhardwaj , Keyur Patel
2019-09-13
09 Padma Pillay-Esnault Uploaded new revision
2019-08-14
08 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::Point Raised - writeup needed
2019-07-30
08 Alvaro Retana Waiting for the authors to reply to the AD Review.
2019-07-30
08 Alvaro Retana IESG state changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation::AD Followup
2019-07-08
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-07-08
08 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-08.txt
2019-07-08
08 (System) New version approved
2019-07-08
08 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , lsr-chairs@ietf.org, Manish Bhardwaj , Padma Pillay-Esnault , Keyur Patel
2019-07-08
08 Padma Pillay-Esnault Uploaded new revision
2019-05-19
07 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2019-05-19
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-05-19
07 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-07.txt
2019-05-19
07 (System) New version approved
2019-05-19
07 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Manish Bhardwaj , Padma Pillay-Esnault , Keyur Patel
2019-05-19
07 Padma Pillay-Esnault Uploaded new revision
2018-12-05
06 Yingzhen Qu
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document defines a new router-LSA bit known as the Host Bit or the H-bit.
    An OSPFv2 router advertising a router-LSA with the H-bit set indicates to other
    OSPFv2 routers in the area supporting the functionality that it MUST NOT be used
    as a transit router. 

Working Group Summary:
 
    The Working Group has reached consensus that this document is useful and should
    be published.
     
Document Quality:
     
      This is a straight forward draft, and similar function exists in ISIS and OSPFv3. Some nits to be fixed.
      There are review comments from AD to be addressed.

Personnel:

      Yingzhen Qu is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF/LSR mailing lists.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78
and BCP 79 have already been filed. If not, explain why?

    Yes, they all confirmed.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
 
    No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG that this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      RFC 6987 should be a Downward Normative References.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

When implementing this document, the SPF calculation defined
in RFC 2328 needs to be changed. This needs to be clearly stated
in the document.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).

This document requires an allocation of Host(H-bit) in OSPF
router-LSA bit registry.
It also requires to define a new Router Functional Capability
(RFC7770), the Host Support Functional Capability, from the Router
Functional Capability Bits TLV.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.
2018-11-30
06 Yingzhen Qu
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document defines a new router-LSA bit known as the Host Bit or the H-bit.
    An OSPFv2 router advertising a router-LSA with the H-bit set indicates to other
    OSPFv2 routers in the area supporting the functionality that it MUST NOT be used
    as a transit router. 

Working Group Summary:
 
    The Working Group has reached consensus that this document is useful and should
    be published.
     
Document Quality:
     
      The document has been implemented by xxxx.

Personnel:

      Yingzhen Qu is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF/LSR mailing lists.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78
and BCP 79 have already been filed. If not, explain why?

    Yes, they all confirmed.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
 
    No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG that this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

The publication of this document will update RFC 2328. This
information has been listed on the title page header,
the Abstract, and Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).

This document requires an allocation of Host(H-bit) in OSPF
router-LSA bit registry.
It also requires to define a new Router Functional Capability
(RFC7770), the Host Support Functional Capability, from the Router
Functional Capability Bits TLV.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.
2018-11-28
06 Alvaro Retana
=== AD Review of draft-ietf-ospf-ospfv2-hbit-06 ===
https://mailarchive.ietf.org/arch/msg/lsr/LkYCwSPRhxGQIPzPmjz2uka6pMk

Dear authors:

I just finished reading this document.  Even though it is relatively short,
I have significant concerns …
=== AD Review of draft-ietf-ospf-ospfv2-hbit-06 ===
https://mailarchive.ietf.org/arch/msg/lsr/LkYCwSPRhxGQIPzPmjz2uka6pMk

Dear authors:

I just finished reading this document.  Even though it is relatively short,
I have significant concerns and I think it needs more work.  Please take a
look at the detailed comments in-line below -- I'm highlighting some of the
issues here.

(1) What is the Update to rfc2328?  Please be specific in both the Abstract
and the Introduction to indicate how rfc2328 is Updated.  Also, see my
question about rfc6987 in §6.

(2) Operational/Deployment Considerations.  There are several places
(specially in §3) where the specification offers a choice (e.g. by using
MAY).  Some of those choices would be better informed if there was a
discussion of the considerations behind them.  Please take a look at
rfc5706 (specially §2).  Either a discussion close to where the behavior is
specified or a separate section is ok.  Please also keep migration in mind
(see comments in §5).

(3) Both the IANA and Security Considerations sections need more details.


I will wait for them to be addressed before starting the IETF Last Call.

Thanks!

Alvaro.


[The line numbers come from idnits.]

...
11                        H-bit Support for OSPFv2
12                    draft-ietf-ospf-ospfv2-hbit-06

[nit] Please make the title more descriptive.  "non-transit router", "host
mode", etc. come to mind.


14 Abstract

16  OSPFv3 defines an option bit for router-LSAs known as the R-bit in
17  RFC5340.  If the R-bit is clear, an OSPFv3 router can participate in
18  OSPF topology flooding, however it will not be used as a transit
19  router.  In such cases, other routers in the OSPFv3 routing domain
20  only install routes to allow local traffic delivery.  This document
21  defines the H-bit functionality to prevent other OSPFv2 routers from
22  using the router for transit traffic in OSPFv2 routing domains as
23  described in RFC 2328.  This document updates RFC 2328.

[minor] Describing the functionality in terms of OSPFv2 would have been
nice.  IOW, there's no need (in the Abstract) to force the reader to go
figure out what OSPFv3 already did to decide if it's worth reading this
document or not.

[major] What is the Update to rfc2328?  Please be specific, both here and
in the Introduction: don't just mention the section updated, but (more
important) what is the update about.  "This document updates rfc2328 by
assigning a bit...changing the SPF process...creating a registry..."
All/none/something else?

Note that the answer to "what is the update?" doesn't have to be all.  I
think that the registry creation is a must.  But Updating because of the
SPF changes means that you expect an rfc2328 implementation to consider the
H-bit when running SPF.  I think you really mean that implementations of
this document (i.e. not all rfc2328 implementations) have to use the
modified SPF.  That is my guess...please consider the answer carefully.


...
42 Copyright Notice

44  Copyright (c) 2018 IETF Trust and the persons identified as the
45  document authors.  All rights reserved.

47  This document is subject to BCP 78 and the IETF Trust's Legal
48  Provisions Relating to IETF Documents
49  (https://trustee.ietf.org/license-info) in effect on the date of
50  publication of this document.  Please review these documents
51  carefully, as they describe your rights and restrictions with respect
52  to this document.  Code Components extracted from this document must
53  include Simplified BSD License text as described in Section 4.e of
54  the Trust Legal Provisions and are provided without warranty as
55  described in the Simplified BSD License.

57  This document may contain material from IETF Documents or IETF
58  Contributions published or made publicly available before November
59  10, 2008.  The person(s) controlling the copyright in some of this
60  material may not have granted the IETF Trust the right to allow
61  modifications of such material outside the IETF Standards Process.
62  Without obtaining an adequate license from the person(s) controlling
63  the copyright in such materials, this document may not be modified
64  outside the IETF Standards Process, and derivative works of it may
65  not be created outside the IETF Standards Process, except to format
66  it for publication as an RFC or to translate it into languages other
67  than English.

[major] As far as I can tell, the first version of
draft-keyupate-ospf-ospfv2-hbit (the predecessor of this document) was
published in 2015.  So the copyright text above doesn't apply.  Are we
missing other predecessors?

If not, then this issue should be easy to fix.  In at least the XML editor
that I use, there's an option to indicate pre-RFC5378 work, or not.  In
this case it seems like it should be No.


...
85 1.  Introduction

[minor] Same comment as for the Abstract: describing the functionality in
terms of OSPFv2 would have been nicer.  You can still make the reference to
the R-bit at the end, if you really want to.

87  OSPFv3 [RFC5340] defines an option bit for router-LSAs known as the
88  R-bit.  If the R-bit is clear, an OSPFv3 router can participate in
89  OSPFv3 topology flooding without acting as a transit router.  In such
90  cases, other routers in the OSPFv3 routing domain only install routes
91  used for local traffic.

93  This functionality is particularly useful for BGP Route Reflectors,
94  known as virtual Route Reflectors (vRRs), that are not in the
95  forwarding path but are in central locations such as data centers.
96  Such Route Reflectors typically are used for route distribution and
97  are not capable of forwarding transit traffic.  However, they need to
98  learn the OSPF topology for:

100  1.  SPF computation for Optimal Route Reflection functionality as
101      defined in [I-D.ietf-idr-bgp-optimal-route-reflection]

103  2.  Reachability resolution for its Route Reflector Clients.

[nit] Clearly route reflection is not the only motivation for this work.
The justification only related to RRs seems gratuitous.  Just a nit...

105  This document defines the R-bit functionality equivalent for OSPFv2
106  defined in [RFC2328] by introducing a new router-LSA bit known as the
107  "H-bit".  This document updates appendix A.4.2 of RFC 2328.

[nit] s/OSPFv2 defined in [RFC2328]/OSPFv2 [RFC2328]  It sounds as if "the
R-bit functionality equivalent for OSPFv2" is already in rfc2328.

[major] Please be specific about what the Update is.


...
117 3.  H-bit Support

119  This document defines a new router-LSA bit known as the Host Bit or
120  the H-bit.  An OSPFv2 router advertising a router-LSA with the H-bit
121  set indicates to other OSPFv2 routers in the area supporting the
122  functionality that it MUST NOT be used as a transit router.  The bit
123  value usage of the H-bit is reversed from the R-bit defined in OSPFv3
124  [RFC5340] to support backward compatibility.  The modified OSPFv2
125  router-LSA format is:

[minor] "...MUST NOT be used as a transit router"  Put a forward reference
to §4.

[nit] The text keeps making reference to the R-bit.  Even though there is a
relationship, the H-bit is an independent feature.  IOW, I don't think
there's a need to explain the relationship to OSPFv3.

[minor] On the same topic:  The comparison to OSPFv3 is made and the
"reverse" bit setting is justified "to support backward compatibility", but
that is not explained anywhere.  I was hoping that §5 (Auto Discovery and
Backward Compatibility) would say something, but it doesn't.

127        0                  1                  2                  3
128        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
129      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
130      |            LS age            |    Options  |      1      |
131      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
132      |                        Link State ID                          |
133      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
134      |                    Advertising Router                        |
135      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
136      |                    LS sequence number                        |
137      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
138      |        LS checksum          |            length            |
139      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
140      |H|0|0|N|W|V|E|B|        0      |            # links            |
141      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
142      |                          Link ID                              |
143      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
144      |                        Link Data                            |
145      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
146      |    Type      |    # TOS    |            metric            |
147      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
148      |                              ...                              |
149      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
150      |      TOS      |        0      |          TOS  metric          |
151      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
152      |                          Link ID                              |
153      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
154      |                        Link Data                            |
155      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
156      |                              ...                              |

158      bit H
159          When set, an OSPFv2 router is a non-transit router and is
160          incapable of forwarding transit traffic.

[nit] Please label the figure: Figure 1...

[minor] Even though it seems obvious from the figure, please be explicit in
saying that the H-bit is the first bit (or however that bit is
identified)...

162  When the H-bit is set, an OSPFv2 router is a non-transit router and
163  should not be used to forward transit traffic.  In this mode, the
164  other OSPFv2 routers in the area SHOULD NOT use the originating
165  OSPFv2 router for transit traffic, but MAY use the OSPFv2 router for
166  local traffic destined to that OSPFv2 router.

[minor] The first/second sentences seem redundant: "should not be used to
forward transit traffic...SHOULD NOT use the originating OSPFv2 router for
transit traffic".

[major] When would the non-transit router be used for transit?  IOW, why
use "SHOULD NOT" and not "MUST NOT"?

[major] "MAY use the OSPFv2 router for local traffic destined to that
OSPFv2 router"  I'm not sure what behavior is being specified here.  The
text sounds as if it was optional to even consider the router as a traffic
destination.  Is that the intent?  Why?  What would make a network operator
decide one way or the other?

168  An OSPFv2 router originating a router-LSA with the H-bit set SHOULD
169  advertise all its non-local router links with a link cost of
170  MaxLinkMetric as defined in Section 3 of [RFC6987].  This is to
171  increase the applicability of the H-bit to partial deployments where
172  it is the responsibility of the operator to ensure that OSPFv2
173  routers not supporting the H-bit do not install routes causing
174  routing loops.

[major] When would a router not advertise MaxLinkMetric?  IOW, why use
SHOULD and not MUST?

[major] What are "non-local router links"?  I always thought of links to be
local to the router...what am I missing?

[nit] s/advertise all its non-local router links with a link cost of
MaxLinkMetric as defined in Section 3 of [RFC6987]/advertise all its
non-local router links with a link cost of MaxLinkMetric [RFC6987]

176  When the H-bit is set, IPv4 prefixes associated with local interfaces
177  in other areas MAY be advertised in summary LSAs.  Non-local IPv4
178  prefixes, e.g., those advertised by other routers and installed
179  during the SPF computation, MAY be advertised in summary-LSAs if
180  configured by policy.  Likewise, when the H-bit is set, only IPv4
181  prefixes associated with local interfaces MAY be advertised in AS-
182  external LSAs.  Non-local IPv4 prefixes, e.g., those exported from
183  other routing protocols, MUST NOT be advertised in AS-external-LSAs.
184  Finally, when the H-bit is set, an Area Border Router (ABR) MUST
185  advertise a consistent H-bit setting in its self-originated router-
186  LSAs for all attached areas.

[minor] Some of the behavior specified in this paragraph may be non
intuitive -- for example: "When the H-bit is set, IPv4 prefixes associated
with local interfaces in other areas MAY be advertised in summary LSAs."
During normal operation (aka rfc2328), these prefixes are always
advertised (assuming normal areas, etc.)...and given that these are local
to the router, it can be argued that one is not using the router as
transit...on the other hand, going to a different area can be interpreted
as transit.  In either case, it would be nice if more was said about the
optional nature of including these prefixes in the summary LSA.  What are
the operational considerations?

[minor] The same comment for "prefixes associated with local interfaces MAY
be advertised in AS-external LSAs".

[major] "Non-local IPv4 prefixes...MAY be advertised in summary-LSAs if
configured by policy."  Doesn't advertising result in the router being
transit?  Doesn't it defeats the purpose of setting the H-bit?  But there
may be operational reasons to do so -- e.g. if the router is the only ABR...

[major] "Non-local IPv4 prefixes...MUST NOT be advertised in
AS-external-LSAs."  This behavior seems consistent with the purpose of the
H-bit, but not with the rest of the paragraph.  Again, why is this
different (operationally) than transiting for non-external inter-area
prefixes.

[major] "...an Area Border Router (ABR) MUST advertise a consistent H-bit
setting in its self-originated router-LSAs for all attached areas."  What
do you mean by "consistent"?  Do you mean "the same", i.e. be non-transit
for all areas?  Do you mean "compatible", i.e. so that the setting avoids
potential loops or black holes?  Please be specific.  And please explain
why -- again, what are the operational considerations?


...
214 5.  Auto Discovery and Backward Compatibility

216  To avoid the possibility of any routing loops due to partial
217  deployment, this document defines a OSPF Router-Information LSA
218  functional capability bit known as the Host Support capability.

[minor] A reference to rfc7770 would be nice.

[mayor] I'm guessing that the RI LSA MUST be area-scoped, right?  Please be
specific.

220  Auto Discovery via announcement of the Host Support Functional
221  Capability ensures that the H-bit functionality and its associated
222  SPF changes SHOULD only take effect if all the routers in a given
223  OSPF area support this functionality.

[major] When can the functionality take effect even if not all routers in
the area support it?  Or maybe it is that it won't take effect even if all
routers support it...  IOW, why SHOULD and not MUST?

[major] There's no guarantee that the RI LSA will reach a router before the
route-carrying LSAs -- which I think implies that SPF could be run before
verifying full H-bit support.  The result may be a loop...or a loop may
exist until the lack of area-wide support is verified... IOW, it seems to
me that this auto discovery mechanism may not work as expected.  Migration
is an important Deployment Consideration.

[major] What is the process to verify area-wide support?  Should the router
build a tree...run SPF...inspect the LSAs...??  I'm assuming/hoping that
this is a common enough operation that it is specified already somewhere
else...

225  Implementations are encouraged to provide a configuration parameter
226  to manually override enforcement of the H-bit functionality in
227  partial deployments where the topology guarantees that OSPFv2 routers
228  not supporting the H-bit do not compute routes resulting in routing
229  loops.  More precisely, the advertisement of MaxLinkMetric for the
230  router's non-local links will prevent OSPFv2 routers not supporting
231  the H-bit from attempting to use it for transit traffic.

[minor] The text seems to indicate what the second sentence is a
clarification of the first one: "Implementations are encouraged to... More
precisely..."  But in reality you are talking about two different things:
the ability to consider the H-bit even in partial deployments, *and*,
advertising MaxLinkMetric.  Please consider rewording to clarify.

233 6.  OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics

235  When calculating the path to an OSPF AS-External-LSA or NSSA-LSA with
236  a Type-2 metric, the advertised Type-2 metric is taken as more
237  significant than the OSPF intra-area or inter-area path.  Hence,
238  advertising the links with MaxLinkMetric as specified in [RFC6987]
239  does not discourage transit traffic when calculating AS external or
240  NSSA routes.  Consequently, OSPF routers implementing [RFC6987] or
241  this specification should advertise a Type-2 metric of LSInfinity for
242  any self-originated AS-External-LSAs or NSSA-LSAs in situations when
243  the OSPF router is acting as a stub router [RFC6987] or implementing
244  this specification.

[major] Should there be Normative language in this paragraph?

[major] This paragraph talks about what a stub router (rfc6987) should do.
In order to do that, this document should be tagged to Update rfc6987.  Is
that the intent?

246 7.  IANA Considerations

248  IANA is requested to create the OSPF Router-LSA bit registry with the
249  following assignments:

251        Value  Description                                Reference
252        0x01    Area Border Router (B-bit)                  [RFC2328]
253        0x02    AS Boundary Router (E-bit)                  [RFC2328]
254        0x04    Virtual Link Endpoint (V-bit)              [RFC2328]
255        0x08    Historic (W-bit)                            [RFC1584]

[major] Even though rfc1584 is classified as Historic, that doesn't mean
that the bit is as well, or that it has been deprecated (at least I didn't
see that in rfc5110).  Please put a name to it -- "wild-card multicast"?

256        0x10    Unconditional NSSA Translator (Nt-bit)      [RFC3101]
257        0x20    Unassigned
258        0x40    Unassigned
259        0x80    Host (H-bit)                            This Document

[major] What should be the assignment policy (rfc8126)?

[minor] Besides the 8 bits above, the Router-LSA (rfc2328) has another 8
bits (to the right) that seem unassigned...should they be included in this
registry as well?

[major nit] I couldn't find where rfc2328 talks about the value of these
bits being 0 and what to do if they are not.  By creating this new
registry, you have the opportunity to (at least) clarify that.

261  This document also defines a new Router Functional Capability
262  [RFC7770] known as the Host Support Functional Capability.  This
263  document requests IANA to allocate the value of this capability from
264  the Router Functional Capability Bits TLV.

[minor] s/TLV/Registry

266 8.  Security Considerations

268  This document introduces no new security considerations beyond those
269  already specified in [RFC6987], [RFC2328], and [RFC5340].

[major]  [*]

This section says nothing!  rfc6987 has no Security Considerations to speak
of (sorry!)...rfc2328's Security Considerations only talk about
authentication, and there's no mention of rfc5709 or rfc7474...and rfc5340
doesn't apply because this document is not about OSPFv3 -- also, rfc5340
doesn't have specific Security Considerations related to the R-bit.



[*] I don't really have a SecDir hat...just pretending I do.

Suggestion: tell the reader why there are no new security considerations.
"This document introduces functionality to do a, b, and c...  Non of that
affects security..."  Of course, more words would be nice.

There is one specific item that I think should be mentioned as a risk.  §5
talks about using Auto Discovery "to avoid the possibility of any routing
loops due to partial deployment".  Even with proper authentication, there
is the possibility that a (rogue) router can advertise the Host Support
capability without really supporting it (there's no way to verify!!).  The
result can be a loop...  I don't think this issue can be mitigated, but
mentioning it would go a long way in demonstrating that you at least
thought about the issues.


...
279 10.1.  Normative References
...
290  [RFC3101]  Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
291              RFC 3101, DOI 10.17487/RFC3101, January 2003,
292              ;.

294  [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
295              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
296              ;.

[minor] These 2 references can be Informative.


...
307 10.2.  Informative References
...
319  [RFC6987]  Retana, A., Nguyen, L., Zinin, A., White, R., and D.
320              McPherson, "OSPF Stub Router Advertisement", RFC 6987,
321              DOI 10.17487/RFC6987, September 2013,
322              ;.

[major] Because of the specification of the use of MaxLinkMetric, this
reference has to be Normative.  rfc6987 is already in the DownRef registry.
2018-11-28
06 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2018-11-28
06 Alvaro Retana Notification list changed to Yingzhen Qu <yingzhen.ietf@gmail.com>, aretana.ietf@gmail.com from Yingzhen Qu <yingzhen.ietf@gmail.com>
2018-11-21
06 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2018-10-03
06 Acee Lindem
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:
   
    This document defines a new router-LSA bit known as the Host Bit or the H-bit.
    An OSPFv2 router advertising a router-LSA with the H-bit set indicates to other
    OSPFv2 routers in the area supporting the functionality that it MUST NOT be used
    as a transit router. 

Working Group Summary:
 
    The Working Group has reached consensus that this document is useful and should
    be published.
     
Document Quality:
     
      The document has been implemented by xxxx.

Personnel:

      Yingzhen Qu is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF/LSR mailing lists.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78
and BCP 79 have already been filed. If not, explain why?

    NA.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.
 
    No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG that this document can progress.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

The publication of this document will update RFC 2328. This
information has been listed on the title page header,
the Abstract, and Introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).

This document requires an allocation of Host(H-bit) in OSPF
router-LSA bit registry.
It also requires to define a new Router Functional Capability
(RFC7770), the Host Support Functional Capability, from the Router
Functional Capability Bits TLV.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      None.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.
2018-10-03
06 Acee Lindem Responsible AD changed to Alvaro Retana
2018-10-03
06 Acee Lindem IETF WG state changed to Submitted to IESG for Publication from WG Document
2018-10-03
06 Acee Lindem IESG state changed to Publication Requested
2018-10-03
06 Acee Lindem IESG process started in state Publication Requested
2018-10-03
06 Acee Lindem Changed consensus to Yes from Unknown
2018-10-03
06 Acee Lindem Intended Status changed to Proposed Standard from None
2018-09-04
06 Yingzhen Qu Changed document writeup
2018-08-27
06 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-06.txt
2018-08-27
06 (System) New version approved
2018-08-27
06 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Manish Bhardwaj , Padma Pillay-Esnault , Keyur Patel
2018-08-27
06 Padma Pillay-Esnault Uploaded new revision
2018-08-08
05 Yingzhen Qu Notification list changed to Yingzhen Qu <yingzhen.ietf@gmail.com>
2018-08-08
05 Yingzhen Qu Document shepherd changed to Yingzhen Qu
2018-08-01
05 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-05.txt
2018-08-01
05 (System) New version approved
2018-08-01
05 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Manish Bhardwaj , Padma Pillay-Esnault , Keyur Patel
2018-08-01
05 Padma Pillay-Esnault Uploaded new revision
2018-08-01
04 (System) Document has expired
2018-02-28
04 Cindy Morgan Notification list changed to none
2018-02-28
04 Cindy Morgan Changed group to Link State Routing (LSR) from Open Shortest Path First IGP (OSPF)
2018-01-28
04 Keyur Patel New version available: draft-ietf-ospf-ospfv2-hbit-04.txt
2018-01-28
04 (System) New version approved
2018-01-28
04 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Manish Bhardwaj , Padma Pillay-Esnault , Keyur Patel
2018-01-28
04 Keyur Patel Uploaded new revision
2017-12-16
03 (System) Document has expired
2017-06-14
03 Keyur Patel New version available: draft-ietf-ospf-ospfv2-hbit-03.txt
2017-06-14
03 (System) New version approved
2017-06-14
03 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Manish Bhardwaj , Padma Pillay-Esnault , Keyur Patel
2017-06-14
03 Keyur Patel Uploaded new revision
2017-04-10
02 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-02.txt
2017-04-10
02 (System) New version approved
2017-04-10
02 (System) Request for posting confirmation emailed to previous authors: Serpil Bayraktar , Manish Bhardwaj , Padma Pillay-Esnault , Keyur Patel , ospf-chairs@ietf.org
2017-04-10
02 Padma Pillay-Esnault Uploaded new revision
2017-01-06
01 (System) Document has expired
2016-07-05
01 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-01.txt
2015-11-09
00 Acee Lindem This document now replaces draft-keyupate-ospf-ospfv2-hbit instead of None
2015-10-18
00 Padma Pillay-Esnault New version available: draft-ietf-ospf-ospfv2-hbit-00.txt