From prz@redback.com Sun Mar 3 16:46:43 2002 From: prz@redback.com (Tony Przygienda) Date: Sun, 03 Mar 2002 08:46:43 -0800 Subject: [Isis-wg] last call on draft draft-ietf-isis-3way-05 ... Message-ID: <3C825373.D3791744@redback.com> We are starting last call on draft-ietf-isis-3way-05 (again, version was updated). The last call will end 3/19/02 thanks -- tony From prz@redback.com Sun Mar 3 16:51:42 2002 From: prz@redback.com (Tony Przygienda) Date: Sun, 03 Mar 2002 08:51:42 -0800 Subject: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... Message-ID: <3C82549D.E348115E@redback.com> We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call will end 3/19/02 thanks -- tony From jparker@axiowave.com Wed Mar 6 15:05:07 2002 From: jparker@axiowave.com (Jeff Parker) Date: Wed, 6 Mar 2002 10:05:07 -0500 Subject: [Isis-wg] reg. ISO10589 Message-ID: > From: Bhama [mailto:bhama.venugopal@wipro.com] > Sent: Thursday, February 21, 2002 6:20 AM > To: isis-wg@juniper.net > Cc: Anitha > Subject: [Isis-wg] reg. ISO10589 > > Hi! > As per the ISO10589 doc.,the definition for 'circuit' is the subset of local routing information pertinent to a single local SNPA and for 'adjacency' is the portion of routing information which pertains to the reachability of a single neighbor ES or IS over a single circuit. > This means they are basically a set of information base. > Adjacency has been mentioned as {circuit,neighbor} pair, so we assume that the Adjacency Database has these 2 entries. > Can you please tell us wot a Circuit Database will contain?And kindly verify our assumption regarding Adjacency Database.... > > Bhama & Anitha There is a MIB that describes the information an SNMP manager might expect to find. You will find a version of that at http://ietf.org/internet-drafts/draft-ietf-isis-wg-mib-07.txt What an implementation keeps is determined by what the implementor needs to store. Some of that information might lie in the ISIS system, and some might lie in an interface specific database. - jeff parker - axiowave networks From aravindravikumar@yahoo.com Sat Mar 9 07:59:11 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Fri, 8 Mar 2002 23:59:11 -0800 (PST) Subject: [Isis-wg] Route Addition to different logical subnet Message-ID: <20020309075911.9876.qmail@web11208.mail.yahoo.com> --0-1413420458-1015660751=:9372 Content-Type: text/plain; charset=us-ascii Hi, In ISIS, Routers can establish adjacency independent of the logical subnets in which they are,if they share the same physical network. How can we add a route to the neighboring router's subnet [which is different] and what should the gateway be for such a route? For a destination for which the next hop is an adjacent router on another logical subnet, how can we add the route ? More specifically, what should be the gateway for such destinations ? Please help me, Regards. --------------------------------- Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! --0-1413420458-1015660751=:9372 Content-Type: text/html; charset=us-ascii
Hi,
 
In ISIS, Routers can establish adjacency independent of the logical subnets in which they are,
if they share the same physical network.
 
How can we add a route to the neighboring router's subnet [which is different] and
what should the gateway be for such a route?
 
For a destination for which the next hop is an adjacent router on another logical subnet,
how can we add the route ?
 
More specifically, what should be the gateway for such destinations ?
 
 
Please help me,
 
Regards.



Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email! --0-1413420458-1015660751=:9372-- From hannes@juniper.net Mon Mar 4 07:28:09 2002 From: hannes@juniper.net (Hannes Gredler) Date: Mon, 4 Mar 2002 08:28:09 +0100 Subject: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-Reply-To: <3C82549D.E348115E@redback.com>; from prz@redback.com on Sun, Mar 03, 2002 at 08:51:42AM -0800 References: <3C82549D.E348115E@redback.com> Message-ID: <20020304082809.A30187@juniper.net> On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call | will end 3/19/02 tony, there is still a typo in 8.5 --- 8.5. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for In-Band Management Purposes. - MT ID #2: Reserved for IPv6 Routing Topology. - MT ID #3: Reserved for Multicast Routing Topology. - MT ID #4-#8190: Reserved for IETF consensus. - MT ID #8191: Reserved for development, experimental and proprietary features. --- in the TLV there are only 12 bits reserved for the ID purpose so i guess it should be --- - MT ID #4-#4094: Reserved for IETF consensus. - MT ID #4095: Reserved for development, experimental and proprietary features. --- /hannes From hannes@juniper.net Mon Mar 4 07:28:09 2002 From: hannes@juniper.net (Hannes Gredler) Date: Mon, 4 Mar 2002 08:28:09 +0100 Subject: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-Reply-To: <3C82549D.E348115E@redback.com>; from prz@redback.com on Sun, Mar 03, 2002 at 08:51:42AM -0800 References: <3C82549D.E348115E@redback.com> Message-ID: <20020304082809.A30187@juniper.net> On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call | will end 3/19/02 tony, there is still a typo in 8.5 --- 8.5. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for In-Band Management Purposes. - MT ID #2: Reserved for IPv6 Routing Topology. - MT ID #3: Reserved for Multicast Routing Topology. - MT ID #4-#8190: Reserved for IETF consensus. - MT ID #8191: Reserved for development, experimental and proprietary features. --- in the TLV there are only 12 bits reserved for the ID purpose so i guess it should be --- - MT ID #4-#4094: Reserved for IETF consensus. - MT ID #4095: Reserved for development, experimental and proprietary features. --- /hannes From hannes@juniper.net Mon Mar 4 07:28:09 2002 From: hannes@juniper.net (Hannes Gredler) Date: Mon, 4 Mar 2002 08:28:09 +0100 Subject: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-Reply-To: <3C82549D.E348115E@redback.com>; from prz@redback.com on Sun, Mar 03, 2002 at 08:51:42AM -0800 References: <3C82549D.E348115E@redback.com> Message-ID: <20020304082809.A30187@juniper.net> On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call | will end 3/19/02 tony, there is still a typo in 8.5 --- 8.5. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for In-Band Management Purposes. - MT ID #2: Reserved for IPv6 Routing Topology. - MT ID #3: Reserved for Multicast Routing Topology. - MT ID #4-#8190: Reserved for IETF consensus. - MT ID #8191: Reserved for development, experimental and proprietary features. --- in the TLV there are only 12 bits reserved for the ID purpose so i guess it should be --- - MT ID #4-#4094: Reserved for IETF consensus. - MT ID #4095: Reserved for development, experimental and proprietary features. --- /hannes From hannes@juniper.net Mon Mar 4 07:28:09 2002 From: hannes@juniper.net (Hannes Gredler) Date: Mon, 4 Mar 2002 08:28:09 +0100 Subject: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-Reply-To: <3C82549D.E348115E@redback.com>; from prz@redback.com on Sun, Mar 03, 2002 at 08:51:42AM -0800 References: <3C82549D.E348115E@redback.com> Message-ID: <20020304082809.A30187@juniper.net> On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call | will end 3/19/02 tony, there is still a typo in 8.5 --- 8.5. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for In-Band Management Purposes. - MT ID #2: Reserved for IPv6 Routing Topology. - MT ID #3: Reserved for Multicast Routing Topology. - MT ID #4-#8190: Reserved for IETF consensus. - MT ID #8191: Reserved for development, experimental and proprietary features. --- in the TLV there are only 12 bits reserved for the ID purpose so i guess it should be --- - MT ID #4-#4094: Reserved for IETF consensus. - MT ID #4095: Reserved for development, experimental and proprietary features. --- /hannes From hannes@juniper.net Mon Mar 4 07:28:09 2002 From: hannes@juniper.net (Hannes Gredler) Date: Mon, 4 Mar 2002 08:28:09 +0100 Subject: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-Reply-To: <3C82549D.E348115E@redback.com>; from prz@redback.com on Sun, Mar 03, 2002 at 08:51:42AM -0800 References: <3C82549D.E348115E@redback.com> Message-ID: <20020304082809.A30187@juniper.net> On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The last call | will end 3/19/02 tony, there is still a typo in 8.5 --- 8.5. Reserved MT ID Values Certain MT topologies are assigned to serve pre-determined purposes: - MT ID #0: Equivalent to the ``standard'' topology. - MT ID #1: Reserved for In-Band Management Purposes. - MT ID #2: Reserved for IPv6 Routing Topology. - MT ID #3: Reserved for Multicast Routing Topology. - MT ID #4-#8190: Reserved for IETF consensus. - MT ID #8191: Reserved for development, experimental and proprietary features. --- in the TLV there are only 12 bits reserved for the ID purpose so i guess it should be --- - MT ID #4-#4094: Reserved for IETF consensus. - MT ID #4095: Reserved for development, experimental and proprietary features. --- /hannes From naiming@redback.com Mon Mar 11 22:03:46 2002 From: naiming@redback.com (Naiming Shen) Date: Mon, 11 Mar 2002 14:03:46 -0800 Subject: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-Reply-To: Mail from Hannes Gredler dated Mon, 04 Mar 2002 08:28:09 +0100 <20020304082809.A30187@juniper.net> Message-ID: <20020311220346.685651531D3@prattle.redback.com> Hannes, good catch, i'll change that. thanks. ] On Sun, Mar 03, 2002 at 08:51:42AM -0800, Tony Przygienda wrote: ] | We are starting last call on draft-ietf-isis-wg-multi-topology-02. The las t call ] | will end 3/19/02 ] ] tony, ] ] there is still a typo in 8.5 ] ] --- ] ] 8.5. Reserved MT ID Values ] ] Certain MT topologies are assigned to serve pre-determined purposes: ] ] - MT ID #0: Equivalent to the ``standard'' topology. ] - MT ID #1: Reserved for In-Band Management Purposes. ] - MT ID #2: Reserved for IPv6 Routing Topology. ] - MT ID #3: Reserved for Multicast Routing Topology. ] - MT ID #4-#8190: Reserved for IETF consensus. ] - MT ID #8191: Reserved for development, experimental and ] proprietary features. ] ] --- ] ] in the TLV there are only 12 bits reserved for the ID purpose ] so i guess it should be ] ] ] --- ] - MT ID #4-#4094: Reserved for IETF consensus. ] - MT ID #4095: Reserved for development, experimental and ] proprietary features. ] ] --- ] ] /hannes _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming From leontsinis@hotmail.com Mon Mar 11 22:09:47 2002 From: leontsinis@hotmail.com (Nikos Leontsinis) Date: Mon, 11 Mar 2002 22:09:47 +0000 Subject: [Isis-wg] IS-IS metrics: in search for a sound way Message-ID:
ISO 10589 states in 7.2.2. that the following 4 isis metrics are defined:

1.Default: Each link is given a metric value based on its throughput
2.Delay metric . It measures the transit delay of the circuit. (pretty common-sensical higher value longer delay)
3. Expense metric. It measures the monetary cost of the network's utilsation-higher value larger expense-.(very unclear to me how this is done)

4 Error metric.It measures the residual (êáôÜëïéðï, õðüëïéðï) error probability of the asociated circuit (also unclear but makes sense as a concept).

If you look at the IS-IS  LSP format's analysis i.e. p.638 Doyle, Routing TCP/IP Volume1 you will see that IOS supports
 only the default metric (bit 4) Bits 5-7  which are delay, expense & error are not supported and they will always be zero.
This is a major IOS caveat as bandwidth alone is by no means sufficient to account for metric assignment.
However, looking at the LSP format is not the only way to reach the above conclusion.
These 3 factors would be brought into consideration on a discussion on how to tune isis metrics by someone
who was building his/her argumentation on pure operational experience. 
The main objective behind metric tuning is network performance improvement. Performance is an umbrella
which incorporates the configuration and measurement of distinct areas. It is not clear to me how the ietf engineers
calculate delay, expense and error as part of their (non Cisco supported) isis impl! ementation. What it is indubitable is that
availability, response time, accuracy and utilisation will be key indicators for the performance of a network and these are the
ones that should also be added as key decision parameters in the metric assignment process.

        In conclusion, I am looking for a good way to measeure metrics either based on bandwidth or geographical distance eventhough I don't think there is one formula which can be used as a panacea. My feeling is that this is a context based approach. One can come to an agreement on what issues to consider but the
decision should be taken on the individual links rather than make it matter of correct application of a specific formula.
For a more detailed analysis on these 4 areas of performance: availability, response time, accuracy and utilisation see
Performance and Fault Management  Della Magiora, et al p.74-85.

Best,

Nikos Leontsinis

 
 
 


Join the world’s largest e-mail service with MSN Hotmail. Click Here
From Alex Zinin Tue Mar 12 02:30:10 2002 From: Alex Zinin (Alex Zinin) Date: Mon, 11 Mar 2002 18:30:10 -0800 Subject: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-Reply-To: <20020311220346.685651531D3@prattle.redback.com> References: <20020311220346.685651531D3@prattle.redback.com> Message-ID: <13891121285.20020311183010@nexsi.com> Naiming, Some editorial comments to save your time: - remove citations from the Abstract - put a standard boilerplate for MUST/MAY/SHOULD you're using. - Fix the "references" section. You need RFC and STD (if applicable) numbers there. See if you can split normative and informative refs. BTW, do we have interoperable implementations for this? -- Alex Zinin Monday, March 11, 2002, 2:03:46 PM, Naiming Shen wrote: > Hannes, > good catch, i'll change that. thanks. From naiming@redback.com Tue Mar 12 03:23:37 2002 From: naiming@redback.com (Naiming Shen) Date: Mon, 11 Mar 2002 19:23:37 -0800 Subject: [Isis-wg] last call on draft draft-ietf-isis-wg-multi-topology-02 ... In-Reply-To: Mail from Alex Zinin dated Mon, 11 Mar 2002 18:30:10 PST <13891121285.20020311183010@nexsi.com> Message-ID: <20020312032337.6E115F2C50@prattle.redback.com> Alex, ] ] Naiming, ] ] Some editorial comments to save your time: ] - remove citations from the Abstract ] - put a standard boilerplate for MUST/MAY/SHOULD ] you're using. ] - Fix the "references" section. You need RFC and ] STD (if applicable) numbers there. See if you ] can split normative and informative refs. will do. ] ] BTW, do we have interoperable implementations for this? i'm only aware of multiple implementations for a while, but not sure if anyone has tested interoperability or not. thanks. ] ] -- ] Alex Zinin ] ] Monday, March 11, 2002, 2:03:46 PM, Naiming Shen wrote: ] ] ] > Hannes, ] ] > good catch, i'll change that. thanks. ] ] - Naiming From aravindravikumar@yahoo.com Thu Mar 14 09:36:02 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Thu, 14 Mar 2002 01:36:02 -0800 (PST) Subject: [Isis-wg] Administratively setting overload bit Message-ID: <20020314093603.38235.qmail@web11203.mail.yahoo.com> --0-862532364-1016098562=:37888 Content-Type: text/plain; charset=us-ascii Hi All, The variable isisSysSetOverload of table isisSysTable (ISIS MIB) can be used to set overload bit administrativly at each level. I am not clear, that if network manager sets this variable to indicate overload condition at a level then do we need to enter waiting state at that level,even if we have enough resources and perform all those actions listed in section 7.3.19 of ISO 10589 for that level. Please help me. Thanks in advance. --------------------------------- Do You Yahoo!? Yahoo! Sports - live college hoops coverage --0-862532364-1016098562=:37888 Content-Type: text/html; charset=us-ascii

Hi All,

            The variable isisSysSetOverload of table isisSysTable (ISIS MIB)

can be used to set overload bit administrativly at each level. I am not clear, that

if network manager sets this variable to indicate overload condition at a level then

do we need to enter waiting state at that level,even if we have enough resources

 and perform all those actions listed in

section 7.3.19 of ISO 10589 for that level.

Please help me. Thanks in advance.

 



Do You Yahoo!?
Yahoo! Sports - live college hoops coverage --0-862532364-1016098562=:37888-- From aravindravikumar@yahoo.com Tue Mar 12 07:06:21 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Mon, 11 Mar 2002 23:06:21 -0800 (PST) Subject: [Isis-wg] doubt regarding administratively setting overload bit Message-ID: <20020312070621.9250.qmail@web11202.mail.yahoo.com> --0-26142839-1015916781=:8978 Content-Type: text/plain; charset=us-ascii Hi All, The variable isisSysSetOverload of table isisSysTable (ISIS MIB) can be used to set overload bit administratively at each level. I am not clear, that if network manager sets this variable to indicate overload condition at a level then do we need to enter waiting state at that level , even if we have proper resources and perform all those actions listed in section 7.3.19 of ISO 10589 for that level. Please help me. Thanks in advance. --------------------------------- Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! --0-26142839-1015916781=:8978 Content-Type: text/html; charset=us-ascii

Hi All,

            The variable isisSysSetOverload of table isisSysTable (ISIS MIB)

can be used to set overload bit administratively at each level. I am not clear, that

if network manager sets this variable to indicate overload condition at a level then

do we need to enter waiting state at that level , even if we have proper resources 

and perform all those actions listed in

section 7.3.19 of ISO 10589 for that level.

Please help me. Thanks in advance.

 



Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email! --0-26142839-1015916781=:8978-- From bneal@broadwing.com Tue Mar 12 16:33:16 2002 From: bneal@broadwing.com (bneal@broadwing.com) Date: Tue, 12 Mar 2002 10:33:16 -0600 Subject: [Isis-wg] IS-IS metrics: in search for a sound way Message-ID: <8E9322ACF085D311918E00805FE6CEE7077A598D@metexch3.ixc-comm.com> Although ISO 10589 defines four different metric fields, I believe the decision process still uses a single scalar metric because IS-IS combines the four fields by simple addition paragraph 7.2.2, note 13. It's up to the network operator to weight these fields according to his own requirements. Point is, you can accomplish pretty much the same thing with a single field--just define which link properties are important to you, weight them according to their relative importance, add up the values and the result is your combined metric, just like IS-IS would have done. +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++ From leontsinis@hotmail.com Tue Mar 12 23:47:55 2002 From: leontsinis@hotmail.com (Nikos Leontsinis) Date: Tue, 12 Mar 2002 23:47:55 +0000 Subject: [Isis-wg] IS-IS metrics: in search for a sound way Message-ID:
Although ISO 10589 defines four different metric fields, I believe the
decision process still uses a single scalar metric because IS-IS combines
the four fields by simple addition paragraph 7.2.2, note 13. It's up to the
network operator to weight these fields according to his own requirements.

No the network operator can only ammend the default cisco metric which is bandwith. The remaining metrics are not supported hence cannot be used what they rather do is to give a hint to the network administrator what to bear in mind when designing his/her network. I was looking for something more coherent  than that as I think metric assinment is by far the most challenging task for the network designer since Cisco together with the remaining implemeters are fairly inefficient in this direction. I am looking for a sound way to measure metrics.

Point is, you can accomplish pretty much the same thing with a single

field--just define which link properties are important to you, weight them
according to their relative importance, add up the values and the result is
your combined metric, just like IS-IS would have done.
+++The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and destroy any copies of this
document.+++


Join the world’s largest e-mail service with MSN Hotmail. Click Here
From bneal@broadwing.com Wed Mar 13 00:53:22 2002 From: bneal@broadwing.com (bneal@broadwing.com) Date: Tue, 12 Mar 2002 18:53:22 -0600 Subject: [Isis-wg] IS-IS metrics: in search for a sound way Message-ID: <8E9322ACF085D311918E00805FE6CEE7077A5997@metexch3.ixc-comm.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CA29.7967F310 Content-Type: text/plain; charset="iso-8859-1" My point is that even if a platform lets you set all four metrics, the SPF computation, as defined by 10589, just adds them up and uses the sum as a single metric. I can only assume that the reason they are broken out separately is for conceptual convenience. (?) A human being can do this just as easily when a platform only supports a single metric, or when using the new-style TLVs that only define one metric. The only real difference is that the actual values of the individual link properties are not reflected in the router's configuration state. As far as a generalized metric-selection schema, I don't think there really is one. How I, as a network operator, assign link metrics will depend on what link properties are interesting to me in my particular situation. For instance, if I can provision bandwidth quickly and have sufficient confidence in my trending and planning efforts, bandwidth isn't interesting to me as an IGP decision input. Delay might be, though, if I have a network of large geographic scope. If I run a regional or metropolitan network, my requirements may be quite different and I would define my metrics accordingly. -----Original Message----- From: Nikos Leontsinis [mailto:leontsinis@hotmail.com] Sent: Tuesday, March 12, 2002 5:48 PM To: Neal, Brad (Broadwing); isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way Although ISO 10589 defines four different metric fields, I believe the decision process still uses a single scalar metric because IS-IS combines the four fields by simple addition paragraph 7.2.2, note 13. It's up to the network operator to weight these fields according to his own requirements. No the network operator can only ammend the default cisco metric which is bandwith. The remaining metrics are not supported hence cannot be used what they rather do is to give a hint to the network administrator what to bear in mind when designing his/her network. I was looking for something more coherent than that as I think metric assinment is by far the most challenging task for the network designer since Cisco together with the remaining implemeters are fairly inefficient in this direction. I am looking for a sound way to measure metrics. Point is, you can accomplish pretty much the same thing with a single field--just define which link properties are important to you, weight them according to their relative importance, add up the values and the result is your combined metric, just like IS-IS would have done. +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++ _____ Join the world's largest e-mail service with MSN Hotmail. Click Here +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++ ------_=_NextPart_001_01C1CA29.7967F310 Content-Type: text/html; charset="iso-8859-1"
My point is that even if a platform lets you set all four metrics, the SPF computation, as defined by 10589, just adds them up and uses the sum as a single metric. I can only assume that the reason they are broken out separately is for conceptual convenience. (?)
 
A human being can do this just as easily when a platform only supports a single metric, or when using the new-style TLVs that only define one metric.  The only real difference is that the actual values of the individual link properties are not reflected in the router's configuration state.
 
As far as a generalized metric-selection schema, I don't think there really is one.  How I, as a network operator, assign link metrics will depend on what link properties are interesting to me in my particular situation.  For instance, if I can provision bandwidth quickly and have sufficient confidence in my trending and planning efforts, bandwidth isn't interesting to me as an IGP decision input.  Delay might be, though, if I have a network of large geographic scope.  If I run a regional or metropolitan network, my requirements may be quite different and I would define my metrics accordingly. 
 

 -----Original Message-----
From: Nikos Leontsinis [mailto:leontsinis@hotmail.com]
Sent: Tuesday, March 12, 2002 5:48 PM
To: Neal, Brad (Broadwing); isis-wg@juniper.net
Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way

Although ISO 10589 defines four different metric fields, I believe the
decision process still uses a single scalar metric because IS-IS combines
the four fields by simple addition paragraph 7.2.2, note 13. It's up to the
network operator to weight these fields according to his own requirements.

No the network operator can only ammend the default cisco metric which is bandwith. The remaining metrics are not supported hence cannot be used what they rather do is to give a hint to the network administrator what to bear in mind when designing his/her network. I was looking for something more coherent  than that as I think metric assinment is by far the most challenging task for the network designer since Cisco together with the remaining implemeters are fairly inefficient in this direction. I am looking for a sound way to measure metrics.

Point is, you can accomplish pretty much the same thing with a single

field--just define which link properties are important to you, weight them
according to their relative importance, add up the values and the result is
your combined metric, just like IS-IS would have done.
+++The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and destroy any copies of this
document.+++


Join the world's largest e-mail service with MSN Hotmail. Click Here

+++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++

------_=_NextPart_001_01C1CA29.7967F310-- From leontsinis@hotmail.com Wed Mar 13 06:34:52 2002 From: leontsinis@hotmail.com (Nikos Leontsinis) Date: Wed, 13 Mar 2002 06:34:52 +0000 Subject: [Isis-wg] IS-IS metrics: in search for a sound way Message-ID:

There must be some documentation about the metric assignment process we just don't know it. This is a topic for a book it should be written for the 3 main routing protocols.

Best Regards,
 Nikos Leontsinis
 
From: bneal@broadwing.com
To: leontsinis@hotmail.com, isis-wg@juniper.net
Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way
Date: Tue, 12 Mar 2002 18:53:22 -0600
MIME-Version: 1.0
Received: from [216.140.57.101] by hotmail.com (3.2) with ESMTP id MHotMailBE57EE23006F4004374ED88C396555F60; Tue, 12 Mar 2002 16:53:56 -0800
Received: by ausmx1.ixc-comm.com with Internet Mail Service (5.5.2653.19)id ; Tue, 12 Mar 2002 18:53:32 -0600
From bneal@broadwing.com Tue, 12 Mar 2002 16:55:15 -0800
Message-ID: <8E9322ACF085D311918E00805FE6CEE7077A5997@metexch3.ixc-comm.com>
X-Mailer: Internet Mail Service (5.5.2653.19)
My point is that even if a platform lets you set all four metrics, the SPF
computation, as defined by 10589, just adds them up and uses the sum as a
single metric. I can only assume that the reason they are broken out
separately is for conceptual convenience. (?)
A human being can do this just as easily when a platform only supports a
single metric, or when using the new-style TLVs that only define one metric.
The only real difference is that the actual values of the individual link
properties are not reflected in the router's configuration state.
As far as a generalized metric-selection schema, I don't think there really
is one. How I, as a network operator, assign link metrics will depend on
what link properties are interesting to me in my particular situation. For
instance, if I can provision bandwidth quickly and have sufficient
confidence in my trending and planning efforts, bandwidth isn't interesting
to me as an IGP decision input. Delay might be, though, if I have a network
of large geographic scope. If I run a regional or metropolitan network, my
requirements may be quite different and I would define my metrics
accordingly.
-----Original Message-----
From: Nikos Leontsinis [mailto:leontsinis@hotmail.com]
Sent: Tuesday, March 12, 2002 5:48 PM
To: Neal, Brad (Broadwing); isis-wg@juniper.net
Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way
Although ISO 10589 defines four different metric fields, I believe the
decision process still uses a single scalar metric because IS-IS combines
the four fields by simple addition paragraph 7.2.2, note 13. It's up to the
network operator to weight these fields according to his own requirements.
No the network operator can only ammend the default cisco metric which is
bandwith. The remaining metrics are not supported hence cannot be used what
they rather do is to give a hint to the network administrator what to bear
in mind when designing his/her network. I was looking for something more
coherent than that as I think metric assinment is by far the most
challenging task for the network designer since Cisco together with the
remaining implemeters are fairly inefficient in this direction. I am looking
for a sound way to measure metrics.
Point is, you can accomplish pretty much the same thing with a single
field--just define which link properties are important to you, weight them
according to their relative importance, add up the values and the result is
your combined metric, just like IS-IS would have done.
+++The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and destroy any copies of this
document.+++
_____
Join the world's largest e-mail service with MSN Hotmail. Click
Here
+++The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and destroy any copies of this
document.+++


Send and receive Hotmail on your mobile device: Click Here
From Eduard.Metz@kpnqwest.com Wed Mar 13 09:11:02 2002 From: Eduard.Metz@kpnqwest.com (Metz, Eduard) Date: Wed, 13 Mar 2002 10:11:02 +0100 Subject: [Isis-wg] IS-IS metrics: in search for a sound way Message-ID: <1E810ACBCC29D51185DF00508B66CCEED02442@ntexghfd02> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CA6E.FF507200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AFAIK, the default metric is more or less 'dimensionless' in current implementations, and therefor not derived from interface bandwidth = directly. So you can put any value in there (based on any formula you wish). =20 In general something like: long, narrow pipes =3D> large metric, and = short, fat pipes =3D> small metric tends to work. Use the math of your choice = to get from one end to the other. =20 cheers, Eduard -----Original Message----- From: Nikos Leontsinis [mailto:leontsinis@hotmail.com] Sent: Monday, 11 March, 2002 23:10 To: isis-wg@juniper.net Subject: [Isis-wg] IS-IS metrics: in search for a sound way ISO 10589 states in 7.2.2. that the following 4 isis metrics are = defined: 1.Default: Each link is given a metric value based on its throughput=20 2.Delay metric . It measures the transit delay of the circuit. (pretty common-sensical higher value longer delay) 3. Expense metric. It measures the monetary cost of the network's utilsation-higher value larger expense-.(very unclear to me how this is done)=20 4 Error metric.It measures the residual (=EA=E1=F4=DC=EB=EF=E9=F0=EF, = =F5=F0=FC=EB=EF=E9=F0=EF) error probability of the asociated circuit (also unclear but makes sense as a concept).=20 If you look at the IS-IS LSP format's analysis i.e. p.638 Doyle, = Routing TCP/IP Volume1 you will see that IOS supports only the default metric (bit 4) Bits 5-7 which are delay, expense & = error are not supported and they will always be zero. This is a major IOS caveat as bandwidth alone is by no means sufficient = to account for metric assignment. However, looking at the LSP format is not the only way to reach the = above conclusion. These 3 factors would be brought into consideration on a discussion on = how to tune isis metrics by someone who was building his/her argumentation on pure operational experience.=20 The main objective behind metric tuning is network performance = improvement. Performance is an umbrella which incorporates the configuration and measurement of distinct areas. = It is not clear to me how the ietf engineers calculate delay, expense and error as part of their (non Cisco = supported) isis impl! ementation. What it is indubitable is that availability, response time, accuracy and utilisation will be key = indicators for the performance of a network and these are the ones that should also be added as key decision parameters in the metric assignment process. In conclusion, I am looking for a good way to measeure metrics either based on bandwidth or geographical distance eventhough I don't = think there is one formula which can be used as a panacea. My feeling is that = this is a context based approach. One can come to an agreement on what = issues to consider but the decision should be taken on the individual links rather than make it = matter of correct application of a specific formula. For a more detailed analysis on these 4 areas of performance: = availability, response time, accuracy and utilisation see Performance and Fault Management Della Magiora, et al p.74-85.=20 Best, Nikos Leontsinis =20 =20 =20 _____ =20 Join the world's largest e-mail service with MSN Hotmail. Click Here _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1CA6E.FF507200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
AFAIK,=20 the default metric is more or less 'dimensionless' in current = implementations,=20 and therefor not derived from interface bandwidth directly. So you can = put any=20 value in there (based on any formula you wish).
 
In=20 general something like: long, narrow pipes =3D> large metric, and = short, fat=20 pipes =3D> small metric tends to work. Use the math of your choice = to get from=20 one end to the other.
 
cheers,
    Eduard
-----Original Message-----
From: Nikos Leontsinis=20 [mailto:leontsinis@hotmail.com]
Sent: Monday, 11 March, = 2002=20 23:10
To: isis-wg@juniper.net
Subject: [Isis-wg] = IS-IS=20 metrics: in search for a sound way

ISO 10589 states in 7.2.2. that the following 4 isis = metrics=20 are defined:

1.Default: Each link is given a metric value = based on=20 its throughput
2.Delay metric . It measures the transit = delay of the=20 circuit. (pretty common-sensical higher value longer delay)
3. = Expense=20 metric. It measures the monetary cost of the network's = utilsation-higher value=20 larger expense-.(very unclear to me how this is done)=20

4 Error metric.It measures the residual = (=EA=E1=F4=DC=EB=EF=E9=F0=EF, =F5=F0=FC=EB=EF=E9=F0=EF) error=20 probability of the asociated circuit (also unclear but makes sense as = a=20 concept).

If you look at the IS-IS  LSP format's analysis i.e. p.638 = Doyle,=20 Routing TCP/IP Volume1 you will see that IOS = supports
 only the=20 default metric (bit 4) Bits 5-7  which are delay, expense & = error are=20 not supported and they will always be zero.
This is a = major IOS caveat=20 as bandwidth alone is by no means sufficient to account for metric=20 assignment.
However, looking at the LSP format is not the only way = to reach=20 the above conclusion.
These 3 factors would be brought into = consideration=20 on a discussion on how to tune isis metrics by someone
who=20 was building his/her argumentation on pure operational=20 experience. 
The main objective behind metric tuning is = network=20 performance improvement. Performance is an umbrella
which = incorporates the=20 configuration and measurement of distinct areas. It is not clear to = me how the=20 ietf engineers
calculate delay, expense and error as part of their = (non=20 Cisco supported) isis impl! ementation. What it is indubitable = is=20 that
availability, response time, accuracy and utilisation will be = key=20 indicators for the performance of a network and these are = the
ones=20 that should also be added as key decision parameters in the metric = assignment=20 process.

        In conclusion, = I am looking=20 for a good way to measeure metrics either based on = bandwidth=20 or geographical distance eventhough I don't think there is = one=20 formula which can be used as a panacea. My feeling is that this = is a=20 context based approach. One can come to an agreement on what = issues to=20 consider but the
decision should be taken on the individual links = rather=20 than make it matter of correct application of a specific = formula.
For a=20 more detailed analysis on these 4 areas of performance: availability, = response=20 time, accuracy and utilisation see
Performance=20 and Fault Management  Della Magiora, et al p.74-85. =

Best,

Nikos = Leontsinis

 
 
 


Join the world's largest e-mail service with MSN Hotmail. Click=20 Here
_______________________________________________ Isis-wg = mailing=20 list - Isis-wg@spider.juniper.net=20 = http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1CA6E.FF507200-- From svemulap@cisco.com Wed Mar 13 19:02:16 2002 From: svemulap@cisco.com (Shankar Vemulapalli) Date: Wed, 13 Mar 2002 11:02:16 -0800 (PST) Subject: [Isis-wg] draft-ietf-isis-transient-02.txt Message-ID: Hi Danny - Everything looks really good in the document. Just a couple of suggestions -[from readability perspective] In the section 4 under "Discussion" " Though, because RtrB has yet to establish and synchronization it's BGP neighbor relationship and routing information with RtrD, RtrB has no knowledge regarding reachability of destination D.1, and therefore discards the packets received from RtrA destined to D.1. " is little verbose... may be it is good to break it up into two sentences. Also, there are too many 'and's In the same section 4 under "Discussion" - " If RtrB were to temporarily set it's LSP Overload bit while synchroniz ing BGP tables with it's neighbors, RtrA would continue to use the work ing RtrA->RtrC->RtrD path, and the LSP should only be used to obtain reachability to locally connected networks (rather than for calculating transit paths through the router, as defined in [1]). " when talking about the "locally connected networks" - include a line saying that it is the Router-B's connected interfaces - so that it brings clarity. Thank you, /Shankar From mshand@cisco.com Thu Mar 14 10:31:21 2002 From: mshand@cisco.com (mike shand) Date: Thu, 14 Mar 2002 10:31:21 +0000 Subject: [Isis-wg] Administratively setting overload bit In-Reply-To: <20020314093603.38235.qmail@web11203.mail.yahoo.com> Message-ID: <4.3.2.7.2.20020314103058.03387638@jaws.cisco.com> At 01:36 14/03/2002 -0800, Aravind Ravikumar wrote:

Hi All,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

            The variable isisSysSetOverload of table isisSysTable (ISIS MIB)

can be used to set overload bit administrativly at each level. I am not clear, that

if network manager sets this variable to indicate overload condition at a level then

do we need to enter waiting state at that level,even if we have enough resources

 and perform all those actions listed in

section 7.3.19 of ISO 10589 for that level.

No.
        Mike


Please help me. Thanks in advance.

 



Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
From jparker@axiowave.com Thu Mar 14 15:06:25 2002 From: jparker@axiowave.com (Jeff Parker) Date: Thu, 14 Mar 2002 10:06:25 -0500 Subject: [Isis-wg] Administratively setting overload bit Message-ID: You may want to take a look at http://ietf.org/internet-drafts/draft-ietf-isis-transient-02.txt to see the kind of devious mindset^H^H^H^H^H^H^H^H^H^H ways people might use this functionality. Briefly, there is a bit in the LSPs we generate that tells the world to route around us, when possible. This bit has been overloaded to use the meaning in other contexts than "I'm low on memory". It is really an admission that there are many resources that we may need. I have distinguished "wait" from "on" because there is a system event (timer firing, finished importing selected external routes from BGP) that will move the variable from "wait" to "off". - jeff parker - axiowave networks -----Original Message----- From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Thursday, March 14, 2002 4:36 AM To: isis-wg@juniper.net Subject: [Isis-wg] Administratively setting overload bit Hi All, The variable isisSysSetOverload of table isisSysTable (ISIS MIB) can be used to set overload bit administrativly at each level. I am not clear, that if network manager sets this variable to indicate overload condition at a level then do we need to enter waiting state at that level,even if we have enough resources and perform all those actions listed in section 7.3.19 of ISO 10589 for that level. Please help me. Thanks in advance. Do You Yahoo!? Yahoo! Sports - live college hoops coverage From JRB@dataconnection.com Thu Mar 14 17:19:51 2002 From: JRB@dataconnection.com (Jon Berger) Date: Thu, 14 Mar 2002 17:19:51 -0000 Subject: [Isis-wg] draft-ietf-isis-wg-multi-topolgy-02 Message-ID: <37701240971DD31193970000F6CCB9F70348F0D4@duke.datcon.co.uk> Could someone explain to me what the assignment of MT ID#2 to IPv6 Routing Topology means? Is #2 the IPv6 equivalent of #0? If so, why can't we just use #0? If not, what does it represent? Jon From JRB@dataconnection.com Thu Mar 14 18:10:45 2002 From: JRB@dataconnection.com (Jon Berger) Date: Thu, 14 Mar 2002 18:10:45 -0000 Subject: [Isis-wg] draft-ietf-isis-3way-05 Message-ID: <37701240971DD31193970000F6CCB9F70348F0DE@duke.datcon.co.uk> Section 3.1 says "Any system that supports this mechanism MUST include Adjacency Three-Way State field in this option. The other fields in this option should be included as explained below in section 3.2." Which implies that it is possible to leave out the Extended Local Circuit ID. However my reading of the rest of the draft is that this is not an option. Jon From Ravindra.Sunkad@vivacenetworks.com Thu Mar 14 19:10:44 2002 From: Ravindra.Sunkad@vivacenetworks.com (Ravindra Sunkad) Date: Thu, 14 Mar 2002 11:10:44 -0800 Subject: [Isis-wg] Extended IP Reachability question Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C1CB8B.F0EC2DD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In the following threads there is some talk about defining a sub-tlv for the Extended IP Reachability TLV that could be used to differentiate external route advertisements from internal route advertisements. Has any work been done on this front? =20 http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 =20 [Isis-wg] IS-IS Extensions for Traffic Engineering [Isis-wg] draft-ietf-isis-traffic-01.txt=20 =20 Thanks, Ravi ------_=_NextPart_001_01C1CB8B.F0EC2DD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In the following = threads there is some talk about defining a sub-tlv for the Extended IP = Reachability TLV that could be used to differentiate external route advertisements from = internal route advertisements. Has any work been done on this = front?

 

= http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31

 

[Isis-wg] IS-IS = Extensions for Traffic Engineering

[Isis-wg] draft-ietf-isis-traffic-01.txt

 

Thanks,

Ravi

=00 ------_=_NextPart_001_01C1CB8B.F0EC2DD9-- From qinzhijian@yahoo.com Fri Mar 15 00:44:21 2002 From: qinzhijian@yahoo.com (zhijian qin) Date: Thu, 14 Mar 2002 16:44:21 -0800 Subject: [Isis-wg] Partition Designated L2 IS Election Problem Message-ID: <000501c1cbba$8c6995d0$e404a8c0@hq.uniant.com> Hi, I am a new guy on ISIS. When I was testing the Partition Repair Option, I create 2 areas, the first area has 6 routers while the second area has 2 routers. Area Addresses: Area1 aa01 Area2 aa02 NSAPs: R1 aa01000000000001 R2 aa01000000000002 R3 aa01000000000003 R4 aa01000000000004 R5 aa01000000000005 R6 aa01000000000006 R7 aa02000000000007 R8 aa02000000000008 Network Topology: _____ _____ | | | | | R7 | -----------------------------------------------------------| R8 | |_____| |_____| | | | | __|___ __|___ | | | | | R3 | | R4 | |_____| |_____| / \ / \ / \ / \ / \ / \ __|___ __|___ __|___ __|___ | | | | | | | | | R1 |-----| R2 |-----------------------------------------------| R6 |------| R5 | |_____| |_____| |_____| |_____| (All links are point-to-point links). I brought up all routers as L1L2 IS with partion repair capability (I am not sure if I can do that). Then I cut the connection between R2 and R6, R1/R2/R3 became a partition of area1 and R4/R5/R6 became another partion. Because every router in area1 can reach area2 directly or indirectly, every router in area1 claims itself as attached. So based the "Election of partition designated level 2 IS" (ISO10589 7.2.10.2), the Partition designated IS for the partition is R1 which has the lowest ID, while the the partion designated IS for the second partion is R4. R1 and R4 treat each other as a virtual adjacency. Each Non-Partition-Designated Routers (R2/R3/R5/R6) use the partition designated router as the next hop when they want to reach the routers in another partiton. The problem is R1, which is the partition designated router of the first partion, use the R3 as the next hop for destination R4, then I got a route loop, when R2 wants to talk to R4, R2 selects R1 as the next hop, then R3, then R1 again, then R3 again,........... i am dead. I did go though the ISO 10589 couple of times for help without any luck, but I still don't believe the protocol itself has something wrong, so could any experts out there can tell me what is wrong with my test envirionment or the software stack I am using might be the bad guy? Thanks a lot in advance, Jackie Qin _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From cmartin@gnilink.net Fri Mar 15 04:22:26 2002 From: cmartin@gnilink.net (Martin, Christian) Date: Thu, 14 Mar 2002 23:22:26 -0500 Subject: [Isis-wg] IS-IS metrics: in search for a sound way Message-ID: <94B9091E1149D411A45C00508BACEB35015F2C67@entmail.gnilink.com> Nikos, There is no "documentation", per se. However, the Operations Research folks have been studying these types of problems for 50 years. They vary in complexity, from a 3-node single metric IP network to a worldwide dispatching system such as that employed by FedEx. Network optimization problems are HARD at a large scale. In fact, some linear programming models are so difficult to compute, that they cannot be solved using today's computers. An example would be finding the fastest way from one street corner to another in Manhattan given known variables like signal frequency, speed limits, number of lanes, and average traffic patterns. The optimal solution is not solvable. But, approximations to the optimal solution are. I believe Brad is trying to convey that there is no simple rule of thumb. Your needs may be different from mine. The tools and methods are the same, however. If you need a quick fix that takes lots into consideration, you can use EIGRPs method as a starting point. As you can infer, the goal of EIGRP is to optimize a path given constraints. Usually, IP networks AIM to minimize delay and maximize bandwidth. If you need some help working this out, a colleague and I have derived a formula that works well for IS-IS/OSPF costing that aims to minimze the delay to transmit one 1500 byte packet. If you need to minimize financial cost, then it gets tougher. If you are interested, try www.citeseer.org and search for things like qos routing, link costs, etc. You will likely find more information than you'll ever need! For more information, try "Network Optimization" by Bertsekas and any reasonable text on Operations Research. Regards, chris -----Original Message----- From: Nikos Leontsinis [mailto:leontsinis@hotmail.com] Sent: Wednesday, March 13, 2002 1:35 AM To: bneal@broadwing.com; isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way There must be some documentation about the metric assignment process we just don't know it. This is a topic for a book it should be written for the 3 main routing protocols. Best Regards, Nikos Leontsinis From: bneal@broadwing.com To: leontsinis@hotmail.com, isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way Date: Tue, 12 Mar 2002 18:53:22 -0600 MIME-Version: 1.0 Received: from [216.140.57.101] by hotmail.com (3.2) with ESMTP id MHotMailBE57EE23006F4004374ED88C396555F60; Tue, 12 Mar 2002 16:53:56 -0800 Received: by ausmx1.ixc-comm.com with Internet Mail Service (5.5.2653.19)id ; Tue, 12 Mar 2002 18:53:32 -0600 >From bneal@broadwing.com Tue, 12 Mar 2002 16:55:15 -0800 Message-ID: <8E9322ACF085D311918E00805FE6CEE7077A5997@metexch3.ixc-comm.com> X-Mailer: Internet Mail Service (5.5.2653.19) My point is that even if a platform lets you set all four metrics, the SPF computation, as defined by 10589, just adds them up and uses the sum as a single metric. I can only assume that the reason they are broken out separately is for conceptual convenience. (?) A human being can do this just as easily when a platform only supports a single metric, or when using the new-style TLVs that only define one metric. The only real difference is that the actual values of the individual link properties are not reflected in the router's configuration state. As far as a generalized metric-selection schema, I don't think there really is one. How I, as a network operator, assign link metrics will depend on what link properties are interesting to me in my particular situation. For instance, if I can provision bandwidth quickly and have sufficient confidence in my trending and planning efforts, bandwidth isn't interesting to me as an IGP decision input. Delay might be, though, if I have a network of large geographic scope. If I run a regional or metropolitan network, my requirements may be quite different and I would define my metrics accordingly. -----Original Message----- From: Nikos Leontsinis [mailto:leontsinis@hotmail.com] Sent: Tuesday, March 12, 2002 5:48 PM To: Neal, Brad (Broadwing); isis-wg@juniper.net Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way Although ISO 10589 defines four different metric fields, I believe the decision process still uses a single scalar metric because IS-IS combines the four fields by simple addition paragraph 7.2.2, note 13. It's up to the network operator to weight these fields according to his own requirements. No the network operator can only ammend the default cisco metric which is bandwith. The remaining metrics are not supported hence cannot be used what they rather do is to give a hint to the network administrator what to bear in mind when designing his/her network. I was looking for something more coherent than that as I think metric assinment is by far the most challenging task for the network designer since Cisco together with the remaining implemeters are fairly inefficient in this direction. I am looking for a sound way to measure metrics. Point is, you can accomplish pretty much the same thing with a single field--just define which link properties are important to you, weight them according to their relative importance, add up the values and the result is your combined metric, just like IS-IS would have done. +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++ _____ Join the world's largest e-mail service with MSN Hotmail. Click Here +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++ Send and receive Hotmail on your mobile device: Click Here _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From ginsberg@pluris.com Fri Mar 15 04:53:24 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Thu, 14 Mar 2002 20:53:24 -0800 Subject: [Isis-wg] Partition Designated L2 IS Election Problem Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F87B@avalon.pluris.com> Defects in the route preference algorithm in the presence of virtual links as defined by ISO 10589:1992 were identified a few years ago. The changes were incorporated into ISO 10589:2001. I recommend you consult that to resolve your dilemma. Pay particular attention to the changes in Section 7.2.10 and 7.4.3. ftp.cisco.com/pub/rfc/ISO/ISO10589v2-2001-07-04.pdf Les > -----Original Message----- > From: zhijian qin [mailto:qinzhijian@yahoo.com] > Sent: Thursday, March 14, 2002 4:44 PM > To: isis-wg@spider.juniper.net > Subject: [Isis-wg] Partition Designated L2 IS Election Problem > > > Hi, > > I am a new guy on ISIS. When I was testing the Partition > Repair Option, I > create 2 areas, the first area has 6 routers while the second > area has 2 > routers. > > Area Addresses: > Area1 aa01 > Area2 aa02 > > NSAPs: > R1 aa01000000000001 > R2 aa01000000000002 > R3 aa01000000000003 > R4 aa01000000000004 > R5 aa01000000000005 > R6 aa01000000000006 > > R7 aa02000000000007 > R8 aa02000000000008 > > Network Topology: > > _____ > _____ > | | > | | > | R7 > | > -----------------------------------------------------------| R8 | > |_____| > |_____| > | > | > | > | > __|___ > __|___ > | | > | | > | R3 | > | R4 | > |_____| > |_____| > / \ > / \ > / \ > / \ > / \ > / \ > __|___ __|___ > __|___ __|___ > | | | | > | | | | > | R1 |-----| R2 > |-----------------------------------------------| R6 > |------| R5 | > |_____| |_____| > |_____| |_____| > > (All links are point-to-point links). > > I brought up all routers as L1L2 IS with partion repair > capability (I am not > sure if I can do that). Then I cut the connection between R2 and R6, > R1/R2/R3 became a partition of area1 and R4/R5/R6 became > another partion. > > Because every router in area1 can reach area2 directly or > indirectly, every > router in area1 claims itself as attached. So based the "Election of > partition designated level 2 IS" (ISO10589 7.2.10.2), the Partition > designated IS for the partition is R1 which has the lowest > ID, while the the > partion designated IS for the second partion is R4. R1 and R4 > treat each > other as a virtual adjacency. Each Non-Partition-Designated Routers > (R2/R3/R5/R6) use the partition designated router as the next > hop when they > want to reach the routers in another partiton. > > The problem is R1, which is the partition designated router > of the first > partion, use the R3 as the next hop for destination R4, then > I got a route > loop, when R2 wants to talk to R4, R2 selects R1 as the next > hop, then R3, > then R1 again, then R3 again,........... i am dead. > > I did go though the ISO 10589 couple of times for help > without any luck, but > I still don't believe the protocol itself has something > wrong, so could any > experts out there can tell me what is wrong with my test > envirionment or the > software stack I am using might be the bad guy? > > Thanks a lot in advance, > > Jackie Qin > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From ginsberg@pluris.com Fri Mar 15 05:01:14 2002 From: ginsberg@pluris.com (Les Ginsberg) Date: Thu, 14 Mar 2002 21:01:14 -0800 Subject: [Isis-wg] IS-IS metrics: in search for a sound way Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F87C@avalon.pluris.com> > > Although ISO 10589 defines four different metric fields, I believe the > decision process still uses a single scalar metric because > IS-IS combines > the four fields by simple addition paragraph 7.2.2, note 13. No - this is not the correct interpretation. Separate forwarding databases must be generated for each supported metric (see 10589:1992 C.2.4). The note Neal is referring to (Note 9 in the 1992 edition/Note 13 in the 2001 edition) is talking about how cost for a path is calculated for a particular type of metric - it is not meant to suggest that metrics of different types should be added together. Les From naiming@redback.com Fri Mar 15 05:11:22 2002 From: naiming@redback.com (Naiming Shen) Date: Thu, 14 Mar 2002 21:11:22 -0800 Subject: [Isis-wg] draft-ietf-isis-wg-multi-topolgy-02 In-Reply-To: Mail from Jon Berger dated Thu, 14 Mar 2002 17:19:51 GMT <37701240971DD31193970000F6CCB9F70348F0D4@duke.datcon.co.uk> Message-ID: <20020315051122.ECE2DF2C5B@prattle.redback.com> Jon, ] Could someone explain to me what the assignment of MT ID#2 to IPv6 Routing ] Topology means? in M-ISIS extension, you can run multiple topologies within an IS-IS instance, the IPv6 topology is assigned to have MT ID of 2. so if you have different topology records in a packet, you can identify which topologies they belong. ] ] Is #2 the IPv6 equivalent of #0? If so, why can't we just use #0? If not, ] what does it represent? the MT ID #0 is for IPv4 unicast. yes in some sense, this #2 is the "normal" IPv6 topology. and if you have more than one IPv6 topologies within a single IS-IS domain, then you have to pick some other numbers.(this is like #0 is for "normal" IPv4 unicast topology, you need to pick other numbers for your other IPv4 unicast topologies). ] ] Jon ] ] _______________________________________________ ] Isis-wg mailing list - Isis-wg@spider.juniper.net ] http://spider.juniper.net/mailman/listinfo/isis-wg - Naiming From swaminathanr@netplane.com Fri Mar 15 07:32:09 2002 From: swaminathanr@netplane.com (Ramalingam, Swaminathan) Date: Fri, 15 Mar 2002 02:32:09 -0500 Subject: [Isis-wg] IS Adjacency table Message-ID: Hi Jeff, Some suggestion on IS Adjacency Table In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is no object conveying the message what "type" of adjacency is that (either Level1 or Level2), when isisISAdjUsage is "Level1and2" ? . It has to convey whether it is "Level 1" or "Level 2" i.e there can be another object before isisISAdjUsage like: isisISAdjType OBJECT-TYPE SYNTAX INTEGER { level1(1), level2(2), } MAX-ACCESS read-only STATUS current DESCRIPTION "An adjacency of type level1 is used for level 1 traffic only. An adjacency of type level2 is used for level 2 traffic only. If this neighbor have another adjacency (at another level L1 or L2), then isisISAdjUsage should be 'levelland2'else it should be same as at this level" REFERENCE "{ISIS.aoi adjacencyUsage (82)}" ::= { isisISAdjEntry 6 } Thanks, Swami From swaminathanr@netplane.com Fri Mar 15 09:10:08 2002 From: swaminathanr@netplane.com (Ramalingam, Swaminathan) Date: Fri, 15 Mar 2002 04:10:08 -0500 Subject: [Isis-wg] RE: IS Adjacency table Message-ID: Also description for isisISAdjNeighPriority reads like: isisISAdjNeighPriority OBJECT-TYPE SYNTAX ISPriority MAX-ACCESS read-only STATUS current DESCRIPTION "Priority of the neighboring Intermediate System for becoming the LAN Level 1 Designated Intermediate System if the value of isisISAdjNeighSysType is L1IntermediateSystem or LAN Level 2 Designated Intermediate System if the value of isisISAdjNeighSysType is L2IntermediateSystem." REFERENCE "{ISIS.aoi lANPriority (86)}" ::= { isisISAdjEntry 8 } what it mean when isisISAdjNeighSysType is "l1l2IntermediateSystem"?. I guess, it should be changed as DESCRIPTION "Priority of the neighboring Intermediate System for becoming the LAN Level 1 Designated Intermediate System if the value of *isisISAdjType* is 'Level1' or LAN Level 2 Designated Intermediate System if the value of *isisISAdjType* is 'level2'." isisISAdjType is new suggested object in my previous mail.. Thanks, Swami -----Original Message----- From: Ramalingam, Swaminathan Sent: Friday, March 15, 2002 1:02 PM To: 'Jeff Parker' Cc: 'isis-wg@spider.juniper.net' Subject: IS Adjacency table Hi Jeff, Some suggestion on IS Adjacency Table In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is no object conveying the message what "type" of adjacency is that (either Level1 or Level2), when isisISAdjUsage is "Level1and2" ? . It has to convey whether it is "Level 1" or "Level 2" i.e there can be another object before isisISAdjUsage like: isisISAdjType OBJECT-TYPE SYNTAX INTEGER { level1(1), level2(2), } MAX-ACCESS read-only STATUS current DESCRIPTION "An adjacency of type level1 is used for level 1 traffic only. An adjacency of type level2 is used for level 2 traffic only. If this neighbor have another adjacency (at another level L1 or L2), then isisISAdjUsage should be 'levelland2'else it should be same as at this level" REFERENCE "{ISIS.aoi adjacencyUsage (82)}" ::= { isisISAdjEntry 6 } Thanks, Swami From rsaluja@nortelnetworks.com Fri Mar 15 14:19:19 2002 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Fri, 15 Mar 2002 09:19:19 -0500 Subject: [Isis-wg] draft-ietf-isis-3way-05 References: <37701240971DD31193970000F6CCB9F70348F0DE@duke.datcon.co.uk> Message-ID: <3C9202E7.5D621FE5@nortelnetworks.com> Jon Berger wrote: > Section 3.1 says > > "Any system that supports this mechanism MUST include Adjacency Three-Way > State field in this option. The other fields in this option should be > included as explained below in section 3.2." > > Which implies that it is possible to leave out the Extended Local Circuit > ID. However my reading of the rest of the draft is that this is not an > option. > > Jon > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg There are some old implementations which send only "Adjacency Three-Way State" field in this TLV. Thanks Rajesh From jlearman@cisco.com Fri Mar 15 16:20:52 2002 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 15 Mar 2002 11:20:52 -0500 Subject: [Isis-wg] IS-IS metrics: in search for a sound way In-Reply-To: <1E810ACBCC29D51185DF00508B66CCEED02442@ntexghfd02> Message-ID: <4.3.2.7.2.20020315105005.03ddd9f0@dingdong.cisco.com> --=====================_4533839==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nikos, Eduard is correct, all metrics are dimensionless values and can be set to represent whatever you think works best for your network. bandwidth is simply the simplest choice that works very well under most circumstances, and assuming that hop-by-hop router-induced delays (other than for queuing) are insignificant. In addition, multiple metrics allows defining of different classes (up to 4) of traffic to be routed using different criteria. The category of traffic must be selected at the source by setting TOS bits (or for CLNS, QoS bits). Unless the source systems set these bits, all traffic is routed using the Default metric. For this reason, many networks use other means of classifying packets and handling QoS and differential services, and this is one of the driving factors behind MPLS and TE, if I my very limited understanding of those topics serves me correctly. Hopefully those who know these subjects well will correct me if I'm wrong! Furthermore, there is a pitfall to using multiple metrics. Unless all routers in the domain support and are properly configured to use the other metrics, you can get very nonintuitive results, as pointed out in Radia Perlman's "Interconnections". For example, let's assume that you (as the originating system) choose to take a path that optimizes "expense" and set the TOS bits accordingly. Also, assume that some routers support the expense metric and others don't. If there any paths between source and destination (within a subdomain, i.e. area or L2 bbone) the shortest of these paths are taken. Even if there is a single 1-cost hop between source and destination, where the router doesn't support the expense metric. All this means is that 1) multiple metrics doesn't give you better routing for default traffic 2) multiple metrics can give better routing for different TOS classes, if end systems set the bits 3) but ONLY if the non-default metrics are very carefully managed in the network. In my experience, the best use of multiple metrics has been in networks where all the traffic is generated by a limited number of applications that understand the domain's rules for metrics, i.e., a network that exists for a specific purpose. The example I have in mind was an electrical power management network. In this case, three metrics were used: default (capacity), delay, and "expense" was set to 1 for every link, so that certain traffic would always use the fewest hops regardless of other circuit properties. Default was used for bulk data transfer, Delay was used for interactive applications, and expense was used for various technical purposes including measurement of link behavior. While I'm on my soapbox, I'll include a warning about use of real-time data to set the delay metric. While this can be done successfully in certain cases, it's very difficult and requires a deep understanding of the network and application data traffic. The problem is that if you measure delays and set the delay metric in real time, you typically get into an unstable situation where, as soon as you lower the delay on a link, it starts attracting more traffic and the delays go up, so you must then raise it's metric, etc. IS-IS was designed with relatively static metric values in mind, to avoid this kind of problem. This doesn't answer your original question, which is "what's the best way to calculate the metric?" This is a very interesting topic that I believe has been studied extensively in various contexts. However, it's beyond the scope of this forum, which pertains to standards issues. The means of setting a metric value is not a matter for a standards committee because it's done entirely within an autonomous system (domain), and can be done any way the administrator thinks will provide the best results in his or her network. No standards are required. If you do find any good texts on the subject, we'd certainly be interested to hear of them, but a detailed discussion of the subject is probably not appropriate here. Regards, Jeff At 04:11 AM 3/13/2002, Metz, Eduard wrote: >AFAIK, the default metric is more or less 'dimensionless' in current= implementations, and therefor not derived from interface bandwidth= directly. So you can put any value in there (based on any formula you= wish). >=20 >In general something like: long, narrow pipes =3D> large metric, and short,= fat pipes =3D> small metric tends to work. Use the math of your choice to= get from one end to the other. >=20 >cheers, > Eduard =20 >-----Original Message-----=20 >From: Nikos Leontsinis [mailto:leontsinis@hotmail.com]=20 >Sent: Monday, 11 March, 2002 23:10=20 >To: isis-wg@juniper.net=20 >Subject: [Isis-wg] IS-IS metrics: in search for a sound way > >ISO 10589 states in 7.2.2. that the following 4 isis metrics are defined: > >1.Default: Each link is given a metric value based on its throughput=20 >2.Delay metric . It measures the transit delay of the circuit. (pretty= common-sensical higher value longer delay)=20 >3. Expense metric. It measures the monetary cost of the network's= utilsation-higher value larger expense-.(very unclear to me how this is= done)=20 > >4 Error metric.It measures the residual (=EA=E1=F4=DC=EB=EF=E9=F0=EF,= =F5=F0=FC=EB=EF=E9=F0=EF) error probability of the asociated circuit (also= unclear but makes sense as a concept).=20 > >If you look at the IS-IS LSP format's analysis i.e. p.638 Doyle, Routing= TCP/IP Volume1 you will see that IOS supports=20 > only the default metric (bit 4) Bits 5-7 which are delay, expense & error= are not supported and they will always be zero.=20 >This is a major IOS caveat as bandwidth alone is by no means sufficient to= account for metric assignment.=20 >However, looking at the LSP format is not the only way to reach the above= conclusion.=20 >These 3 factors would be brought into consideration on a discussion on how= to tune isis metrics by someone=20 >who was building his/her argumentation on pure operational experience.=20 >The main objective behind metric tuning is network performance improvement.= Performance is an umbrella=20 >which incorporates the configuration and measurement of distinct areas. It= is not clear to me how the ietf engineers=20 >calculate delay, expense and error as part of their (non Cisco supported)= isis impl! ementation. What it is indubitable is that=20 >availability, response time, accuracy and utilisation will be key= indicators for the performance of a network and these are the=20 >ones that should also be added as key decision parameters in the metric= assignment process. > > In conclusion, I am looking for a good way to measeure metrics= either based on bandwidth or geographical distance eventhough I don't think= there is one formula which can be used as a panacea. My feeling is that= this is a context based approach. One can come to an agreement on what= issues to consider but the=20 >decision should be taken on the individual links rather than make it matter= of correct application of a specific formula.=20 >For a more detailed analysis on these 4 areas of performance: availability,= response time, accuracy and utilisation see=20 >Pe= rformance and Fault Management Della Magiora, et al p.74-85.=20 > >Best,=20 >Nikos Leontsinis >=20 > > >=20 > > >=20 >---------- >Join the world's largest e-mail service with MSN Hotmail.= Click Here=20 >_______________________________________________ Isis-wg mailing list -= Isis-wg@spider.juniper.net= http://spider.juniper.net/mailman/listinfo/isis-wg=20 --=====================_4533839==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Nikos,

Eduard is correct, all metrics are dimensionless values and can be
set to represent whatever you think works best for your network.
bandwidth is simply the simplest choice that works very well under
most circumstances, and assuming that hop-by-hop router-induced delays
(other than for queuing) are insignificant.

In addition, multiple metrics allows defining of different classes
(up to 4) of traffic to be routed using different criteria.  The category
of traffic must be selected at the source by setting TOS bits (or for
CLNS, QoS bits).  Unless the source systems set these bits, all traffic
is routed using the Default metric.  For this reason, many networks use
other means of classifying packets and handling QoS and=20 differential
services, and this is one of the driving factors behind MPLS and=20 TE,
if I my very limited understanding of those topics serves me correctly.
Hopefully those who know these subjects well will correct me if I'm
wrong!

Furthermore, there is a pitfall to using multiple metrics.  Unless
all routers in the domain support and are properly configured to=20 use
the other metrics, you can get very nonintuitive results, as=20 pointed
out in Radia Perlman's "Interconnections".  For example, let's assume
that you (as the originating system) choose to take a path that
optimizes "expense" and set the TOS bits accordingly.  Also, assume
that some routers support the expense metric and others don't.
If there any paths between source and destination (within a subdomain,
i.e. area or L2 bbone) the shortest of these paths are taken.  Even
if there is a single 1-cost hop between source and destination, where
the router doesn't support the expense metric.

All this means is that

  1) multiple metrics doesn't give you better routing for default traffic
  2) multiple metrics can give better routing for different TOS classes,
       if end systems set the bits
  3) but ONLY if the non-default metrics are very carefully managed
       in the network.

In my experience, the best use of multiple metrics has been in networks
where all the traffic is generated by a limited number of applications
that understand the domain's rules for metrics, i.e., a network
that exists for a specific purpose.  The example I have in mind was an
electrical power management network.  In this case, three metrics were
used: default (capacity), delay, and "expense" was set to 1 for every
link, so that certain traffic would always use the fewest hops regardless
of other circuit properties.  Default was used for bulk data transfer,
Delay was used for interactive applications, and expense was used for
various technical purposes including measurement of link behavior.

While I'm on my soapbox, I'll include a warning about use of real-time
data to set the delay metric.  While this can be done successfully in
certain cases, it's very difficult and requires a deep=20 understanding
of the network and application data traffic.  The problem is that if
you measure delays and set the delay metric in real time, you typically
get into an unstable situation where, as soon as you lower the=20 delay
on a link, it starts attracting more traffic and the delays go up,
so you must then raise it's metric, etc.  IS-IS was designed with
relatively static metric values in mind, to avoid this kind of problem.

This doesn't answer your original question, which is "what's the best
way to calculate the metric?"  This is a very interesting topic that
I believe has been studied extensively in various contexts.  However,
it's beyond the scope of this forum, which pertains to standards issues.
The means of setting a metric value is not a matter for a standards
committee because it's done entirely within an autonomous system
(domain), and can be done any way the administrator thinks will
provide the best results in his or her network.  No standards are
required.  If you do find any good texts on the subject, we'd certainly
be interested to hear of them, but a detailed discussion of the
subject is probably not appropriate here.

Regards,
Jeff

At 04:11 AM 3/13/2002, Metz, Eduard wrote:
AFAIK, the default metric is more or less 'dimensionless' in current implementations, and therefor not derived from interface bandwidth directly. So you can put any value in there (based on any formula you wish).
 
In general something like: long, narrow pipes =3D> large metric, and short, fat pipes =3D> small metric tends to work. Use the math of your choice to get from one end to the other.
 
cheers,
    Eduard
-----Original Message-----
From: Nikos Leontsinis [mailto:leontsinis@hotmail.com]
Sent: Monday, 11 March, 2002 23:10
To: isis-wg@juniper.net
Subject: [Isis-wg] IS-IS metrics: in search for a sound way

ISO 10589 states in 7.2.2. that the following 4 isis metrics are defined:

1.Default: Each link is given a metric value based on its throughput=20
2.Delay metric . It measures the transit delay of the circuit. (pretty common-sensical higher value longer delay)
3. Expense metric. It measures the monetary cost of the network's utilsation-higher value larger expense-.(very unclear to me how this is done)

4 Error metric.It measures the residual (=EA=E1=F4=DC=EB=EF=E9=F0=EF,= =F5=F0=FC=EB=EF=E9=F0=EF) error probability of the asociated circuit (also unclear but makes sense as a concept).

If you look at the IS-IS  LSP format's analysis i.e. p.638 Doyle, Routing TCP/IP Volume1 you will see that IOS supports
 only the default metric (bit 4) Bits 5-7  which are delay, expense & error are not supported and they will always be zero.
This is a major IOS caveat as bandwidth alone is by no means sufficient to account for metric assignment.
However, looking at the LSP format is not the only way to reach the above conclusion.
These 3 factors would be brought into consideration on a discussion on how to tune isis metrics by someone
who was building his/her argumentation on pure operational experience.=20
The main objective behind metric tuning is network performance improvement. Performance is an umbrella
which incorporates the configuration and measurement of distinct areas. It is not clear to me how the ietf engineers
calculate delay, expense and error as part of their (non Cisco supported) isis impl! ementation. What it is indubitable is that
availability, response time, accuracy and utilisation will be key indicators for the performance of a network and these are the
ones that should also be added as key decision parameters in the metric assignment process.

        In conclusion, I am looking for a good way to measeure metrics either based on bandwidth or geographical distance eventhough I don't think there is one formula which can be used as a panacea. My feeling is that this is a context based approach. One can come to an agreement on what issues to consider but the
decision should be taken on the individual links rather than make it matter of correct application of a specific formula.
For a more detailed analysis on these 4 areas of performance: availability, response time, accuracy and utilisation see
Performance and Fault Management  Della Magiora, et al p.74-85.

Best,
Nikos Leontsinis
 


 


 

Join the world's largest e-mail service with MSN Hotmail. Click Here
_______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg
--=====================_4533839==_.ALT-- From koen.vermeulen@alcatel.be Mon Mar 18 11:02:36 2002 From: koen.vermeulen@alcatel.be (Koen Vermeulen) Date: Mon, 18 Mar 2002 12:02:36 +0100 Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area Message-ID: <3C95C94C.4E94CE@alcatel.be> Hello,

I have a question related to the support of IPv4/IPv6
mixed routing domains.

Every router will indicate inside its LSP what IP
version it is capable off using the 'protocols supported'
TLV: an IPv4-only router will indicate it supports
IPv4, and IPv6-only router will indicate it supports
IPv6 and an IPv4/IPv6 router indicates it supports both.

This 'protocols supported' TLV can be used inside the
SPF for a certain IP version (I assume that an IPv4/IPv6
router will need to run 2 SPFs, one for IPv4 and one for
IPv6) to determine whether ot not to take the related LSP
into account.

This mechanism will work fine as long as an IPv4/IPv6
capable router can forward both IPv4 and IPv6 traffic
on all its interfaces. Because of the 'node level' nature
of the 'protocols supported' TLV, it is not possible
to perform a correct calculation with IPv4/IPv6 routers
which have a mixture of IPv4-only and IPv6-only interfaces.
This can be shown easily with an example:

                +----+
                | R1 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (1)
                   |
                   |
                +----+
                | R2 | IPv4/IPv6
                +----+
                   |
                   | IPv4-only capable link (2)
                   |
                   |
                +----+
                | R3 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (3)
                   |
                   |
                +----+
                | R4 | IPv4/IPv6
                +----+
                  |
                  x

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and
(3) can forward IPv6 packets, link (2) can only forward IPv4
traffic. x is an IPv6 network address.

Suppose R1 is calculating a route to IPv6 network x. Because
of the fact that R2 and R3 are both generating an LSP which
indicates they are IPv6 capable, the resulting route to x will
be via R2 and R3. Although, the link (2) between R2 and R3 is
not capable of forwarding IPv6 traffic.

I went back to RFC 1195 1.4 'Support of Mixed Routing Domains',
because here similar problems occur. From what I understand
from this text, is that a dual router here can both forward
CLNS and IP on all its interfaces, although it is not specifically
stated.

In case we take this rule also for IPv4/IPv6 capable routers
(all interfaces are IPv4/IPv6 capable), there is of course no
problem. On the other hand, during the transition of IPv4
to IPv6 I can image a lot of routers which will have a
mixture of IPv4-only and IPv6-only interfaces.

As a solution for this problem we were considering of announcing
in every IS-reachablity TLV via a sub-TLV the capability of
that specific interface (again via 'protocols supported')?
This can be picked up in the SPF to decide whether or not
take that link into account for a certain IP version.
 

All suggestions/remarks/corrections are welcome.

Thanks,
Koen From christi@nortelnetworks.com Mon Mar 18 13:41:10 2002 From: christi@nortelnetworks.com (Philip Christian) Date: Mon, 18 Mar 2002 13:41:10 -0000 Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area Message-ID: <4103264BC8D3D51180B7002048400C454FB5DF@zhard0jd.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CE82.90402DC0 Content-Type: text/plain; charset="iso-8859-1" According to the topological restrictions of RFC 1195, if IPv4 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv4. By the same logic, if IPv6 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv6. Therefore in your example, all of the nodes would have to be IPv4 and IPv6 capable, as both network-layer protocols appear in the area. This topological restriction applies due to the following clause in section 3.10 of RFC 1195 "The Dijkstra computation does not take into consideration whether a router is IP-only, OSI-only, or dual. The topological restrictions specified in section 1.4 ensure that IP packets will only be sent via IP-capable routers, and OSI packets will only be sent via OSI-capable routers." In other words, seperate SPF calculations for IPv4 and IPv6 are not necessary, and in fact contrary to the above clause. Not everyone may agree with this, but I believe that that is what it says. What many vendors do do, is to gate adjacency formation on whether a neighbour supports at least one network-layer protocol in common with you. This prevents a useless adjacency from forming (between an IPv4-only and an IPv6 only router). This behaviour would appear to not be contrary to RFC 1195, and is fairly normal practise. Philip -----Original Message----- From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] Sent: 18 March 2002 11:03 To: Isis-wg Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area Hello, I have a question related to the support of IPv4/IPv6 mixed routing domains. Every router will indicate inside its LSP what IP version it is capable off using the 'protocols supported' TLV: an IPv4-only router will indicate it supports IPv4, and IPv6-only router will indicate it supports IPv6 and an IPv4/IPv6 router indicates it supports both. This 'protocols supported' TLV can be used inside the SPF for a certain IP version (I assume that an IPv4/IPv6 router will need to run 2 SPFs, one for IPv4 and one for IPv6) to determine whether ot not to take the related LSP into account. This mechanism will work fine as long as an IPv4/IPv6 capable router can forward both IPv4 and IPv6 traffic on all its interfaces. Because of the 'node level' nature of the 'protocols supported' TLV, it is not possible to perform a correct calculation with IPv4/IPv6 routers which have a mixture of IPv4-only and IPv6-only interfaces. This can be shown easily with an example: +----+ | R1 | IPv4/IPv6 +----+ | | IPv6 capable link (1) | | +----+ | R2 | IPv4/IPv6 +----+ | | IPv4-only capable link (2) | | +----+ | R3 | IPv4/IPv6 +----+ | | IPv6 capable link (3) | | +----+ | R4 | IPv4/IPv6 +----+ | x R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and (3) can forward IPv6 packets, link (2) can only forward IPv4 traffic. x is an IPv6 network address. Suppose R1 is calculating a route to IPv6 network x. Because of the fact that R2 and R3 are both generating an LSP which indicates they are IPv6 capable, the resulting route to x will be via R2 and R3. Although, the link (2) between R2 and R3 is not capable of forwarding IPv6 traffic. I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', because here similar problems occur. From what I understand from this text, is that a dual router here can both forward CLNS and IP on all its interfaces, although it is not specifically stated. In case we take this rule also for IPv4/IPv6 capable routers (all interfaces are IPv4/IPv6 capable), there is of course no problem. On the other hand, during the transition of IPv4 to IPv6 I can image a lot of routers which will have a mixture of IPv4-only and IPv6-only interfaces. As a solution for this problem we were considering of announcing in every IS-reachablity TLV via a sub-TLV the capability of that specific interface (again via 'protocols supported')? This can be picked up in the SPF to decide whether or not take that link into account for a certain IP version. All suggestions/remarks/corrections are welcome. Thanks, Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1CE82.90402DC0 Content-Type: text/html; charset="iso-8859-1"

According to the topological restrictions of RFC 1195, if IPv4 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv4.
By the same logic, if IPv6 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv6.
 
Therefore in your example, all of the nodes would have to be IPv4 and IPv6 capable, as both network-layer protocols appear in the area.
 
This topological restriction applies due to the following clause in section 3.10 of RFC 1195
 
"The Dijkstra computation does not take into consideration whether a router
is IP-only, OSI-only, or dual. The topological restrictions specified in
section 1.4 ensure that IP packets will only be sent via IP-capable
routers, and OSI packets will only be sent via OSI-capable routers."
 
In other words, seperate SPF calculations for IPv4 and IPv6 are not necessary, and in fact contrary to the above clause.
 
Not everyone may agree with this, but I believe that that is what it says.
 
What many vendors do do, is to gate adjacency formation on whether a neighbour supports at least one network-layer protocol in common with you.
This prevents a useless adjacency from forming (between an IPv4-only and an IPv6 only router).
This behaviour would appear to not be contrary to RFC 1195, and is fairly normal practise.
 
Philip
-----Original Message-----
From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
Sent: 18 March 2002 11:03
To: Isis-wg
Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area

Hello,

I have a question related to the support of IPv4/IPv6
mixed routing domains.

Every router will indicate inside its LSP what IP
version it is capable off using the 'protocols supported'
TLV: an IPv4-only router will indicate it supports
IPv4, and IPv6-only router will indicate it supports
IPv6 and an IPv4/IPv6 router indicates it supports both.

This 'protocols supported' TLV can be used inside the
SPF for a certain IP version (I assume that an IPv4/IPv6
router will need to run 2 SPFs, one for IPv4 and one for
IPv6) to determine whether ot not to take the related LSP
into account.

This mechanism will work fine as long as an IPv4/IPv6
capable router can forward both IPv4 and IPv6 traffic
on all its interfaces. Because of the 'node level' nature
of the 'protocols supported' TLV, it is not possible
to perform a correct calculation with IPv4/IPv6 routers
which have a mixture of IPv4-only and IPv6-only interfaces.
This can be shown easily with an example:

                +----+
                | R1 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (1)
                   |
                   |
                +----+
                | R2 | IPv4/IPv6
                +----+
                   |
                   | IPv4-only capable link (2)
                   |
                   |
                +----+
                | R3 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (3)
                   |
                   |
                +----+
                | R4 | IPv4/IPv6
                +----+
                  |
                  x

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and
(3) can forward IPv6 packets, link (2) can only forward IPv4
traffic. x is an IPv6 network address.

Suppose R1 is calculating a route to IPv6 network x. Because
of the fact that R2 and R3 are both generating an LSP which
indicates they are IPv6 capable, the resulting route to x will
be via R2 and R3. Although, the link (2) between R2 and R3 is
not capable of forwarding IPv6 traffic.

I went back to RFC 1195 1.4 'Support of Mixed Routing Domains',
because here similar problems occur. From what I understand
from this text, is that a dual router here can both forward
CLNS and IP on all its interfaces, although it is not specifically
stated.

In case we take this rule also for IPv4/IPv6 capable routers
(all interfaces are IPv4/IPv6 capable), there is of course no
problem. On the other hand, during the transition of IPv4
to IPv6 I can image a lot of routers which will have a
mixture of IPv4-only and IPv6-only interfaces.

As a solution for this problem we were considering of announcing
in every IS-reachablity TLV via a sub-TLV the capability of
that specific interface (again via 'protocols supported')?
This can be picked up in the SPF to decide whether or not
take that link into account for a certain IP version.
 

All suggestions/remarks/corrections are welcome.

Thanks,
Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg

------_=_NextPart_001_01C1CE82.90402DC0-- From jlearman@cisco.com Mon Mar 18 14:42:12 2002 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 18 Mar 2002 09:42:12 -0500 Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area In-Reply-To: <4103264BC8D3D51180B7002048400C454FB5DF@zhard0jd.europe.nor tel.com> Message-ID: <4.3.2.7.2.20020318092744.01e1c528@dingdong.cisco.com> --=====================_212817855==_.ALT Content-Type: text/plain; charset="us-ascii" Philip is correct; however, note that routers that run separate SPF calculations for each protocol type will behave identically to those that do not in any network that meets the topology restrictions. Their behavior differs only in networks that violate the restrictions. Failing to form adjacencies based on protocol is not mentioned anywhere in 1195, and again is outside the scope based on the topology restrictions. However, on a LAN where some routers form adjacencies per 10589 and others reject adjacencies based on protocols supported, the DR election process is not guaranteed to succeed, so DR priority should be carefully managed on such LANs. Regards, Jeff At 08:41 AM 3/18/2002, Philip Christian wrote: >According to the topological restrictions of RFC 1195, if IPv4 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv4. >By the same logic, if IPv6 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv6. > >Therefore in your example, all of the nodes would have to be IPv4 and IPv6 capable, as both network-layer protocols appear in the area. > >This topological restriction applies due to the following clause in section 3.10 of RFC 1195 > >"The Dijkstra computation does not take into consideration whether a router >is IP-only, OSI-only, or dual. The topological restrictions specified in >section 1.4 ensure that IP packets will only be sent via IP-capable >routers, and OSI packets will only be sent via OSI-capable routers." > >In other words, seperate SPF calculations for IPv4 and IPv6 are not necessary, and in fact contrary to the above clause. > >Not everyone may agree with this, but I believe that that is what it says. > >What many vendors do do, is to gate adjacency formation on whether a neighbour supports at least one network-layer protocol in common with you. >This prevents a useless adjacency from forming (between an IPv4-only and an IPv6 only router). >This behaviour would appear to not be contrary to RFC 1195, and is fairly normal practise. > >Philip >>-----Original Message----- >>From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be] >>Sent: 18 March 2002 11:03 >>To: Isis-wg >>Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area >> >>Hello, >> >>I have a question related to the support of IPv4/IPv6 >>mixed routing domains. >> >>Every router will indicate inside its LSP what IP >>version it is capable off using the 'protocols supported' >>TLV: an IPv4-only router will indicate it supports >>IPv4, and IPv6-only router will indicate it supports >>IPv6 and an IPv4/IPv6 router indicates it supports both. >> >>This 'protocols supported' TLV can be used inside the >>SPF for a certain IP version (I assume that an IPv4/IPv6 >>router will need to run 2 SPFs, one for IPv4 and one for >>IPv6) to determine whether ot not to take the related LSP >>into account. >> >>This mechanism will work fine as long as an IPv4/IPv6 >>capable router can forward both IPv4 and IPv6 traffic >>on all its interfaces. Because of the 'node level' nature >>of the 'protocols supported' TLV, it is not possible >>to perform a correct calculation with IPv4/IPv6 routers >>which have a mixture of IPv4-only and IPv6-only interfaces. >>This can be shown easily with an example: >> >> +----+ >> | R1 | IPv4/IPv6 >> +----+ >> | >> | IPv6 capable link (1) >> | >> | >> +----+ >> | R2 | IPv4/IPv6 >> +----+ >> | >> | IPv4-only capable link (2) >> | >> | >> +----+ >> | R3 | IPv4/IPv6 >> +----+ >> | >> | IPv6 capable link (3) >> | >> | >> +----+ >> | R4 | IPv4/IPv6 >> +----+ >> | >> x >> >>R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and >>(3) can forward IPv6 packets, link (2) can only forward IPv4 >>traffic. x is an IPv6 network address. >> >>Suppose R1 is calculating a route to IPv6 network x. Because >>of the fact that R2 and R3 are both generating an LSP which >>indicates they are IPv6 capable, the resulting route to x will >>be via R2 and R3. Although, the link (2) between R2 and R3 is >>not capable of forwarding IPv6 traffic. >> >>I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', >>because here similar problems occur. From what I understand >>from this text, is that a dual router here can both forward >>CLNS and IP on all its interfaces, although it is not specifically >>stated. >> >>In case we take this rule also for IPv4/IPv6 capable routers >>(all interfaces are IPv4/IPv6 capable), there is of course no >>problem. On the other hand, during the transition of IPv4 >>to IPv6 I can image a lot of routers which will have a >>mixture of IPv4-only and IPv6-only interfaces. >> >>As a solution for this problem we were considering of announcing >>in every IS-reachablity TLV via a sub-TLV the capability of >>that specific interface (again via 'protocols supported')? >>This can be picked up in the SPF to decide whether or not >>take that link into account for a certain IP version. >> >> >>All suggestions/remarks/corrections are welcome. >> >>Thanks, >>Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg --=====================_212817855==_.ALT Content-Type: text/html; charset="us-ascii"
Philip is correct; however, note that routers that run separate SPF
calculations for each protocol type will behave identically to those
that do not in any network that meets the topology restrictions.
Their behavior differs only in networks that violate the restrictions.

Failing to form adjacencies based on protocol is not mentioned anywhere in
1195, and again is outside the scope based on the topology restrictions.
However, on a LAN where some routers form adjacencies per 10589
and others reject adjacencies based on protocols supported, the DR
election process is not guaranteed to succeed, so DR priority should
be carefully managed on such LANs.

Regards,
Jeff
 

At 08:41 AM 3/18/2002, Philip Christian wrote:
According to the topological restrictions of RFC 1195, if IPv4 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv4.
By the same logic, if IPv6 is to be routed in an area, then all of the ISs in the area must be capable of forwarding IPv6.
 
Therefore in your example, all of the nodes would have to be IPv4 and IPv6 capable, as both network-layer protocols appear in the area.
 
This topological restriction applies due to the following clause in section 3.10 of RFC 1195
 
"The Dijkstra computation does not take into consideration whether a router
is IP-only, OSI-only, or dual. The topological restrictions specified in
section 1.4 ensure that IP packets will only be sent via IP-capable
routers, and OSI packets will only be sent via OSI-capable routers."
 
In other words, seperate SPF calculations for IPv4 and IPv6 are not necessary, and in fact contrary to the above clause.
 
Not everyone may agree with this, but I believe that that is what it says.
 
What many vendors do do, is to gate adjacency formation on whether a neighbour supports at least one network-layer protocol in common with you.
This prevents a useless adjacency from forming (between an IPv4-only and an IPv6 only router).
This behaviour would appear to not be contrary to RFC 1195, and is fairly normal practise.
 
Philip
-----Original Message-----
From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
Sent: 18 March 2002 11:03
To: Isis-wg
Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area

Hello,

I have a question related to the support of IPv4/IPv6
mixed routing domains.

Every router will indicate inside its LSP what IP
version it is capable off using the 'protocols supported'
TLV: an IPv4-only router will indicate it supports
IPv4, and IPv6-only router will indicate it supports
IPv6 and an IPv4/IPv6 router indicates it supports both.

This 'protocols supported' TLV can be used inside the
SPF for a certain IP version (I assume that an IPv4/IPv6
router will need to run 2 SPFs, one for IPv4 and one for
IPv6) to determine whether ot not to take the related LSP
into account.

This mechanism will work fine as long as an IPv4/IPv6
capable router can forward both IPv4 and IPv6 traffic
on all its interfaces. Because of the 'node level' nature
of the 'protocols supported' TLV, it is not possible
to perform a correct calculation with IPv4/IPv6 routers
which have a mixture of IPv4-only and IPv6-only interfaces.
This can be shown easily with an example:

                +----+
                | R1 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (1)
                   |
                   |
                +----+
                | R2 | IPv4/IPv6
                +----+
                   |
                   | IPv4-only capable link (2)
                   |
                   |
                +----+
                | R3 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (3)
                   |
                   |
                +----+
                | R4 | IPv4/IPv6
                +----+
                  |
                  x

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and
(3) can forward IPv6 packets, link (2) can only forward IPv4
traffic. x is an IPv6 network address.

Suppose R1 is calculating a route to IPv6 network x. Because
of the fact that R2 and R3 are both generating an LSP which
indicates they are IPv6 capable, the resulting route to x will
be via R2 and R3. Although, the link (2) between R2 and R3 is
not capable of forwarding IPv6 traffic.

I went back to RFC 1195 1.4 'Support of Mixed Routing Domains',
because here similar problems occur. From what I understand
from this text, is that a dual router here can both forward
CLNS and IP on all its interfaces, although it is not specifically
stated.

In case we take this rule also for IPv4/IPv6 capable routers
(all interfaces are IPv4/IPv6 capable), there is of course no
problem. On the other hand, during the transition of IPv4
to IPv6 I can image a lot of routers which will have a
mixture of IPv4-only and IPv6-only interfaces.

As a solution for this problem we were considering of announcing
in every IS-reachablity TLV via a sub-TLV the capability of
that specific interface (again via 'protocols supported')?
This can be picked up in the SPF to decide whether or not
take that link into account for a certain IP version.
 

All suggestions/remarks/corrections are welcome.

Thanks,
Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg
--=====================_212817855==_.ALT-- From koen.vermeulen@alcatel.be Mon Mar 18 15:09:38 2002 From: koen.vermeulen@alcatel.be (Koen Vermeulen) Date: Mon, 18 Mar 2002 16:09:38 +0100 Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area References: Message-ID: <3C960332.C5AD648@alcatel.be> --------------C11ECE905FC5FD8750E75473 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, OK, I agree with the fact that in case we take the RFC 1195 topological restrictions into account (which means that in case we want to forward IPv6 traffic inside an area all routers need to be able to forward IPv6 traffic) only 1 SPF is required and we don't need to look at the 'protocols supported' TLV. However, this makes it hard according to me for the transition of an area from IPv4 to IPv6. This means that from the moment we want to forward IPv6 traffic through an area, all routers and all its interfaces needs to be IPv6 capable. I don't see immediately how this can work during transition. Any suggestions? Regards, Koen Koen Vermeulen wrote: > Hello, > > I have a question related to the support of IPv4/IPv6 > mixed routing domains. > > Every router will indicate inside its LSP what IP > version it is capable off using the 'protocols supported' > TLV: an IPv4-only router will indicate it supports > IPv4, and IPv6-only router will indicate it supports > IPv6 and an IPv4/IPv6 router indicates it supports both. > > This 'protocols supported' TLV can be used inside the > SPF for a certain IP version (I assume that an IPv4/IPv6 > router will need to run 2 SPFs, one for IPv4 and one for > IPv6) to determine whether ot not to take the related LSP > into account. > > This mechanism will work fine as long as an IPv4/IPv6 > capable router can forward both IPv4 and IPv6 traffic > on all its interfaces. Because of the 'node level' nature > of the 'protocols supported' TLV, it is not possible > to perform a correct calculation with IPv4/IPv6 routers > which have a mixture of IPv4-only and IPv6-only interfaces. > This can be shown easily with an example: > > +----+ > | R1 | IPv4/IPv6 > +----+ > | > | IPv6 capable link (1) > | > | > +----+ > | R2 | IPv4/IPv6 > +----+ > | > | IPv4-only capable link (2) > | > | > +----+ > | R3 | IPv4/IPv6 > +----+ > | > | IPv6 capable link (3) > | > | > +----+ > | R4 | IPv4/IPv6 > +----+ > | > x > > R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and > (3) can forward IPv6 packets, link (2) can only forward IPv4 > traffic. x is an IPv6 network address. > > Suppose R1 is calculating a route to IPv6 network x. Because > of the fact that R2 and R3 are both generating an LSP which > indicates they are IPv6 capable, the resulting route to x will > be via R2 and R3. Although, the link (2) between R2 and R3 is > not capable of forwarding IPv6 traffic. > > I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', > because here similar problems occur. From what I understand > from this text, is that a dual router here can both forward > CLNS and IP on all its interfaces, although it is not specifically > stated. > > In case we take this rule also for IPv4/IPv6 capable routers > (all interfaces are IPv4/IPv6 capable), there is of course no > problem. On the other hand, during the transition of IPv4 > to IPv6 I can image a lot of routers which will have a > mixture of IPv4-only and IPv6-only interfaces. > > As a solution for this problem we were considering of announcing > in every IS-reachablity TLV via a sub-TLV the capability of > that specific interface (again via 'protocols supported')? > This can be picked up in the SPF to decide whether or not > take that link into account for a certain IP version. > > > All suggestions/remarks/corrections are welcome. > > Thanks, > Koen _______________________________________________ Isis-wg mailing > list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg --------------C11ECE905FC5FD8750E75473 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,

OK, I agree with the fact that in case we take the RFC 1195 topological
restrictions into account (which means that in case we want to forward
IPv6 traffic inside an area all routers need to be able to forward IPv6
traffic) only 1 SPF is required and we don't need to look at the
'protocols supported' TLV.
However, this makes it hard according to me for the transition of an
area from IPv4 to IPv6. This means that from the moment we want
to forward IPv6 traffic through an area, all routers and all its interfaces
needs to be IPv6 capable.

I don't see immediately how this can work during transition.

Any suggestions?

Regards,
Koen

Koen Vermeulen wrote:

Hello,

I have a question related to the support of IPv4/IPv6
mixed routing domains.

Every router will indicate inside its LSP what IP
version it is capable off using the 'protocols supported'
TLV: an IPv4-only router will indicate it supports
IPv4, and IPv6-only router will indicate it supports
IPv6 and an IPv4/IPv6 router indicates it supports both.

This 'protocols supported' TLV can be used inside the
SPF for a certain IP version (I assume that an IPv4/IPv6
router will need to run 2 SPFs, one for IPv4 and one for
IPv6) to determine whether ot not to take the related LSP
into account.

This mechanism will work fine as long as an IPv4/IPv6
capable router can forward both IPv4 and IPv6 traffic
on all its interfaces. Because of the 'node level' nature
of the 'protocols supported' TLV, it is not possible
to perform a correct calculation with IPv4/IPv6 routers
which have a mixture of IPv4-only and IPv6-only interfaces.
This can be shown easily with an example:

                +----+
                | R1 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (1)
                   |
                   |
                +----+
                | R2 | IPv4/IPv6
                +----+
                   |
                   | IPv4-only capable link (2)
                   |
                   |
                +----+
                | R3 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (3)
                   |
                   |
                +----+
                | R4 | IPv4/IPv6
                +----+
                  |
                  x

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and
(3) can forward IPv6 packets, link (2) can only forward IPv4
traffic. x is an IPv6 network address.

