Multi-Topology (MT) Routing in OSPF
RFC 4915
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-12-20 |
09 | (System) | Received changes through RFC Editor sync (changed abstract to 'This document describes an extension to Open Shortest Path First (OSPF) in order to define independent ... Received changes through RFC Editor sync (changed abstract to 'This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology. An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]') |
2015-10-14 |
09 | (System) | Notify list changed from ospf-chairs@ietf.org to (None) |
2012-08-22 |
09 | (System) | post-migration administrative database adjustment to the No Objection position for David Kessens |
2007-07-02 |
09 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2007-07-02 |
09 | Amy Vezza | [Note]: 'RFC 4915' added by Amy Vezza |
2007-06-30 |
09 | (System) | RFC published |
2007-06-14 |
09 | (System) | New version available: draft-ietf-ospf-mt-09.txt |
2007-02-08 |
09 | (System) | IANA Action state changed to No IC from In Progress |
2007-02-08 |
09 | (System) | IANA Action state changed to In Progress |
2007-02-05 |
09 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-02-02 |
09 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-02-02 |
09 | Amy Vezza | IESG has approved the document |
2007-02-02 |
09 | Amy Vezza | Closed "Approve" ballot |
2007-01-23 |
09 | Bill Fenner | State Changes to Approved-announcement to be sent from IESG Evaluation by Bill Fenner |
2007-01-23 |
09 | Bill Fenner | Removed from agenda for telechat - 2007-01-25 by Bill Fenner |
2007-01-23 |
09 | David Kessens | [Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens |
2007-01-22 |
09 | Bill Fenner | Placed on agenda for telechat - 2007-01-25 by Bill Fenner |
2007-01-22 |
09 | Bill Fenner | State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Bill Fenner |
2007-01-22 |
09 | Bill Fenner | Adding (LATE) to agenda to see if new version clears DISCUSSes. |
2007-01-22 |
09 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2007-01-22 |
08 | (System) | New version available: draft-ietf-ospf-mt-08.txt |
2006-12-15 |
09 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2006-12-14 |
09 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2006-12-14 |
09 | Sam Hartman | [Ballot comment] My no-obj is based on the assumption David's discuss is addressed. I strongly agree that ruling the forwarding plane issues out of scope ... [Ballot comment] My no-obj is based on the assumption David's discuss is addressed. I strongly agree that ruling the forwarding plane issues out of scope is a bad idea. I think the routing area really needs to sign up to dealing with the forwarding considerations for this and for the similar ISIS document. |
2006-12-14 |
09 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman |
2006-12-14 |
09 | Amy Vezza | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Amy Vezza |
2006-12-14 |
09 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2006-12-14 |
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2006-12-14 |
09 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2006-12-13 |
09 | David Kessens | [Ballot comment] Comments received the Ops Directorate by Pekka Savola: Some editorial comments: - The document should state that it Updates the OSPF spec, RFC ... [Ballot comment] Comments received the Ops Directorate by Pekka Savola: Some editorial comments: - The document should state that it Updates the OSPF spec, RFC 2328. - Abstract also mentions 'different classes of service based on flexible criteria, or an in-band network management [topologies]' which are not mentioned anymore later in the draft; this should probably be removed from the abstract or applicability expanded in Introduction or some suitable section. - "[M-ISIS] describes a similar mechanism for ISIS." after talking about ToS as multi-topology hasn't been even mentioned yet; better place would be after the second paragraph of Introduction. |
2006-12-13 |
09 | David Kessens | [Ballot discuss] I agree with the following review that I received from Pekka Savola from the Ops Directorate: ----- I believe there are a couple ... [Ballot discuss] I agree with the following review that I received from Pekka Savola from the Ops Directorate: ----- I believe there are a couple of problems with this specification. Apart from the second issue below these should be easy to solve; the 2nd issue may require a bit further though and a closer look of security area and routing directorate would likely be a good idea. First of all, section 3.7 defines the MT-ID values for the whole 1-byte space without establishing an IANA registry. If the IETF wanted to define a new MT-ID values for whatever reasons, this would become rather complex and there would not be up-to-date registry anywhere. If there is no strong reason for the current approach, I'd suggest putting the existing list under IANA stewardship and defining a part of MT-ID space as assignable under some policy, e.g., Standards Action. Second, I'm not sure the security considerations is adequate. As evidenced by the abstract, the intent is to use this e.g., for in-band network management which clearly seeks the security 'benefit' of restricting in-band access from 'default'. The forwarding plane matching implications were decreed out of scope of this memo (section 3.8). Presumably implementations are going to use something like the source or destination IP addresses to determine which packets belong to which topology. (Non-specified) classifying packets to multiple forwarding and control planes seems to change the security assumptions of OSPF. At the very least, I'd like to see some discussion about the security properties of forwarding function separation (s3.8) and its implications such as packets getting forwarded to a wrong topology. ----- Proposed fix: Follow Pekka's advise for the first issue. For the second issue: this document has potential operational issues and ruling them out of scope is not how one deals solves this issue. This document really needs an operational considerations section on how to deal with the seperation in the real world and an expanded security consideration section. |
2006-12-13 |
09 | David Kessens | [Ballot Position Update] New position, Discuss, has been recorded by David Kessens |
2006-12-13 |
09 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2006-12-13 |
09 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2006-12-13 |
09 | Dan Romascanu | [Ballot comment] 1. It would be useful that the statement in the Introduction 'TOS based routing as described in [TOS-OSPF] was never deployed and was ... [Ballot comment] 1. It would be useful that the statement in the Introduction 'TOS based routing as described in [TOS-OSPF] was never deployed and was subsequently deprecated.' is backed-up by a reference. The appropriate reference is I believe Annex G.10 in RFC2178 2. I am surprised by the absence of a Manageability and Operations Considerations section, or of any reference to such considerations in the document. There are at least two good reasons beyond the usual ones for such consideration to be included: - the document lists the creation of a dedicated topology for network management as one of the principal applications of OSPF MT routing - the PROTO write-up mentions that 'there may be implications on the MIB' |
2006-12-13 |
09 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2006-12-12 |
09 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2006-12-12 |
09 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter |
2006-12-11 |
09 | Yoshiko Fong | IANA Comment: After discussion with the document authors, IANA understands that there are no IANA Actions required upon approval of this document. |
2006-12-11 |
09 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie |
2006-12-11 |
09 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2006-12-10 |
09 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2006-12-07 |
09 | Bill Fenner | Placed on agenda for telechat - 2006-12-14 by Bill Fenner |
2006-12-07 |
09 | Bill Fenner | [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner |
2006-12-07 |
09 | Bill Fenner | Ballot has been issued by Bill Fenner |
2006-12-07 |
09 | Bill Fenner | Created "Approve" ballot |
2006-11-30 |
07 | (System) | New version available: draft-ietf-ospf-mt-07.txt |
2006-11-02 |
09 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-10-25 |
09 | Yoshiko Fong | IANA Last Call Comments : As described in the IANA Considerations section this document redefines the T-bit for a router's TOS capability as the MT-bit. ... IANA Last Call Comments : As described in the IANA Considerations section this document redefines the T-bit for a router's TOS capability as the MT-bit. The T-bit does not appear in a registry maintained by IANA. The TOS field in OSPF 2 for Router-LSAs, Summary-LSAs, NSSA-LSAs and AS-External LSAs is redefined by this document at MT-ID. The TOS field does not appear in a registry maintained by IANA. IANA understands that it has no IANA Actions upon approval of this document. |
2006-10-19 |
09 | Amy Vezza | Last call sent |
2006-10-19 |
09 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-10-19 |
09 | Bill Fenner | State Changes to Last Call Requested from AD Evaluation by Bill Fenner |
2006-10-19 |
09 | Bill Fenner | Last Call was requested by Bill Fenner |
2006-10-19 |
09 | (System) | Ballot writeup text was added |
2006-10-19 |
09 | (System) | Last call text was added |
2006-10-19 |
09 | (System) | Ballot approval text was added |
2006-07-24 |
09 | Bill Fenner | [Note]: 'The PROTO shepherd is Acee Lindem <acee@cisco.com>' added by Bill Fenner |
2006-07-24 |
09 | Bill Fenner | State Change Notice email list have been change to ospf-chairs@tools.ietf.org from acee@cisco.com, dube.rohit@gmail.com |
2006-07-24 |
09 | Bill Fenner | [Note]: 'The PROTO shepherd is Acee Lindem <acee@cisco.com>' added by Bill Fenner |
2006-02-01 |
06 | (System) | New version available: draft-ietf-ospf-mt-06.txt |
2006-01-23 |
09 | Bill Fenner | State Changes to AD Evaluation from Publication Requested by Bill Fenner |
2006-01-23 |
09 | Bill Fenner | [Note]: 'The PROTO shepherd is Acee Lindem <acee@cisco.com>' added by Bill Fenner |
2006-01-23 |
09 | Bill Fenner | State Change Notice email list have been change to acee@cisco.com, dube.rohit@gmail.com from acee@cisco.com, rohit@utstar.com |
2006-01-13 |
05 | (System) | New version available: draft-ietf-ospf-mt-05.txt |
2005-07-18 |
09 | Bill Fenner | Proto answers from Acee: 1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID ... Proto answers from Acee: 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? I have reviewed every version of the document and, in fact, have acted as editor. Rohit and I have discussed the document (he can speak for his own level of review). 2. Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Non-OSPF WG members do not normally review OSPF drafts. Comments were received on the revisions of the document. Since I reviewed and edited the document I have no concerns with the quality of review. 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. There may be implications on the MIB. However, OSPF MIB enhancements have typically followed functional enhancements. 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. Alex Zinin has said several times that the forwarding issues with MTR need to be documented but my understanding is that we agreed that this would go in a separate document. If people would be happier, something very similar to section 12 of the M-ISIS draft could be added. However, I'm against since inadequately covering a subject is worse than saying that the subject is beyond the scope of the document. 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? The draft was accepted as a WG document and sufficient opportunity has been given to disagree of comment on it. When the document was initially accepted as a WG document, OSPF implementors from multiple vendors agreed that it should be accepted. 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 <http://www.ietf.org/ID-Checklist.html> ? When I took over editing of the document, I converted it to xml2rfc. Hence, I believe all the nits are satisfied. Please let me know if they are not. 8. Is the document split into normative and informative references? 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.) There are normative/informative references and none of the normative references will hold up the document. The M-ISIS draft has not advanced to RFC state but it is an informative reference. 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Proposed Standard. |
2005-07-05 |
09 | Bill Fenner | Pick up dropped ball - there's an open ticket requesting that this draft advance from April. I suspect the lack of a clear action-requesting subject ... Pick up dropped ball - there's an open ticket requesting that this draft advance from April. I suspect the lack of a clear action-requesting subject line caused it to be overlooked. |
2005-07-05 |
09 | Bill Fenner | Draft Added by Bill Fenner in state Publication Requested |
2005-04-22 |
04 | (System) | New version available: draft-ietf-ospf-mt-04.txt |
2005-03-30 |
03 | (System) | New version available: draft-ietf-ospf-mt-03.txt |
2005-03-18 |
02 | (System) | New version available: draft-ietf-ospf-mt-02.txt |
2005-02-23 |
01 | (System) | New version available: draft-ietf-ospf-mt-01.txt |
2004-10-05 |
00 | (System) | New version available: draft-ietf-ospf-mt-00.txt |