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

From: Naiming Shen <[email-masked]>
Date: Sat, 02 Apr 2005 21:46:09 -0800

Dave & Chris,

Can you issue a LC on the draft?

Just want to add here the reasons of the change in the latest
version I mentioned below: on a LAN, if an interface is
configured of running ISIS level-1-2, there is a possibility
that the MT set in L1 IIH is different from the MT set in L2 IIH,
thus it's possible to have two routers on the LAN form different
MT set of adjacency between the L1 and L2.

For example, R1 advertises MT a and MT b in both L1 and L2 IIHs,
but R2 advertises MT a in L1 IIHs, MT a and MT b in L2 IIHs. It
forms a L1/L2 boundary for MT b, but not for MT a.

 From spec point of view, this is nothing wrong. Since each MT
carries it's own ATT bit and each MT calculates it's own
routes, there is no need to make the L1/L2 alignment for all
the MTs. Thus we removed the sentence "boundaries between levels
will be the same for all MTs." in the latest version of the
draft. Thanks to Les who raised this issue.

Although I don't see any reason to make the boundaries differently
for the MTs, as far as I know of, none of the current
implementations allows users configuring MT set differently
for the two levels. But it's an implementation and configuration
choice.

thanks.
- Naiming

Naiming Shen wrote:
> 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
> 
> [email-masked] wrote:
> 
>> 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 
>>
>>
> 
> ------------------------------------------------------------------------
> 
> *** 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

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg