Skip to main content

Support of Address Families in OSPFv3
RFC 5838

Revision differences

Document history

Date Rev. By Action
2015-10-14
10 (System) Notify list changed from ospf-chairs@ietf.org, draft-ietf-ospf-af-alt@ietf.org to (None)
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2012-08-22
10 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-04-21
10 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2010-04-21
10 Amy Vezza [Note]: 'RFC 5838' added by Amy Vezza
2010-04-20
10 (System) RFC published
2010-03-01
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-03-01
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-03-01
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-02-22
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-02-22
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-02-18
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-02-18
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-02-18
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-02-17
10 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-02-17
10 (System) IANA Action state changed to In Progress
2010-02-17
10 Amy Vezza IESG state changed to Approved-announcement sent
2010-02-17
10 Amy Vezza IESG has approved the document
2010-02-17
10 Amy Vezza Closed "Approve" ballot
2010-02-16
10 Ross Callon State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon
2010-02-16
10 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2010-02-16
10 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2010-01-12
10 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2009-12-15
10 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2009-12-15
10 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-12-15
10 (System) New version available: draft-ietf-ospf-af-alt-10.txt
2009-12-04
10 (System) Removed from agenda for telechat - 2009-12-03
2009-12-03
10 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2009-12-03
10 Tim Polk
[Ballot discuss]
This is a very minor discuss, but I wanted to be sure the reference to the MC-bit in section
2.2 is deleted, as …
[Ballot discuss]
This is a very minor discuss, but I wanted to be sure the reference to the MC-bit in section
2.2 is deleted, as agreed to in Acee's email exchange with Alexey.  Suggested RFC Editor's
Note:

OLD
  A new AF-bit is added to the OSPFv3 options field.  V6-bit and MC-bit
  are only applicable to the IPv6 unicast AF.
NEW
  A new AF-bit is added to the OSPFv3 options field.  The V6-bit
  is only applicable to the IPv6 unicast AF.
2009-12-03
10 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-12-03
10 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2009-12-02
10 Russ Housley
[Ballot comment]
The Gen-ART Review by Christian Vogt raised the following:
  >
  > In section 3, "Backwards Compatibility", it may furthermore be worth …
[Ballot comment]
The Gen-ART Review by Christian Vogt raised the following:
  >
  > In section 3, "Backwards Compatibility", it may furthermore be worth
  > mentioning that all modifications to OSPFv3, as specified in this
  > document, exclusively affect the use of OSPFv3 for new address families.
  > Since this is a prerequisite for backwards compatibility, it will
  > further support the backwards compatibility claim of this section.
2009-12-02
10 Russ Housley
[Ballot discuss]
The Gen-ART Review by Christian Vogt raised one thing that could be
  changed to improve readability:
  >
  > The document …
[Ballot discuss]
The Gen-ART Review by Christian Vogt raised one thing that could be
  changed to improve readability:
  >
  > The document uses the acronym "AF" both to denote the term address
  > family, as well as to refer to the OSPF extensions being specified in
  > the document (e.g., in the definition of the AF bit in section 2.2).
  > This is confusing, in particular because "AF" is explicitly defined only
  > to mean the former, not the latter.  I suggest using a different name,
  > e.g., "AF support", to denote the OSPF extensions being specified, and
  > adding a definition for this to the introduction of the document.
  >
  Is there any reason that this change should not be made?
