OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type
draft-ietf-ospf-hybrid-bcast-and-p2mp-06

[Ballot discuss]
Thank you for discussing my Discuss and commenting on my Comment.

As ar as I can see, one point remains from my Discuss that was not addressed in email or in the revised I-D...

Section 5 is a little timid about the consequences of misconfiguration.
It is true that misconfiguration "will not cause any persistent loops or
black holing of traffic", but it might cause the network to be
partitioned.

You should indicate how misconfiguration is detected and notified to the
operator by a conformant node (presumably when it receives a network LSA
from the DR, or when it does not receive a link Type 1 advertisement
with a link cost).

[Ballot discuss]
Updated after the IPR was notified to the working group

---

Is this document addressing the June 2008 charter milestone:
  Develop multiple OSPFv3 protocol alternatives to reduce flooding
  overhead and adjacencies in a MANET environment and submit to the
  IESG as experimental RFCs

If so, why is it not Experimental? Maybe the charter is out of date, or
maybe this should be published as Experimental. The Shepher write-up
doesn't clarify why this document is targeted as Standards Track.

---

In the Introduction you say:

  This document proposes a new interface type that can be used on layer
  2 networks that have broadcast capability.

Why do you specifically limit to underlying networks at layer 2? Surely
this mechanism works when OSPF is run over any broadcast link.

---

Section 4.1

  The default value of the LinkLSASuppression is "disabled".  It MAY be
  set to "enabled" via configuration.

I think this is an inappropriate use of MAY. Given that you are already
within a caveat saygin this text applies to implementations that support 
this document, I think you need s/MAY/can/ .

---

Section 5 is a little timid about the consequences of misconfiguration.
It is true that misconfiguration "will not cause any persistent loops or
black holing of traffic", but it might cause the network to be
partitioned.

You should indicate how misconfiguration is detected and notified to the
operator by a conformant node (presumably when it receives a network LSA
from the DR, or when it does not receive a link Type 1 advertisement
with a link cost).

[Ballot comment]
I don't think this should "Update" any other documents, but the IESG has to sort this point out in general, and we shouldn't hold this document up for that.

Total nits, just because I came across them while reviewing; no need to respond to these.

-- Section 1 --
OLD
  to each of the neighboring routers on the network in it's router LSA.
NEW (nit; remove apostrophe)
  to each of the neighboring routers on the network in its router LSA.

OLD
  configuration of the identity of it's neighboring routers.  It also
NEW (nit; remove apostrophe)
  configuration of the identity of its neighboring routers.  It also
Or better...
  configuration of the identity of neighboring routers.  It also

OLD
  network.  Further, it mandates establishment of adjacencies to all
  all configured or discovered neighbors on the network.  However, it
NEW (nit; duplicate "all")
  network.  Further, it mandates establishment of adjacencies to all
  configured or discovered neighbors on the network.  However, it

-- Section 3 --
OLD
  2 topology as well as various link quality metrics such as bandwidth,
  delay and jitter among others.
NEW (nit; add comma)
  2 topology as well as various link quality metrics such as bandwidth,
  delay and jitter, among others.

-- Section 4.2 --
OLD
  Routers MUST support an additional field called the Neighbor Output
  Cost.  This is the cost of sending a data packet to the neighbor,
  expressed in the link state metric.  The default value of this field
  is the Interface output cost.  It MAY be set to a different value
SHOULD THIS BE (adding capitals)?:
  [...] The default value of this field is the Interface Output Cost.

[Ballot comment]
(Modified after e-mail exchange with Acee Lindem)
Expand "DR" and "BDR" on first reference.

I cleared my Discuss, deferring to and supporting Barry's
Discuss regarding text that explicitly explains how this
document updates the OSPF specification.

[Ballot comment]
Nit: Perhaps this is a term of art, but I found this text in 4.8 confusing:

  o  If a router is the DR on the interface, [...]

Should it read "router is the DR on the subnet" (or "link"), or
perhaps "router is in state DR on the interface"?

I cleared my Discuss, deferring to and supporting Barry's
Discuss regarding text that explicitly explains how this
document updates the OSPF specification.

[Ballot discuss]
[Updated after the 16 Aug telechat.]
Small, easy point:

I understand that the intent is that all new implementations of OSPF are expected to comply with this... is that correct?  If so, then this document should state the requirement more clearly.  For example (these aren't necessarily the right wording, but they'll help get the point across):

Abstract:
OLD
  This document describes a mechanism to model a broadcast network as a
  hybrid of broadcast and point-to-multipoint networks for purposes of
  OSPF operation.
