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 |