2009-12-02
10 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2009-12-02
10 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-12-02
10 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2009-12-02
10 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-12-02
10 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2009-12-02
10 Dan Romascanu
[Ballot comment]
I support Adrian's DISCUSS about the need to mention 'update RFC 5340' in the header of the document because of the changing …
[Ballot comment]
I support Adrian's DISCUSS about the need to mention 'update RFC 5340' in the header of the document because of the changing of semantics in the Instance ID. This being said I think that the backwards compatibility section demonstrates that there are no backward compatibility issues, although it would be useful if some text would be added about the limitations of mixing routers compliant with this specification and 'non-capable' routers in the topology, and maybe operational recommendations about the transition of the network to a fully compliant configuration.
2009-12-02
10 Dan Romascanu
[Ballot comment]
I support Adrian's DISCUSS about the need to mention 'update RFC 5340' in the header of the document because of the changing …
[Ballot comment]
I support Adrian's DISCUSS about the need to mention 'update RFC 5340' in the header of the document because of the changing of semantics in the ID
2009-12-02
10 Ross Callon The document shepherd has been changed to Nischal Sheth (nsheth@juniper.net).
2009-12-01
10 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks
2009-12-01
10 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-12-01
10 Ralph Droms
[Ballot comment]
A few nites...

From section 1:

  There are requirements to advertise other AFs
  in OSPFv3 including multicast IPv6, unicast IPv4, and …
[Ballot comment]
A few nites...

From section 1:

  There are requirements to advertise other AFs
  in OSPFv3 including multicast IPv6, unicast IPv4, and multicast IPv4.

Can details about the source and nature of these requirements be provided?


In section 3:

  Currently the entire Instance ID number space is used for IPv6
  unicast.

Can a reference to this usage specification be cited here?


Expand "LSAs" on first use?


In section 2.2:

  s/When a router supports AF/When a router supports AF Instance IDs/

for clarity?
2009-11-30
10 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-11-30
10 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-11-28
10 Alexey Melnikov
[Ballot comment]
Agreeing with Adrian about the missing Updates field.

2.2.  OSPFv3 Options Changes

  A new AF-bit is added to the OSPFv3 options field.  …
[Ballot comment]
Agreeing with Adrian about the missing Updates field.

2.2.  OSPFv3 Options Changes

  A new AF-bit is added to the OSPFv3 options field.  V6-bit and MC-bit
  are only applicable to the IPv6 unicast AF.

I don't see any bit called "MC" in the table below:

                              1                    2
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9  0  1  2  3
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+
          | | | | | | | | | | | | | | | |AF|*|*|DC|R|N|x | E|V6|
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+

2.7.  Database Description Maximum Transmissoin Unit (MTU)
      Specification for Non-IPv6 AFs

        0                  1                  2                  3
        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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              6 (TBD)          |              4              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IPv6 MTU                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is MTU in network byte order?
2009-11-28
10 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov
2009-11-28
10 Alexey Melnikov
[Ballot comment]
2.2.  OSPFv3 Options Changes

  A new AF-bit is added to the OSPFv3 options field.  V6-bit and MC-bit
  are only applicable to …
[Ballot comment]
2.2.  OSPFv3 Options Changes

  A new AF-bit is added to the OSPFv3 options field.  V6-bit and MC-bit
  are only applicable to the IPv6 unicast AF.

I don't see any bit called "MC" in the table below:

                              1                    2
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9  0  1  2  3
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+
          | | | | | | | | | | | | | | | |AF|*|*|DC|R|N|x | E|V6|
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+

2.7.  Database Description Maximum Transmissoin Unit (MTU)
      Specification for Non-IPv6 AFs

        0                  1                  2                  3
        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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              6 (TBD)          |              4              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          IPv6 MTU                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is MTU in network byte order?
2009-11-27
10 Adrian Farrel [Ballot comment]
A bit odd to have the Acknowledgements in an Appendix
2009-11-27
10 Adrian Farrel
[Ballot discuss]
A good piece of work and a reasonable solution to the problem. I will vote "Yes" when we have resolved my relatively small …
[Ballot discuss]
A good piece of work and a reasonable solution to the problem. I will vote "Yes" when we have resolved my relatively small Discuss issues.

---

I think this draft updates RFC 5340.
My reasoning is that RFC 5340 imposes no restrictions on the use of
the Instance ID, but this document places semantics on the value of
that field.

---

RFC 5340 says
  Instance ID
      Every interface is assigned an Instance ID.  This should default
      to 0.  It is only necessary to assign a value other than 0 on
      those links that will contain multiple separate communities of
      OSPF routers.  For example, suppose that there are two communities
      of routers on a given ethernet segment that you wish to keep
      separate.
      The first community is assigned an Instance ID of 0 and all the
      routers in the first community will be assigned 0 as the Instance
      ID for interfaces connected to the ethernet segment.  An Instance
      ID of 1 is assigned to the other routers' interfaces connected to
      the ethernet segment.  The OSPF transmit and receive processing
      (see Section 4.2) will then keep the two communities separate.
Now, suppose we have a link that only supports IPv4 unicast. According
to the text in RFC 5340, we have to use (should use / can use) Instance
ID 0 on this link.
But this draft says we MUST use an Instance ID in the range 64-95.     
At the very least this is cause for "updates RFC5340", but I think you
need to call out this change more clearly to avoid interop problems.

---

Furthermore, in section 2.3 you have
  Prefixes which don't match the AF of the OSPFv3 instance, MUST be
  discarded in any route computation.
This is an interoperability change from RFC 5340 since legacy
implementations are allowed to send all addresses with (e.g.) Instance
ID 0.

---

Section 2.7
I am not comfortable with the reinclusion of the figure for the OSPFv3
database description packet. It seems to me that you are just
reinterpretting one field slightly and defining a new bit. Including the
whole packet format gives two normative definitions for the packet.

---

Section 5
The IANA section could use some tidying up, although IANA has resolved
some issues during IETF last call.
Perhaps the right thing to do is to update the document in line with
the discussions with IANA.
Points that I notice...

  The following IANA assignments are to be made from existing
  registries:

...but the second piece of work listed is a new registry.

It would be good to identify the registries and the details of what
you want included in the registries.
2009-11-27
10 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2009-11-25
10 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon
2009-11-25
10 Ross Callon Ballot has been issued by Ross Callon
2009-11-25
10 Ross Callon Created "Approve" ballot
2009-11-25
10 Ross Callon Placed on agenda for telechat - 2009-12-03 by Ross Callon
2009-11-25
10 Ross Callon State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon
2009-11-17
09 (System) New version available: draft-ietf-ospf-af-alt-09.txt
2009-10-22
10 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Julien Laganier.
2009-10-14
10 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-10-12
10 Amanda Baber
IANA questions/comments:

- Note that we have questions for the authors and the IESG Routing
ADs about Action 3.


ACTION 1:

A new assignment in …
IANA questions/comments:

- Note that we have questions for the authors and the IESG Routing
ADs about Action 3.


ACTION 1:

A new assignment in the "OSPFv3 Options (24 bits)" registry at
http://iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml

Value Description Reference
----- ----------- ----------
TBD AF-bit [RFC-ospf-af-alt-08]


ACTION 2:

A new registry at
http://iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml

Registry Name: OSPFv3 Instance ID Address Family Values
Reference: [RFC-ospf-af-alt-08]

Registration procedures: Standards Action

Value Designation Reference
------- ---------------------------- ----------
0 Base IPv6 Unicast AF [RFC-ospf-af-alt-08]
1-31 IPv6 Unicast AFs dependent [RFC-ospf-af-alt-08]
on local policy
32 Base IPv6 Multicast [RFC-ospf-af-alt-08]
33-63 IPv6 Multicast AFs dependent [RFC-ospf-af-alt-08]
on local policy
64 Base IPv4 Unicast AF [RFC-ospf-af-alt-08]
65-95 IPv4 Unicast AFs dependent [RFC-ospf-af-alt-08]
on local policy
96 Base IPv4 Multicast [RFC-ospf-af-alt-08]
97-127 IPv4 Multicast AFs dependent [RFC-ospf-af-alt-08]
on local policy
128-255 Unassigned

Value type: 8bit unsigned integer


ACTION 3:

QUESTION: The "IANA Considerations" section says, "M6-Bit is
assigned as defined in Section 2.7."
To our understanding, this M6-Bit is used in the "Database
Description Packet." There is to our knowledge no registry for
the bits of these types of packets.

To the authors: is our understanding of your request correct?

To the IESG Routing AD: if our understanding is right, should a new
registry for "Database Description Packet" bits be created, and if yes,
then what would be the appropriate content, registration procedures, etc...?

A prototype registry could be:

Registration Procedures: Standards Action

Value = 8bit

Value Description Reference
----- ------------------------ ---------
0x01 Master/Slave (MS-bit) [TBD]
0x02 More (M-bit) [TBD]
0x04 Init (I-bit) [TBD]
0x08 Unassigned
0x10 IPv6 MTU (M6-bit) [RFC-ospf-af-alt-08]
0x20 Unassigned
0x40 Unassigned
0x80 Unassigned


ACTION 4:

A new assignment in the ""Link Local Signalling TLV Identifiers
(LLS Types)" registry at
http://iana.org/assignments/ospf-lls-tlvs/ospf-lls-tlvs.xhtml

LLS Type Name Reference
-------- -------- -----------
TBD IPv6 MTU [RFC-ospf-af-alt-08]
2009-10-03
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Julien Laganier
2009-10-03
10 Samuel Weiler Request for Last Call review by SECDIR is assigned to Julien Laganier
2009-09-30
10 Amy Vezza Last call sent
2009-09-30
10 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-09-29
10 Ross Callon Last Call was requested by Ross Callon
2009-09-29
10 Ross Callon State Changes to Last Call Requested from Publication Requested by Ross Callon
2009-09-29
10 (System) Ballot writeup text was added
2009-09-29
10 (System) Last call text was added
2009-09-29
10 (System) Ballot approval text was added
2009-07-17
10 Ross Callon
PROTO writeup by Acee Lindem:

  1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do …
PROTO writeup by Acee Lindem:

  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. Dave Ward, in his capacity as Routing AD, reviewed it
    several times.

    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?

    There is no opposition to this draft. We still have an outstanding
    requirement to support advertisement of multiple address families
    using a single instance but it hasn't be strong enough to push the
    work forward.

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

tmp/draft-ietf-ospf-af-alt-08.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    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:
  ----------------------------------------------------------------------------

    No issues found here.

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

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
    first submitted before 10 November 2008.  Should you add the disclaimer?
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more information.).


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

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

  == Outdated reference: A later version (-08) exists of
    draft-ietf-ospf-lls-05


    Summary: 0 errors (**), 2 warnings (==), 0 comments (--).

    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 informational references to IDs. the [LLS] reference is
    currently on the RFC queue.

  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
    * Working Group Summary
    * Protocol Quality

This document describes protocol extentions to advertise multiple address
families using multiple instances of OSPFv3. The protocol extentions are
very intuitive and implementable. Full backward compatibility is provided
with implementations not supporting the specifications.

There are several implementations, at least one of which is commercially
available.
2009-07-17
10 Ross Callon Draft Added by Ross Callon in state Publication Requested
2009-07-12
08 (System) New version available: draft-ietf-ospf-af-alt-08.txt
2009-05-04
10 (System) Document has expired
2008-10-31
07 (System) New version available: draft-ietf-ospf-af-alt-07.txt
2007-11-07
06 (System) New version available: draft-ietf-ospf-af-alt-06.txt
2007-04-09
05 (System) New version available: draft-ietf-ospf-af-alt-05.txt
2006-09-29
04 (System) New version available: draft-ietf-ospf-af-alt-04.txt
2006-03-08
03 (System) New version available: draft-ietf-ospf-af-alt-03.txt
2005-10-05
02 (System) New version available: draft-ietf-ospf-af-alt-02.txt
2004-11-01
01 (System) New version available: draft-ietf-ospf-af-alt-01.txt
2004-04-06
00 (System) New version available: draft-ietf-ospf-af-alt-00.txt