NEW
  This document updates OSPF with a mechanism that models a broadcast
  network as a hybrid of broadcast and point-to-multipoint networks for purposes
  of OSPF operation.  New implementations of OSPF are expected to support
  this mechanism.

Introduction:
OLD
  This document proposes a new interface type that can be used on layer
  2 networks that have broadcast capability.
NEW
  This document introduces a new interface type into OSPF.  The new
  interface type should be supported in all new OSPF implementations,
  and it can be used on layer 2 networks that have broadcast capability.

[Ballot comment]
Updated to incorporate Sandy's secdir review:

1) a/s1: Please expand LSA in the absract/intro when they are first used.

2) s4.4: Expand DR and BDR

3) s5: should the must and should be MUST and SHOULD?

4) from secdir:  Please indicate why it was necessary to introduce type 3 stub network links for the router's subnet.  Perhaps the authors expect that readers will be so intimately familiar with OSPF design that the motivation for each change will be obvious.

5) s5: Section 5 considers cases where some routers on a broadcast network follow the hybrid behavior and other follow the broadcast/NBMA behavior.  OSPF works on the assumption that all routers share the same dataset and therefore each will compute shortest paths that will not introduce loops.  In this case, not all routers will be working from the same dataset of links, raising concern about loops.  Section 5 (briefly) says that in this case there would be "no traffic traversing certain pairs of routers" but no loops.  I can understand that enough to believe it.    But I am not as confident that a router that produces both the network LSA and a router LSA with the p2mp links could not confuse the situation sufficiently to produce loops.  I wonder if the authors have considered that case.  I'm sorry that I was not able to devote the time to the shortest path computation to resolve this lack of confidence for myself.

6) section 4.5 says "the DR MUST NOT generate a network LSA for the interface."  OSPF's specs in general do not recommend reporting errors, or I would suggest a new error report if a network LSA were spotted on an interface that was designated as hybrid.

[Ballot discuss]
1) For OSPFv3, the security considerations point to 5340.  With the recent publication of RFC 6506, should this document be pointing there as well?

[Ballot comment]
1) a/s1: Please expand LSA in the absract/intro when they are first used.

2) s4.4: Expand DR and BDR

3) s5: should the must and should be MUST and SHOULD?

[Ballot comment]
Nit: Perhaps this is a term of art, but I found this text in 4.8 confusing:

  o  If a router is the DR on the interface, [...]

Should it read "router is the DR on the subnet" (or "link"), or
perhaps "router is in state DR on the interface"?

[Ballot comment]
The use of 2119 language in sections 4.1 and 4.2 is bogus. These are all conformance and configuration statements that have nothing to do (at least as stated) with requirements (or options) for interoperability or prevention of damage. For example, in 4.1:

  Routers MUST support configuration of the Router Priority for the
  interface.

  The default value of the LinkLSASuppression is "disabled".  It MAY be
  set to "enabled" via configuration.

Change to:

  Routers implementing this specification will have a configuration option
  for the Router Priority for the interface.

  The default value of the LinkLSASuppression is "disabled".  It may be
  set to "enabled" via configuration.

Similarly for 4.2.

In 4.8, you also have odd constructions with the 2119 language:

  o  If a router is the DR on the interface, it MUST NOT examine the
      pre-restart network LSA for the interface in order to determine
      the previous set of adjacencies.

The requirement is not on the examination, it is on the use. I suggest simply:

  o  If a router is the DR on the interface, the pre-restart network
      LSA for the interface MUST NOT be used to determine
      the previous set of adjacencies.

For the other bullet:

  o  If a router is in state DROther on the interface, it MUST consider
      an adjacency to non-DR and non-BDR neighbors as reestablished when
      the neighbor state reaches 2-Way.

"Considering" is not the requirement. In fact, I suspect this is not a requirement at all, but rather a definition. I think this works better:

  o  If a router is in state DROther on the interface, an adjacency
      to non-DR and non-BDR neighbors is reestablished when
      the neighbor state reaches 2-Way.

[Ballot comment]

- Its a bit of a concern that the IPR declaration isn't
visible on the tools page [1] for this, but is on the tools
page for draft-nsheth [2] that preceeded this.  Can somoene
do whatever's needed to ensure the IPR declaration will be
linked from the tools page for the eventual RFC?

  [1] http://tools.ietf.org/html/draft-ietf-ospf-hybrid-bcast-and-p2mp
  [2] http://tools.ietf.org/html/draft-nsheth-ospf-hybrid-bcast-and-p2mp

