Subject: [Isis-wg] M-ISIS

From: Brian Edwards <[email-masked]>
Date: Fri, 16 Mar 2001 16:58:15 -0800

Instead of specifying reserved MT ID #'s in the M-ISIS draft; why not use
the Address Families defined in RFC1700 like MBGP? I mentioned this to
Nischal and he thinks it is a good idea, so I am sending it to the working
group for comments.

-Brian
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Micah Bartell <[email-masked]>
Date: Mon, 19 Mar 2001 12:30:34 -0600

Isn't the idea of this draft to be a generic model for providing multiple topologies in the same AFI?

I am also concerned about the AFI grouping that is done within this proposal.  We take multiple AFI's and include them in a single TLV....I think it may worthwhile to consider the grouping a bit closer.

For example:

AFI = IPv4
    Sub-AFI = Unicast
    Sub-AFI = Multicast
    Sub-AFI = VPN

AFI = IPv6
    Sub-AFI = Unicast
    Sub-AFI = Multicast
    Sub-AFI = VPN

AFI = CLNS

(Inband Management Network is a member of VPN Sub-AFI)

This draft is taking all of the IPvX AFI's and Sub-AFI's and just mixing them all together in a single TLV.  IS-IS is an integrated protocol, we do not need to integrate it all at the TLV level again.  I would say we have plenty of TLV numbers available to cover about the next 50-75 protocols developed.  If we can resolve the number of fragments limitation, we should be fine to carry all of this TE information.  (How long before our LSPs are 90% TE info, and 10% routing info?)

It makes sense to have the IPv4 TLV (135) and the IPv6 (236) be the primary TLV for their respective AFI, and have Sub-AFI information contained within.

This draft does not remove the need for TLV22, but adds another TLV222, which would contain redundant information.  The same holds true for TLV135 and TLV235.  In fact, how many copies of the same link or prefix would we carry potentiallly?  This would cause a fair amount of LSP Bloat, IMHO.

If your goal is to create multiple topologies for IPv4 and IPv6, then create them on AFI boundaries.  Using the Sub-AFI as the boundary removes the ability to leverage common information across that AFI.  But a generic catch-all for all AFI's is not the right method.  

It can be argued that TLV 135 is going to become too bloated.  Maybe TLV 135 should be used primarily to carry TE information, allowing for a separate TLV that is routing specific.

Take your TLV 235 for instance.  Make this IPv4 specific.  Then we have the following sub-tlvs:

       sub-TLV 1: Unicast       Length: 4    Value: Metric
       sub-TLV 2: Multicast     Length: 4    Value: Metric
       sub-TLV 3: VPN Route     Length: 8    Value: VPN ID<4> Metric<4>

Now we take TLV 236 and relegate that to TE Information and the standard topology.  We create TLV 237 for our IPv6 MT TLV, with the following sub-TLV's.

       sub-TLV 1: Unicast       Length: 4    Value: Metric
       sub-TLV 2: Multicast     Length: 4    Value: Metric
       sub-TLV 3: VPN Route     Length: 8    Value: VPN ID<4> Metric<4>

Now we take a look at TLV22.  This is going to have to carry our TE information and the default metric.  Now let's assume that we wish to carry multiple topologies.  So we create TLV 222 and TLV 223.  We now have our MT Extended IS Reachability TLV's.  One for IPv4 and one for IPv6.  Our sub-TLVs would be as follows:

       sub-TLV 1: Unicast       Length: 4    Value: Metric
       sub-TLV 2: Multicast     Length: 4    Value: Metric
       sub-TLV 3: VPN Route     Length: 8    Value: VPN ID<4> Metric<4>

If all of the topologies are congruent, you don't need to include a sub-TLV and you just default to the metric in TLV 22.  In fact in all of the *new* TLV's mentioned here, the Unicast sub-TLV is optional, because that information is still carried in the main TLV.

Obviously the formatting of these TLV's is a bit different, because in the standard TLV's you would not need a sub-TLV for unicast due to the default metric.  But since these MT TLVs are in addition to the main TLV, the unicast metric is optional in the MT TLV.

More or less this is just off the top of my head, so if this is based off an incorrect understanding about how the MT draft works....

/mpb

--
Micah Bartell, CCIE #5069			[email-masked]
Network Consulting Engineer   			Phone: 469.255.1806
SP-Advanced Network Services			Cisco Systems, Inc		
--
The Network Works, No Excuses
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Wed, 21 Mar 2001 00:39:49 -0800

I think M-ISIS is very different from MBGP. This is not meant to
"transport" AFI and sub-AFI routes as the case in MBGP. When we proposed
the reserved number and labelled them as "IPv6" or "multicast", it does
not mean inside those TLVs, we will have IPv6 routes, or 224.x.x.x routes.
They are still IPv4 unicast routes. Those routes are just "belong" to the
IGP topologies we designate them for the use of IPv6 or of multicast.
An example comes to mind will be UUcast, which is a seperate topology
from regular IP unicast backbones and of course runs it's own IGP. Even
though the purpose of that network is for multicast business, but the IGP
is no different from the IGPs running in unicast IP backbones.

Besides it uses up two more bytes than the MT ID# scheme, it will also
casue confusing since the AFI or sub-AFI don't really have their true
meaning. While the other useful things as In-Band management, special
QoS networks may not be defined in the rfc1700. I would say just keep
the current draft number scheme.

thanks.

 ]
 ]Instead of specifying reserved MT ID #'s in the M-ISIS draft; why not use
 ]the Address Families defined in RFC1700 like MBGP? I mentioned this to
 ]Nischal and he thinks it is a good idea, so I am sending it to the working
 ]group for comments.
 ]
 ]-Brian
 ]_______________________________________________
 ]Isis-wg mailing list  -  [email-masked]
 ]http://external.juniper.net/mailman/listinfo/isis-wg

- Naiming

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Mar 2001 09:24:50 -0800

>> not mean inside those TLVs, we will have IPv6 routes, or 224.x.x.x routes.

    Naiming, you seem to be implying MBGP carries 224.x.x.x routes. This is
    certainly not true. If that wasn't what you intended, ignore this message.

Dino

---

From: Naiming Shen <[email-masked]>
Date: Thu, 22 Mar 2001 07:19:27 -0800

]>> I think M-ISIS is very different from MBGP. This is not meant to
 ]>> "transport" AFI and sub-AFI routes as the case in MBGP. When we proposed
 ]>> the reserved number and labelled them as "IPv6" or "multicast", it does
 ]>> not mean inside those TLVs, we will have IPv6 routes, or 224.x.x.x routes.
 ]
 ]    Naiming, you seem to be implying MBGP carries 224.x.x.x routes. This is
 ]    certainly not true. If that wasn't what you intended, ignore this message
.

      Dino. Thanks pointing this out. My mistake. I had a wrong impression
      that MBGP were able to carry both types of routes. MBGP made it's
      mistake on this(using the AFIs), that's why so confusing:-)

      And I still mentain the rest part of my argument. But if we are
      going to use the AFIs, we probably need a bit to indicate the value
      is or not from the AFIs of rfc1700, since some of the applications
      has little to do with address family; or make the AFI when it's 0,
      the sub-AFI portion is our M-ISIS definition of topologies.

      Thanks.

 ]
 ]Dino
 ]
 ]     

- Naiming