Suppose R1 is calculating a route to IPv6 network x. Because
of the fact that R2 and R3 are both generating an LSP which
indicates they are IPv6 capable, the resulting route to x will
be via R2 and R3. Although, the link (2) between R2 and R3 is
not capable of forwarding IPv6 traffic.

I went back to RFC 1195 1.4 'Support of Mixed Routing Domains',
because here similar problems occur. From what I understand
from this text, is that a dual router here can both forward
CLNS and IP on all its interfaces, although it is not specifically
stated.

In case we take this rule also for IPv4/IPv6 capable routers
(all interfaces are IPv4/IPv6 capable), there is of course no
problem. On the other hand, during the transition of IPv4
to IPv6 I can image a lot of routers which will have a
mixture of IPv4-only and IPv6-only interfaces.

As a solution for this problem we were considering of announcing
in every IS-reachablity TLV via a sub-TLV the capability of
that specific interface (again via 'protocols supported')?
This can be picked up in the SPF to decide whether or not
take that link into account for a certain IP version.
 

All suggestions/remarks/corrections are welcome.

Thanks,
Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg

--------------C11ECE905FC5FD8750E75473-- From Larmer@CommSense.Net Mon Mar 18 15:39:34 2002 From: Larmer@CommSense.Net (Ken Larmer) Date: Mon, 18 Mar 2002 10:39:34 -0500 Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area In-Reply-To: <3C960332.C5AD648@alcatel.be> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C1CE69.31DADF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Koen, RFC-1195 states the following: 4.4 Maintaining Router Adjacencies ... ... ... Dual routers must operate in a dual fashion on every link in the routing domain over which they are running IS-IS. Thus, the value of the "protocols supported" field must be identical on every link(i.e., for any one router running IS-IS, all of the Hellos and LSPs transmitted by it must contain the same "protocols supported" values). Cheers, Ken Larmer CommSense Networks -----Original Message----- From: isis-wg-admin@external.juniper.net [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Koen Vermeulen Sent: Monday, March 18, 2002 10:10 AM To: Isis-wg Subject: Re: [Isis-wg] Ipv4/Ipv6 routers in 1 area Hello, OK, I agree with the fact that in case we take the RFC 1195 topological restrictions into account (which means that in case we want to forward IPv6 traffic inside an area all routers need to be able to forward IPv6 traffic) only 1 SPF is required and we don't need to look at the 'protocols supported' TLV. However, this makes it hard according to me for the transition of an area from IPv4 to IPv6. This means that from the moment we want to forward IPv6 traffic through an area, all routers and all its interfaces needs to be IPv6 capable. I don't see immediately how this can work during transition. Any suggestions? Regards, Koen Koen Vermeulen wrote: Hello, I have a question related to the support of IPv4/IPv6 mixed routing domains. Every router will indicate inside its LSP what IP version it is capable off using the 'protocols supported' TLV: an IPv4-only router will indicate it supports IPv4, and IPv6-only router will indicate it supports IPv6 and an IPv4/IPv6 router indicates it supports both. This 'protocols supported' TLV can be used inside the SPF for a certain IP version (I assume that an IPv4/IPv6 router will need to run 2 SPFs, one for IPv4 and one for IPv6) to determine whether ot not to take the related LSP into account. This mechanism will work fine as long as an IPv4/IPv6 capable router can forward both IPv4 and IPv6 traffic on all its interfaces. Because of the 'node level' nature of the 'protocols supported' TLV, it is not possible to perform a correct calculation with IPv4/IPv6 routers which have a mixture of IPv4-only and IPv6-only interfaces. This can be shown easily with an example: +----+ | R1 | IPv4/IPv6 +----+ | | IPv6 capable link (1) | | +----+ | R2 | IPv4/IPv6 +----+ | | IPv4-only capable link (2) | | +----+ | R3 | IPv4/IPv6 +----+ | | IPv6 capable link (3) | | +----+ | R4 | IPv4/IPv6 +----+ | x R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and (3) can forward IPv6 packets, link (2) can only forward IPv4 traffic. x is an IPv6 network address. Suppose R1 is calculating a route to IPv6 network x. Because of the fact that R2 and R3 are both generating an LSP which indicates they are IPv6 capable, the resulting route to x will be via R2 and R3. Although, the link (2) between R2 and R3 is not capable of forwarding IPv6 traffic. I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', because here similar problems occur. From what I understand from this text, is that a dual router here can both forward CLNS and IP on all its interfaces, although it is not specifically stated. In case we take this rule also for IPv4/IPv6 capable routers (all interfaces are IPv4/IPv6 capable), there is of course no problem. On the other hand, during the transition of IPv4 to IPv6 I can image a lot of routers which will have a mixture of IPv4-only and IPv6-only interfaces. As a solution for this problem we were considering of announcing in every IS-reachablity TLV via a sub-TLV the capability of that specific interface (again via 'protocols supported')? This can be picked up in the SPF to decide whether or not take that link into account for a certain IP version. All suggestions/remarks/corrections are welcome. Thanks, Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------=_NextPart_000_0018_01C1CE69.31DADF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Koen,
 
RFC-1195 states the = following:=20
=20
 4.4 Maintaining Router Adjacencies=20
...=20
...=20
...=20
Dual routers must operate in a dual fashion on every link in = the routing = domain over=20 which they are running IS-IS. Thus, the value of=20 the "protocols supported" = field must be=20 identical on every link(i.e., for any one router running IS-IS, all of = the=20 Hellos and LSPs   = transmitted by it=20 must contain the same "protocols supported"  =20 values).


 
Cheers, =
Ken Larmer=20
CommSense Networks
-----Original Message-----
From:=20 isis-wg-admin@external.juniper.net=20 [mailto:isis-wg-admin@external.juniper.net]On Behalf Of Koen=20 Vermeulen
Sent: Monday, March 18, 2002 10:10 = AM
To:=20 Isis-wg
Subject: Re: [Isis-wg] Ipv4/Ipv6 routers in 1=20 area

Hello,=20

OK, I agree with the fact that in case we take the RFC 1195 = topological=20
restrictions into account (which means that in case we want to = forward=20
IPv6 traffic inside an area all routers need to be able to forward = IPv6=20
traffic) only 1 SPF is required and we don't need to look at the=20
'protocols supported' TLV.
However, this makes it hard = according to me=20 for the transition of an
area from IPv4 to IPv6. This means that = from the=20 moment we want
to forward IPv6 traffic through an area, all = routers=20 and all its interfaces
needs to be IPv6 capable.=20

I don't see immediately how this can work during transition.=20

Any suggestions?=20

Regards,
Koen=20

Koen Vermeulen wrote:=20

Hello,=20

I have a question related to the support of IPv4/IPv6=20
mixed routing domains.=20

Every router will indicate inside its LSP what IP=20
version it is capable off using the 'protocols = supported'=20
TLV: an IPv4-only router will indicate it supports=20
IPv4, and IPv6-only router will indicate it supports=20
IPv6 and an IPv4/IPv6 router indicates it supports = both.=20

This 'protocols supported' TLV can be used inside the=20
SPF for a certain IP version (I assume that an = IPv4/IPv6=20
router will need to run 2 SPFs, one for IPv4 and one = for=20
IPv6) to determine whether ot not to take the related = LSP=20
into account.=20

This mechanism will work fine as long as an IPv4/IPv6=20
capable router can forward both IPv4 and IPv6 traffic=20
on all its interfaces. Because of the 'node level' = nature=20
of the 'protocols supported' TLV, it is not possible =
to=20 perform a correct calculation with IPv4/IPv6 routers =
which have=20 a mixture of IPv4-only and IPv6-only interfaces.
This = can be=20 shown easily with an example:=20 =

           =     =20 +----+=20 =
           = ;    =20 | R1 | IPv4/IPv6=20 =
           = ;    =20 +----+=20 =
           = ;       =20 |=20 =
           = ;       =20 | IPv6 capable link (1)=20 =
           = ;       =20 |=20 =
           = ;       =20 |=20 =
           = ;    =20 +----+=20 =
           = ;    =20 | R2 | IPv4/IPv6=20 =
           = ;    =20 +----+=20 =
           = ;       =20 |=20 =
           = ;       =20 | IPv4-only capable link (2)=20 =
           = ;       =20 |=20 =
           = ;       =20 |=20 =
           = ;    =20 +----+=20 =
           = ;    =20 | R3 | IPv4/IPv6=20 =
           = ;    =20 +----+=20 =
           = ;       =20 |=20 =
           = ;       =20 | IPv6 capable link (3)=20 =
           = ;       =20 |=20 =
           = ;       =20 |=20 =
           = ;    =20 +----+=20 =
           = ;    =20 | R4 | IPv4/IPv6=20 =
           = ;    =20 +----+=20 =
           = ;      =20 |=20 =
           = ;      =20 x=20

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) = and=20
(3) can forward IPv6 packets, link (2) can only forward = IPv4=20
traffic. x is an IPv6 network address.=20

Suppose R1 is calculating a route to IPv6 network x. = Because=20
of the fact that R2 and R3 are both generating an LSP = which=20
indicates they are IPv6 capable, the resulting route to x = will=20
be via R2 and R3. Although, the link (2) between R2 and R3 = is=20
not capable of forwarding IPv6 traffic.=20

I went back to RFC 1195 1.4 'Support of Mixed Routing = Domains',=20
because here similar problems occur. From what I = understand=20
from this text, is that a dual router here can both = forward=20
CLNS and IP on all its interfaces, although it is not=20 specifically
stated.=20

In case we take this rule also for IPv4/IPv6 capable = routers=20
(all interfaces are IPv4/IPv6 capable), there is of course = no=20
problem. On the other hand, during the transition of = IPv4=20
to IPv6 I can image a lot of routers which will have a=20
mixture of IPv4-only and IPv6-only interfaces.=20

As a solution for this problem we were considering of = announcing=20
in every IS-reachablity TLV via a sub-TLV the capability = of=20
that specific interface (again via 'protocols = supported')?=20
This can be picked up in the SPF to decide whether or = not=20
take that link into account for a certain IP version.=20
 =20

All suggestions/remarks/corrections are welcome.=20

Thanks,
Koen=20 _______________________________________________ Isis-wg mailing list = -=20 Isis-wg@spider.juniper.net http://spider= .juniper.net/mailman/listinfo/isis-wg

------=_NextPart_000_0018_01C1CE69.31DADF00-- From jlearman@cisco.com Mon Mar 18 16:25:08 2002 From: jlearman@cisco.com (Jeff Learman) Date: Mon, 18 Mar 2002 11:25:08 -0500 Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area In-Reply-To: <3C960332.C5AD648@alcatel.be> References: Message-ID: <4.3.2.7.2.20020318111308.03d43ee8@dingdong.cisco.com> --=====================_219337240==_.ALT Content-Type: text/plain; charset="us-ascii" I agree, I suspect that 1195's restrictions are unnecessarily severe, and that they won't serve us well for migrating to IPV6. I think this is a very important discussion for us to be having. There are two restrictions that we need to consider: 1. Interface rules (a router must support all "supported protocols" on all interfaces) 2. Area / Domain rules (need I list them here?) A third consideration that is important is whether adjacency establishment should be a function of protocols supported. While it seems sensible to do this, it would break the DR election process. I hesitate to recommend changing restriction 1, but if it would be completely impractical to stand on this rule, we need to know about it. I'd really like input from service providers here. The second rule is easy to violate; some implementations already do. Those that do behave identically as those that don't, when deployed in a network that meets the restrictions. You can't deploy a router that doesn't violate the second restriction (i.e., a router that runs a single SPF) in a network that violates the rules, of course, so compatibility issues shouldn't be a problem here. Regards, Jeff At 10:09 AM 3/18/2002, Koen Vermeulen wrote: >Hello, > >OK, I agree with the fact that in case we take the RFC 1195 topological >restrictions into account (which means that in case we want to forward >IPv6 traffic inside an area all routers need to be able to forward IPv6 >traffic) only 1 SPF is required and we don't need to look at the >'protocols supported' TLV. >However, this makes it hard according to me for the transition of an >area from IPv4 to IPv6. This means that from the moment we want >to forward IPv6 traffic through an area, all routers and all its interfaces >needs to be IPv6 capable. > >I don't see immediately how this can work during transition. > >Any suggestions? > >Regards, >Koen > >Koen Vermeulen wrote: >>Hello, >> >>I have a question related to the support of IPv4/IPv6 >>mixed routing domains. >> >>Every router will indicate inside its LSP what IP >>version it is capable off using the 'protocols supported' >>TLV: an IPv4-only router will indicate it supports >>IPv4, and IPv6-only router will indicate it supports >>IPv6 and an IPv4/IPv6 router indicates it supports both. >> >>This 'protocols supported' TLV can be used inside the >>SPF for a certain IP version (I assume that an IPv4/IPv6 >>router will need to run 2 SPFs, one for IPv4 and one for >>IPv6) to determine whether ot not to take the related LSP >>into account. >> >>This mechanism will work fine as long as an IPv4/IPv6 >>capable router can forward both IPv4 and IPv6 traffic >>on all its interfaces. Because of the 'node level' nature >>of the 'protocols supported' TLV, it is not possible >>to perform a correct calculation with IPv4/IPv6 routers >>which have a mixture of IPv4-only and IPv6-only interfaces. >>This can be shown easily with an example: >> >> +----+ >> | R1 | IPv4/IPv6 >> +----+ >> | >> | IPv6 capable link (1) >> | >> | >> +----+ >> | R2 | IPv4/IPv6 >> +----+ >> | >> | IPv4-only capable link (2) >> | >> | >> +----+ >> | R3 | IPv4/IPv6 >> +----+ >> | >> | IPv6 capable link (3) >> | >> | >> +----+ >> | R4 | IPv4/IPv6 >> +----+ >> | >> x >> >>R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and >>(3) can forward IPv6 packets, link (2) can only forward IPv4 >>traffic. x is an IPv6 network address. >> >>Suppose R1 is calculating a route to IPv6 network x. Because >>of the fact that R2 and R3 are both generating an LSP which >>indicates they are IPv6 capable, the resulting route to x will >>be via R2 and R3. Although, the link (2) between R2 and R3 is >>not capable of forwarding IPv6 traffic. >> >>I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', >>because here similar problems occur. From what I understand >>from this text, is that a dual router here can both forward >>CLNS and IP on all its interfaces, although it is not specifically >>stated. >> >>In case we take this rule also for IPv4/IPv6 capable routers >>(all interfaces are IPv4/IPv6 capable), there is of course no >>problem. On the other hand, during the transition of IPv4 >>to IPv6 I can image a lot of routers which will have a >>mixture of IPv4-only and IPv6-only interfaces. >> >>As a solution for this problem we were considering of announcing >>in every IS-reachablity TLV via a sub-TLV the capability of >>that specific interface (again via 'protocols supported')? >>This can be picked up in the SPF to decide whether or not >>take that link into account for a certain IP version. >> >> >>All suggestions/remarks/corrections are welcome. >> >>Thanks, >>Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg --=====================_219337240==_.ALT Content-Type: text/html; charset="us-ascii"
I agree, I suspect that 1195's restrictions are unnecessarily severe,
and that they won't serve us well for migrating to IPV6.  I think this
is a very important discussion for us to be having.

There are two restrictions that we need to consider:

  1.  Interface rules (a router must support all "supported protocols"
      on all interfaces)

  2.  Area / Domain rules (need I list them here?)

A third consideration that is important is whether adjacency establishment
should be a function of protocols supported.  While it seems sensible to
do this, it would break the DR election process.

I hesitate to recommend changing restriction 1, but if it would be
completely impractical to stand on this rule, we need to know about it.
I'd really like input from service providers here.

The second rule is easy to violate; some implementations already do.
Those that do behave identically as those that don't, when deployed in
a network that meets the restrictions.  You can't deploy a router that
doesn't violate the second restriction (i.e., a router that runs a single
SPF) in a network that violates the rules, of course, so compatibility
issues shouldn't be a problem here.

Regards,
Jeff

At 10:09 AM 3/18/2002, Koen Vermeulen wrote:
Hello,

OK, I agree with the fact that in case we take the RFC 1195 topological
restrictions into account (which means that in case we want to forward
IPv6 traffic inside an area all routers need to be able to forward IPv6
traffic) only 1 SPF is required and we don't need to look at the
'protocols supported' TLV.
However, this makes it hard according to me for the transition of an
area from IPv4 to IPv6. This means that from the moment we want
to forward IPv6 traffic through an area, all routers and all its interfaces
needs to be IPv6 capable.

I don't see immediately how this can work during transition.

Any suggestions?

Regards,
Koen

Koen Vermeulen wrote:
Hello,

I have a question related to the support of IPv4/IPv6
mixed routing domains.

Every router will indicate inside its LSP what IP
version it is capable off using the 'protocols supported'
TLV: an IPv4-only router will indicate it supports
IPv4, and IPv6-only router will indicate it supports
IPv6 and an IPv4/IPv6 router indicates it supports both.

This 'protocols supported' TLV can be used inside the
SPF for a certain IP version (I assume that an IPv4/IPv6
router will need to run 2 SPFs, one for IPv4 and one for
IPv6) to determine whether ot not to take the related LSP
into account.

This mechanism will work fine as long as an IPv4/IPv6
capable router can forward both IPv4 and IPv6 traffic
on all its interfaces. Because of the 'node level' nature
of the 'protocols supported' TLV, it is not possible
to perform a correct calculation with IPv4/IPv6 routers
which have a mixture of IPv4-only and IPv6-only interfaces.
This can be shown easily with an example:

                +----+
                | R1 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (1)
                   |
                   |
                +----+
                | R2 | IPv4/IPv6
                +----+
                   |
                   | IPv4-only capable link (2)
                   |
                   |
                +----+
                | R3 | IPv4/IPv6
                +----+
                   |
                   | IPv6 capable link (3)
                   |
                   |
                +----+
                | R4 | IPv4/IPv6
                +----+
                  |
                  x

R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and
(3) can forward IPv6 packets, link (2) can only forward IPv4
traffic. x is an IPv6 network address.

Suppose R1 is calculating a route to IPv6 network x. Because
of the fact that R2 and R3 are both generating an LSP which
indicates they are IPv6 capable, the resulting route to x will
be via R2 and R3. Although, the link (2) between R2 and R3 is
not capable of forwarding IPv6 traffic.

I went back to RFC 1195 1.4 'Support of Mixed Routing Domains',
because here similar problems occur. From what I understand
from this text, is that a dual router here can both forward
CLNS and IP on all its interfaces, although it is not specifically
stated.

In case we take this rule also for IPv4/IPv6 capable routers
(all interfaces are IPv4/IPv6 capable), there is of course no
problem. On the other hand, during the transition of IPv4
to IPv6 I can image a lot of routers which will have a
mixture of IPv4-only and IPv6-only interfaces.

As a solution for this problem we were considering of announcing
in every IS-reachablity TLV via a sub-TLV the capability of
that specific interface (again via 'protocols supported')?
This can be picked up in the SPF to decide whether or not
take that link into account for a certain IP version.
 

All suggestions/remarks/corrections are welcome.

Thanks,
Koen _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg
--=====================_219337240==_.ALT-- From naiming@redback.com Mon Mar 18 17:36:25 2002 From: naiming@redback.com (Naiming Shen) Date: Mon, 18 Mar 2002 09:36:25 -0800 Subject: [Isis-wg] Ipv4/Ipv6 routers in 1 area In-Reply-To: Mail from Koen Vermeulen dated Mon, 18 Mar 2002 16:09:38 +0100 <3C960332.C5AD648@alcatel.be> Message-ID: <20020318173625.E341F1DCC71@prattle.redback.com> ] ] Hello, ] ] OK, I agree with the fact that in case we take the RFC 1195 topological ] restrictions into account (which means that in case we want to forward ] IPv6 traffic inside an area all routers need to be able to forward IPv6 ] traffic) only 1 SPF is required and we don't need to look at the ] 'protocols supported' TLV. ] However, this makes it hard according to me for the transition of an ] area from IPv4 to IPv6. This means that from the moment we want ] to forward IPv6 traffic through an area, all routers and all its ] interfaces ] needs to be IPv6 capable. ] ] I don't see immediately how this can work during transition. ] ] Any suggestions? please take a look at: draft-ietf-isis-wg-multi-topology-02.txt to see if your problem is solved by using M-ISIS. ] ] Regards, ] Koen ] ] Koen Vermeulen wrote: ] ] > Hello, ] > ] > I have a question related to the support of IPv4/IPv6 ] > mixed routing domains. ] > ] > Every router will indicate inside its LSP what IP ] > version it is capable off using the 'protocols supported' ] > TLV: an IPv4-only router will indicate it supports ] > IPv4, and IPv6-only router will indicate it supports ] > IPv6 and an IPv4/IPv6 router indicates it supports both. ] > ] > This 'protocols supported' TLV can be used inside the ] > SPF for a certain IP version (I assume that an IPv4/IPv6 ] > router will need to run 2 SPFs, one for IPv4 and one for ] > IPv6) to determine whether ot not to take the related LSP ] > into account. ] > ] > This mechanism will work fine as long as an IPv4/IPv6 ] > capable router can forward both IPv4 and IPv6 traffic ] > on all its interfaces. Because of the 'node level' nature ] > of the 'protocols supported' TLV, it is not possible ] > to perform a correct calculation with IPv4/IPv6 routers ] > which have a mixture of IPv4-only and IPv6-only interfaces. ] > This can be shown easily with an example: ] > ] > +----+ ] > | R1 | IPv4/IPv6 ] > +----+ ] > | ] > | IPv6 capable link (1) ] > | ] > | ] > +----+ ] > | R2 | IPv4/IPv6 ] > +----+ ] > | ] > | IPv4-only capable link (2) ] > | ] > | ] > +----+ ] > | R3 | IPv4/IPv6 ] > +----+ ] > | ] > | IPv6 capable link (3) ] > | ] > | ] > +----+ ] > | R4 | IPv4/IPv6 ] > +----+ ] > | ] > x ] > ] > R1, R2, R3 and R4 are IPv4/IPv6 capable routers. Links (1) and ] > (3) can forward IPv6 packets, link (2) can only forward IPv4 ] > traffic. x is an IPv6 network address. ] > ] > Suppose R1 is calculating a route to IPv6 network x. Because ] > of the fact that R2 and R3 are both generating an LSP which ] > indicates they are IPv6 capable, the resulting route to x will ] > be via R2 and R3. Although, the link (2) between R2 and R3 is ] > not capable of forwarding IPv6 traffic. ] > ] > I went back to RFC 1195 1.4 'Support of Mixed Routing Domains', ] > because here similar problems occur. From what I understand ] > from this text, is that a dual router here can both forward ] > CLNS and IP on all its interfaces, although it is not specifically ] > stated. ] > ] > In case we take this rule also for IPv4/IPv6 capable routers ] > (all interfaces are IPv4/IPv6 capable), there is of course no ] > problem. On the other hand, during the transition of IPv4 ] > to IPv6 I can image a lot of routers which will have a ] > mixture of IPv4-only and IPv6-only interfaces. ] > ] > As a solution for this problem we were considering of announcing ] > in every IS-reachablity TLV via a sub-TLV the capability of ] > that specific interface (again via 'protocols supported')? ] > This can be picked up in the SPF to decide whether or not ] > take that link into account for a certain IP version. ] > ] > ] > All suggestions/remarks/corrections are welcome. ] > ] > Thanks, ] > Koen _______________________________________________ Isis-wg mailing ] > list - Isis-wg@spider.juniper.net ] > http://spider.juniper.net/mailman/listinfo/isis-wg ] - Naiming From Ravindra.Sunkad@vivacenetworks.com Mon Mar 18 18:09:41 2002 From: Ravindra.Sunkad@vivacenetworks.com (Ravindra Sunkad) Date: Mon, 18 Mar 2002 10:09:41 -0800 Subject: [Isis-wg] Extended IP Reachability question Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C1CEA8.1311AE3D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I haven't seen any responses in regards to the following thread. So, I'm assuming that no such sub-tlv has been defined so far. I propose a color/tag sub-tlv for the Extended IP Reachability TLV. This will be similar to the "Administrative group" sub-tlv defined=20 for the Extended IS Reachability TLV. It contains a 4-octet bit mask. The least significant bit is defined to indicate whether the IP prefix is outside the IS-IS routing domain. =20 Please provide me your inputs. =20 Thanks, Ravi =20 -----Original Message----- From: Ravindra Sunkad=20 Sent: Thursday, March 14, 2002 11:11 AM To: isis-wg@juniper.net Subject: [Isis-wg] Extended IP Reachability question Hi, =20 In the following threads there is some talk about defining a sub-tlv for the Extended IP Reachability TLV that could be used to differentiate external route advertisements from internal route advertisements. Has any work been done on this front? =20 http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 =20 [Isis-wg] IS-IS Extensions for Traffic Engineering [Isis-wg] draft-ietf-isis-traffic-01.txt=20 =20 Thanks, Ravi ------_=_NextPart_001_01C1CEA8.1311AE3D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 haven't seen any responses in regards to the following thread. So, I'm = assuming=20 that no such sub-tlv has been defined so far.
I=20 propose a color/tag sub-tlv for the Extended IP Reachability = TLV. This will=20 be similar to the "Administrative group" sub-tlv defined =
for=20 the Extended IS Reachability TLV. It contains a 4-octet bit mask. The = least=20 significant bit is defined to indicate whether the IP=20 prefix
is=20 outside the IS-IS routing domain.
 
Please=20 provide me your inputs.
 
Thanks,
Ravi
 
-----Original = Message-----
From:=20 Ravindra Sunkad
Sent: Thursday, March 14, 2002 11:11 = AM
To:=20 isis-wg@juniper.net
Subject: [Isis-wg] Extended IP = Reachability=20 question

Hi,

 

In the following = threads=20 there is some talk about defining a sub-tlv for the Extended IP = Reachability=20 TLV that could be used to differentiate external route advertisements = from=20 internal route advertisements. Has any work been done on this=20 front?

 

= http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31

 

[Isis-wg] IS-IS = Extensions=20 for Traffic Engineering

[Isis-wg]=20 draft-ietf-isis-traffic-01.txt

 

Thanks,

Ravi

=00 ------_=_NextPart_001_01C1CEA8.1311AE3D-- From tli@procket.com Mon Mar 18 21:03:05 2002 From: tli@procket.com (Tony Li) Date: Mon, 18 Mar 2002 13:03:05 -0800 Subject: [Isis-wg] Extended IP Reachability question In-Reply-To: References: Message-ID: <15510.22025.927785.672153@alpha-tli.procket.com> Why? Tony Ravindra Sunkad writes: | I haven't seen any responses in regards to the following thread. So, I'm | assuming that no such sub-tlv has been defined so far. | I propose a color/tag sub-tlv for the Extended IP Reachability TLV. This | will be similar to the "Administrative group" sub-tlv defined | for the Extended IS Reachability TLV. It contains a 4-octet bit mask. | The least significant bit is defined to indicate whether the IP prefix | is outside the IS-IS routing domain. | | Please provide me your inputs. | | Thanks, | Ravi | | -----Original Message----- | From: Ravindra Sunkad | Sent: Thursday, March 14, 2002 11:11 AM | To: isis-wg@juniper.net | Subject: [Isis-wg] Extended IP Reachability question | | | | Hi, | | | | In the following threads there is some talk about defining a | sub-tlv for the Extended IP Reachability TLV that could be used to | differentiate external route advertisements from internal route | advertisements. Has any work been done on this front? | | | | http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 | | | | [Isis-wg] IS-IS Extensions for Traffic Engineering | | [Isis-wg] draft-ietf-isis-traffic-01.txt | | | | Thanks, | | Ravi | | | Message | | | | | |
I | haven't seen any responses in regards to the following thread. So, I'm assuming | that no such sub-tlv has been defined so far.
|
I | propose a color/tag sub-tlv for the Extended IP Reachability TLV. This will | be similar to the "Administrative group" sub-tlv defined
|
for | the Extended IS Reachability TLV. It contains a 4-octet bit mask. The least | significant bit is defined to indicate whether the IP | prefix
|
is | outside the IS-IS routing domain.
|
 
|
Please | provide me your inputs.
|
 
|
Thanks,
|
Ravi
|
 
|
-----Original Message-----
From: | Ravindra Sunkad
Sent: Thursday, March 14, 2002 11:11 AM
To: | isis-wg@juniper.net
Subject: [Isis-wg] Extended IP Reachability | question

|
|
|

Hi,

|

 

|

In the following threads | there is some talk about defining a sub-tlv for the Extended IP Reachability | TLV that could be used to differentiate external route advertisements from | internal route advertisements. Has any work been done on this | front?

|

 

|

http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31

|

 

|

[Isis-wg] IS-IS Extensions | for Traffic Engineering

|

[Isis-wg] | draft-ietf-isis-traffic-01.txt

|

 

|

Thanks,

|

Ravi

| From cmartin@gnilink.net Mon Mar 18 21:27:16 2002 From: cmartin@gnilink.net (Martin, Christian) Date: Mon, 18 Mar 2002 16:27:16 -0500 Subject: [Isis-wg] Extended IP Reachability question Message-ID: <94B9091E1149D411A45C00508BACEB35015F2C82@entmail.gnilink.com> See http://search.ietf.org/internet-drafts/draft-martin-neal-policy-isis-admin-t ags-04.txt for this type of information. How the vendor implements the policy is up to the vendor, but matching internal vs external and tagging shouldn't be an issue during LSP creation. chris -----Original Message----- From: Ravindra Sunkad [mailto:Ravindra.Sunkad@vivacenetworks.com] Sent: Monday, March 18, 2002 1:10 PM To: isis-wg@juniper.net Subject: RE: [Isis-wg] Extended IP Reachability question I haven't seen any responses in regards to the following thread. So, I'm assuming that no such sub-tlv has been defined so far. I propose a color/tag sub-tlv for the Extended IP Reachability TLV. This will be similar to the "Administrative group" sub-tlv defined for the Extended IS Reachability TLV. It contains a 4-octet bit mask. The least significant bit is defined to indicate whether the IP prefix is outside the IS-IS routing domain. Please provide me your inputs. Thanks, Ravi -----Original Message----- From: Ravindra Sunkad Sent: Thursday, March 14, 2002 11:11 AM To: isis-wg@juniper.net Subject: [Isis-wg] Extended IP Reachability question Hi, In the following threads there is some talk about defining a sub-tlv for the Extended IP Reachability TLV that could be used to differentiate external route advertisements from internal route advertisements. Has any work been done on this front? http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 [Isis-wg] IS-IS Extensions for Traffic Engineering [Isis-wg] draft-ietf-isis-traffic-01.txt Thanks, Ravi From Ravindra.Sunkad@vivacenetworks.com Mon Mar 18 22:00:02 2002 From: Ravindra.Sunkad@vivacenetworks.com (Ravindra Sunkad) Date: Mon, 18 Mar 2002 14:00:02 -0800 Subject: [Isis-wg] Extended IP Reachability question Message-ID: When IS-IS routes are redistributed to other protocols this piece of information can be useful and could serve as an additional filter. Also, we might want to create LDP LSPs only for internal prefixes. Ravi > -----Original Message----- > From: Tony Li [mailto:tli@procket.com] > Sent: Monday, March 18, 2002 1:03 PM > To: Ravindra Sunkad > Cc: isis-wg@juniper.net > Subject: RE: [Isis-wg] Extended IP Reachability question > > > > > Why? > > Tony > > > > Ravindra Sunkad writes: > | I haven't seen any responses in regards to the following > thread. So, I'm | assuming that no such sub-tlv has been > defined so far. | I propose a color/tag sub-tlv for the > Extended IP Reachability TLV. This | will be similar to the > "Administrative group" sub-tlv defined > | for the Extended IS Reachability TLV. It contains a > 4-octet bit mask. | The least significant bit is defined to > indicate whether the IP prefix | is outside the IS-IS > routing domain. | > | Please provide me your inputs. > | > | Thanks, > | Ravi > | > | -----Original Message----- > | From: Ravindra Sunkad > | Sent: Thursday, March 14, 2002 11:11 AM > | To: isis-wg@juniper.net > | Subject: [Isis-wg] Extended IP Reachability question > | > | > | > | Hi, > | > | > | > | In the following threads there is some talk about defining a > | sub-tlv for the Extended IP Reachability TLV that could be > used to | differentiate external route advertisements from > internal route | advertisements. Has any work been done on > this front? | > | > | > | http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 > | > | > | > | [Isis-wg] IS-IS Extensions for Traffic Engineering > | > | [Isis-wg] draft-ietf-isis-traffic-01.txt > | > | > | > | Thanks, > | > | Ravi > | > | Transitional//EN"> | Message > | | name=GENERATOR> | > | > | > |
class=890335817-18032002>I > | haven't seen any responses in regards to the following > thread. So, I'm assuming > | that no such sub-tlv has been defined so > far.
|
color=#0000ff size=2>I > | propose a color/tag sub-tlv for the Extended IP > Reachability TLV. This will > | be similar to the "Administrative group" sub-tlv defined >
|
size=2>for > | the Extended IS Reachability TLV. It contains a 4-octet > bit mask. The least > | significant bit is defined to indicate whether the IP > | prefix
> |
class=890335817-18032002>is > | outside the IS-IS routing domain.
> |
| class=890335817-18032002> 
> |
class=890335817-18032002>Please > | provide me your inputs.
> |
| class=890335817-18032002> 
> |
| class=890335817-18032002>Thanks,
> |
| class=890335817-18032002>Ravi
> |
| class=890335817-18032002> 
> |
-----Original > Message-----
From: > | Ravindra Sunkad
Sent: Thursday, March 14, 2002 > 11:11 AM
To: > | isis-wg@juniper.net
Subject: [Isis-wg] Extended > IP Reachability > | question

> |
| style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: > #0000ff 2px solid; MARGIN-RIGHT: 0px"> > |
> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier > New'">Hi,

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier > New'"> 

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">In > the following threads > | there is some talk about defining a sub-tlv for the > Extended IP Reachability > | TLV that could be used to differentiate external route > advertisements from > | internal route advertisements. Has any work been done on this > | front?

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier > New'"> 

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"> | > href="http://spider.juniper.net/pipermail/isis-wg/1999/thread. > html#31">http://spider.juniper.net/pipermail/isis-wg/1999/thre > ad.html#31

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier > New'"> 

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier > New'">[Isis-wg] IS-IS Extensions > | for Traffic Engineering

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">[Isis-wg] > | draft-ietf-isis-traffic-01.txt

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: > Arial"> 

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: > Arial">Thanks,

> |

| style="FONT-SIZE: 10pt; FONT-FAMILY: > Arial">Ravi

> | > From Ravindra.Sunkad@vivacenetworks.com Mon Mar 18 22:15:53 2002 From: Ravindra.Sunkad@vivacenetworks.com (Ravindra Sunkad) Date: Mon, 18 Mar 2002 14:15:53 -0800 Subject: [Isis-wg] Extended IP Reachability question Message-ID: Chris, Thanks. This could work. But it would be good if everybody automatically originates a predefined sub-tlv tagging prefixes as external. i.e. I prefer this sub-tlv not be administrative. Ravi > -----Original Message----- > From: Martin, Christian [mailto:cmartin@gnilink.net] > Sent: Monday, March 18, 2002 1:27 PM > To: Ravindra Sunkad; isis-wg@juniper.net > Subject: RE: [Isis-wg] Extended IP Reachability question > > > See > http://search.ietf.org/internet-drafts/draft-martin-neal-polic > y-isis-admin-t > ags-04.txt for this type of information. How the vendor > implements the policy is up to the vendor, but matching > internal vs external and tagging shouldn't be an issue during > LSP creation. > > chris > > > > -----Original Message----- > From: Ravindra Sunkad [mailto:Ravindra.Sunkad@vivacenetworks.com] > Sent: Monday, March 18, 2002 1:10 PM > To: isis-wg@juniper.net > Subject: RE: [Isis-wg] Extended IP Reachability question > > > I haven't seen any responses in regards to the following > thread. So, I'm assuming that no such sub-tlv has been > defined so far. I propose a color/tag sub-tlv for the > Extended IP Reachability TLV. This will be similar to the > "Administrative group" sub-tlv defined > for the Extended IS Reachability TLV. It contains a 4-octet > bit mask. The least significant bit is defined to indicate > whether the IP prefix is outside the IS-IS routing domain. > > Please provide me your inputs. > > Thanks, > Ravi > > -----Original Message----- > From: Ravindra Sunkad > Sent: Thursday, March 14, 2002 11:11 AM > To: isis-wg@juniper.net > Subject: [Isis-wg] Extended IP Reachability question > > > Hi, > > In the following threads there is some talk about defining a > sub-tlv for the Extended IP Reachability TLV that could be > used to differentiate external route advertisements from > internal route advertisements. Has any work been done on this front? > http://spider.juniper.net/pipermail/isis-wg/1999/thread.html#31 [Isis-wg] IS-IS Extensions for Traffic Engineering [Isis-wg] draft-ietf-isis-traffic-01.txt Thanks, Ravi From tli@procket.com Tue Mar 19 00:38:03 2002 From: tli@procket.com (Tony Li) Date: Mon, 18 Mar 2002 16:38:03 -0800 Subject: [Isis-wg] Extended IP Reachability question In-Reply-To: References: Message-ID: <15510.34923.740783.933930@alpha-tli.procket.com> | When IS-IS routes are redistributed to other protocols this piece of | information can be useful and could serve as an additional filter. Also, | we might want to create LDP LSPs only for internal prefixes. I believe that over the history of the Internet, it has been shown to be generally a catastrophic event to ever put any external prefixes into your IGP. It seems an error to encourage that. Similarly, unconstrained redistribution of prefixes from your IGP into BGP can also result in unwanted exposure of your internal topology to the outside world. Thus, it would seem to me that the primary mechanism to filtering routes redistributed into and out of IS-IS should be a manually configured prefix filter. Given that this exists (if redistribution is even necessary -- which I begin to doubt), I fail to see the overwhelming need for this additional bit of data. So again, why do we need this? Tony From Ravindra.Sunkad@vivacenetworks.com Tue Mar 19 03:05:26 2002 From: Ravindra.Sunkad@vivacenetworks.com (Ravindra Sunkad) Date: Mon, 18 Mar 2002 19:05:26 -0800 Subject: [Isis-wg] Extended IP Reachability question Message-ID: Perhaps there is no application in the real world that needs to differentiate IS-IS internal routes from externals. I was not sure if this was dropped purposefully from the isis-traffic draft or dropped because it was not in the scope of the document as one of the archived postings suggested. Since this is a shift from RFC-1195 is it worth mentioning the rationale in the traffic-eng draft? Thanks for your responses. Ravi > -----Original Message----- > From: Tony Li [mailto:tli@procket.com] > Sent: Monday, March 18, 2002 4:38 PM > To: Ravindra Sunkad > Cc: Tony Li; isis-wg@juniper.net > Subject: RE: [Isis-wg] Extended IP Reachability question > > > > | When IS-IS routes are redistributed to other protocols > this piece of | information can be useful and could serve as > an additional filter. Also, | we might want to create LDP > LSPs only for internal prefixes. > > > I believe that over the history of the Internet, it has been > shown to be generally a catastrophic event to ever put any > external prefixes into your IGP. It seems an error to encourage that. > > Similarly, unconstrained redistribution of prefixes from your > IGP into BGP can also result in unwanted exposure of your > internal topology to the outside world. > > Thus, it would seem to me that the primary mechanism to > filtering routes redistributed into and out of IS-IS should > be a manually configured prefix filter. Given that this > exists (if redistribution is even necessary -- which I begin > to doubt), I fail to see the overwhelming need for this > additional bit of data. > > So again, why do we need this? > > Tony > From jlearman@cisco.com Tue Mar 19 18:32:19 2002 From: jlearman@cisco.com (Jeff Learman) Date: Tue, 19 Mar 2002 13:32:19 -0500 Subject: [Isis-wg] Extended IP Reachability question In-Reply-To: Message-ID: <4.3.2.7.2.20020319133041.03aedf08@dingdong.cisco.com> At 10:05 PM 3/18/2002, Ravindra Sunkad wrote: >Perhaps there is no application in the real world that needs to >differentiate IS-IS internal routes from externals. >I was not sure if this was dropped purposefully from the isis-traffic >draft or dropped because it was not in the scope of the document as one >of the archived postings suggested. Since this is a shift from RFC-1195 >is it worth mentioning the rationale in the traffic-eng draft? This sounds like be a good idea, because this question seems to pop up with annoying regularity. >Thanks for your responses. > >Ravi > >> -----Original Message----- >> From: Tony Li [mailto:tli@procket.com] >> Sent: Monday, March 18, 2002 4:38 PM >> To: Ravindra Sunkad >> Cc: Tony Li; isis-wg@juniper.net >> Subject: RE: [Isis-wg] Extended IP Reachability question >> >> >> >> | When IS-IS routes are redistributed to other protocols >> this piece of | information can be useful and could serve as >> an additional filter. Also, | we might want to create LDP >> LSPs only for internal prefixes. >> >> >> I believe that over the history of the Internet, it has been >> shown to be generally a catastrophic event to ever put any >> external prefixes into your IGP. It seems an error to encourage that. >> >> Similarly, unconstrained redistribution of prefixes from your >> IGP into BGP can also result in unwanted exposure of your >> internal topology to the outside world. >> >> Thus, it would seem to me that the primary mechanism to >> filtering routes redistributed into and out of IS-IS should >> be a manually configured prefix filter. Given that this >> exists (if redistribution is even necessary -- which I begin >> to doubt), I fail to see the overwhelming need for this >> additional bit of data. >> >> So again, why do we need this? >> >> Tony >> >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From Prashant.Shukla@flukenetworks.com Tue Mar 19 23:46:47 2002 From: Prashant.Shukla@flukenetworks.com (Shukla, Prashant) Date: Tue, 19 Mar 2002 15:46:47 -0800 Subject: [Isis-wg] unsubsribe Message-ID: <838EF00CFC5DD511BA750008C78CBA9BD5189F@evtexc03.tc.fluke.com> unsubsribe From ramsrm@tdd.sj.nec.com" hi all, I have the following doubt, could u please explain me? * we r maintaining 2 area address list in an IS, * manual area address list and * another list, which is having all the area addresses present in that area( formed from L1 LSPs). my doubt is, if an IS originates a packet, in the source NSAP field, can we use an area address such that it is present in the second list but not in the manual area address list of that IS? second doubt is, similar to the frst doubt. When an IS originates the ISH, 10589 says, we have to use the lowest available area address in the NET field. For finding the lowest available area address, do we have to search only the manual area address list or can we search the second list also? thanks rams. From jlearman@cisco.com Wed Mar 20 19:52:38 2002 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 20 Mar 2002 14:52:38 -0500 Subject: [Isis-wg] area address in Source NSAP. In-Reply-To: <01C1CFFD.B4A9B1A0.ramsrm@tdd.sj.nec.com> Message-ID: <4.3.2.7.2.20020320143806.01d02d48@dingdong.cisco.com> Answer to second question first: You must use the lowest-valued manual area address in your NET. As for the first question, I assume you mean a CLNS user datagram. The rules for network addresses (I forget the ISO doc numbers for "naming and addressing", and "netwok layer addressing") mean that you're not supposed to play mix and match with pieces of NSAP addresses. A system is assigned an NSAP address and should use it. This includes an IS. The implication is that the NSAP for an IS network service user should have an area address matching one of its manual area addresses, but it needn't be the lowest one. Now for the tricky part -- you could probably get away with using any of the dynamic area addresses and it would work. However (a) you'd be breaking the addressing rules, and (b) you'd get into trouble in various dynamic conditions, such as when the area gets partitioned, or when a dynamic area address is dropped. I can't think of any good reason for using a dynamic area address as part of a source NSAP address. While I'm on the soap-box, I should point out another source of confusion concerning IS-IS and NSAP addresses of network service users on the IS. If you have area address A and B, and system ID I, and an NSEL of 1, that means you could have two different NSAP addresses: A-I-1 or B-I-1. According to how IS-IS works, it will deliver packets to either just the same way. HOWEVER, you have no right to assume the CLNS engine and/or Transport implementation on another IS will be able to accept packets with mix-and-match addresses. Some implementations will, some won't. Both are within the letter and spirit of the law. You aren't allowed to play mix-and-match with NSAP addresses, so if you do, be prepared to expect either outcome. This complicates autodiscovery mechanisms based on the IS-IS FDB, for example. Regards, Jeff At 01:55 PM 3/20/2002, ramanathan rams wrote: >hi all, > > I have the following doubt, could u please explain me? > >* we r maintaining 2 area address list in an IS, > * manual area address list and > * another list, which is having all the area addresses present in that >area( formed from L1 LSPs). > > my doubt is, if an IS originates a packet, in the source NSAP field, can >we use an area address such that it is present in the second list but not >in the manual area address list of that IS? > > second doubt is, similar to the frst doubt. When an IS originates the >ISH, 10589 says, we have to use the lowest available area address in the >NET field. For finding the lowest available area address, do we have to >search only the manual area address list or can we search the second list >also? > >thanks >rams. > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From ramsrm@tdd.sj.nec.com" Hi all, Is there any standard or document explaining how to handle unnumbered Point to Point I/Fs in ISIS for IP? Thanks rams. From jlearman@cisco.com Thu Mar 21 23:37:21 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 21 Mar 2002 18:37:21 -0500 Subject: [Isis-wg] unnumbered PP i/fs. In-Reply-To: <01C1D0E7.0CEA50B0.ramsrm@tdd.sj.nec.com> Message-ID: <4.3.2.7.2.20020321183706.039d9a70@dingdong.cisco.com> Does there need to be? At 05:45 PM 3/21/2002, ramanathan rams wrote: >Hi all, > > Is there any standard or document explaining how to handle unnumbered Point to Point I/Fs in ISIS for IP? > >Thanks >rams. > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From ramsrm@tdd.sj.nec.com" hi, If the PP connection between two routers does not have any IP address assigned for their interfaces then we need to have some mechanism by which that unnumbered interface is used in rib calculation. If we don't have any IP address assigned then we cannot advertise the IP address for that interface in hello packet and lsps cannot have any info regarding that interface, so effectively the shortest path via that interface(if one exists)will be missing from everyone's rib right?. or is it already handled in ISIS for IP by some means? OSPF supports this unnumbered PP I/Fs by filling the IfIndex in Router LSA. Thanks rams. -----Original Message----- From: Jeff Learman [SMTP:jlearman@cisco.com] Sent: Thursday, March 21, 2002 3:37 PM To: ramsrm@tdd.sj.nec.com Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] unnumbered PP i/fs. Does there need to be? At 05:45 PM 3/21/2002, ramanathan rams wrote: >Hi all, > > Is there any standard or document explaining how to handle unnumbered Point to Point I/Fs in ISIS for IP? > >Thanks >rams. > >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From ramsrm@tdd.sj.nec.com" hi, Thanks for the info, I have used this info, to do the SPF calculation and unnumbered link is also included in the SPF calculation. I didn't realize the IS neighbour used in LSP with which we can find the SPF eventhough the IP Internal Reachability info for that unnumbered link won't be there in neighbour's LSP. thanks rams. -----Original Message----- From: Jeff Parker [SMTP:jparker@axiowave.com] Sent: Thursday, March 21, 2002 5:02 PM To: 'ramsrm@tdd.sj.nec.com' Subject: RE: [Isis-wg] unnumbered PP i/fs. > hi, > > If the PP connection between two routers does not have > any IP address > assigned for their interfaces then we need to have some > mechanism by which > that unnumbered interface is used in rib calculation. > If we don't have any IP address assigned then we cannot > advertise the IP > address for that interface in hello packet and lsps cannot > have any info > regarding that interface, so effectively the shortest path via that > interface(if one exists)will be missing from everyone's rib > right?. or is > it already handled in ISIS for IP by some means? > OSPF supports this unnumbered PP I/Fs by filling the IfIndex > in Router LSA. > > Thanks > rams. What is your concern - the basic connectivity, which is provided by sending the SysIDs around, or how the routers forward? - jeff parker - axiowave networks From aridaman kaushik" hi all, The draft For Ipv6 version 2 is totally failure. It is not accordance with ISO 10589. It supports 32 bit default metric. In ISO 10589, neighbour TLVs are having 8 metric inormation. in present case for ipv4/iso, we are sending same 8 bit metric infomation, but We have to maintain separate metrics for ipv4/iso and ip6 separately due to their range difference? So how this will be tackled for ipv6?. In neighbiour TLV we are sending 8 bit metrics information, but in ipv6 reachiability, we will be sending 32 bit metric, SPF calculation fails here.? I think, either neighbour IS6 TLV should be provided or some sub TLV in ipv6 reachiability TLV should be added to make it compatible with existing ipv4/iso implementation or ipv6 reachiability should also contain 8 bit metric infomation. thanks in advance ari. From jlearman@cisco.com Fri Mar 22 14:00:37 2002 From: jlearman@cisco.com (Jeff Learman) Date: Fri, 22 Mar 2002 09:00:37 -0500 Subject: [Isis-wg] unnumbered PP i/fs. In-Reply-To: <01C1D0F8.C73942D0.ramsrm@tdd.sj.nec.com> Message-ID: <4.3.2.7.2.20020322085740.01d13f58@dingdong.cisco.com> Rams, What does the PPP link connect to? Presumably it's an IS, so you advertise that IS as an IS neighbor. Then, when SPF is run, you will find you're connected to everything that the other router is connected to, using that PPP link. Jeff At 07:52 PM 3/21/2002, ramanathan rams wrote: >hi, > > If the PP connection between two routers does not have any IP address >assigned for their interfaces then we need to have some mechanism by which >that unnumbered interface is used in rib calculation. >If we don't have any IP address assigned then we cannot advertise the IP >address for that interface in hello packet and lsps cannot have any info >regarding that interface, so effectively the shortest path via that >interface(if one exists)will be missing from everyone's rib right?. or is >it already handled in ISIS for IP by some means? >OSPF supports this unnumbered PP I/Fs by filling the IfIndex in Router LSA. > >Thanks >rams. > >-----Original Message----- >From: Jeff Learman [SMTP:jlearman@cisco.com] >Sent: Thursday, March 21, 2002 3:37 PM >To: ramsrm@tdd.sj.nec.com >Cc: isis-wg@juniper.net >Subject: Re: [Isis-wg] unnumbered PP i/fs. > > >Does there need to be? > >At 05:45 PM 3/21/2002, ramanathan rams wrote: >>Hi all, >> >> Is there any standard or document explaining how to handle >unnumbered Point to Point I/Fs in ISIS for IP? >> >>Thanks >>rams. >> >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@spider.juniper.net >>http://spider.juniper.net/mailman/listinfo/isis-wg From aravindravikumar@yahoo.com Mon Mar 25 07:13:25 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Sun, 24 Mar 2002 23:13:25 -0800 (PST) Subject: [Isis-wg] few doubts on LSP purging Message-ID: <20020325071325.69853.qmail@web11207.mail.yahoo.com> --0-1208872431-1017040405=:68872 Content-Type: text/plain; charset=us-ascii Hi All, ISO 10589 section 7.3.16.4 says when we purge an LSP with zero remaining life time we should retain the header in the database for ZeroAgeLifetime and if we are purging because of any other reson we have to retain the header in the database for MaxAge. Am I correct in assuming that the purging of old Designated IS's pseudoNode LSP by the new Designated system and the purging of local pseudonode LSP when the system is resigning as designated system are two such situations, where we are purging eventhough the remaining life time has not become zero? My doubts are as follows: 1. What exactly is the purpose of retaining the header for MaxAge ? 2. What are the things for which we should'nt use such an aged out LSP retained in our database and what are the things for which the LSP can be used? 3. Can we include it in CSNPs? 4. Can we consider them while doing look up in the database (for eg: while trying to add entry into database) . If we do consider and if the IS becomes Designated IS again, before the pseudoNode LSPs from the earlier stint as Designated IS are removed from the LS database A. What should be done, with the header of the aged out pseudonode LSPs retained in the database? B.Should we take the sequence number of the aged out LSP into consideration while generating the new pseudonode LSP? Thanks in advance. Aravind --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-1208872431-1017040405=:68872 Content-Type: text/html; charset=us-ascii

Hi All,

ISO 10589 section 7.3.16.4 says when we purge an LSP with zero remaining
life time we should retain the header in  the database for ZeroAgeLifetime
and  if we are purging because of any other reson we have to retain the
header in the database for MaxAge.

Am I correct in assuming that the purging of old Designated IS's pseudoNode
LSP by the new Designated system and the purging of local pseudonode LSP
when the system is resigning as designated system are two such situations,
where we are purging eventhough the remaining life time has not become zero?

My doubts are as follows:

1. What exactly is the purpose of retaining the header for MaxAge ?

2. What are the things for which we should'nt use such an aged out LSP retained
   in our database and what are the things for which the LSP  can be used?

3. Can we include it in CSNPs?

4. Can we consider them while doing look up in the database (for eg: while
   trying to add entry into database) . If we do consider and if the IS
   becomes Designated IS again, before the pseudoNode LSPs from the earlier
   stint as Designated IS are removed from the LS database

   A. What should be done, with the header of the aged out pseudonode LSPs
       retained in the database?

   B.Should we take the sequence number of the aged out LSP into consideration
      while generating the new pseudonode LSP?


Thanks in advance.

Aravind



Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-1208872431-1017040405=:68872-- From mshand@cisco.com Mon Mar 25 09:08:59 2002 From: mshand@cisco.com (mike shand) Date: Mon, 25 Mar 2002 09:08:59 +0000 Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <20020325071325.69853.qmail@web11207.mail.yahoo.com> Message-ID: <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> At 23:13 24/03/2002 -0800, Aravind Ravikumar wrote: >Hi All, > >ISO 10589 section 7.3.16.4 says when we purge an LSP with zero remaining >life time we should retain the header in the database for ZeroAgeLifetime >and if we are purging because of any other reson we have to retain the >header in the database for MaxAge. > >Am I correct in assuming that the purging of old Designated IS's pseudoNode >LSP by the new Designated system and the purging of local pseudonode LSP >when the system is resigning as designated system are two such situations, >where we are purging eventhough the remaining life time has not become zero? Yes >My doubts are as follows: > >1. What exactly is the purpose of retaining the header for MaxAge ? Because if the network partitions such that some copies of the old LSP are left unpurged, and then the partition is healed, there must be a purge header still alive to cause those LSPs to be properly purged. Note that the strict requirement in all cases is that the purge header is retained for the maximum possible lifetime of any copy of the LSP in the network. So you COULD use just the actual remaining lifetime (plus a bit). This becomes interesting when we consider having variable max lifetimes. >2. What are the things for which we should'nt use such an aged out LSP >retained > in our database and what are the things for which the LSP can be used? Nothing and everything. You use it exactly as a normal LSP. Of course it won't have any data, so you wouldn't use it in an SPF, but you wouldn't do that anyway since npobody else's LSP would point to it. >3. Can we include it in CSNPs? >Yes you MUST. >4. Can we consider them while doing look up in the database (for eg: while > trying to add entry into database) . If we do consider and if the IS > becomes Designated IS again, before the pseudoNode LSPs from the earlier > stint as Designated IS are removed from the LS database I'm not quite sure what you mean by this. Can you re-phrase the question? > A. What should be done, with the header of the aged out pseudonode LSPs > retained in the database? It will get overwritten by the NEW version > B.Should we take the sequence number of the aged out LSP into > consideration > while generating the new pseudonode LSP? Yes if you have it, but you don't have to, since if you start at 1 and there are any old copies of the purge header out there, they will cause their sequence number to be propagated back to you, and you will then automatically issue your new LSP with the next highest number. i.e. it all just works. Mike >Thanks in advance. > >Aravind > > > >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards® From tli@procket.com Mon Mar 25 09:21:42 2002 From: tli@procket.com (Tony Li) Date: Mon, 25 Mar 2002 01:21:42 -0800 Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> References: <20020325071325.69853.qmail@web11207.mail.yahoo.com> <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> Message-ID: <15518.60454.503308.514679@alpha-tli.procket.com> | >3. Can we include it in CSNPs? | | Yes you MUST. Interesting. Why? Omitting the LSP from the CSNP is an indication of not having valid information for the LSP, which should be identical to including it with zero lifetime. Tony p.s. Dave, warm up a PR for me... ;-) From tli@procket.com Mon Mar 25 09:18:11 2002 From: tli@procket.com (Tony Li) Date: Mon, 25 Mar 2002 01:18:11 -0800 Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <20020325071325.69853.qmail@web11207.mail.yahoo.com> References: <20020325071325.69853.qmail@web11207.mail.yahoo.com> Message-ID: <15518.60243.358599.281794@alpha-tli.procket.com> | Am I correct in assuming that the purging of old Designated IS's pseudoNode | LSP by the new Designated system and the purging of local pseudonode LSP | when the system is resigning as designated system are two such situations, | where we are purging eventhough the remaining life time has not become zero? A fine example. | My doubts are as follows: | | 1. What exactly is the purpose of retaining the header for MaxAge ? It's been demonstrated quite conclusively with extensive field experience that if a node does not retain the header and simply flush it, then the node will somehow relearn the LSP through some peer and reinstate it. It then purges it and the cycle continues. | 2. What are the things for which we should'nt use such an aged out LSP | retained | in our database and what are the things for which the LSP can be used? There is no point in using it for anything other than a fine indication that you don't want to relearn it. | 3. Can we include it in CSNPs? Not adviseable. I'd bet that it's against the letter of the law and in any case it would not help anything to advertise it. | 4. Can we consider them while doing look up in the database (for eg: while | trying to add entry into database) . If we do consider and if the IS | becomes Designated IS again, before the pseudoNode LSPs from the earlier | stint as Designated IS are removed from the LS database | | B.Should we take the sequence number of the aged out LSP into | consideration while generating the new pseudonode LSP? Absolutely. Despite the purge, there will be some system out there somewhere that has hung onto the old LSP. | A. What should be done, with the header of the aged out pseudonode LSPs | retained in the database? I would compare the newly received LSP against the aged out header and perform standard sequence number checks. This should discard duplicate echos of what was just purged. Tony From mshand@cisco.com Mon Mar 25 09:58:34 2002 From: mshand@cisco.com (mike shand) Date: Mon, 25 Mar 2002 09:58:34 +0000 Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <15518.60454.503308.514679@alpha-tli.procket.com> References: <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> <20020325071325.69853.qmail@web11207.mail.yahoo.com> <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> Message-ID: <4.3.2.7.2.20020325093543.035bd008@jaws.cisco.com> At 01:21 25/03/2002 -0800, Tony Li wrote: > | >3. Can we include it in CSNPs? > | > | Yes you MUST. > > >Interesting. Why? > >Omitting the LSP from the CSNP is an indication of not having valid >information for the LSP, which should be identical to including it with >zero lifetime. Its not quite the same as having no information. It says "I have no information and YOU shouldn't have any either". SO suppose the DR has a purge header for an LSP. Some other router on the LAN has the full copy. It sends that out on the LAN and the DR realizes that it has a newer version (i.e. the purge has half a bit more sequence number), so it floods it on the LAN. But the packet gets lost. Oh OK, maybe you are right. The CSNP claims nothing, so the other router re-sends its full copy, which causes the DR to resend the purge. I guess it all gets sorted out in the end. But its slightly "unnatural". But my immediate reaction was that you should always do the normal thing and not special case the purge header. As far as the update process is concerned, the only interesting thing about a purge header is that it appears to be newer than a non-purged LSP with the same sequence number. The only special casing that I know about is that you must not set SRMflags for a zero sequence number "LSP". Mike >Tony > >p.s. Dave, warm up a PR for me... ;-) From aravindravikumar@yahoo.com Mon Mar 25 10:30:20 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Mon, 25 Mar 2002 02:30:20 -0800 (PST) Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> Message-ID: <20020325103020.92920.qmail@web11202.mail.yahoo.com> --0-771338235-1017052220=:90002 Content-Type: text/plain; charset=us-ascii Hi Mike, Thanks for the reply and now I have understood the issues, but for a small clarifcation. If an IS finds out, while processing the CSNP (which includes the aged out entry in it) from a DIS, that it is not having the aged out LSP in its database or is having an older copy, then it will make a request for the LSP in its next PSNP. But since only the header of the aged out LSP is sent in response to the PSNP, won't it be rejected because of authentication faliure, in case authentication is configured and this sequence will keep on repeating. Am I right or wrong, please clarify? >>4. Can we consider them while doing look up in the database (for eg: while >> trying to add entry into database) . If we do consider and if the IS >> becomes Designated IS again, before the pseudoNode LSPs from the earlier >> stint as Designated IS are removed from the LS database >I'm not quite sure what you mean by this. Can you re-phrase the question? Sorry for putting the above question in a wrong way in my earlier mail. Any way its more to the implementation side and is clear now from your answers to the two questions that followed it. I was trying to describe a situation followed by the doubts on that. I'll put the situation in a proper way as follows System A is Designated IS for a LAN System B comes up and becomes the designated IS Now the pseudonode LSPs generated by A will be purged and the headers will be retained. System B goes down and system A again becomes the designated IS. A is still having the headers of the old pseudonode LSPs,which it comes across while trying to add the new pseudonode LSPs to the database It was in this context I asked the other two questions Aravind --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-771338235-1017052220=:90002 Content-Type: text/html; charset=us-ascii