- section 3: having read this, the motiviation still isn't
very clear to this reader, perhaps a concrete example of
different costs of communication that this spec addresses
would help.

- 4.1 & 4.2: what does " It MAY be set to "enabled" via
configuration" in 4.1 mean? It seems like a tautology so I
don't know what you're trying to say.  Similarly, in 4.2, "
It MAY be set to a different value using mechanisms which
are outside the scope of this document" is odd.

- expanding DR/BDR in 4.4 would be good.

[Ballot discuss]
Is this document addressing the June 2008 charter milestone:
  Develop multiple OSPFv3 protocol alternatives to reduce flooding
  overhead and adjacencies in a MANET environment and submit to the
  IESG as experimental RFCs

If so, why is it not Experimental? Maybe the charter is out of date, or
maybe this should be published as Experimental. The Shepher write-up
doesn't clarify why this document is targeted as Standards Track.

---

The Shepherd write-up template ask the Shepherd to summarize the WG
discussion of the IPR disclosure. There is no such summary.

It might be enough to state that the disclosure was brought to the
attention of the WG on  and that there were no comments.

Can the Shepherd please clarify?

---

In the Introduction you say:

  This document proposes a new interface type that can be used on layer
  2 networks that have broadcast capability.

Why do you specifically limit to underlying networks at layer 2? Surely
this mechanism works when OSPF is run over any broadcast link.

---

Section 4.1

  The default value of the LinkLSASuppression is "disabled".  It MAY be
  set to "enabled" via configuration.

I think this is an inappropriate use of MAY. Given that you are already
within a caveat saygin this text applies to implementations that support 
this document, I think you need s/MAY/can/ .

---

Section 5 is a little timid about the consequences of misconfiguration.
It is true that misconfiguration "will not cause any persistent loops or
black holing of traffic", but it might cause the network to be
partitioned.

You should indicate how misconfiguration is detected and notified to the
operator by a conformant node (presumably when it receives a network LSA
from the DR, or when it does not receive a link Type 1 advertisement
with a link cost).

[Ballot comment]
The Shepherd write-up has me confused. It calls out extensions to
OSPFv2, but does not mention OSPFv3.

---

I agree with Barry's issue/Discuss/question about updating RFC 2328 and
RFC 5340. I note that RFC 3623 is updated as much as RFC 2328.

---

I should be interested to know the Traffic Engineering implications of
this document.

[Ballot discuss]
Small, easy point:

This "updates" OSPF v2 and v3 -- that means that all new implementations of OSPF are expected to comply with this... right?  If not (if this is an optional extension), then the "updates" is probably not correct.  If it *is* correct, then this document should state the requirement more clearly.  For example (these aren't necessarily the right wording, but they'll help get the point across):

Abstract:
OLD
  This document describes a mechanism to model a broadcast network as a
  hybrid of broadcast and point-to-multipoint networks for purposes of
  OSPF operation.
NEW
  This document updates OSPF with a mechanism that models a broadcast
  network as a hybrid of broadcast and point-to-multipoint networks for purposes
  of OSPF operation.

Introduction:
OLD
  This document proposes a new interface type that can be used on layer
  2 networks that have broadcast capability.
NEW
  This document introduces a new interface type into OSPF.  The new
  interface type should be supported in all new OSPF implementations,
  and it can be used on layer 2 networks that have broadcast capability.

[Ballot comment]
Total nits, just because I came across them while reviewing; no need to respond to these.

-- Section 1 --
OLD
  to each of the neighboring routers on the network in it's router LSA.
NEW (nit; remove apostrophe)
  to each of the neighboring routers on the network in its router LSA.

OLD
  configuration of the identity of it's neighboring routers.  It also
NEW (nit; remove apostrophe)
  configuration of the identity of its neighboring routers.  It also
Or better...
  configuration of the identity of neighboring routers.  It also

OLD
  network.  Further, it mandates establishment of adjacencies to all
  all configured or discovered neighbors on the network.  However, it
NEW (nit; duplicate "all")
  network.  Further, it mandates establishment of adjacencies to all
  configured or discovered neighbors on the network.  However, it

-- Section 3 --
OLD
  2 topology as well as various link quality metrics such as bandwidth,
  delay and jitter among others.
NEW (nit; add comma)
  2 topology as well as various link quality metrics such as bandwidth,
  delay and jitter, among others.

-- Section 4.2 --
OLD
  Routers MUST support an additional field called the Neighbor Output
  Cost.  This is the cost of sending a data packet to the neighbor,
  expressed in the link state metric.  The default value of this field
  is the Interface output cost.  It MAY be set to a different value
SHOULD THIS BE (adding capitals)?:
  [...] The default value of this field is the Interface Output Cost.

[Ballot discuss]
I have no problems with the publication of this document, but I do want to have a discussion about some aspects of it.

1. It is unclear to me when a router supporting this new interface type would ever generate a Network LSA.  But, section 4.5 says that routers SHOULD NOT generate one, rather than MUST NOT generate one.  In what situation(s), would a router want to generate a Network LSA for an interface configured to operate in this new fashion?

2. Section 7 identifies MIB variables that need to be modified to support this new interface type.  Is there any intention of doing the MIB update to incorporate these changes?  I do not readily see a WG draft that proposes these updates.

IANA has reviewed draft-ietf-ospf-hybrid-bcast-and-p2mp-03, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: CORRECTED Last Call:  (OSPF Hybrid Broadcast and P2MP Interface Type) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'OSPF Hybrid Broadcast and P2MP Interface Type'
  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
ietf@ietf.org mailing lists by 2012-07-19. 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


  This document describes a mechanism to model a broadcast network as a
  hybrid of broadcast and point-to-multipoint networks for purposes of
  OSPF operation.  Neighbor discovery and maintenance as well as LSA
  database synchronization are performed using the broadcast model, but
  the network is represented using the point-to-multipoint model in the
  router LSAs of the routers connected to it.  This allows an accurate
  representation of the cost of communication between different routers
  on the network, while maintaining the network efficiency of broadcast
  operation.  This approach is relatively simple and requires minimal
  changes to OSPF.

  This document updates both OSPFv2 [RFC2328] and OSPFv3 [RFC5340].


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ospf-hybrid-bcast-and-p2mp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ospf-hybrid-bcast-and-p2mp/ballot/

The following IPR declaration is applicable to this draft
https://datatracker.ietf.org/ipr/1529/

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (OSPF Hybrid Broadcast and P2MP Interface Type) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'OSPF Hybrid Broadcast and P2MP Interface Type'
  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
ietf@ietf.org mailing lists by 2012-07-19. 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


  This document describes a mechanism to model a broadcast network as a
  hybrid of broadcast and point-to-multipoint networks for purposes of
  OSPF operation.  Neighbor discovery and maintenance as well as LSA
  database synchronization are performed using the broadcast model, but
  the network is represented using the point-to-multipoint model in the
  router LSAs of the routers connected to it.  This allows an accurate
  representation of the cost of communication between different routers
  on the network, while maintaining the network efficiency of broadcast
  operation.  This approach is relatively simple and requires minimal
  changes to OSPF.

  This document updates both OSPFv2 [RFC2328] and OSPFv3 [RFC5340].




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ospf-hybrid-bcast-and-p2mp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ospf-hybrid-bcast-and-p2mp/ballot/


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

Suggested text for the MIB section

o  For ospfIfType/ospfv3IfType, a new value broadcast-p2mp-hybrid(x) for the hybrid interface type (x to be defined when the revised  MIB documents are approved).

(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?

    Proposed Standard

(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 draft extends OSPFv2 with an additional interface type that
    has the property of supporting the adjacency reduction and flooding
    optimizations of broadcast networks while still allowing separate
    costs to be specified for each neighbor.

    Working Group Summary

    The only discussion worth noting was was how this document was
    positioned against the previously published MANET documents. We
    agreed that the MANET mechanisms could be used to accomplish the
    same goal but that the simplicity of this draft warrents
    standardization by the working group.

    Document Quality

    The document has gone through several WG review cycles and
    revisions. There is at least one implementation of the initial
    revision.

    Personnel

    Acee Lindem is the document shepherd and Stewart Bryant is the
    responsible AD.

(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 was presented at two IETFs and went through several WG
    reviews.

(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 interested community 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. 

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

  Yes - Defensive patent. https://datatracker.ietf.org/ipr/1529/

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

  These is consensus behind the draft with the only questions
  coming authors of OSPF MANET experimental RFCs that may be
  used to accomplish the same end of getting the unequal costs
  and exploit multicast flooding. We resolved these questions
  by agreeing to also accept draft describing how these OSPF
  MANET extensions could be used.

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

  All idnits errors and warnings have been 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 interested community considers it unnecessary.

    Yes. Updates RFC 2328 and RFC 5340.

(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 doesn't require any IANA actions. The one added code
    point for the new interface type is not part of the protocol - only
    the reference implementation used to describer protocol behavior. 

(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 to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

    Not Applicable.