Subject: RE: [Isis-wg] ID status ?

From: DAUVERGNE Emmanuel FTRD/DAC/ISS <[email-masked]>
Date: Wed, 26 Apr 2000 18:51:44 +0200

Ok, thanks a lot for this explanation. Fine for me!
Manu

-----Message d'origine-----
De: Henk Smit [mailto:[email-masked]]
Date: mercredi 26 avril 2000 13:24
À: [email-masked]
Cc: [email-masked]
Objet: Re: [Isis-wg] ID status ?

> Actually, I was first concerned with the up/down bit encoding : - in
> draft-ietf-domain-wide-02, it is suggested to encode it in the
> classical TLVs (128 and 130) on the high-order bit reserved of the
> default metric. (And the 4-byte metrics field remain a structured
> field).

  The reason for this is that some customers wanted to have L2->L1
 route-leaking in the older TLVs, and preferably in a way where you
 only need to upgrade the L1L2 routers. With this hack of using the
 reserved bit in existing TLVs 128 and 130, older implementations
 will just ignore the up/down bit.

> rather than, - in draft-ietf-isis-traffic-01, it is suggested to
> encode it in the extended TLVs, where it is encoded in the control
> information field. (And the 4-byte metric is a flat field)

  This is a cleaner way. The up/down bit has nothing to do with the
metrics.
 So why make it part of it. We have two unused bits in the
prefix-lenght
 field, so we could save a byte for each IP prefix by using one of
these
 two unused bits as the up/down bit. For the other bit we found
another
 use: indicator whether there are sub-TLVs present.

> I was confused about this difference : why not using the same
> high-order bit in the 4-byte metric? (which would leave 31-bit for
> the metric value)

  Because metric and up/down bit have nothing to do with each other.
 And why make the metric wider, and then start nibbling bits off of
 it again. Yes, we could have done it that way, but we didn't. Also
 note that draft-ietf-isis-traffic-01.txt is older than 
 draft-ietf-domain-wide-02.txt. And draft-ietf-isis-traffic-01.txt is
 in use in the Internet today, while I don't know of any ISPs (or
 enterprise networks) that use draft-ietf-domain-wide-02.txt today.

> I was also confused about the extended IS reachibility TLV which
> default-metric is "only" 3-byte long (and not 4-byte long). 

  That was my idea.
 One of the problems with the TLVs in 10589 and rfc1195 is that the
 metrics between areas (or rather between L1 and L2) are not very
 useful. Link metrics are 1-63, which creates some limitations for
 people designing networks. But the overall result is a little less bad,
 as the path inside an area or inside the L2 backbone can be up to 1023.
 However, if your L1 path has a cost over 63, that cost can not be
 advertised, it has to be rounded down to 63.
  The problem is the fact that the added cost of the links can be way
 bigger than what you can advertise in a TLV 128 or 130. We wanted to
 prevent that from happening. So the link cost can be 2^24 at most, while
 the advertised total path cost can be 2^32. That way you can have 256
 links with the worst cost in your network, and still maintain the
 path cost when advertising between L1 and L2. And the risk of overflowing
 a ulong of 4 bytes in your implementation is reduced as well.

    Hope this helps,

            henk.

> Thanks for your time
> Manu
> 
> 
> 
>  draft-ietf-isis-traffic-01.txt gives you new TLVs to advertise links
>  and IP prefixes, and those new TLVs have more bits for metrics. I know
>  of at least two inter-operable implementations that are use in ISP
>  backbones today.
> 
>     Hope this helps,
> 
>        Henk.
>  
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
> 

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