Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-09.txt

From: [email-masked]
Date: Wed, 23 Mar 2005 16:12:15 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IS-IS for IP Internets Working Group of the IETF.

	Title		: M-ISIS: Multi Topology (MT)Routing in IS-IS
	Author(s)	: T. Przygienda, et al.
	Filename	: draft-ietf-isis-wg-multi-topology-09.txt
	Pages		: 12
	Date		: 2005-3-23
	
This draft describes an optional mechanism within ISIS used today
by many ISPs for IGP routing within their clouds. This draft
describes how to run within a single ISIS domain a set of
independent IP topologies that we call Multi-Topologies (MTs).
This MT extension can be used for variety of purposes such as an
in-band management network ``on top'' of the original IGP topology,
maintain separate IGP routing domains for isolated multicast or
IPv6 islands within the backbone, or force a subset of an address
space to follow a different topology.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-isis-wg-multi-topology-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Wed, 23 Mar 2005 13:46:02 -0800

Hi working-group,

We have updated the M-ISIS draft, the main change is to remove
the wording of aligning isis L1/L2 boundary for all topologies.
A diff is attached, please send comments if you have any.

thanks.
- Naiming

> http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-09.txt
*** draft-ietf-isis-wg-multi-topology-08.txt	Wed Mar 16 19:15:21 2005
--- draft-ietf-isis-wg-multi-topology-09.txt	Fri Mar 18 11:36:38 2005
***************
*** 1,9 ****
  
  Network Working Group                             Tony Przygienda (Xebeo)
  Internet Draft                                    Naiming Shen    (Cisco)
! <draft-ietf-isis-wg-multi-topology-08.txt>        Nischal Sheth (Juniper)
  March 2005
  Expires: September 2005

                M-ISIS: Multi Topology (MT) Routing in IS-IS
--- 1,9 ----
  
  Network Working Group                             Tony Przygienda (Xebeo)
  Internet Draft                                    Naiming Shen    (Cisco)
! <draft-ietf-isis-wg-multi-topology-09.txt>        Nischal Sheth (Juniper)
  March 2005
  Expires: September 2005

                M-ISIS: Multi Topology (MT) Routing in IS-IS
*************** Internet Draft                   M-ISIS 
*** 82,94 ****
      advertise it in the new TLV. Thus not including such a TLV in the
      IIH implies MT ID #0 capability only. Through this exchange of MT
      capabilities, a router is able to advertise the IS TLVs in LSPs
      with common MT set over those adjacencies.
  
-     As a simplifying side-effect, boundaries between levels will be the
-     same for all MTs.
- 
      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.
  
--- 82,91 ----
*************** Internet Draft                   M-ISIS 
*** 96,110 ****
  
      Adjacencies on point-to-point interfaces are formed as usual with
      ISIS routers not implementing MT extensions.  If local router does
      not participate in certain MTs, it will not advertise those MTIDs
      in it's IIHs and thus will not include that neighbor within it's
!     topology based LSPs.  On the other hand, if a MTID is not
!     detected in remote side's IIHs, the local router MUST NOT include
!     that neighbor within it's MT LSPs. The local router SHOULD NOT form
!     adjacency if they don't have at least one common MT set over the
!     interface.
  
  5.2.  Forming Adjacencies on Broadcast Interfaces
  
      On a LAN, all the routers on the LAN which implement the MT
      extension MAY advertise their MT capability TLV in their IIHs.
--- 93,106 ----
  
      Adjacencies on point-to-point interfaces are formed as usual with
      ISIS routers not implementing MT extensions.  If local router does
      not participate in certain MTs, it will not advertise those MTIDs
      in it's IIHs and thus will not include that neighbor within it's
!     LSPs. On the other hand, if a MTID is not detected in remote
!     side's IIHs, the local router MUST NOT include that neighbor
!     within it's LSPs.  The local router SHOULD NOT form adjacency if
!     they don't have at least one common MT set over the interface.
  
  5.2.  Forming Adjacencies on Broadcast Interfaces
  
      On a LAN, all the routers on the LAN which implement the MT
      extension MAY advertise their MT capability TLV in their IIHs.
*************** Internet Draft                   M-ISIS 
*** 153,166 ****
      pseudo-node LSP construction.

  7.  MTs and Overload, Partition and Attached Bits
  
!     As stated earlier, all MTs share the same set of L1-L2 boundaries
!     and NETs.  However, a router could for each of the MTs become
!     potentially partitioned, overloaded and attached independently.
!     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.
  
      Attached bit and overload bit are part of the MT TLV being
      distributed within a node's LSP fragment zero. Since each adjacency
--- 149,161 ----
      pseudo-node LSP construction.

  7.  MTs and Overload, Partition and Attached Bits
  
!     A router could for each of the MTs become potentially
!     partitioned, overloaded and attached independently.  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.
  
      Attached bit and overload bit are part of the MT TLV being
      distributed within a node's LSP fragment zero. Since each adjacency
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg