Skip to main content

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