M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)
RFC 5120
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2017-05-16
|
12 | (System) | Changed document authors from "Tony Przygienda" to "Tony Przygienda, Naiming Shen, Nischal Sheth" |
|
2015-10-14
|
12 | (System) | Notify list changed from isis-chairs@ietf.org to (None) |
|
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Mark Townsley |
|
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the Yes position for Russ Housley |
|
2008-02-11
|
12 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2008-02-11
|
12 | Amy Vezza | [Note]: 'RFC 5120' added by Amy Vezza |
|
2008-02-08
|
12 | (System) | RFC published |
|
2007-11-26
|
12 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2007-11-21
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2007-11-21
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2007-11-21
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2007-11-20
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2007-11-19
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2007-11-19
|
12 | Amy Vezza | IESG has approved the document |
|
2007-11-19
|
12 | Amy Vezza | Closed "Approve" ballot |
|
2007-11-19
|
12 | (System) | IANA Action state changed to In Progress |
|
2007-11-16
|
12 | (System) | Removed from agenda for telechat - 2007-11-15 |
|
2007-11-15
|
12 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
|
2007-11-15
|
12 | Dan Romascanu | [Ballot comment] |
|
2007-11-15
|
12 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
|
2007-11-15
|
12 | Chris Newman | [Ballot comment] I am carrying forward Ted's no objection, but have not otherwise reviewed this document. |
|
2007-11-15
|
12 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
|
2007-11-14
|
12 | David Ward | [Ballot Position Update] New position, Recuse, has been recorded by David Ward |
|
2007-11-14
|
12 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2007-11-13
|
12 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2007-11-13
|
12 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
|
2007-11-13
|
12 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to Yes from No Objection by Russ Housley |
|
2007-11-13
|
12 | Russ Housley | Placed on agenda for telechat - 2007-11-15 by Russ Housley |
|
2007-11-13
|
12 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2007-11-13
|
12 | Russ Housley | State Changes to IESG Evaluation::AD Followup from Dead by Russ Housley |
|
2007-11-13
|
12 | (System) | New version available: draft-ietf-isis-wg-multi-topology-12.txt |
|
2007-10-26
|
12 | (System) | Document has expired |
|
2007-10-25
|
12 | Russ Housley | State Changes to Dead from IESG Evaluation::Revised ID Needed by Russ Housley |
|
2007-05-01
|
12 | Russ Housley | Responsible AD has been changed to Russ Housley from Ross Callon |
|
2007-04-30
|
12 | Ross Callon | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ross Callon |
|
2007-03-22
|
12 | Bill Fenner | Responsible AD has been changed to Ross Callon from Bill Fenner |
|
2006-11-08
|
12 | (System) | Request for Early review by SECDIR Completed. Reviewer: Vidya Narayanan. |
|
2006-10-26
|
12 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
|
2006-10-26
|
12 | Amy Vezza | [Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Discuss by Amy Vezza |
|
2006-10-26
|
12 | Jari Arkko | [Ballot comment] > To prevent > unnecessary complexity, MT extensions does not support > partition repair. The overload, partition and attached bits in LSP > … [Ballot comment] > To prevent > unnecessary complexity, MT extensions does not support > partition repair. The overload, partition and attached bits in LSP > header only reflect the status of the default topology. Did you mean "To prevent unnecessary complexity, MT extensions do not support partition repair for other partitions than the default partition"? |
|
2006-10-26
|
12 | Russ Housley | [Ballot comment] Please add a terminology section to expand the ISIS acronyms. |
|
2006-10-26
|
12 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
|
2006-10-26
|
12 | Russ Housley | [Ballot discuss] Please add a reference to RFC 3567 in the security section, and encourage the use of RFC 3567 for authentication. Please … [Ballot discuss] Please add a reference to RFC 3567 in the security section, and encourage the use of RFC 3567 for authentication. Please add a discussion of authorization to the security considerations section. In particular, any information that is used to determine which RIB to update should be highlighted. Section 2 indicates that the MTID is not sufficient when there exists overlapping IP address space among the topologies. Also, please summarize the consequences if is the wrong RIB is selected. |
|
2006-10-26
|
12 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
|
2006-10-26
|
12 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2006-10-26
|
12 | Mark Townsley | [Ballot discuss] The document seems to dance around the issue of how to mark packets in different topologies, e.g.: "The generic approach of packet to … [Ballot discuss] The document seems to dance around the issue of how to mark packets in different topologies, e.g.: "The generic approach of packet to multiple MT RIB mapping over the same inbound interface is outside the scope of this draft." I can accept that since this is an IS-IS draft, it does not speak of the various methods of IP packet marking, but what document is going to be published that defines such mappings? It would seem that to create a functioning system, this would need to be defined somewhere. May we at least have an informational reference? |
|
2006-10-26
|
12 | Mark Townsley | [Ballot Position Update] Position for Mark Townsley has been changed to Discuss from No Objection by Mark Townsley |
|
2006-10-26
|
12 | Mark Townsley | [Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Discuss by Mark Townsley |
|
2006-10-26
|
12 | Mark Townsley | [Ballot Position Update] New position, Discuss, has been recorded by Mark Townsley |
|
2006-10-26
|
12 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded by David Kessens |
|
2006-10-25
|
12 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
|
2006-10-25
|
12 | Ross Callon | [Ballot Position Update] New position, Recuse, has been recorded by Ross Callon |
|
2006-10-25
|
12 | Sam Hartman | [Ballot comment] I'm not familiar enough with ISIS to give this a good review. |
|
2006-10-25
|
12 | Sam Hartman | [Ballot Position Update] New position, Abstain, has been recorded by Sam Hartman |
|
2006-10-25
|
12 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
|
2006-10-24
|
12 | Brian Carpenter | [Ballot comment] 12. IANA Considerations ... IANA is also requested to update the IS-IS codepoint registry (http://www.iana.org/assignments/isis-tlv-codepoints) so that … [Ballot comment] 12. IANA Considerations ... IANA is also requested to update the IS-IS codepoint registry (http://www.iana.org/assignments/isis-tlv-codepoints) so that TLV codes 222, 229, 235 and 237 refer to this document's RFC number. [[ note to the RFC-editor: the above paragraph may be removed or reworded prior to RFC publication ]] I don't see how this can be removed. Also see editorial issues in Gen-ART review at http://www1.ietf.org/mail-archive/web/gen-art/current/msg01406.html |
|
2006-10-24
|
12 | Brian Carpenter | [Ballot discuss] IANA Considerations issue: IANA is requested to create a new registry, "IS-IS multi-topology ID values" with the assignment listed … [Ballot discuss] IANA Considerations issue: IANA is requested to create a new registry, "IS-IS multi-topology ID values" with the assignment listed in Section 7.5 of this document and registration policies for future assignments. That doesn't look right. This document should define the policy (Standards Action or whatever, as per RFC 2434). From Gen-ART review by Miguel Garcie: - Section 8 says: "The implementation and configuration MUST make sure the IP packets are only traversed through the nodes and links intended for the topologies and applications". The normative MUST is not actionable. Which actions do I need to take in the implementation to implement the MUST? How can the interoperability of those features be demonstrated? |
|
2006-10-24
|
12 | Brian Carpenter | [Ballot Position Update] New position, Discuss, has been recorded by Brian Carpenter |
|
2006-10-23
|
12 | Ted Hardie | [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie |
|
2006-10-23
|
12 | Lars Eggert | [Ballot comment] Inconsistent use of RFC2119 terms throughout, but especially in Section 7. There are a number of lower-case 2119 terms where the … [Ballot comment] Inconsistent use of RFC2119 terms throughout, but especially in Section 7. There are a number of lower-case 2119 terms where the uppercase is clearly warranted. There are also paraphrases that should be replaced with the implied 2119 terms. (I was considering to make this a DISCUSS, but since the intended meaning of the text is clear, I felt a strong COMMENT was sufficient.) Please expand acronyms (SPF, IIH, TLV, LSP, DIS, etc.) on first use or at least point to a document that defines them. Section 2., paragraph 1: > Each adjacency formed MUST be classified as belonging to a set of > MTs on the interface. This is achieved by adding a new TLV into > IIH packets that advertises which topologies the interface belongs > to. If MT #0 is the only MT on the interface, it is optional to > advertise it in the new TLV. Thus not including such a TLV in the > IIH implies MT ID #0 capability only. The logic here is actually the opposite of what is stated: _Because_ not including a TLV implies MT #0 only, it is OPTIONAL to include it. Section 2., paragraph 3: > In the case of adjacency contains multiple MTs on an interface, and > if there exists overlapping IP address space among the topologies, > additional mechanism MAY be used to resolve the topology identity of > the incoming IP packets on the interface. This paragraph is unfortunately too terse to understand what issues this could cause and why and what "additional mechanisms" may be desirable. Section 10., paragraph 0: > 10. Acknowledgments Nit: Typically comes just before the references. Section 12., paragraph 0: > 12. IANA Considerations I second Brian's concerns about the IANA considerations. |
|
2006-10-23
|
12 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2006-10-23
|
12 | Dan Romascanu | [Ballot comment] 1. Section 7.5 - I am wondering if reserving almost 4000 values for IETF consensus, and only 100 for 'development, experimental and proprietary … [Ballot comment] 1. Section 7.5 - I am wondering if reserving almost 4000 values for IETF consensus, and only 100 for 'development, experimental and proprietary features' is the right proportion, unless of course the authors want to send a strong signal that experimental and proprietary features are strongly discouraged. 2. Second phrase in Section 9.1 - there seems to be a 'that' missing. Should probably read 'This 'mgmt' topology will include all the routers THAT need to be managed'. |
|
2006-10-23
|
12 | Dan Romascanu | [Ballot comment] Second phrase in Section 9.1 - there seems to be a 'that' missing. Should probably read 'This 'mgmt' topology will include all the … [Ballot comment] Second phrase in Section 9.1 - there seems to be a 'that' missing. Should probably read 'This 'mgmt' topology will include all the routers THAT need to be managed'. |
|
2006-10-23
|
12 | Dan Romascanu | [Ballot discuss] Section 7.5 reserves a MT ID value for IPv4 in-band management purposes but not for IPv6. There is no text as far as … [Ballot discuss] Section 7.5 reserves a MT ID value for IPv4 in-band management purposes but not for IPv6. There is no text as far as I could see it that shows that the applicability of multi-topology routing for the purpose of creating a in-band management network on top of the original IGP topology is restricted to IPv4. I suggest to have this issue clarified - is the value for both IPv4 and IPv6, or is a value for IPv6 missing, or some text that shows why a value for IPv6 is not needed, or ... |
|
2006-10-23
|
12 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2006-10-20
|
12 | Brian Carpenter | [Ballot comment] 12. IANA Considerations IANA is requested to create a new registry, "IS-IS multi-topology ID values" with the assignment listed … [Ballot comment] 12. IANA Considerations IANA is requested to create a new registry, "IS-IS multi-topology ID values" with the assignment listed in Section 7.5 of this document and registration policies for future assignments. That doesn't look right. Surely this document should define the policy (Standards Action or whatever, as per RFC 2434)? IANA is also requested to update the IS-IS codepoint registry (http://www.iana.org/assignments/isis-tlv-codepoints) so that TLV codes 222, 229, 235 and 237 refer to this document's RFC number. [[ note to the RFC-editor: the above paragraph may be removed or reworded prior to RFC publication ]] I don't see how this can be removed. |
|
2006-10-19
|
12 | Bill Fenner | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Bill Fenner |
|
2006-10-19
|
12 | Bill Fenner | Placed on agenda for telechat - 2006-10-26 by Bill Fenner |
|
2006-10-19
|
12 | Bill Fenner | [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner |
|
2006-10-19
|
12 | Bill Fenner | Ballot has been issued by Bill Fenner |
|
2006-10-19
|
12 | Bill Fenner | Created "Approve" ballot |
|
2006-04-18
|
12 | Bill Fenner | State Changes to Waiting for AD Go-Ahead from Waiting for AD Go-Ahead::Revised ID Needed by Bill Fenner |
|
2006-04-18
|
12 | Bill Fenner | Naiming and Alex worked out the update with an RFC Editor note in February. Bill needs to check on a writeup from the chairs and … Naiming and Alex worked out the update with an RFC Editor note in February. Bill needs to check on a writeup from the chairs and implementation info to move forward. |
|
2006-04-18
|
12 | Bill Fenner | State Change Notice email list have been change to isis-chairs@tools.ietf.org from dward@cisco.com, chopps@rawdofmt.org |
|
2006-04-18
|
12 | Bill Fenner | Note field has been cleared by Bill Fenner |
|
2006-03-29
|
12 | Bill Fenner | Shepherding AD has been changed to Bill Fenner from Alex Zinin |
|
2005-11-02
|
12 | Alex Zinin | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead::AD Followup by Alex Zinin |
|
2005-11-02
|
12 | Alex Zinin | [Note]: 'Waiting for Naming to come back on comments that were not addressed by the revision.' added by Alex Zinin |
|
2005-10-21
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2005-10-21
|
11 | (System) | New version available: draft-ietf-isis-wg-multi-topology-11.txt |
|
2005-10-18
|
12 | Alex Zinin | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Alex Zinin |
|
2005-10-18
|
12 | Alex Zinin | State Changes to Waiting for AD Go-Ahead from Waiting for Writeup by Alex Zinin |
|
2005-10-18
|
12 | Alex Zinin | Issues brought up during AD-review: > 10. LSP Flooding > > An implementation MAY have the option to use additional MT > information … Issues brought up during AD-review: > 10. LSP Flooding > > An implementation MAY have the option to use additional MT > information in the LSP and on the adjacency to reduce some of the > unnecessary LSP flooding over the point-to-point links. If a > receiving interface and an outgoing interface don't share any > common MT capability, the implementation MAY have the option not to > flood this LSP out on that interface. Since the fragment zero LSP > contains the MTID, the MT capability of any LSP can be identified. > If the LSP and the adjacencies of an outgoing interface do not > share any common MT capability, the implementation MAY have the > option not to flood this LSP out on that interface. An > implementation MAY want to have the operators to control those > optimization base on network topology and environment to ensure > the LSP flooding reliability. From what I remember the discussion a long time ago, we explicitly did not want to encourage flooding changes, as risky. Has there been a discussion in the WG about this? If the WG wanted to do that, it seems that more would need to be described than what meets the eye above. If complete specification of the subject is not the goal, I would suggest simply removing the above. > When there is an adjacency MT set change over a point-to-point > link and the adjacency is in UP state, both sides SHOULD force an > exchange of one set of CSNPs over that link. Should this be a "MUST" instead? I.e., is there a case where NOT doing this is OK? > 11.1. Multi-Topology TLV ... > This MT TLV can advertise up to 127 MTs and it can occur multiple > times if needed within IIHs and LSP fragment zero. The result MT Does it HAVE to be announced in the frag zero? Does it have to be announced in other frags? > 9. MT SPF Computation As a result of previous discussion, a decision was made that there would be no provisioning for interworking/transition between the regular IS-IS for IPv4 and IPv6 and the MT#0 default topology. This is fine, on the other hand, given that there's no safeguard against someone deploying them in a mixed environment, do you guys think we could at least have a warning by SPF when it sees TLVs of both types announced by nodes? |
|
2005-09-21
|
12 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
|
2005-09-08
|
12 | Michelle Cotton | IANA Last Call Comments: NO IANA Considerations section We understand this document to have NO IANA Actions. |
|
2005-09-07
|
12 | Amy Vezza | Last call sent |
|
2005-09-07
|
12 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2005-09-07
|
12 | Alex Zinin | AD-review comments: > 10. LSP Flooding > > An implementation MAY have the option to use additional MT > information in the LSP … AD-review comments: > 10. LSP Flooding > > An implementation MAY have the option to use additional MT > information in the LSP and on the adjacency to reduce some of the > unnecessary LSP flooding over the point-to-point links. If a > receiving interface and an outgoing interface don't share any > common MT capability, the implementation MAY have the option not to > flood this LSP out on that interface. Since the fragment zero LSP > contains the MTID, the MT capability of any LSP can be identified. > If the LSP and the adjacencies of an outgoing interface do not > share any common MT capability, the implementation MAY have the > option not to flood this LSP out on that interface. An > implementation MAY want to have the operators to control those > optimization base on network topology and environment to ensure > the LSP flooding reliability. From what I remember the discussion a long time ago, we explicitly did not want to encourage flooding changes, as risky. Has there been a discussion in the WG about this? If the WG wanted to do that, it seems that more would need to be described than what meets the eye above. If complete specification of the subject is not the goal, I would suggest simply removing the above. > When there is an adjacency MT set change over a point-to-point > link and the adjacency is in UP state, both sides SHOULD force an > exchange of one set of CSNPs over that link. Should this be a "MUST" instead? I.e., is there a case where NOT doing this is OK? > 11.1. Multi-Topology TLV ... > This MT TLV can advertise up to 127 MTs and it can occur multiple > times if needed within IIHs and LSP fragment zero. The result MT Does it HAVE to be announced in the frag zero? Does it have to be announced in other frags? > 9. MT SPF Computation As a result of previous discussion, a decision was made that there would be no provisioning for interworking/transition between the regular IS-IS for IPv4 and IPv6 and the MT#0 default topology. This is fine, on the other hand, given that there's no safeguard against someone deploying them in a mixed environment, do you guys think we could at least have a warning by SPF when it sees TLVs of both types announced by nodes? |
|
2005-09-06
|
12 | Alex Zinin | Last Call was requested by Alex Zinin |
|
2005-09-06
|
12 | Alex Zinin | State Changes to Last Call Requested from Publication Requested by Alex Zinin |
|
2005-09-06
|
12 | (System) | Ballot writeup text was added |
|
2005-09-06
|
12 | (System) | Last call text was added |
|
2005-09-06
|
12 | (System) | Ballot approval text was added |
|
2005-07-18
|
12 | Bill Fenner | State Change Notice email list have been change to dward@cisco.com, chopps@rawdofmt.org from <tli@procket.com>, <prz@xebeo.com> |
|
2005-07-13
|
12 | Dinara Suleymanova | State Changes to Publication Requested from AD is watching::AD Followup by Dinara Suleymanova |
|
2005-07-13
|
12 | Dinara Suleymanova | Intended Status has been changed to Proposed Standard from Informational |
|
2005-05-09
|
10 | (System) | New version available: draft-ietf-isis-wg-multi-topology-10.txt |
|
2005-03-23
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2005-03-23
|
09 | (System) | New version available: draft-ietf-isis-wg-multi-topology-09.txt |
|
2005-03-18
|
08 | (System) | New version available: draft-ietf-isis-wg-multi-topology-08.txt |
|
2004-06-25
|
07 | (System) | New version available: draft-ietf-isis-wg-multi-topology-07.txt |
|
2003-05-08
|
12 | Alex Zinin | Marking it back to the WG, which is where this doc really is. |
|
2003-05-08
|
12 | Alex Zinin | State Changes to AD is watching :: Revised ID Needed from AD Evaluation :: Revised ID Needed by Zinin, Alex |
|
2003-03-30
|
12 | Alex Zinin | A discussion with Kay in SF indicated that additional work is needed on the draft. Authors will follow up with Kay. |
|
2003-03-26
|
06 | (System) | New version available: draft-ietf-isis-wg-multi-topology-06.txt |
|
2003-03-11
|
12 | Alex Zinin | Still some issues found in the doc. New ver coming. |
|
2003-03-11
|
12 | Alex Zinin | State Changes to AD Evaluation :: Revised ID Needed from AD Evaluation by Zinin, Alex |
|
2003-02-05
|
12 | Alex Zinin | State Changes to AD Evaluation from AD Evaluation :: Revised ID Needed by Zinin, Alex |
|
2002-11-08
|
12 | Alex Zinin | State Changes to AD Evaluation :: Revised ID Needed from AD Evaluation :: External Party by Zinin, Alex |
|
2002-10-02
|
05 | (System) | New version available: draft-ietf-isis-wg-multi-topology-05.txt |
|
2002-08-16
|
12 | Alex Zinin | responsible has been changed to Working Group from Area Directors |
|
2002-07-03
|
04 | (System) | New version available: draft-ietf-isis-wg-multi-topology-04.txt |
|
2002-05-01
|
12 | Alex Zinin | Not ready yet: a number of technical and editorial comments. See https://irg.attlabs.net/bugzilla/show_bug.cgi?id=56 for more info. |
|
2002-05-01
|
12 | Alex Zinin | State Changes to New Version Needed (WG/Author) from AD Evaluation … State Changes to New Version Needed (WG/Author) from AD Evaluation by Alex Zinin |
|
2002-04-09
|
03 | (System) | New version available: draft-ietf-isis-wg-multi-topology-03.txt |
|
2002-04-04
|
12 | Alex Zinin | Intended Status has been changed to Informational from None |
|
2002-04-04
|
12 | Alex Zinin | Completed WG LC per WG chairs. Authors will submit a new version with minor comments soon. Starting AD review now. |
|
2002-04-04
|
12 | Alex Zinin | Draft Added by Alex Zinin |
|
2002-01-28
|
02 | (System) | New version available: draft-ietf-isis-wg-multi-topology-02.txt |
|
2001-10-19
|
01 | (System) | New version available: draft-ietf-isis-wg-multi-topology-01.txt |
|
2001-02-27
|
00 | (System) | New version available: draft-ietf-isis-wg-multi-topology-00.txt |