Hi Mike,

Thanks for the reply and now I have understood the issues, but for a small clarifcation.

If an IS finds out, while processing the CSNP (which includes the aged out entry in it) from a DIS, that

it is not having the aged out LSP in its database or is having an older copy, then it will make a request for the LSP

in its next PSNP. But since only the header of the aged out LSP is sent in response to the PSNP, won't

it be rejected because of authentication faliure, in case authentication is configured and this sequence will keep on

repeating. Am I right or wrong, please clarify?

>>4. Can we consider them while doing look up in the database (for eg: while
>> trying to add entry into database) . If we do consider and if the IS
>> becomes Designated IS again, before the pseudoNode LSPs from the earlier
>> stint as Designated IS are removed from the LS database

>I'm not quite sure what you mean by this. Can you re-phrase the question?

Sorry for putting the above question in a wrong way in my earlier mail. Any way its more to the implementation

side and is clear now from your answers to the two questions that followed it. I was trying to describe

a situation followed by the doubts on that.

I'll put the situation in a proper way as follows

System A is Designated IS for a LAN

System B comes up and becomes the designated IS

Now the pseudonode LSPs generated by A will be purged and the headers will be retained.

System B goes down and system A again becomes the designated IS.

A is still having the headers of the old pseudonode LSPs,which it comes across while

trying to add the new pseudonode LSPs to the database

It was in this context I asked the other two questions

