Subject: [Isis-wg] IS-IS Extensions for Traffic Engineering

From: Grant Mills <[email-masked]>
Date: Fri, 03 Sep 1999 12:58:45 +0100

A quick query regarding draft-ietf-isis-traffic-01.

In RFC 1195 we implement the Internal and External IP reachibilty TLVs in LSPs for ISIS routes (Internal), Non ISIS routes
(External), for example (depending on route propagation policies). In addition the TLV allows the specification of metrics as being
internal or external as well.

In the traffic engineering draft a single TLV (135) is used to hold IP reachibility information. However I do not see any bit field
for specifying External/Internal for these routes. The internal/external bit for metrics I can live without but how do I map the old
scheme to the daft proposal? Is there an unspecified Sub-TLV for doing this? Is the idea to go from old world Level1 Internal,
Level2 Internal/External routes to just flat Level1 and Level2 routes?

Regards,

Grant.

-- 
______________________________________________________________________

Grant Mills,                            Tel:   +44 (1252) 360013
Lucent Technologies Inc.,       __      Fax:   +44 (1252) 360077
InterNetworking Systems UK,   //  \\
Suites 11/12, First Base,     ||  ||    URL:   http://www.lucent.com
Beacontree Plaza,             \\__//           
Gillette Way,                           Email: 
Reading, Berks, RG2 0BS,                     [email-masked]
United Kingdom.                              [email-masked]
______________________________________________________________________

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

---

From: Grant Mills <[email-masked]>
Date: Fri, 03 Sep 1999 13:14:27 +0100

Ooops please excuse the "daft" typo

>... but how do I map the old
>scheme to the daft proposal?

---

From: Henk Smit <[email-masked]>
Date: Fri, 3 Sep 1999 14:15:14 +0200 (MET DST)

> In RFC 1195 we implement the Internal and External IP reachibilty
> TLVs in LSPs for ISIS routes (Internal), Non ISIS routes (External),
> for example (depending on route propagation policies). In addition
> the TLV allows the specification of metrics as being internal or
> external as well.
> 
> In the traffic engineering draft a single TLV (135) is used to hold
> IP reachibility information. However I do not see any bit field for
> specifying External/Internal for these routes. The internal/external
> bit for metrics I can live without

  Thank you.
 One of the reasons that we didn't put this in our draft is that
 the I/E metric bit is implemented wrongly in our IOS implementation.
 No customer ever really complained about it. So it seems the I/E
 metric bit is not used at all. At least not by our customers.

> but how do I map the old scheme
> to the daft proposal? Is there an unspecified Sub-TLV for doing
> this? Is the idea to go from old world Level1 Internal, Level2
> Internal/External routes to just flat Level1 and Level2 routes?

  Yes.
 Please note that in RFC1195, paragraph 3.10.2, 2c), there is a note,
 saying:

         NOTE: Internal routes (routes to destinations announced
         in the "IP Internal Reachability Information" field),
         and external routes using internal metrics (routes to
         destinations announced in the "IP External Reachability
         Information" field, with a metric of type "internal")
         are treated identically for the purpose of the order of
         preference of routes, and the Dijkstra calculation.

  So why do you want to see the difference between internal prefixes
 and external prefixes ? It doesn't matter for route selection.
 So I assume you want to use this to prevent "redistribution
 feedback" when doing mutual redistributing with another IGP
 at two or more places ? Or do you have another reason ?

  draft-ietf-isis-traffic-01 allows us to specify sub-TLVs for
 IP prefixes. One thing we plan to do is define a sub-TLV to
 tag or color IP prefixes. Those tags/colors can be used to
 distinquish between internal and external routes. Then you
 can use those tags/colors to control redistribution. We could
 even define one or more "well-known colors", like well-known
 BGP communities like no-advertise, etc.

    Hope this helps,

             Henk.

---

From: Grant Mills <[email-masked]>
Date: Fri, 03 Sep 1999 13:58:56 +0100

Henk,

thanks for the reply.

>  metric bit is not used at all. At least not by our customers.

I'm glad you said that. ;-) We have a Cisco metrics mode which we can turn on if we wish to interoperate properly with Cisco ISIS.
And turn it off to work the Digital/ISO way. ;-)

>  at two or more places ? Or do you have another reason ?

True route selection is not the issue. As you say it is useful when injecting foreign routes from another IGP, e.g. OSPF, BGP, etc
and have those routes tagged at a different route priority or effected by targeted route policies than the ISIS routes. 
 
>  BGP communities like no-advertise, etc.

When do you plan to publish the sub-TLV options. I assume this sub-TLV is similar to the one that appears in the extended IS
reachability TLV?

Cheers,

Grant.

---

From: Henk Smit <[email-masked]>
Date: Fri, 3 Sep 1999 16:20:51 +0200 (MET DST)

> When do you plan to publish the sub-TLV options. I assume this
> sub-TLV is similar to the one that appears in the extended IS
> reachability TLV?

  The idea was that draft-ietf-isis-traffic-01 only defines the
 things that are needed to do traffic engineering (with MPLS).
 That would be the new IS neighbor TLV that has the ability to
 do sub-TLVs. Plus the sub-TLVs that are needed for TE. While
 we were at this, we wanted to extend the metric space. To make
 sure the wider metric space was usable between areas, we also
 needed to define a new IP prefix TLV. This is where we stopped
 with our new additions.
  Anything else new that is not directly related to TE should
 go into a separate drafts. The downside would be that we end up
 with many new RFCs and drafts. The upside would be that we can
 continue moving the older drafts through the standards track
 while developing new technologies.
 
  If you want to implement a new sub-TLV for route tagging/coloring,
 feel free to document your implementation in a new draft. Otherwise
 it would probably take a few months before I, or someone else at
 cisco, would implement and document this.

     Cheers,

             henk.