OSPF Multi-Area Adjacency
RFC 5185

[Ballot discuss]
I would otherwise have balloted Yes, but isn't there an inconsistency
in the following excerpt from the document?


  Multi-area adjacencies are announced as unnumbered point-to-point
  links.

  ...

      Link Data = Neighbor's IP Address or IfIndex (if the underlying
      interface is unnumbered).

  This will announce a topological path through the corresponding area.
  While advertising the neighbor's IP address in the link data isn't
  consistent with the unnumbered link model, it is required to
  eliminate ambiguity when there are parallel point-to-point
  adjacencies.

First, we say that the advertisements defined in the document are
unnumbered point-to-point links. The second part says to use ifIndex
for unnumbered links. The third part claims that the use of an
IP address is necessary. What am I missing?

Or perhaps the issue is what the underlying interface vs. the advertised
link are. If so, the document does not explain what happens when the
underlying link is unnumbered and you have parallel p2p adjacencies.
Perhaps that's not a configuration that is allowed?

In any case, some clarification for this reader at least would be
welcome.

[Ballot discuss]
I would otherwise have balloted Yes, but isn't there an inconsistency
in the following excerpt from the document?


  Multi-area adjacencies are announced as unnumbered point-to-point
  links.

  ...

      Link Data = Neighbor's IP Address or IfIndex (if the underlying
      interface is unnumbered).

  This will announce a topological path through the corresponding area.
  While advertising the neighbor's IP address in the link data isn't
  consistent with the unnumbered link model, it is required to
  eliminate ambiguity when there are parallel point-to-point
  adjacencies.

First, we say that the advertisements defined in the document are
unnumbered point-to-point links. The secnd part says to use ifIndex
for unnumbered links. The third part claims that the use of an
IP address is necessary. What am I missing?

PROTO writeup by Abhay Roy:

  1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

Yes

  2. Has the document had adequate review from both key WG members and
    key non-WG members?

Yes

    Do you have any concerns about the depth or breadth of the reviews
    that have been performed?
   
No.

  3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

No

  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any
    event, if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

No

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

This document has been reviewed and revised for several years. It
has been implemented by  two vendors.

  6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

No

  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items ?

  idnits 2.08.08

draft-ietf-ospf-multi-area-adj-08.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC 4748:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

  == There are 1 instance of lines with non-RFC3330-compliant IPv4 addresses in
    the document.  If these are example addresses, they should be changed.

#### It's a reference to a section in an rfc, not an ipv4 address
#### false alarm

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Unexpected draft version: The latest known version of
    draft-ietf-isis-igp-p2p-over-lan is -05, but you're referring to -06.
    (However, the state information for draft-ietf-isis-igp-p2p-over-lan is not    up-to-date.  The last update was unsuccessful)

#### It's like chasing the moving draft. We could possibly edit
#### this to the latest rev during rfc-ed cycle.

    Summary: 0 errors (**), 1 warning (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

  8. Is the document split into normative and informative references?

Yes

    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (note here that the RFC editor will not publish an RFC with
    normative references to IDs, it will delay publication until all 
    such IDs are also ready for publication as RFCs.)

No - only information references to IDs.

  9. What is the intended status of the document? (e.g., Proposed
    Standard, Informational?)

Proposed Standard

10. For Standards Track and BCP documents, the IESG approval
    announcement includes a write-up section with the following 
    sections:

    * Technical Summary
     
This draft extends OSPF so that a single interface can be used in
multiple areas without any additional encapsulation overhead.

    * Working Group Summary
     
There was no opposition to this document.

    * Protocol Quality
     
This is a very simple draft and there are two vendor
implementations at this time.

From: Acee Lindem
Subject: [Fwd: OSPF Multi-Area Adjacency]
Date: Wed, 17 Aug 2005 10:12:19 -0400
To: IESG Secretary
Cc: Bill Fenner , Alex Zinin
    , Rohit Dube

We'll be re-last calling this document as an standards track
document.
Thanks,
Acee

From: "Acee Lindem"
Subject: Re: OSPF Muli-Area Adjacency -
        draft-ietf-ospf-multi-area-adj-02.txt
Date: Wed, 3 Nov 2004 10:05:33 -0500
To: "Mailing List"
Cc: "iesg-secretary" , "Alex Zinin"
    , "Bill Fenner"

The WG last call for the subject document has completed
and the comments have been incorportated into
draft-ietf-ospf-multi-area-adj-03.txt.