Aravind



Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-771338235-1017052220=:90002-- From mshand@cisco.com Mon Mar 25 10:33:34 2002 From: mshand@cisco.com (mike shand) Date: Mon, 25 Mar 2002 10:33:34 +0000 Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <20020325103020.92920.qmail@web11202.mail.yahoo.com> References: <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> Message-ID: <4.3.2.7.2.20020325103234.03639ee0@jaws.cisco.com> At 02:30 25/03/2002 -0800, Aravind Ravikumar wrote: >Hi Mike, > >Thanks for the reply and now I have understood the issues, but for a small >clarifcation. > >If an IS finds out, while processing the CSNP (which includes the aged out >entry in it) from a DIS, that > >it is not having the aged out LSP in its database or is having an older >copy, then it will make a request for the LSP > >in its next PSNP. But since only the header of the aged out LSP is sent in >response to the PSNP, won't > >it be rejected because of authentication faliure, in case authentication >is configured and this sequence will keep on > >repeating. Am I right or wrong, please clarify? No. you have to include authentication even for purge headers. Mike > >>4. Can we consider them while doing look up in the database (for eg: while > >> trying to add entry into database) . If we do consider and if the IS > >> becomes Designated IS again, before the pseudoNode LSPs from the earlier > >> stint as Designated IS are removed from the LS database > > >I'm not quite sure what you mean by this. Can you re-phrase the question? > >Sorry for putting the above question in a wrong way in my earlier mail. >Any way its more to the implementation > >side and is clear now from your answers to the two questions that followed >it. I was trying to describe > >a situation followed by the doubts on that. > >I'll put the situation in a proper way as follows > >System A is Designated IS for a LAN > >System B comes up and becomes the designated IS > >Now the pseudonode LSPs generated by A will be purged and the headers will >be retained. > >System B goes down and system A again becomes the designated IS. > >A is still having the headers of the old pseudonode LSPs,which it comes >across while > >trying to add the new pseudonode LSPs to the database > >It was in this context I asked the other two questions > >Aravind > > > >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards® From dkatz@juniper.net Mon Mar 25 18:37:24 2002 From: dkatz@juniper.net (Dave Katz) Date: Mon, 25 Mar 2002 10:37:24 -0800 (PST) Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <15518.60454.503308.514679@alpha-tli.procket.com> (message from Tony Li on Mon, 25 Mar 2002 01:21:42 -0800) References: <20020325071325.69853.qmail@web11207.mail.yahoo.com> <4.3.2.7.2.20020325084755.034e42f8@jaws.cisco.com> <15518.60454.503308.514679@alpha-tli.procket.com> Message-ID: <200203251837.g2PIbOf19019@cirrus.juniper.net> Omitting the LSP from the CSNP is an indication of not having valid information for the LSP, which should be identical to including it with zero lifetime. Tony p.s. Dave, warm up a PR for me... ;-) I agree with you here; in the partition case, if there's no information on one side of the network and the spent LSP is on the other, everybody's on the same foot; if there is a live LSP on one side and the spent LSP on the other, the live one will be flooded into the other side when the partition heals and the originator (who is presumably on the spent side) will do the right thing. Moreover, this is an optimization, as there's no harm in the stale LSP hanging around (which will only happen if the originator is disconnected from the rest of the network) as it will just take up space in the database until it times out of its own accord. Having said that, many years ago Tony and I got a first-hand education on why holding negative (purged) state is necessary. A certain west coast regional network running OSPF on equipment made by a certain common former employer of ours was having regular network meltdowns of MAXAGE LSAs. Turns out there was a simple and subtle bug in the flooding mechanism (something was being acked when it should have just been dropped, I believe) and the net result was that old MAXAGE LSAs would repeatedly come falling in from the network Oort Cloud and ricochet around inside the network, with several different sequence numbers. The lesson learned from this is that you have to hold onto negative state long enough to make sure that it will never come back to you, so that its flooding damps out (since there is no lifetime limit to this information.) OSPF takes an agressive, but fragile approach to this--if all of your neighbors have acknowledged the purged LSA, then you can toss the state (since those neighbors will not flood it to you again, and by extrapolation their neighbors will not flood it to them, etc.) Works perfectly as long as there's no bug, but it gets really ugly when things aren't quite right. ISIS, because it doesn't use a positive acknowledgement scheme on LANs (a feature) must hold the negative state until it is guaranteed that it has reached all corners of the network; otherwise it could slosh back and forth through the network repeatedly. (I *think* it is guaranteed to stabilize eventually as the LSP wavefronts will cancel one another out, but if you put a flapping link or two into the picture I think you can come up with a somewhat plausible scenario in which it might not ever stop.) Link state protocols are not as simple as they appear, as has been discovered repeatedly by those who have attempted to roll their own. From padma@juniper.net Mon Mar 25 21:53:20 2002 From: padma@juniper.net (Padma Pillay-Esnault) Date: Mon, 25 Mar 2002 13:53:20 -0800 Subject: [Isis-wg] About the IS Adjacency Area Address Table Message-ID: <3C9F9C50.17C598E4@juniper.net> Jeff I have a couple of questions about the IS Adjacency Area Address Table Index as compared to the IS Adjacency IP Address Table. isisISAdjAreaAddrEntry OBJECT-TYPE SYNTAX IsisISAdjAreaAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one Area Address reported by a neighboring Intermediate System in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjAreaAddrAdjIndex, <<<<<<<<< (1) isisISAdjAreaAddress } <<<<<<<<< (2) ::= { isisISAdjAreaAddrTable 1 } ----------- isisISAdjIPAddrEntry OBJECT-TYPE SYNTAX IsisISAdjIPAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one IP Address reported by a neighboring Intermediate System in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjIndex, <<<<<<<<<<<<< isisISAdjIPAddrAdjIndex <<<<<<<<<<<<< } ::= { isisISAdjIPAddrTable 1 } Why is it that we have the isisISAdjAreaAddrAdjIndex I believe that the isisISAdjIndex could be used here as well ? We have isisISAdjIPAddrAdjIndex for the ip addresses why not have an index for the area addresses as well. IMHO, this would simplify greatly the code having an index (len 1) instead of the address (len 22) Lastly this would make the two tables consistent. Any light appreciated as to why they are implemented differently Padma From jparker@axiowave.com Mon Mar 25 22:50:34 2002 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 25 Mar 2002 17:50:34 -0500 Subject: [Isis-wg] RE: IS Adjacency table Message-ID: > Also description for isisISAdjNeighPriority reads like: > > isisISAdjNeighPriority OBJECT-TYPE > SYNTAX ISPriority > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Priority of the neighboring Intermediate System for > becoming the LAN Level 1 Designated Intermediate System > if the value of isisISAdjNeighSysType is > L1IntermediateSystem or LAN Level 2 Designated > Intermediate System if the value of > isisISAdjNeighSysType is L2IntermediateSystem." > REFERENCE "{ISIS.aoi lANPriority (86)}" > ::= { isisISAdjEntry 8 } > > > what it mean when isisISAdjNeighSysType is > "l1l2IntermediateSystem"?. You are right. It is confusing. It is only relevant on a LAN, where there will be an adjacency per level. It may be simplest to simplest to say isisISAdjNeighPriority OBJECT-TYPE SYNTAX ISPriority MAX-ACCESS read-only STATUS current DESCRIPTION "Priority of the neighboring Intermediate System for becoming the Designated Intermediate System." REFERENCE "{ISIS.aoi lANPriority (86)}" ::= { isisISAdjEntry 8 } > In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is no object > conveying the message what "type" of adjacency is that (either Level1 or > Level2) I believe that the isisISAdjUsage variable conveys this information. - jeff parker From jparker@axiowave.com Mon Mar 25 23:34:07 2002 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 25 Mar 2002 18:34:07 -0500 Subject: [Isis-wg] RE: About the IS Adjacency Area Address Table Message-ID: > Jeff > > I have a couple of questions about the IS Adjacency Area Address Table > Index as compared to > the IS Adjacency IP Address Table. > > Why is it that we have the isisISAdjAreaAddrAdjIndex I believe that > the isisISAdjIndex could be used here as well ? Good suggestion. Done. > > We have isisISAdjIPAddrAdjIndex for the ip addresses why not have an > index for the area addresses as well. > IMHO, this would simplify greatly the code having an index (len 1) > instead of the address (len 22) > > Padma You are not the first person to complain about the efforts needed to walk the Adj Address Table, given that ISO addresses are variable length. I will add an index to simplify implementation. - jeff parker IsisISAdjAreaAddrEntry ::= SEQUENCE { isisISAdjAreaAddrIndex Integer32, isisISAdjAreaAddress OSINSAddress } isisISAdjAreaAddrIndex OBJECT-TYPE SYNTAX Integer32 (1..2000000000) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index for the areas associated with one neighbor. This provides a simpler way to walk the table." ::= { isisISAdjAreaAddrEntry 1 } From padma@juniper.net Mon Mar 25 23:43:42 2002 From: padma@juniper.net (Padma Pillay-Esnault) Date: Mon, 25 Mar 2002 15:43:42 -0800 Subject: [Isis-wg] Re: About the IS Adjacency Area Address Table References: Message-ID: <3C9FB62E.BD6F072@juniper.net> Jeff I also came up with the same situation with the isisISAdjProtSuppTable we could make all the tables under adjacency consistent by putting the isisISAdjIndex and an index on the entry we are walking Thanks Padma Jeff Parker wrote: > > Jeff > > > > I have a couple of questions about the IS Adjacency Area Address Table > > Index as compared to > > the IS Adjacency IP Address Table. > > > > Why is it that we have the isisISAdjAreaAddrAdjIndex I believe that > > the isisISAdjIndex could be used here as well ? > > Good suggestion. Done. > > > > We have isisISAdjIPAddrAdjIndex for the ip addresses why not have an > > index for the area addresses as well. > > IMHO, this would simplify greatly the code having an index (len 1) > > instead of the address (len 22) > > > > Padma > > You are not the first person to complain about the efforts needed to > walk the Adj Address Table, given that ISO addresses are variable > length. I will add an index to simplify implementation. > > - jeff parker > > IsisISAdjAreaAddrEntry ::= > SEQUENCE { > isisISAdjAreaAddrIndex > Integer32, > isisISAdjAreaAddress > OSINSAddress > } > > isisISAdjAreaAddrIndex OBJECT-TYPE > SYNTAX Integer32 (1..2000000000) > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An index for the areas associated with one neighbor. > This provides a simpler way to walk the table." > ::= { isisISAdjAreaAddrEntry 1 } From jparker@axiowave.com Mon Mar 25 23:55:41 2002 From: jparker@axiowave.com (Jeff Parker) Date: Mon, 25 Mar 2002 18:55:41 -0500 Subject: [Isis-wg] RE: About the IS Adjacency Area Address Table Message-ID: > Jeff > > I also came up with the same situation with the > isisISAdjProtSuppTable we could make all the > tables under adjacency consistent > by putting the isisISAdjIndex Done > and an index on the entry we are walking > > Padma I understand the problems in walking complex types like the new IP address or an OSI address. But help me understand why we need an index to walk a scalar. Isn't this something that GetNext papers over for us? - jeff parker isisISAdjProtSuppEntry OBJECT-TYPE SYNTAX IsisISAdjProtSuppEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains one protocol supported by a neighboring Intermediate System as reported in its IIH PDUs." INDEX { isisSysInstance, isisCircIndex, isisISAdjIndex, isisISAdjProtSuppProtocol } ::= { isisISAdjProtSuppTable 1 } IsisISAdjProtSuppEntry ::= SEQUENCE { isisISAdjProtSuppProtocol SupportedProtocol } isisISAdjProtSuppProtocol OBJECT-TYPE SYNTAX SupportedProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "One supported protocol as reported in IIH PDUs received from the neighbor." ::= { isisISAdjProtSuppEntry 1 } -- From padma@juniper.net Tue Mar 26 00:16:58 2002 From: padma@juniper.net (Padma Pillay-Esnault) Date: Mon, 25 Mar 2002 16:16:58 -0800 Subject: [Isis-wg] RE: About the IS Adjacency Area Address Table References: Message-ID: <3C9FBDFA.D6A835BA@juniper.net> Jeff Parker wrote: > > > Jeff > > > > I also came up with the same situation with the > > isisISAdjProtSuppTable we could make all the > > tables under adjacency consistent > > by putting the isisISAdjIndex > > Done > > > and an index on the entry we are walking > > > > Padma > > I understand the problems in walking complex types > like the new IP address or an OSI address. But > help me understand why we need an index to walk > a scalar. Isn't this something that GetNext papers > over for us? I was thinking of a list built from the tlv which is not necessarily ordered . Then it is easier to to code a lookup on an index than run thru the list to find the next entry based on the value ... I guess I could do that differently. May be I am uniformizing too much ;-) Padma > > - jeff parker > > isisISAdjProtSuppEntry OBJECT-TYPE > SYNTAX IsisISAdjProtSuppEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "Each entry contains one protocol supported by a > neighboring Intermediate System as reported in its IIH > PDUs." > INDEX { isisSysInstance, > isisCircIndex, > isisISAdjIndex, > isisISAdjProtSuppProtocol } > ::= { isisISAdjProtSuppTable 1 } > > IsisISAdjProtSuppEntry ::= > SEQUENCE { > isisISAdjProtSuppProtocol > SupportedProtocol > } > > isisISAdjProtSuppProtocol OBJECT-TYPE > SYNTAX SupportedProtocol > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "One supported protocol as reported in IIH PDUs received > from the neighbor." > ::= { isisISAdjProtSuppEntry 1 } > -- > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg From lliu@chiaro.com Tue Mar 26 00:42:22 2002 From: lliu@chiaro.com (Laura Liu) Date: Mon, 25 Mar 2002 18:42:22 -0600 Subject: [Isis-wg] few doubts on LSP purging Message-ID: <2383E22BDFF6D311BB8400B0D021A50701F451AD@MAIL> ----ISVW_ISUX_boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D45F.17802420" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D45F.17802420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 To add another situation: router A has multiple LSP fragments of router = B, when router B made some changes, purged it LSPs and the new lsp can fit = into one pdu (lsp #0), router A need to purge the old lsp fragments (lsp #1 = and above), those lsp headers should be retained in the database for = MaxAge. =20 Am I right? =20 thanks in advance! =20 Laura -----Original Message-----=20 From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com] Sent: Monday, March 25, 2002 1:13 AM To: isis-wg@juniper.net Subject: [Isis-wg] few doubts on LSP purging Hi All, ISO 10589 section 7.3.16.4 says when we purge an LSP with zero = remaining=20 life time we should retain the header in the database for = ZeroAgeLifetime and if we are purging because of any other reson we have to retain the = header in the database for MaxAge. Am I correct in assuming that the purging of old Designated IS's = pseudoNode LSP by the new Designated system and the purging of local pseudonode = LSP=20 when the system is resigning as designated system are two such = situations, where we are purging eventhough the remaining life time has not become = zero? My doubts are as follows: 1. What exactly is the purpose of retaining the header for MaxAge ? 2. What are the things for which we should'nt use such an aged out LSP retained in our database and what are the things for which the LSP can be = used? 3. Can we include it in CSNPs? 4. Can we consider them while doing look up in the database (for eg: = while trying to add entry into database) . If we do consider and if the IS = becomes Designated IS again, before the pseudoNode LSPs from the = earlier stint as Designated IS are removed from the LS database=20 A. What should be done, with the header of the aged out pseudonode = LSPs retained in the database? B.Should we take the sequence number of the aged out LSP into consideration while generating the new pseudonode LSP? Thanks in advance. Aravind _____ =20 Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards=AE ------_=_NextPart_001_01C1D45F.17802420 Content-Type: text/html; charset="iso-8859-1"
Hi All,
 
To add another situation: router A has multiple LSP fragments of router B, when router B made some changes, purged it LSPs and the new lsp can fit into one pdu (lsp #0), router A need to purge the old lsp fragments (lsp #1 and above), those lsp headers should be retained in the database for MaxAge.
 
Am I right?
 
thanks in advance!
 
Laura
-----Original Message----- 
From: Aravind Ravikumar [mailto:aravindravikumar@yahoo.com]
Sent: Monday, March 25, 2002 1:13 AM
To: isis-wg@juniper.net
Subject: [Isis-wg] few doubts on LSP purging

Hi All,

ISO 10589 section 7.3.16.4 says when we purge an LSP with zero remaining
life time we should retain the header in  the database for ZeroAgeLifetime
and  if we are purging because of any other reson we have to retain the
header in the database for MaxAge.

Am I correct in assuming that the purging of old Designated IS's pseudoNode
LSP by the new Designated system and the purging of local pseudonode LSP
when the system is resigning as designated system are two such situations,
where we are purging eventhough the remaining life time has not become zero?

My doubts are as follows:

1. What exactly is the purpose of retaining the header for MaxAge ?

2. What are the things for which we should'nt use such an aged out LSP retained
   in our database and what are the things for which the LSP  can be used?

3. Can we include it in CSNPs?

4. Can we consider them while doing look up in the database (for eg: while
   trying to add entry into database) . If we do consider and if the IS
   becomes Designated IS again, before the pseudoNode LSPs from the earlier
   stint as Designated IS are removed from the LS database

   A. What should be done, with the header of the aged out pseudonode LSPs
       retained in the database?

   B.Should we take the sequence number of the aged out LSP into consideration
      while generating the new pseudonode LSP?


Thanks in advance.

Aravind



Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
------_=_NextPart_001_01C1D45F.17802420-- ----ISVW_ISUX_boundary Content-Type: text/plain;charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline ----------------------------------------- (on rchss001) This e-mail and any files transmitted with it are the property of Chiaro Networks, Ltd., and may contain confidential and privileged material for the sole use of the intended recipient(s) to whom this e-mail is addressed. If you are not one of the named recipient(s), or otherwise have reason to believe that you have received this message in error, please notify the sender and delete all copies from your system. Any other use, retention, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. --------------------------------------------------------- ----ISVW_ISUX_boundary-- From prz@redback.com Mon Mar 25 22:58:03 2002 From: prz@redback.com (Tony Przygienda) Date: Mon, 25 Mar 2002 14:58:03 -0800 Subject: [Isis-wg] few doubts on LSP purging References: <2383E22BDFF6D311BB8400B0D021A50701F451AD@MAIL> Message-ID: <3C9FAB7A.7AD3DD6D@redback.com> Laura Liu wrote: > Hi All,To add another situation: router A has multiple LSP fragments of router B, when router > B made some changes, purged it LSPs and the new lsp can fit into one pdu (lsp #0), router A > need to purge the old lsp fragments (lsp #1 and above), those lsp headers should be retained > in the database for MaxAge. > > you do not 'compact' fragments into a single fragment again. That would make the semantics of > information > deletion/addition within fragments hard to track and would lead to extensive flapping of e.g. > prefixes if you're > unlucky. > > > Each fragment is basically an independent entity when it comes to flooding and purging > > thanks > > > > -- tony From rayq@riverstonenet.com Tue Mar 26 01:48:57 2002 From: rayq@riverstonenet.com (Qiu, Ray) Date: Mon, 25 Mar 2002 17:48:57 -0800 Subject: [Isis-wg] draft-ietf-isis-wg-multi-topology-02.txt Message-ID: <329F35B18824D511B9C30008C73395583300@exc-sc1> Hi, I got one stupid question about this draft. It seems that MT ID are 12 bits as defined in the draft. But the reserved MT ID value is up to 8191. How can we get to 8191 by using 12 bits? Thanks, Ray From rayq@riverstonenet.com Tue Mar 26 01:51:53 2002 From: rayq@riverstonenet.com (Qiu, Ray) Date: Mon, 25 Mar 2002 17:51:53 -0800 Subject: [Isis-wg] draft-ietf-isis-wg-multi-topology-02.txt Message-ID: <329F35B18824D511B9C30008C73395583301@exc-sc1> Hi, I got one stupid question about this draft. It seems that MT ID are 12 bits as defined in the draft. But the reserved MT ID value is up to 8191. How can we get to 8191 by using 12 bits? Thanks, Ray From svemulap@cisco.com Tue Mar 26 01:55:52 2002 From: svemulap@cisco.com (Shankar Vemulapalli) Date: Mon, 25 Mar 2002 17:55:52 -0800 (PST) Subject: [Isis-wg] draft-ietf-isis-wg-multi-topology-02.txt In-Reply-To: <329F35B18824D511B9C30008C73395583301@exc-sc1> Message-ID: This has already been pointed out ... and I believe Naiming is taking care of it in the next version :-) /Shankar At 5:51pm 03/25/02 -0800, Qiu, Ray wrote: > Hi, > > I got one stupid question about this draft. > > It seems that MT ID are 12 bits as defined in the draft. But the reserved > MT ID > value is up to 8191. How can we get to 8191 by using 12 bits? > > Thanks, > Ray > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From rayq@riverstonenet.com Tue Mar 26 01:57:52 2002 From: rayq@riverstonenet.com (Qiu, Ray) Date: Mon, 25 Mar 2002 17:57:52 -0800 Subject: [Isis-wg] draft-ietf-isis-wg-multi-topology-02.txt Message-ID: <329F35B18824D511B9C30008C73395583302@exc-sc1> Shankar, Thanks. Sorry that I didn't know. :) Ray -----Original Message----- From: Shankar Vemulapalli [mailto:svemulap@cisco.com] Sent: Monday, March 25, 2002 5:56 PM To: Qiu, Ray Cc: 'isis-wg@spider.juniper.net' Subject: Re: [Isis-wg] draft-ietf-isis-wg-multi-topology-02.txt This has already been pointed out ... and I believe Naiming is taking care of it in the next version :-) /Shankar At 5:51pm 03/25/02 -0800, Qiu, Ray wrote: > Hi, > > I got one stupid question about this draft. > > It seems that MT ID are 12 bits as defined in the draft. But the reserved > MT ID > value is up to 8191. How can we get to 8191 by using 12 bits? > > Thanks, > Ray > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From swaminathanr@netplane.com Tue Mar 26 05:15:45 2002 From: swaminathanr@netplane.com (Ramalingam, Swaminathan) Date: Tue, 26 Mar 2002 00:15:45 -0500 Subject: [Isis-wg] RE: IS Adjacency table Message-ID: See Inline > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Tuesday, March 26, 2002 4:21 AM > To: 'Ramalingam, Swaminathan' > Cc: 'isis-wg@spider.juniper.net' > Subject: RE: [Isis-wg] RE: IS Adjacency table > > > > > Also description for isisISAdjNeighPriority reads like: > > > > isisISAdjNeighPriority OBJECT-TYPE > > SYNTAX ISPriority > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "Priority of the neighboring Intermediate System for > > becoming the LAN Level 1 Designated Intermediate System > > if the value of isisISAdjNeighSysType is > > L1IntermediateSystem or LAN Level 2 Designated > > Intermediate System if the value of > > isisISAdjNeighSysType is L2IntermediateSystem." > > REFERENCE "{ISIS.aoi lANPriority (86)}" > > ::= { isisISAdjEntry 8 } > > > > > > what it mean when isisISAdjNeighSysType is > > "l1l2IntermediateSystem"?. > > You are right. It is confusing. It is only relevant on a LAN, > where there will be an adjacency per level. It may be simplest > to simplest to say > > isisISAdjNeighPriority OBJECT-TYPE > SYNTAX ISPriority > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Priority of the neighboring Intermediate System for > becoming the Designated Intermediate System." > REFERENCE "{ISIS.aoi lANPriority (86)}" > ::= { isisISAdjEntry 8 } > > > > In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is no object > > conveying the message what "type" of adjacency is that > (either Level1 or > > Level2) > > I believe that the isisISAdjUsage variable conveys this information. This is true for Point-to-Point. But in broadcast network, We create two adjacencies Level 1 and Level 2 separtely even the IS is configured as "L2 IS with manualL2Only false" i.e L1L2. In Sec 8.4.2 of ISO 10589, last paragraph reads like: "Level 2 Intermediate Systems (with manualL2onlyMode "False") shall perform both of the above actions.Separate Level 1 and Level 2 LAN IIH PDUs shall be sent to the multi-destination addresses AllL1ISs and AllL2ISs describing the neighbor Intermediate systems for Level 1 and Level 2 respectively.Separate Adjacencies shall be created by the receipt of Level 1 and Level 2 LAN IIH PDUs". It means even the IS is configured for L1L2, we create two Adjacencies with "neighbourSystemType" with L1 and L2 separately. My Point is there is no adjacencyUsage called "L1L2" in BROADCAST NETWORK. So any two "L1L2IS" will have 2 Adjacency separately for Level 1 & 2 respectively (as there are two different hellos) Also whenever we receive L1 IIH or L2 IIH, we need to set the neighbourSystemType to 'L1 IS' or 'L2 IS' as per sec 8.4.2.2 & 8.4.2.3. It will be easy to implement when one create two separate adjacency with L1 and L2 as "Adjacency Type". Let me know if we are not in sync.. > > - jeff parker > From tli@procket.com Tue Mar 26 05:17:59 2002 From: tli@procket.com (Tony Li) Date: Mon, 25 Mar 2002 21:17:59 -0800 Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <3C9FAB7A.7AD3DD6D@redback.com> References: <2383E22BDFF6D311BB8400B0D021A50701F451AD@MAIL> <3C9FAB7A.7AD3DD6D@redback.com> Message-ID: <15520.1159.205579.971259@alpha-tli.procket.com> | > Hi All,To add another situation: router A has multiple LSP fragments of router B, when router | > B made some changes, purged it LSPs and the new lsp can fit into one pdu (lsp #0), router A | > need to purge the old lsp fragments (lsp #1 and above), those lsp headers should be retained | > in the database for MaxAge. | > | > you do not 'compact' fragments into a single fragment again. That would make the semantics of | > information | > deletion/addition within fragments hard to track and would lead to extensive flapping of e.g. | > prefixes if you're | > unlucky. | > | > | > Each fragment is basically an independent entity when it comes to flooding and purging Further.... if a IS does decide to regenerate its LSP, then it should simply bump the sequence number and flood the new version. The IS should NEVER purge an LSP with just the intent of replacing it with another subsequent verison. Tony From aravindravikumar@yahoo.com Tue Mar 26 09:45:47 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Tue, 26 Mar 2002 01:45:47 -0800 (PST) Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <4.3.2.7.2.20020325103234.03639ee0@jaws.cisco.com> Message-ID: <20020326094547.13926.qmail@web11202.mail.yahoo.com> --0-1160155901-1017135947=:13833 Content-Type: text/plain; charset=us-ascii Hi, 1.While purging if we retain only the header and the authentication CLV, the existing checksum will be inconsistent as we are removing rest of the data portion So Do we need to A.Recompute checksum? or B.Leave it as it is? or C.Make it 0 In second case mentioned above,the receiving IS will generate corruptedLSPReceived circuit event, according to section section 7.3.14.2.e.1 and will treat it as an aged out LSP. In the third case the receiving IS will treat the LSP as an aged outLSP without generating a corruptedLSPReceived circuit event according to section 7.3.14.2.i I personally feel, the third option is the better one. Am I right? 2.What does the following note in the section 7.3.16.4 of ISO 10589 imply NOTE 32 A check of the checksum of a zero Remaining Lifetime LSP succeeds even though the data portion is not present Does it mean that since LSP received with corrupted checksum are treated as if the remaining life time is zero,we can afford to have a wrong checksum for the LSP we are trying to purge so that any IS which receives it considers it as an aged out LSP 3.What are we supposed to do in response to corruptedLSPReceived circuit event,I think we don't have any management variable corresponding to this event.What is the pupose of generating this event Aravind mike shand wrote: At 02:30 25/03/2002 -0800, Aravind Ravikumar wrote: >Hi Mike, > >Thanks for the reply and now I have understood the issues, but for a small >clarifcation. > >If an IS finds out, while processing the CSNP (which includes the aged out >entry in it) from a DIS, that > >it is not having the aged out LSP in its database or is having an older >copy, then it will make a request for the LSP > >in its next PSNP. But since only the header of the aged out LSP is sent in >response to the PSNP, won't > >it be rejected because of authentication faliure, in case authentication >is configured and this sequence will keep on > >repeating. Am I right or wrong, please clarify? No. you have to include authentication even for purge headers. Mike > >>4. Can we consider them while doing look up in the database (for eg: while > >> trying to add entry into database) . If we do consider and if the IS > >> becomes Designated IS again, before the pseudoNode LSPs from the earlier > >> stint as Designated IS are removed from the LS database > > >I'm not quite sure what you mean by this. Can you re-phrase the question? > >Sorry for putting the above question in a wrong way in my earlier mail. >Any way its more to the implementation > >side and is clear now from your answers to the two questions that followed >it. I was trying to describe > >a situation followed by the doubts on that. > >I'll put the situation in a proper way as follows > >System A is Designated IS for a LAN > >System B comes up and becomes the designated IS > >Now the pseudonode LSPs generated by A will be purged and the headers will >be retained. > >System B goes down and system A again becomes the designated IS. > >A is still having the headers of the old pseudonode LSPs,which it comes >across while > >trying to add the new pseudonode LSPs to the database > >It was in this context I asked the other two questions > >Aravind > > > >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards® --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-1160155901-1017135947=:13833 Content-Type: text/html; charset=us-ascii

Hi,

1.While purging if we retain only the header and the authentication CLV,
the existing checksum will be inconsistent as we are removing rest of the
data portion So Do we need to

A.Recompute checksum? or

B.Leave it as it is? or

C.Make it 0

In second case mentioned above,the receiving IS
will generate corruptedLSPReceived circuit event, according to section
section 7.3.14.2.e.1 and will treat it as an aged out LSP.

In the third case the receiving IS will treat the LSP as an aged outLSP
without generating a corruptedLSPReceived circuit event according to
section 7.3.14.2.i

I personally feel, the third option is the better one. Am I right?

 


2.What does the following note in the section 7.3.16.4 of ISO 10589 imply

NOTE 32 A check of the checksum of a zero Remaining
Lifetime LSP succeeds even though the data portion is not
present

Does it mean that since LSP received with corrupted checksum
are treated as if the remaining life time is zero,we can afford
to have a wrong checksum for the LSP we are trying to purge so that any IS
which receives it considers it as an aged out LSP

 

3.What are we supposed to do in response to corruptedLSPReceived
circuit event,I think we don't have any management variable
corresponding to this event.What is the pupose of generating
this event

Aravind
 

 

 

 

 

  mike shand <mshand@cisco.com> wrote:

At 02:30 25/03/2002 -0800, Aravind Ravikumar wrote:

>Hi Mike,
>
>Thanks for the reply and now I have understood the issues, but for a small
>clarifcation.
>
>If an IS finds out, while processing the CSNP (which includes the aged out
>entry in it) from a DIS, that
>
>it is not having the aged out LSP in its database or is having an older
>copy, then it will make a request for the LSP
>
>in its next PSNP. But since only the header of the aged out LSP is sent in
>response to the PSNP, won't
>
>it be rejected because of authentication faliure, in case authentication
>is configured and this sequence will keep on
>
>repeating. Am I right or wrong, please clarify?

No. you have to include authentication even for purge headers.

Mike



> >>4. Can w! e consider them while doing look up in the database (for eg: while
> >> trying to add entry into database) . If we do consider and if the IS
> >> becomes Designated IS again, before the pseudoNode LSPs from the earlier
> >> stint as Designated IS are removed from the LS database
>
> >I'm not quite sure what you mean by this. Can you re-phrase the question?
>
>Sorry for putting the above question in a wrong way in my earlier mail.
>Any way its more to the implementation
>
>side and is clear now from your answers to the two questions that followed
>it. I was trying to describe
>
>a situation followed by the doubts on that.
>
>I'll put the situation in a proper way as follows
>
>System A is Designated IS for a LAN
>
>System B comes up and becomes the designated IS
>
>Now the pseudonode LSPs generated by A will be purged and the he! aders will
>be retained.
>
>System B goes down and system A again becomes the designated IS.
>
>A is still having the headers of the old pseudonode LSPs,which it comes
>across while
>
>trying to add the new pseudonode LSPs to the database
>
>It was in this context I asked the other two questions
>
>Aravind
>
>
>
>Do You Yahoo!?
>Yahoo! Movies - coverage of the 74th Academy Awards®



Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-1160155901-1017135947=:13833-- From mshand@cisco.com Tue Mar 26 10:47:04 2002 From: mshand@cisco.com (mike shand) Date: Tue, 26 Mar 2002 10:47:04 +0000 Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <20020326094547.13926.qmail@web11202.mail.yahoo.com> References: <4.3.2.7.2.20020325103234.03639ee0@jaws.cisco.com> Message-ID: <4.3.2.7.2.20020326103406.035d4618@jaws.cisco.com> At 01:45 26/03/2002 -0800, Aravind Ravikumar wrote: >Hi, > >1.While purging if we retain only the header and the authentication CLV, >the existing checksum will be inconsistent as we are removing rest of the >data portion So Do we need to > >A.Recompute checksum? or > >B.Leave it as it is? or > >C.Make it 0 The original design assumed that you would make it zero. However you can in fact do any of the above because the checksum is not checked for a zero lifetime PDU. >In second case mentioned above,the receiving IS >will generate corruptedLSPReceived circuit event, according to section >section 7.3.14.2.e.1 and will treat it as an aged out LSP. Note that this is in fact wrong, and has been corrected by a defect report which is incorporated in 10589 version2. The correct thing to do with a corrupt LSP is to ignore it, NOT to purge it. The latter action can create storms (and indeed has been observed to do so) in the presence of a flakey link which causes excessive LSP corruption. However, your assumption that the second case will lead to this action is incorrect because of the note you refer to below. The checksum will be ignored if the lifetime is zero. >In the third case the receiving IS will treat the LSP as an aged outLSP >without generating a corruptedLSPReceived circuit event according to >section 7.3.14.2.i Yes. that (as I said) was the original intention - that the checksum should be zero. Note that a Fletcher Checksum can never genuinely be zero, so there is no confusion with unpurged LSPs. >I personally feel, the third option is the better one. Am I right? Yes. > > > >2.What does the following note in the section 7.3.16.4 of ISO 10589 imply > >NOTE 32 A check of the checksum of a zero Remaining >Lifetime LSP succeeds even though the data portion is not >present > >Does it mean that since LSP received with corrupted checksum >are treated as if the remaining life time is zero,we can afford >to have a wrong checksum for the LSP we are trying to purge so that any IS >which receives it considers it as an aged out LSP No. It means that since there is no data portion (or strictly needn't be, because I believe some strange implementation persist in retaining the data portion of a zero age LSP - it doesn't matter - it's just a waste of space), there is no need to check the checksum. As I said above, it is no longer thought desirable to purge a corrupt LSP. > > >3.What are we supposed to do in response to corruptedLSPReceived >circuit event,I think we don't have any management variable >corresponding to this event.What is the pupose of generating >this event As far as the protocol is concerned, just ignore it. The idea of the event is to draw some manager's attention to the fact that weird things are happening. Mike >Aravind > > > > > > > > > > > mike shand wrote: >>At 02:30 25/03/2002 -0800, Aravind Ravikumar wrote: >> >> >Hi Mike, >> > >> >Thanks for the reply and now I have understood the issues, but for a small >> >clarifcation. >> > >> >If an IS finds out, while processing the CSNP (which includes the aged out >> >entry in it) from a DIS, that >> > >> >it is not having the aged out LSP in its database or is having an older >> >copy, then it will make a request for the LSP >> > >> >in its next PSNP. But since only the header of the aged out LSP is sent in >> >response to the PSNP, won't >> > >> >it be rejected because of authentication faliure, in case authentication >> >is configured and this sequence will keep on >> > >> >repeating. Am I right or wrong, please clarify? >> >>No. you have to include authentication even for purge headers. >> >>Mike >> >> >> >> > >>4. Can w! e consider them while doing look up in the database (for >> eg: while >> > >> trying to add entry into database) . If we do consider and if the IS >> > >> becomes Designated IS again, before the pseudoNode LSPs from the >> earlier >> > >> stint as Designated IS are removed from the LS database >> > >> > >I'm not quite sure what you mean by this. Can you re-phrase the question? >> > >> >Sorry for putting the above question in a wrong way in my earlier mail. >> >Any way its more to the implementation >> > >> >side and is clear now from your answers to the two questions that followed >> >it. I was trying to describe >> > >> >a situation followed by the doubts on that. >> > >> >I'll put the situation in a proper way as follows >> > >> >System A is Designated IS for a LAN >> > >> >System B comes up and becomes the designated IS >> > >> >Now the pseudonode LSPs generated by A will be purged and the hea! ders >> will >> >be retained. >> > >> >System B goes d! own and system A again becomes the designated IS. >> > >> >A is still having the headers of the old pseudonode LSPs,which it comes >> >across while >> > >> >trying to add the new pseudonode LSPs to the database >> > >> >It was in this context I asked the other two questions >> > >> >Aravind >> > >> > >> > >> >Do You Yahoo!? >> >Yahoo! Movies - coverage of the 74th Academy Awards® > > > >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards® From jparker@axiowave.com Tue Mar 26 14:42:01 2002 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 26 Mar 2002 09:42:01 -0500 Subject: [Isis-wg] RE: IS Adjacency table Message-ID: We are not in sync. There are two variables for each adjacency: what the type (l1, l2, both) the other IS is, and how the adj is being used (l1 or l2 on LAN, one of l1, l2, or both on p2p). I think we have everything you need. Perhaps you could explain again what you need. - jeff parker > > > In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is no object > > > conveying the message what "type" of adjacency is that > > (either Level1 or > > > Level2) > > > > I believe that the isisISAdjUsage variable conveys this information. > > > This is true for Point-to-Point. But in broadcast network, We > create two > adjacencies Level 1 and Level 2 separtely even the IS is > configured as "L2 > IS with manualL2Only false" i.e L1L2. > In Sec 8.4.2 of ISO 10589, last paragraph reads like: > > "Level 2 Intermediate Systems (with manualL2onlyMode > "False") shall perform > both of the above actions.Separate Level 1 and Level 2 LAN > IIH PDUs shall be > sent to the multi-destination addresses AllL1ISs and AllL2ISs > describing the > neighbor Intermediate systems for Level 1 and Level 2 > respectively.Separate > Adjacencies shall be created by the receipt of Level 1 and > Level 2 LAN IIH > PDUs". > > It means even the IS is configured for L1L2, we create two > Adjacencies with > "neighbourSystemType" with L1 and L2 separately. My Point is > there is no > adjacencyUsage called "L1L2" in BROADCAST NETWORK. So any two > "L1L2IS" will > have 2 Adjacency separately for Level 1 & 2 respectively (as > there are two > different hellos) > > Also whenever we receive L1 IIH or L2 IIH, we need to set the > neighbourSystemType to 'L1 IS' or 'L2 IS' as per sec 8.4.2.2 > & 8.4.2.3. It > will be easy to implement when one create two separate > adjacency with L1 and > L2 as "Adjacency Type". > > Let me know if we are not in sync.. > > > > > > - jeff parker > > > From swaminathanr@netplane.com Tue Mar 26 15:18:25 2002 From: swaminathanr@netplane.com (Ramalingam, Swaminathan) Date: Tue, 26 Mar 2002 10:18:25 -0500 Subject: [Isis-wg] RE: IS Adjacency table Message-ID: > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Tuesday, March 26, 2002 8:12 PM > To: 'Ramalingam, Swaminathan' > Cc: 'isis-wg@spider.juniper.net' > Subject: RE: [Isis-wg] RE: IS Adjacency table > > > We are not in sync. > > There are two variables for each adjacency: what the type > (l1, l2, both) the other IS is, and how the adj is being > used (l1 or l2 on LAN, one of l1, l2, or both on p2p). Yes.There can be *either* l1 or l2 on LAN. This is the one I need. I was assuming that you meant for LAN, Usage can be l1, l2 or both. All the confusion came to me when usage is "both" in a broadcast network. Thanks for the clarification. -- Swaminathan > > I think we have everything you need. Perhaps you could > explain again what you need. > > - jeff parker > > > > > In draft-ietf-isis-wg-mib-07.txt IS Adj table, there is > no object > > > > conveying the message what "type" of adjacency is that > > > (either Level1 or > > > > Level2) > > > > > > I believe that the isisISAdjUsage variable conveys this > information. > > > > > > This is true for Point-to-Point. But in broadcast network, We > > create two > > adjacencies Level 1 and Level 2 separtely even the IS is > > configured as "L2 > > IS with manualL2Only false" i.e L1L2. > > In Sec 8.4.2 of ISO 10589, last paragraph reads like: > > > > "Level 2 Intermediate Systems (with manualL2onlyMode > > "False") shall perform > > both of the above actions.Separate Level 1 and Level 2 LAN > > IIH PDUs shall be > > sent to the multi-destination addresses AllL1ISs and AllL2ISs > > describing the > > neighbor Intermediate systems for Level 1 and Level 2 > > respectively.Separate > > Adjacencies shall be created by the receipt of Level 1 and > > Level 2 LAN IIH > > PDUs". > > > > It means even the IS is configured for L1L2, we create two > > Adjacencies with > > "neighbourSystemType" with L1 and L2 separately. My Point is > > there is no > > adjacencyUsage called "L1L2" in BROADCAST NETWORK. So any two > > "L1L2IS" will > > have 2 Adjacency separately for Level 1 & 2 respectively (as > > there are two > > different hellos) > > > > Also whenever we receive L1 IIH or L2 IIH, we need to set the > > neighbourSystemType to 'L1 IS' or 'L2 IS' as per sec 8.4.2.2 > > & 8.4.2.3. It > > will be easy to implement when one create two separate > > adjacency with L1 and > > L2 as "Adjacency Type". > > > > Let me know if we are not in sync.. > > > > > > > > > > - jeff parker > > > > > > From prz@redback.com Tue Mar 26 15:09:11 2002 From: prz@redback.com (Tony Przygienda) Date: Tue, 26 Mar 2002 07:09:11 -0800 Subject: [Isis-wg] few doubts on LSP purging References: <20020326094547.13926.qmail@web11202.mail.yahoo.com> Message-ID: <3CA08F16.125E3A4E@redback.com> Aravind Ravikumar wrote: > Hi, > > 1.While purging if we retain only the header and the authentication CLV, > the existing checksum will be inconsistent as we are removing rest of the > data portion So Do we need to > I would recommend to read the hmac draft and ponder over it some. Basically it is undesirable for anyone _but_ the originator to purge the originated LSP (and modern implementations adhere to this rule AFAIK) and in doing so, it should remove the content of the LSP except for the authentication TLV. This has denial-of-service protection implications that are spelled out. Coming back to the Dave-Tony reciprocal shoulder-patting on the 'maintain aged-out LSP' instead of dropping it after all neighbors acked ;-) IMHO I liked OSPF better when memory was at a premium and always went along the line 'if you can't write robust software, do something else in your life' since the OSPF spec was correct. Given the dramatic increase in memory & CPU availability in modern embedded systems and the constant or rather dropping amount of engineer brain cycles facing an onslaught of features and protocols, I tend to concur with them. Robust, over-engineered designs are better, except when they keep excessive amounts of redundant state. thqanks -- tony From jparker@axiowave.com Tue Mar 26 17:27:29 2002 From: jparker@axiowave.com (Jeff Parker) Date: Tue, 26 Mar 2002 12:27:29 -0500 Subject: [Isis-wg] RE: Local IP addresses in the ISIS MIB. Message-ID: > Hi Jeff > > The isisCircTable and isisCircLevelTable allow me to configure > a circuit, but not the IP addresses on that circuit (advertised > in TLV 132 in IIH PDUs). > > Are we expected to get this information from elsewhere? If not, > I think we should add a table to configure this information. > > Thanks > Gavin Gavin - I hope you won't think it a copout if I say that we shouldn't configure that. The IP address on an interface will be used by many others. Rather than invent our own storage for this, we should use standard MIBs for this purpose. - jeff parker From rja@extremenetworks.com Tue Mar 26 18:22:56 2002 From: rja@extremenetworks.com (RJ Atkinson) Date: Tue, 26 Mar 2002 13:22:56 -0500 Subject: [Isis-wg] RE: Local IP addresses in the ISIS MIB. In-Reply-To: Message-ID: <7EDD9FD3-40E6-11D6-BFF7-00039357A82A@extremenetworks.com> On Tuesday, March 26, 2002, at 12:27 , Jeff Parker wrote: >> Hi Jeff >> >> The isisCircTable and isisCircLevelTable allow me to configure >> a circuit, but not the IP addresses on that circuit (advertised >> in TLV 132 in IIH PDUs). >> >> Are we expected to get this information from elsewhere? If not, >> I think we should add a table to configure this information. >> >> Thanks >> Gavin > > Gavin - > I hope you won't think it a copout if I say that we > shouldn't configure that. > > The IP address on an interface will be used by many > others. Rather than invent our own storage for this, we > should use standard MIBs for this purpose. To paraphrase Jeff: One should use an existing Interface MIB (rather than IS-IS MIB) to configure the IP Addresses on interfaces. Ran rja@extremenetworks.com From prz@redback.com Tue Mar 26 16:23:55 2002 From: prz@redback.com (Tony Przygienda) Date: Tue, 26 Mar 2002 08:23:55 -0800 Subject: [Isis-wg] overran by spam, only posts by subscribed members will be appearing ... Message-ID: <3CA0A09B.E306CC58@redback.com> L&G, this list got overrun by spam. I used quietly to clean up somewhere between 30 and 200 messages per week of spam through the admin interface to pick out the few legitimate postings by un-subscribed people. Unfortunately, it's at the point where the effort is not worth it anymore. I just let the spam sit there and die. Which means, if you want your posting to appear, pls make sure you're subscribed to the list ... thanks -- tony From GMcP@dataconnection.com Tue Mar 26 17:22:51 2002 From: GMcP@dataconnection.com (Gavin McPherson) Date: Tue, 26 Mar 2002 17:22:51 -0000 Subject: [Isis-wg] Local IP addresses in the ISIS MIB. Message-ID: <53F74F5A7B94D511841C00B0D0AB16F8B50832@baker.datcon.co.uk> Hi Jeff The isisCircTable and isisCircLevelTable allow me to configure a circuit, but not the IP addresses on that circuit (advertised in TLV 132 in IIH PDUs). Are we expected to get this information from elsewhere? If not, I think we should add a table to configure this information. Thanks Gavin From danny@tcb.net Tue Mar 26 18:43:34 2002 From: danny@tcb.net (Danny McPherson) Date: Tue, 26 Mar 2002 11:43:34 -0700 Subject: [Isis-wg] overran by spam, only posts by subscribed members will be appearing ... Message-ID: <200203261843.g2QIhYj26387@tcb.net> Don't forget then to add explicit accept rules for the addresses outlined here: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt -danny > this list got overrun by spam. I used quietly to clean up somewhere > between 30 and 200 messages per week of spam through the admin > interface to pick out the few legitimate postings by un-subscribed > people. Unfortunately, it's at the point where the effort is not worth > it anymore. I just let the spam sit there and die. Which means, if > you want your posting to appear, pls make sure you're subscribed to > the list ... From prz@redback.com Tue Mar 26 16:52:14 2002 From: prz@redback.com (Tony Przygienda) Date: Tue, 26 Mar 2002 08:52:14 -0800 Subject: [Isis-wg] overran by spam, only posts by subscribed members will be appearing ... References: <200203261843.g2QIhYj26387@tcb.net> Message-ID: <3CA0A73D.8B09239@redback.com> Danny McPherson wrote: > Don't forget then to add explicit accept rules for the > addresses outlined here: > > http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt > Danny, thanks, done, actually this is just a threat, I'll look @ the big spam collection infrequently to pick out important stuff. It's just I wanted to forcce people to subscribe if they want to post and therefore make my job easier ;-) thanks -- tony > > -danny > > > this list got overrun by spam. I used quietly to clean up somewhere > > between 30 and 200 messages per week of spam through the admin > > interface to pick out the few legitimate postings by un-subscribed > > people. Unfortunately, it's at the point where the effort is not worth > > it anymore. I just let the spam sit there and die. Which means, if > > you want your posting to appear, pls make sure you're subscribed to > > the list ... From dkatz@juniper.net Tue Mar 26 22:50:32 2002 From: dkatz@juniper.net (Dave Katz) Date: Tue, 26 Mar 2002 14:50:32 -0800 (PST) Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <3CA08F16.125E3A4E@redback.com> (message from Tony Przygienda on Tue, 26 Mar 2002 07:09:11 -0800) References: <20020326094547.13926.qmail@web11202.mail.yahoo.com> <3CA08F16.125E3A4E@redback.com> Message-ID: <200203262250.g2QMoWM23230@cirrus.juniper.net> Coming back to the Dave-Tony reciprocal shoulder-patting on the 'maintain aged-out LSP' instead of dropping it after all neighbors acked ;-) IMHO I liked OSPF better when memory was at a premium and always went along the line 'if you can't write robust software, do something else in your life' since the OSPF spec was correct. Given the dramatic increase in memory & CPU availability in modern embedded systems and the constant or rather dropping amount of engineer brain cycles facing an onslaught of features and protocols, I tend to concur with them. Robust, over-engineered designs are better, except when they keep excessive amounts of redundant state. Obviously it was a formative moment for both of us. ;-) There is an existence proof that writing a robust routing protocol implementation is difficult, and becoming moreso by the day as the demands of features, scalability, and dynamism all increase. A brittle system has an unfortunate but quite spectacular way of failing catastrophically. Designs that are more forgiving are more practical to implement. On the other hand, brittle designs help reduce competition. It's all tradeoffs, of course, but if keeping the purged LSPs around for awhile cramps the memory footprint, you're probably already dead given the dynamic memory usage profiles of most implementations. (I think this equine corpse has been sufficiently beaten.) From swaminathanr@netplane.com Wed Mar 27 05:46:54 2002 From: swaminathanr@netplane.com (Ramalingam, Swaminathan) Date: Wed, 27 Mar 2002 00:46:54 -0500 Subject: [Isis-wg] RE: IS Adjacency table Message-ID: > -----Original Message----- > From: Jeff Parker [mailto:jparker@axiowave.com] > Sent: Tuesday, March 26, 2002 8:12 PM > To: 'Ramalingam, Swaminathan' > Cc: 'isis-wg@spider.juniper.net' > Subject: RE: [Isis-wg] RE: IS Adjacency table > > > We are not in sync. > > There are two variables for each adjacency: what the type > (l1, l2, both) the other IS is, and how the adj is being > used (l1 or l2 on LAN, one of l1, l2, or both on p2p). I have a doubt when I look in to Circ Level Table Indices. It has only 'level1IS' and 'level2IS'. If we have l1l2 adjacency (in p2p), we need l1l2IS Level Index, right?. Pl. Clarify Thanks, ~ Swaminathan > > I think we have everything you need. Perhaps you could > explain again what you need. > > - jeff parker > > From aravindravikumar@yahoo.com Wed Mar 27 07:11:35 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Tue, 26 Mar 2002 23:11:35 -0800 (PST) Subject: [Isis-wg] confusion regarding IP summarization Message-ID: <20020327071135.83418.qmail@web11201.mail.yahoo.com> --0-1036385184-1017213095=:82549 Content-Type: text/plain; charset=us-ascii Hi, All I am not clear about, what other information should be included in IP reachability field of level 2 LSP by a L1L2 IS, apart from IP addresses which are directly reachable via its own interfaces. Is it required to advertise ALL IP networks that are learned from other system's L1 LSP's IP reachability entries? or is it enough if the IS advetises(in its level2 LSP) ,only those networks which it considers reachable after the level1 SPF? Thanks in advance Aravind --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-1036385184-1017213095=:82549 Content-Type: text/html; charset=us-ascii

Hi, All

I am not  clear about, what other information
should be included in IP reachability
field of level 2 LSP by a L1L2 IS, apart from IP addresses
which are directly reachable via its own interfaces.

Is it required to advertise ALL IP networks that are learned
from other system's L1 LSP's IP reachability entries?

 or

is it enough if the IS  advetises(in its level2 LSP) ,only those networks
which it considers reachable after the level1 SPF?


Thanks in advance
Aravind



Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-1036385184-1017213095=:82549-- From tli@procket.com Wed Mar 27 08:02:17 2002 From: tli@procket.com (Tony Li) Date: Wed, 27 Mar 2002 00:02:17 -0800 Subject: [Isis-wg] confusion regarding IP summarization In-Reply-To: <20020327071135.83418.qmail@web11201.mail.yahoo.com> References: <20020327071135.83418.qmail@web11201.mail.yahoo.com> Message-ID: <15521.31881.626226.935425@alpha-tli.procket.com> | I am not clear about, what other information | should be included in IP reachability | field of level 2 LSP by a L1L2 IS, apart from IP addresses | which are directly reachable via its own interfaces. | | Is it required to advertise ALL IP networks that are learned | from other system's L1 LSP's IP reachability entries? | | or | | is it enough if the IS advetises(in its level2 LSP) ,only those networks | which it considers reachable after the level1 SPF? My interpretation is that the L2 is only required to include all of its local prefixes. Additional route injection is an implementation decision. Tony From tli@procket.com Wed Mar 27 08:49:11 2002 From: tli@procket.com (Tony Li) Date: Wed, 27 Mar 2002 00:49:11 -0800 Subject: [Isis-wg] few doubts on LSP purging In-Reply-To: <4.3.2.7.2.20020326103406.035d4618@jaws.cisco.com> References: <4.3.2.7.2.20020325103234.03639ee0@jaws.cisco.com> <4.3.2.7.2.20020326103406.035d4618@jaws.cisco.com> Message-ID: <15521.34695.503552.591936@alpha-tli.procket.com> | >1.While purging if we retain only the header and the authentication CLV, | >the existing checksum will be inconsistent as we are removing rest of the | >data portion So Do we need to | > | >A.Recompute checksum? or | > | >B.Leave it as it is? or | > | >C.Make it 0 | | The original design assumed that you would make it zero. However you can in | fact do any of the above because the checksum is not checked for a zero | lifetime PDU. IMHO, you should do A, in keeping with the general idea that checksums are good. Even if an implementation doesn't check them, you can be strict in what you send to insure interoperability. Tony From rsaluja@nortelnetworks.com Wed Mar 27 14:57:26 2002 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 27 Mar 2002 09:57:26 -0500 Subject: [Isis-wg] confusion regarding IP summarization References: <20020327071135.83418.qmail@web11201.mail.yahoo.com> Message-ID: <3CA1DDD6.DABBBAD1@nortelnetworks.com> Aravind Ravikumar wrote: > Hi, All > > I am not clear about, what other information > should be included in IP reachability > field of level 2 LSP by a L1L2 IS, apart from IP addresses > which are directly reachable via its own interfaces. > > Is it required to advertise ALL IP networks that are learned > from other system's L1 LSP's IP reachability entries? > > or > > is it enough if the IS advetises(in its level2 LSP) ,only those > networks > which it considers reachable after the level1 SPF? I think you should advertise the configured summary addresses and then go through the networks reachable after the level1 SPF and if the network is not covered by the summary address, you should advertise that network as well. Thanks, Rajesh > > > > Thanks in advance > Aravind > > > ----------------------------------------------------------------------- > Do You Yahoo!? > Yahoo! Movies - coverage of the 74th Academy Awards® -- ------------------------------------------------------------- Rajesh Saluja Nortel Networks Inc 600 Technology Park Billerica, MA 01821 Ph: (978) 288-7791 Fax: (978) 670-8760 -------------------------------------------------------------- From sprevidi@cisco.com Wed Mar 27 15:21:25 2002 From: sprevidi@cisco.com (stefano previdi) Date: Wed, 27 Mar 2002 16:21:25 +0100 Subject: [Isis-wg] confusion regarding IP summarization In-Reply-To: <3CA1DDD6.DABBBAD1@nortelnetworks.com> References: <20020327071135.83418.qmail@web11201.mail.yahoo.com> <3CA1DDD6.DABBBAD1@nortelnetworks.com> Message-ID: <200203271521.QAA25108@strange-brew.cisco.com> On Wednesday 27 March 2002 15:57, Rajesh Saluja wrote: > Aravind Ravikumar wrote: > > > Hi, All > > > > I am not clear about, what other information > > should be included in IP reachability > > field of level 2 LSP by a L1L2 IS, apart from IP addresses > > which are directly reachable via its own interfaces. > > > > Is it required to advertise ALL IP networks that are learned > > from other system's L1 LSP's IP reachability entries? > > > > or > > > > is it enough if the IS advetises(in its level2 LSP) ,only those > > networks > > which it considers reachable after the level1 SPF? > > I think you should advertise the configured summary addresses and then > go through the networks reachable after the level1 SPF and if the > network is not covered by the summary address, you should advertise that > network as well. I would suggest to advertise summary addresses only if you have more specific routes. s. > > Thanks, > Rajesh > > > > > > > > > Thanks in advance > > Aravind > > > > > > ----------------------------------------------------------------------- > > Do You Yahoo!? > > Yahoo! Movies - coverage of the 74th Academy Awards® > > -- > > ------------------------------------------------------------- > Rajesh Saluja > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > Ph: (978) 288-7791 Fax: (978) 670-8760 > -------------------------------------------------------------- > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > From rsaluja@nortelnetworks.com Wed Mar 27 15:29:18 2002 From: rsaluja@nortelnetworks.com (Rajesh Saluja) Date: Wed, 27 Mar 2002 07:29:18 -0800 Subject: [Isis-wg] confusion regarding IP summarization Message-ID: <8B888AAAAB0FD31189590008C7918443080F52AA@zbl6c002.corpeast.baynetworks.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D5A4.29461098 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, advertise summary address only if you have at least one more = specific network (for this summary) calculated through level 1 SPF.=20 Thanks, Rajesh -----Original Message----- From: stefano previdi [mailto:sprevidi@cisco.com] Sent: Wednesday, March 27, 2002 10:21 AM To: Saluja, Rajesh [BL60:432:EXCH]; Aravind Ravikumar Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] confusion regarding IP summarization On Wednesday 27 March 2002 15:57, Rajesh Saluja wrote: > Aravind Ravikumar wrote: >=20 > > Hi, All > > > > I am not clear about, what other information > > should be included in IP reachability > > field of level 2 LSP by a L1L2 IS, apart from IP addresses > > which are directly reachable via its own interfaces. > > > > Is it required to advertise ALL IP networks that are learned > > from other system's L1 LSP's IP reachability entries? > > > > or > > > > is it enough if the IS advetises(in its level2 LSP) ,only those > > networks > > which it considers reachable after the level1 SPF? >=20 > I think you should advertise the configured summary addresses and = then > go through the networks reachable after the level1 SPF and if the > network is not covered by the summary address, you should advertise = that > network as well. I would suggest to advertise summary addresses only if you have=20 more specific routes. s. >=20 > Thanks, > Rajesh >=20 > > > > > > > > Thanks in advance > > Aravind > > > > > > = ----------------------------------------------------------------------- > > Do You Yahoo!? > > Yahoo! Movies - coverage of the 74th Academy Awards=AE >=20 > -- >=20 > ------------------------------------------------------------- > Rajesh Saluja > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > Ph: (978) 288-7791 Fax: (978) 670-8760 > -------------------------------------------------------------- >=20 >=20 >=20 > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg >=20 ------_=_NextPart_001_01C1D5A4.29461098 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Isis-wg] confusion regarding IP summarization

Yes, advertise summary address only if you have at = least one more specific network (for this summary) calculated through = level 1 SPF.

Thanks,
Rajesh

-----Original Message-----
From: stefano previdi [mailto:sprevidi@cisco.com]=
Sent: Wednesday, March 27, 2002 10:21 AM
To: Saluja, Rajesh [BL60:432:EXCH]; Aravind = Ravikumar
Cc: isis-wg@juniper.net
Subject: Re: [Isis-wg] confusion regarding IP = summarization


On Wednesday 27 March 2002 15:57, Rajesh Saluja = wrote:
> Aravind Ravikumar wrote:
>
> > Hi, All
> >
> > I am not  clear about, what other = information
> > should be included in IP = reachability
> > field of level 2 LSP by a L1L2 IS, apart = from IP addresses
> > which are directly reachable via its own = interfaces.
> >
> > Is it required to advertise ALL IP = networks that are learned
> > from other system's L1 LSP's IP = reachability entries?
> >
> >  or
> >
> > is it enough if the IS  advetises(in = its level2 LSP) ,only those
> > networks
> > which it considers reachable after the = level1 SPF?
>
> I think you should advertise the configured = summary addresses and then
> go through the networks reachable after the = level1 SPF and if the
> network is not covered by the summary address, = you should advertise that
> network as well.

I would suggest to advertise summary addresses only = if you have
more specific routes.

s.

>
> Thanks,
> Rajesh
>
> >
> >
> >
> > Thanks in advance
> > Aravind
> >
> >
> > = -----------------------------------------------------------------------<= /FONT>
> > Do You Yahoo!?
> > Yahoo! Movies - coverage of the 74th = Academy Awards=AE
>
> --
>
> = -------------------------------------------------------------
> Rajesh Saluja
> Nortel Networks Inc 600 Technology Park = Billerica, MA  01821
> Ph: (978) = 288-7791      Fax: (978) 670-8760
> = --------------------------------------------------------------
>
>
>
> = _______________________________________________
> Isis-wg mailing list  -  = Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg=
>

------_=_NextPart_001_01C1D5A4.29461098-- From prz@redback.com Wed Mar 27 13:27:45 2002 From: prz@redback.com (Tony Przygienda) Date: Wed, 27 Mar 2002 05:27:45 -0800 Subject: [Isis-wg] confusion regarding IP summarization References: <20020327071135.83418.qmail@web11201.mail.yahoo.com> <3CA1DDD6.DABBBAD1@nortelnetworks.com> Message-ID: <3CA1C8D1.A387F82B@redback.com> Rajesh Saluja wrote: > Aravind Ravikumar wrote: > > > Hi, All > > > > I am not clear about, what other information > > should be included in IP reachability > > field of level 2 LSP by a L1L2 IS, apart from IP addresses > > which are directly reachable via its own interfaces. > > > > Is it required to advertise ALL IP networks that are learned > > from other system's L1 LSP's IP reachability entries? > > > > or > > > > is it enough if the IS advetises(in its level2 LSP) ,only those > > networks > > which it considers reachable after the level1 SPF? > > I think you should advertise the configured summary addresses and then > go through the networks reachable after the level1 SPF and if the > network is not covered by the summary address, you should advertise that > network as well. Rajesh, that's implementation advice which is ok to discuss on the list IMHO with big disclaimers disclosing it as such and preferrably declining any liability ;-) Now, giving questionable or wrong implementaiton advice as I think you're doing here ;-) can be taken as sign of naivite or as subtle influence ... This kind of stretches my judgement capability as of whether it's ok or not since it has been done by major players within IETF as well ;-) thanks -- tony From canningt@nortelnetworks.com Wed Mar 27 15:49:38 2002 From: canningt@nortelnetworks.com (Terry Canning) Date: Wed, 27 Mar 2002 15:49:38 -0000 Subject: [Isis-wg] confusion regarding IP summarization Message-ID: <17A46A8BD7E7D41199E300508BE3A94C03F3E335@zirey00b.europe.nortel.com> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D5A7.00939A14 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, RFC 1195 is quite clear on this matter. Section 3.2 states: The manually configured addresses are included in level 2 LSPs only if they correspond to at least one address which is reachable in the area. For manually configured level 2 addresses, the associated metric values to announce in level 2 LSPs are also manually configured. The configured addresses will supercede reachable = address entries from level 1 LSPs based only on the IP address and subnet mask -- metric values are not considered when determining if a given configured address supercedes an address obtained from a level 1 = LSP. =20 Any address obtained from a level 1 LSP which is not superceded by the manually configured information is included in the level 2 LSPs. Regards Terry Canning -----Original Message----- From: stefano previdi [mailto:sprevidi@cisco.com] Sent: 27 March 2002 15:21 To: Saluja, Rajesh [BL60:432:EXCH]; Aravind Ravikumar Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] confusion regarding IP summarization On Wednesday 27 March 2002 15:57, Rajesh Saluja wrote: > Aravind Ravikumar wrote: >=20 > > Hi, All > > > > I am not clear about, what other information > > should be included in IP reachability > > field of level 2 LSP by a L1L2 IS, apart from IP addresses > > which are directly reachable via its own interfaces. > > > > Is it required to advertise ALL IP networks that are learned > > from other system's L1 LSP's IP reachability entries? > > > > or > > > > is it enough if the IS advetises(in its level2 LSP) ,only those > > networks > > which it considers reachable after the level1 SPF? >=20 > I think you should advertise the configured summary addresses and = then > go through the networks reachable after the level1 SPF and if the > network is not covered by the summary address, you should advertise = that > network as well. I would suggest to advertise summary addresses only if you have=20 more specific routes. s. >=20 > Thanks, > Rajesh >=20 > > > > > > > > Thanks in advance > > Aravind > > > > > > = ----------------------------------------------------------------------- > > Do You Yahoo!? > > Yahoo! Movies - coverage of the 74th Academy Awards=AE >=20 > -- >=20 > ------------------------------------------------------------- > Rajesh Saluja > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > Ph: (978) 288-7791 Fax: (978) 670-8760 > -------------------------------------------------------------- >=20 >=20 >=20 > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg >=20 _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg ------_=_NextPart_001_01C1D5A7.00939A14 Content-Type: text/html; charset="iso-8859-1" RE: [Isis-wg] confusion regarding IP summarization

Folks,



RFC 1195 is quite clear on this matter. Section 3.2 states:



   The manually configured addresses are included in level 2 LSPs only

   if they correspond to at least one address which is reachable in the

   area. For manually configured level 2 addresses, the associated

   metric values to announce in level 2 LSPs are also manually

   configured. The configured addresses will supercede reachable address

   entries from level 1 LSPs based only on the IP address and subnet

   mask -- metric values are not considered when determining if a given

   configured address supercedes an address obtained from a level 1 LSP.

 

   Any address obtained from a level 1 LSP which is not superceded by

   the manually configured information is included in the level 2 LSPs.



Regards

Terry Canning



-----Original Message-----
From: stefano previdi [mailto:sprevidi@cisco.com]
Sent: 27 March 2002 15:21
To: Saluja, Rajesh [BL60:432:EXCH]; Aravind Ravikumar
Cc: isis-wg@juniper.net
Subject: Re: [Isis-wg] confusion regarding IP summarization


On Wednesday 27 March 2002 15:57, Rajesh Saluja wrote:

> Aravind Ravikumar wrote:

>

> > Hi, All

> >

> > I am not  clear about, what other information

> > should be included in IP reachability

> > field of level 2 LSP by a L1L2 IS, apart from IP addresses

> > which are directly reachable via its own interfaces.

> >

> > Is it required to advertise ALL IP networks that are learned

> > from other system's L1 LSP's IP reachability entries?

> >

> >  or

> >

> > is it enough if the IS  advetises(in its level2 LSP) ,only those

> > networks

> > which it considers reachable after the level1 SPF?

>

> I think you should advertise the configured summary addresses and then

> go through the networks reachable after the level1 SPF and if the

> network is not covered by the summary address, you should advertise that

> network as well.



I would suggest to advertise summary addresses only if you have

more specific routes.



s.



>

> Thanks,

> Rajesh

>

> >

> >

> >

> > Thanks in advance

> > Aravind

> >

> >

> > -----------------------------------------------------------------------

> > Do You Yahoo!?

> > Yahoo! Movies - coverage of the 74th Academy Awards®

>

> --

>

> -------------------------------------------------------------

> Rajesh Saluja

> Nortel Networks Inc 600 Technology Park Billerica, MA  01821

> Ph: (978) 288-7791      Fax: (978) 670-8760

> --------------------------------------------------------------

>

>

>

> _______________________________________________

> Isis-wg mailing list  -  Isis-wg@spider.juniper.net

> http://spider.juniper.net/mailman/listinfo/isis-wg

>

_______________________________________________

Isis-wg mailing list  -  Isis-wg@spider.juniper.net

http://spider.juniper.net/mailman/listinfo/isis-wg

------_=_NextPart_001_01C1D5A7.00939A14-- From cast@allegronetworks.com Wed Mar 27 20:14:59 2002 From: cast@allegronetworks.com (Neal Castagnoli) Date: Wed, 27 Mar 2002 12:14:59 -0800 Subject: [Isis-wg] confusion regarding IP summarization Message-ID: RFC 2966 has something to say about this too: Another detail that implementors should be aware of is the fact that L1L2 routers should only advertise in their L2 LSP those L1 routes that they use for forwarding themselves. They should not unconditionally advertise into L2 all prefixes from LSPs in the L1 database. Is it OK to discuss on this list about whether or not the whole specified automatic redistribution thing is good default behavior? --Neal -----Original Message----- From: Terry Canning [mailto:canningt@nortelnetworks.com] Sent: Wednesday, March 27, 2002 7:50 AM To: stefano previdi; Rajesh Saluja; Aravind Ravikumar Cc: isis-wg@juniper.net Subject: RE: [Isis-wg] confusion regarding IP summarization Folks, RFC 1195 is quite clear on this matter. Section 3.2 states: The manually configured addresses are included in level 2 LSPs only if they correspond to at least one address which is reachable in the area. For manually configured level 2 addresses, the associated metric values to announce in level 2 LSPs are also manually configured. The configured addresses will supercede reachable address entries from level 1 LSPs based only on the IP address and subnet mask -- metric values are not considered when determining if a given configured address supercedes an address obtained from a level 1 LSP. Any address obtained from a level 1 LSP which is not superceded by the manually configured information is included in the level 2 LSPs. Regards Terry Canning -----Original Message----- From: stefano previdi [mailto:sprevidi@cisco.com] Sent: 27 March 2002 15:21 To: Saluja, Rajesh [BL60:432:EXCH]; Aravind Ravikumar Cc: isis-wg@juniper.net Subject: Re: [Isis-wg] confusion regarding IP summarization On Wednesday 27 March 2002 15:57, Rajesh Saluja wrote: > Aravind Ravikumar wrote: > > > Hi, All > > > > I am not clear about, what other information > > should be included in IP reachability > > field of level 2 LSP by a L1L2 IS, apart from IP addresses > > which are directly reachable via its own interfaces. > > > > Is it required to advertise ALL IP networks that are learned > > from other system's L1 LSP's IP reachability entries? > > > > or > > > > is it enough if the IS advetises(in its level2 LSP) ,only those > > networks > > which it considers reachable after the level1 SPF? > > I think you should advertise the configured summary addresses and then > go through the networks reachable after the level1 SPF and if the > network is not covered by the summary address, you should advertise that > network as well. I would suggest to advertise summary addresses only if you have more specific routes. s. > > Thanks, > Rajesh > > > > > > > > > Thanks in advance > > Aravind > > > > > > ----------------------------------------------------------------------- > > Do You Yahoo!? > > Yahoo! Movies - coverage of the 74th Academy Awards® > > -- > > ------------------------------------------------------------- > Rajesh Saluja > Nortel Networks Inc 600 Technology Park Billerica, MA 01821 > Ph: (978) 288-7791 Fax: (978) 670-8760 > -------------------------------------------------------------- > > > > _______________________________________________ > Isis-wg mailing list - Isis-wg@spider.juniper.net > http://spider.juniper.net/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg From tli@procket.com Wed Mar 27 20:58:50 2002 From: tli@procket.com (Tony Li) Date: Wed, 27 Mar 2002 12:58:50 -0800 Subject: [Isis-wg] confusion regarding IP summarization In-Reply-To: References: Message-ID: <15522.12938.630184.132444@alpha-tli.procket.com> | Is it OK to discuss on this list about whether or not the whole specified | automatic redistribution thing is good default behavior? It's fine by me within reason. Just understand that it's an off-topic conversation about implementation issues and isn't a WG issue. Tony From jlearman@cisco.com Wed Mar 27 21:13:55 2002 From: jlearman@cisco.com (Jeff Learman) Date: Wed, 27 Mar 2002 16:13:55 -0500 Subject: [Isis-wg] confusion regarding IP summarization In-Reply-To: <15522.12938.630184.132444@alpha-tli.procket.com> References: Message-ID: <4.3.2.7.2.20020327161018.01cb7e58@dingdong.cisco.com> Tony, based on an earlier post, it seems to me that 1195 requires automatic L2 distribution of L1 routes that aren't covered by L2 configured summary routes. You didn't contradict it, but I think that the text in 2966 that Neal quoted did. Sounds to me that there's more than an implementation issue here. Jeff At 03:58 PM 3/27/2002, Tony Li wrote: > | Is it OK to discuss on this list about whether or not the whole specified > | automatic redistribution thing is good default behavior? > > >It's fine by me within reason. Just understand that it's an off-topic >conversation about implementation issues and isn't a WG issue. > >Tony >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg From aravindravikumar@yahoo.com Thu Mar 28 09:27:02 2002 From: aravindravikumar@yahoo.com (Aravind Ravikumar) Date: Thu, 28 Mar 2002 01:27:02 -0800 (PST) Subject: [Isis-wg] confusion regarding IP summarization In-Reply-To: <4.3.2.7.2.20020327161018.01cb7e58@dingdong.cisco.com> Message-ID: <20020328092702.63680.qmail@web11202.mail.yahoo.com> --0-1866968233-1017307622=:60859 Content-Type: text/plain; charset=us-ascii Hi, I also feel that its not an implementation issue. I was trying to find what exactly certain section of RFC 1195 means The quoted section of RFC 1195 ( More specifically the following sentance was the source of my confusion, "Any address obtained from a level 1 LSP which is not superceded by the manually configured information is included in the level 2 LSPs.") Some of these IP addresses which we get in L1 LSP may not be added to our forwarding database as a result of there being no path to the advertising router. I think that it will be inconsistent if an we advertises about routes that we ourselves are not using.The question was asked in this context The quoted section of rfc 2966 also seems to say the same thing, So if we go strictly by the words the section of rfc 1195 and the section of rfc 2966 sounds contradictory The section next to the quoted section of rfc 2966 says this "Not all prefixes need to be advertised up or down the hierarchy. Implementations might allow for additional manual filtering or summarization to further bring down the number of inter-area prefixes they advertise in their LSPs." RFC 1195 seems to give no such choice and is strictly saying to advertise all address obtained from level 1 LSP.(Either advertise the Summary which supercedes it or if no such summary is configured it advertise the netwok itself) But the following section of rfc 1195 wchich talks about cost computation of advertised IP addresses seems to help "Any address obtained from a level 1 LSP which is not superceded by the manually configured information is included in the level 2 LSPs. In this case, the metric value announced in the level 2 LSPs is calculated from the sum of the metric value announced in the corresponding level 1 LSP, plus the distance from the level 2 router to the appropriate level 1 router . Note: If this sum resultsin a metric value greater than 63 (the maximum value that can be reported in level 2 LSPs), thenthe value 63 must be used." Does this section imply that if we don't have an entry to the advertising level1 router we should'nt advertise those IP address in level 2 LSP,since we cannot compute the cost If this interpretation is corrrect then there is no contradiction. Is it correct? Aravind Jeff Learman wrote: Tony, based on an earlier post, it seems to me that 1195 requires automatic L2 distribution of L1 routes that aren't covered by L2 configured summary routes. You didn't contradict it, but I think that the text in 2966 that Neal quoted did. Sounds to me that there's more than an implementation issue here. Jeff At 03:58 PM 3/27/2002, Tony Li wrote: > | Is it OK to discuss on this list about whether or not the whole specified > | automatic redistribution thing is good default behavior? > > >It's fine by me within reason. Just understand that it's an off-topic >conversation about implementation issues and isn't a WG issue. > >Tony >_______________________________________________ >Isis-wg mailing list - Isis-wg@spider.juniper.net >http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________ Isis-wg mailing list - Isis-wg@spider.juniper.net http://spider.juniper.net/mailman/listinfo/isis-wg --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® --0-1866968233-1017307622=:60859 Content-Type: text/html; charset=us-ascii

Hi,

I also feel that its not an implementation issue.

I was trying to find what exactly certain section of RFC 1195 means

The  quoted section of RFC 1195 ( More specifically the following
sentance was the source of my confusion,
"Any address obtained from a level 1 LSP which is not superceded by
the manually configured information is included in the level 2 LSPs.")

Some of these IP addresses which we get in L1 LSP
may not be added to our forwarding database as a result of
there being no path to the advertising router.
I think that it will be inconsistent if an we advertises about routes
that we ourselves are not using.The question was asked in this context

The quoted section of rfc 2966 also seems to say the same thing,
So if we go strictly by the words the section of
rfc 1195 and the  section of rfc 2966 sounds contradictory


The section next to the quoted section of rfc 2966 says this

   "Not all prefixes need to be advertised up or down the hierarchy.
   Implementations might allow for additional manual filtering or
   summarization to further bring down the number of inter-area prefixes
   they advertise in their LSPs."

RFC 1195 seems to give no such choice and is strictly saying to
advertise all address obtained from level 1 LSP.(Either advertise
the Summary which supercedes it or if no such summary is
configured it advertise the netwok itself)

But the following section of rfc 1195 wchich talks about cost computation of advertised
IP addresses seems to help

"Any address obtained from a level 1 LSP which is not superceded by the
manually configured information is included in the level 2 LSPs. In this
case, the metric value announced in the level 2 LSPs is calculated from
the sum of the metric value announced in the corresponding level 1 LSP,
plus the distance from the level 2 router to the appropriate level 1 router
. Note: If this sum resultsin a metric value greater than 63 (the maximum
value that can be reported in level 2 LSPs), thenthe value 63 must be used."

Does this section imply that if we don't have an entry to the advertising level1
router we should'nt advertise those IP address in level 2 LSP,since we cannot compute the cost

If this interpretation is corrrect
then there is no contradiction. Is it correct?

Aravind

 


 

  Jeff Learman <jlearman@cisco.com> wrote:


Tony, based on an earlier post, it seems to me that 1195 requires
automatic L2 distribution of L1 routes that aren't covered by L2
configured summary routes. You didn't contradict it, but I think
that the text in 2966 that Neal quoted did.

Sounds to me that there's more than an implementation issue here.

Jeff


At 03:58 PM 3/27/2002, Tony Li wrote:


> | Is it OK to discuss on this list about whether or not the whole specified
> | automatic redistribution thing is good default behavior?
>
>
>It's fine by me within reason. Just understand that it's an off-topic
>conversation about implementation issues and isn't a WG issue.
>
>Tony
>_______________________________________________
>Isis-wg mailing list - Isis-wg@spider.juniper.net
>http://spider.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list - Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg



Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards® --0-1866968233-1017307622=:60859-- From Internet-Drafts@ietf.org Thu Mar 28 12:07:28 2002 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Thu, 28 Mar 2002 07:07:28 -0500 Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-09.txt Message-ID: <200203281207.HAA22210@ietf.org> --NextPart 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 : IS-IS Extensions in Support of Generalized MPLS Author(s) : K. Kompella, Y. Rekhter, A. Banerjee, J. Drake, G. Bernstein, D. Fedyk, E. Mannie, D. Saha, V. Sharma Filename : draft-ietf-isis-gmpls-extensions-09.txt Pages : 10 Date : 27-Mar-02 This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). The description of the extensions is specified in [GMPLS- ROUTING]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-gmpls-extensions-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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020327152124.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isis-gmpls-extensions-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020327152124.I-D@ietf.org> --OtherAccess-- --NextPart-- From jlearman@cisco.com Thu Mar 28 13:24:11 2002 From: jlearman@cisco.com (Jeff Learman) Date: Thu, 28 Mar 2002 08:24:11 -0500 Subject: [Isis-wg] confusion regarding IP summarization In-Reply-To: <20020328092702.63680.qmail@web11202.mail.yahoo.com> References: <4.3.2.7.2.20020327161018.01cb7e58@dingdong.cisco.com> Message-ID: <4.3.2.7.2.20020328081330.03a89008@dingdong.cisco.com> --=====================_146718500==_.ALT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While it may be safer to include only reachable L1 routes in one's L2 LSPs, the existence of any unreachable L1 routes indicates that the area is partitioned. I don't think it was the intent of 1195 (and it clearly was not the intent of 10589) to deal with area partitions by changing L2 address advertisements. Offhand, I can't see what harm would be caused by omitting unreachable addresses, other than a little more L2 SPF churn for a flapping L1 link that partitions an area. Regards, Jeff Disclaimer: I do not work on IS-IS at Cisco, and my opinions do not necessarily reflect those of my employer. At 04:27 AM 3/28/2002, Aravind Ravikumar wrote: >Hi,=20 > >I also feel that its not an implementation issue. > >I was trying to find what exactly certain section of RFC 1195 means > >The quoted section of RFC 1195 ( More specifically the following >sentance was the source of my confusion, >"Any address obtained from a level 1 LSP which is not superceded by=20 >the manually configured information is included in the level 2 LSPs.") > >Some of these IP addresses which we get in L1 LSP >may not be added to our forwarding database as a result of >there being no path to the advertising router. >I think that it will be inconsistent if an we advertises about routes >that we ourselves are not using.The question was asked in this context=20 > >The quoted section of rfc 2966 also seems to say the same thing, >So if we go strictly by the words the section of=20 >rfc 1195 and the section of rfc 2966 sounds contradictory=20 > > >The section next to the quoted section of rfc 2966 says this=20 > > "Not all prefixes need to be advertised up or down the hierarchy. > Implementations might allow for additional manual filtering or > summarization to further bring down the number of inter-area prefixes > they advertise in their LSPs."=20 > >RFC 1195 seems to give no such choice and is strictly saying to=20 >advertise all address obtained from level 1 LSP.(Either advertise=20 >the Summary which supercedes it or if no such summary is >configured it advertise the netwok itself)=20 > >But the following section of rfc 1195 wchich talks about cost computation= of advertised=20 >IP addresses seems to help=20 > >"Any address obtained from a level 1 LSP which is not superceded by the=20 >manually configured information is included in the level 2 LSPs. In this=20 >case, the metric value announced in the level 2 LSPs is calculated from=20 >the sum of the metric value announced in the corresponding level 1 LSP, >plus the distance from the level 2 router to the appropriate level 1 router >. Note: If this sum resultsin a metric value greater than 63 (the maximum= =20 >value that can be reported in level 2 LSPs), thenthe value 63 must be= used."=20 > >Does this section imply that if we don't have an entry to the advertising= level1 >router we should'nt advertise those IP address in level 2 LSP,since we= cannot compute the cost > >If this interpretation is corrrect >then there is no contradiction. Is it correct? > >Aravind=20 > > =20 > > > =20 > > Jeff Learman wrote:=20 >> >>Tony, based on an earlier post, it seems to me that 1195 requires >>automatic L2 distribution of L1 routes that aren't covered by L2 >>configured summary routes. You didn't contradict it, but I think >>that the text in 2966 that Neal quoted did. >> >>Sounds to me that there's more than an implementation issue here. >> >>Jeff >> >> >>At 03:58 PM 3/27/2002, Tony Li wrote: >> >> >>> | Is it OK to discuss on this list about whether or not the whole= specified >>> | automatic redistribution thing is good default behavior? >>> >>> >>>It's fine by me within reason. Just understand that it's an off-topic >>>conversation about implementation issues and isn't a WG issue. >>> >>>Tony >>>_______________________________________________ >>>Isis-wg mailing list - Isis-wg@spider.juniper.net >>>http://spider.juniper.net/mailman/listinfo/isis-wg >>_______________________________________________ >>Isis-wg mailing list - Isis-wg@spider.juniper.net >>http://spider.juniper.net/mailman/listinfo/isis-wg > > > >Do You Yahoo!? >Yahoo! Movies - coverage of the 74th Academy Awards=AE=20 --=====================_146718500==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
While it may be safer to include only reachable L1 routes in one's
L2 LSPs, the existence of any unreachable L1 routes indicates that
the area is partitioned.  I don't think it was the intent of 1195
(and it clearly was not the intent of 10589) to deal with area partitions
by changing L2 address advertisements.

Offhand, I can't see what harm would be caused by omitting unreachable
addresses, other than a little more L2 SPF churn for a flapping L1 link
that partitions an area.

Regards,
Jeff

Disclaimer: I do not work on IS-IS at Cisco, and my opinions do not
necessarily reflect those of my employer.



At 04:27 AM 3/28/2002, Aravind Ravikumar wrote:

Hi,

I also feel that its not an implementation issue.

I was trying to find what exactly certain section of RFC 1195 means

The  quoted section of RFC 1195 ( More specifically the following
sentance was the source of my confusion,
"Any address obtained from a level 1 LSP which is not superceded by
the manually configured information is included in the level 2 LSPs.")

Some of these IP addresses which we get in L1 LSP
may not be added to our forwarding database as a result of
there being no path to the advertising router.
I think that it will be inconsistent if an we advertises about routes
that we ourselves are not using.The question was asked in this context

The quoted section of rfc 2966 also seems to say the same thing,
So if we go strictly by the words the section of
rfc 1195 and the  section of rfc 2966 sounds contradictory


The section next to the quoted section of rfc 2966 says this

   "Not all prefixes need to be advertised up or down the hierarchy.
   Implementations might allow for additional manual filtering or
   summarization to further bring down the number of inter-area prefixes
   they advertise in their LSPs."

RFC 1195 seems to give no such choice and is strictly saying to
advertise all address obtained from level 1 LSP.(Either advertise
the Summary which supercedes it or if no such summary is
configured it advertise the netwok itself)

But the following section of rfc 1195 wchich talks about cost computation of advertised
IP addresses seems to help

"Any address obtained from a level 1 LSP which is not superceded by the
manually configured information is included in the level 2 LSPs. In this
case, the metric value announced in the level 2 LSPs is calculated from
the sum of the metric value announced in the corresponding level 1 LSP,
plus the distance from the level 2 router to the appropriate level 1 router
. Note: If this sum resultsin a metric value greater than 63 (the maximum
value that can be reported in level 2 LSPs), thenthe value 63 must be used."

Does this section imply that if we don't have an entry to the advertising level1
router we should'nt advertise those IP address in level 2 LSP,since we cannot compute the cost

If this interpretation is corrrect
then there is no contradiction. Is it correct?

Aravind

 


 

  Jeff Learman <jlearman@cisco.com> wrote:=20

Tony, based on an earlier post, it seems to me that 1195 requires
automatic L2 distribution of L1 routes that aren't covered by L2
configured summary routes. You didn't contradict it, but I think
that the text in 2966 that Neal quoted did.

Sounds to me that there's more than an implementation issue here.

Jeff


At 03:58 PM 3/27/2002, Tony Li wrote:


> | Is it OK to discuss on this list about whether or not the whole specified
> | automatic redistribution thing is good default behavior?
>
>
>It's fine by me within reason. Just understand that it's an off-topic
>conversation about implementation issues and isn't a WG issue.
>
>Tony
>_______________________________________________
>Isis-wg mailing list - Isis-wg@spider.juniper.net
>http://spider.juniper.net/mailman/listinfo/isis-wg _______________________________________________
Isis-wg mailing list - Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg


Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards=AE
--=====================_146718500==_.ALT-- From tli@procket.com Thu Mar 28 18:52:07 2002 From: tli@procket.com (Tony Li) Date: Thu, 28 Mar 2002 10:52:07 -0800 Subject: [Isis-wg] confusion regarding IP summarization In-Reply-To: <4.3.2.7.2.20020328081330.03a89008@dingdong.cisco.com> References: <4.3.2.7.2.20020327161018.01cb7e58@dingdong.cisco.com> <4.3.2.7.2.20020328081330.03a89008@dingdong.cisco.com> Message-ID: <15523.26199.642001.684563@alpha-tli.procket.com> | Offhand, I can't see what harm would be caused by omitting unreachable | addresses, other than a little more L2 SPF churn for a flapping L1 link | that partitions an area. If your L1 is partitioned and you have multiple L1L2s for the area, then you want each L1L2 to only advertise its reachable addresses. Tony From prz@net4u.ch Fri Mar 29 08:03:47 2002 From: prz@net4u.ch (Tony Przygienda) Date: Fri, 29 Mar 2002 00:03:47 -0800 Subject: [Isis-wg] confusion regarding IP summarization References: <4.3.2.7.2.20020327161018.01cb7e58@dingdong.cisco.com> <4.3.2.7.2.20020328081330.03a89008@dingdong.cisco.com> <15523.26199.642001.684563@alpha-tli.procket.com> Message-ID: <3CA41FE3.5080005@net4u.ch> Tony Li wrote: > > | Offhand, I can't see what harm would be caused by omitting unreachable > | addresses, other than a little more L2 SPF churn for a flapping L1 link > | that partitions an area. > > >If your L1 is partitioned and you have multiple L1L2s for the area, then >you want each L1L2 to only advertise its reachable addresses. > so this is just one example of why e.g. you would _not_ aggregate even you have an aggregate configured. I had a half-written ospf draft 1-2 years ago after discussions with John & Rob suggesting that if you see advertisement from an ABR in your area that is not connected (kind of easy to figure out when you ran intra-area computation), you should _deaggregate_ into area 0. Never seemed quite worth it since as pointed out, aggregation is so implementation-dependent. And guess what, changes to ABR behavior specified recently would influence all that stuff again. Another problem is e.g. that you may be tempted and go ahead and deploy an implementation that per default leaks all L1s into L2s as 1195 seems to suggest. Any customer with any serious multi-level backbone will very quickly teach you to abandon that practice unless he wants to have hundreds of level-1 addresses sloshing around the network and defeat purpose of level-2 to a good extent. Another one to make the heads of the let's-standardize-aggregation crowd spin: If an aggregate subsumes another aggregate, which and how many do you advertise? Funny enough, there are more than a single possible correct answer depending on your deployment scenario. And last juicy morcel: 1195 and OSPF want you to set aggregate metric to max. metric of aggregated prefixes. Go check the largest deployed implementaion and you'll be in for a surprise. Yes, it could loop if you really, really try but there is a method to this madness as well. We can go on and on ... We're kind of getting down the drain that I tried to plug so before I chime out of this discussion: Aggregation is very implementation and deployment dependent and I would strongly object any push to standardize it unless interoperability problems can be pointed out. Don't forget that this list has an Occam's razor: if it's not needed for interoperability, don't standardize it and especially, don't standardize for fun and to pass time! So a draft describing possibilites and problems with aggregation is fine but at a first MUST or SHOULD I'll probably get vocal ;-) thanks & out -- tony