<4.3.2.7.2.20011221131041.053f6f08@dingdong.cisco.com>
Message-ID: <4.3.2.7.2.20011222122747.01d61790@dingdong.cisco.com>
I believe that defaults should be optimized for when one is deploying
a large number of systems, rather than just one. But minimizing the
settings that must be made when deploying a single router in an
existing network is also reasonable.
I think it's more important to make it easy to put together networks
that are configured correctly than to make it easy for networks to work
even when misconfigured, though, so I still recommend L1 as the default.
In any case, though, will this draft really affect how any vendor's
implementation will default? Perhaps the default should be unspecified,
since there are good arguments to go either way. (On the other hand,
this IS a standards group!)
Jeff
As usual, please note that I don't represent Cisco.
At 07:12 PM 12/21/2001, Naiming Shen wrote:
> ]
> ]I'm surprised that the default for level would be L1+L2. If
> ]most ISIS routers are deployed as L1+L2 routers, then either
> ]they're only used in small domains or else they're not being
> ]deployed properly. I would expect the typical router to be
> ]L1, with L1+L2 routers in much smaller quantities. It's
> ]supposed to be hierarchical and scalable, after all.
> ]
> ]Even if today, ISIS routers tend to be L1+L2, does that mean
> ]we should make it the default? Shouldn't we be encouraging
> ]the proper, hierarchical deployment? Or am I missing something?
> ]
>
>I don't think the issue is the number of routers in which level
>determines the default setting, or the default setting means people
>actually runs isis in both level-1/level-2. The reason some vendors
>(correctly) use level-1/level-2 as default is because a user can
>drop the router in any topology which will work.
>
>If the L1/L2 router is in pure L1 area, then it behaves like a L1
>router since no neighbor will talk with it with L2 packets. If the
>L1/L2 router is in the "border" position, then its perfect. If the
>L1/L2 router is in a pure L2 domain, then it only works like a L2
>router.
>
>There is a rare pathological case if the default is L1 for IS-IS
>and no one bothers to change it: all the routers in the network are
>in one area and running L1/L2 mode, if the user forgets to change the
>level setting and drop this new L1 router in the middle, it will think
>all the neighbors as gateways and it may blackhole the traffic. The
>default of L1/L2 comes handy in this case.
>
>thanks.
>- Naiming
From bogus@does.not.exist.com Mon Dec 24 06:25:22 2001
From: bogus@does.not.exist.com ()
Date: Mon, 24 Dec 2001 11:55:22 +0530
Subject: [Isis-wg] External IPRA
Message-ID: <200112240617.LAA27184@WS0005.indiatimes.com>
--=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868
Content-Type: text/plain; charset=us-ascii
Hi,
Kindly clarify the following
Whether External IPRA needs to be summarized? If yes, then consider the following.
External IPRA with Internal Metric matches Summary Address Table Entry S1. We announce S1 with what ever metric that is configured in the Summary Address Table
Note: SA table does not have a field indicating the type of metric whether internal or external.
External IPRA with External Metric matches Summary Address Table Entry S2. What should be done now, since the metric configured in the summary Address Table does not specify whether it is internal or external can S2 now be announced for the External IPRA. Will this not violate the specification which says, that external metrics are not camparable to internal metrics?
Any help on this is greatly appreciated
Thanks & Regards
Sivakumar A
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in
--=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868
Content-Type: text/html; charset=us-ascii
Hi,
Kindly clarify the following
Whether External IPRA needs to be summarized? If yes, then consider the following.
External IPRA with Internal Metric matches Summary Address Table Entry S1. We announce S1 with what ever metric that is configured in the Summary Address Table
Note: SA table does not have a field indicating the type of metric whether internal or external.
External IPRA with External Metric matches Summary Address Table Entry S2. What should be done now, since the metric configured in the summary Address Table does not specify whether it is internal or external can S2 now be announced for the External IPRA. Will this not violate the specification which says, that external metrics are not camparable to internal metrics?
Any help on this is greatly appreciated
Thanks & Regards
Sivakumar A
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in
--=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868--
From selvarajr@future.futsoft.com Mon Dec 24 08:28:37 2001
From: selvarajr@future.futsoft.com (SelvarajR)
Date: Mon, 24 Dec 2001 13:58:37 +0530
Subject: [Isis-wg] External IPRA
In-Reply-To: <200112240617.LAA27184@WS0005.indiatimes.com>
Message-ID: <000401c18c54$fc55afa0$2006040a@future.futsoft.com>
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01C18C83.160DEBA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hi Siva,
In most of the implementation Summary address metric is NOT configurable.
Its determined dynamically whenever an IPRA falls under that. The LEAST
value among all the IPRA falling under the SA is advertised as the SA's
metric in the corresponding LSP.
If the SA is configured for L12, then the least value should be determined
for each level and should be advertised in the corresponding LSP. While Ext
and Int RA falls under the same SA, then the Int RA's are preferred over Ext
RA's.Thats it.
if ,RA1 => MetricType - External, Configured metric - 10
RA2 => MetricType - Internal, Configured metric - 50
if RA1 and RA2 falls under the same summary address(say SA1) for the same
level, then metric with which SA1 should be advertised in the corresponding
level LSP should be 50 and metric type should be Internal.
Other hand, if SA1 is configured for L12, and if RA1 is configured for
L1-only and RA2 is configured for L2-only, then
SA1 should be advertised in L1 LSP with Metric = 10, Metric Type External.
SA1 should be advertised in L2 LSP with Metric = 50, Metric Type Internal.
Selva.
-----Original Message-----
From: isis-wg-admin@spider.juniper.net
[mailto:isis-wg-admin@spider.juniper.net]On Behalf Of sivaa@indiatimes.com
Sent: Monday, 24 December 2001 11:55 AM
To: workgroup
Cc: Jeff Parker; Radia Perlman - Boston Center for Networking
Subject: [Isis-wg] External IPRA
Hi,
Kindly clarify the following
Whether External IPRA needs to be summarized? If yes, then consider the
following.
External IPRA with Internal Metric matches Summary Address Table Entry
S1. We announce S1 with what ever metric that is configured in the Summary
Address Table
Note: SA table does not have a field indicating the type of metric whether
internal or external.
External IPRA with External Metric matches Summary Address Table Entry S2.
What should be done now, since the metric configured in the summary Address
Table does not specify whether it is internal or external can S2 now be
announced for the External IPRA. Will this not violate the specification
which says, that external metrics are not camparable to internal metrics?
[Selvaraj R] In this case , External routes should be ignored. Should
prefer only the Internal routes.
Any help on this is greatly appreciated
Thanks & Regards
Sivakumar A
----------------------------------------------------------------------------
--
Get Your Private, Free E-mail from Indiatimes at
http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from
http://www.planetm.co.in
------=_NextPart_000_0005_01C18C83.160DEBA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi=20
Siva,
In=20
most of the implementation Summary address metric is =
NOT configurable.=20
Its determined dynamically whenever an IPRA falls under that.=20
The LEAST value among all the IPRA =
falling=20
under the SA is advertised as the SA's metric in the corresponding=20
LSP.
If the=20
SA is configured for L12, then the least value should be determined for =
each=20
level and should be advertised in the corresponding LSP. While Ext and Int =
RA falls=20
under the same SA, then the Int RA's are preferred over Ext=20
RA's.Thats it.
if=20
,RA1 =3D> MetricType - =
External, =20
Configured metric - 10
=20
RA2 =3D> MetricType - Internal, Configured metric -=20
50
if RA1 and RA2=20
falls under the same summary address(say SA1) for the same level, =
then=20
metric with which SA1 should be advertised in the corresponding level=20
LSP should be 50 and metric type should be=20
Internal.
Other=20
hand, if SA1 is configured for L12, and if RA1 is configured =
for L1-only=20
and RA2 is configured for L2-only, then
SA1=20
should be advertised in L1 LSP with Metric =3D 10, Metric Type=20
External.
SA1 should be=20
advertised in L2 LSP with Metric =3D 50, Metric Type=20
Internal.
Selva.
-----Original =
Message-----
From:=20
isis-wg-admin@spider.juniper.net =
[mailto:isis-wg-admin@spider.juniper.net]On=20
Behalf Of sivaa@indiatimes.com
Sent: Monday, 24 December =
2001=20
11:55 AM
To: workgroup
Cc: Jeff Parker; Radia =
Perlman -=20
Boston Center for Networking
Subject: [Isis-wg] External=20
IPRA
Hi,
Kindly clarify the following
Whether External IPRA needs to be summarized? =
If yes, then=20
consider the following.
External IPRA with Internal Metric matches Summary Address =
Table=20
Entry S1. We announce S1 with what ever metric that is configured in =
the=20
Summary Address Table
Note: SA table does not have a field indicating the type of =
metric=20
whether internal or external.
External IPRA with External Metric matches Summary Address Table =
Entry S2.=20
What should be done now, since the metric configured in the summary =
Address=20
Table does not specify whether it is internal or external can S2 now =
be=20
announced for the External IPRA. Will this not violate the =
specification which=20
says, that external metrics are not camparable to internal =
metrics?
[Selvaraj R] In this case , External =
routes=20
should be ignored. Should prefer only the Internal =
routes.
Any help on this is greatly appreciated
Thanks & Regards
Sivakumar A
Get Your Private, Free E-mail from =
Indiatimes at=20
http://email.indiatimes.com
Buy Music, =
Video, CD-ROM,=20
Audio-Books and Music Accessories from http://www.planetm.co.in=20
------=_NextPart_000_0005_01C18C83.160DEBA0--
From VishwasM@netplane.com Wed Dec 26 09:52:39 2001
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Wed, 26 Dec 2001 04:52:39 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
Jeff,
Thanks for forwarding to the list(got useful comments there) and sorry for
the delayed response, have not checked my mails for some time. Comments
inline prefixed by a VM>.
Thanks,
Vishwas
> 1. The isisAreaAddr description given in the overview section
> is not clear.
> I think it should be mentioned area addresses in Level 1
> LSP's, else first
> reading it gets confused with isisISAdjAreaAddr.
I'm not sure what you are suggesting here. The MIB
currently includes the following introduction
-- The Level 1 Area Address Table
-- The Level 1 Area Address Table contains the
-- union of the sets of area addresses reported in all Level 1
-- LSPs received by this Intermediate System.
Are you suggesting this is too much or too little?
If too little, could you provide suggested text?
VM> I was talking about the overview section, Section 4. At present it says
- isisAreaAddr
This table includes area addresses reported by peers.
I thought it would be better if you clarifed this. It could say "area
addresses reported in Level 1 LSP's."
Regarding DEFVAL for SysType, does any vendor use any other default but
L1/L2?
Also regarding the range for SysMaxLSPGenInt, MaxAge is given as an
architectural constant in document ISO-10589, section 7.3.21. So I guess
anyone who does not follow the MaxAge limit would not follow the new range
either(so no big deal). However setting the Max value of the range correctly
would not allow a wrong setting of SysMaxLSPGenInt in an implementation that
follows the architectural constants. Don't you think so? (A similar thing is
done in OSPF)
> 6. What does isisSummAddrAdminState signify(does it signify
> from or to) ie
> when it is L1, is the table used to summarize to or from the L1?
I have added text. See if it is clearer now.
VM> Yes.
> 8. What does functional multicast address mean?
You are asking about the definition of the object below.
I have no idea what this is about, and have done a quick
pass through 10589 without enlightenment. Is there someone
out there who can shed light on this?
isisCircMCAddr OBJECT-TYPE
SYNTAX INTEGER{
group (1),
functional (2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies which type of multicast address will
be used for sending HELLO PDUs on this
circuit."
DEFVAL { group }
::= { isisCircEntry 16 }
VM> Does it mean the value of 2, is not used at present?
> 9. Wouldnt it be nice to keep a count of External routes, L1
> routes , L2
> routes. Or may be how many of TLV 128 and how many 130? I am
> just trying to
> draw a parallel with OSPF.
I have added to my todo list. I won't try to add them this morning.
VM> Great !!! ;-)
> 10. What is the summary area-default metric. I feel thats not
> required. If
> it matches more than one dest we can have the min cost of al
> the dest it
> encompasses. Shldnt there be another field to tell when summ
> area default
> metric is to be used, if thats required?
The term Default has an unusaul meaning in the protocol.
I have removed "default" and "Def" from the names of metrics
where they appear, and added text to better describe the meaning
of "DefaultMetric" in ISIS. The DefaultMetric TC is left as is.
VM> Good enough.
> 11. What does isisSysL1state and SysL2state OFF mean? What
> is the relation to isisSysSetOverload?(If any)
>
> Thanks,
> Vishwas
There is a notion of an overload bit which is used to signal
that a router is low on memory, and thus not to be trusted.
In OSPF, we don't use a router as a transit node until it has
finished the DataBase exchange. In ISIS, some implementations
allow the administrator to bring up the router with the overload
bit set for a given time period. This gives the router a
chance to become synchronized.
I have added text to the isisSysL1State and L2State definitions:
see if that makes things clearer.
VM> mmmmm.....I am still not very clear.(I understand overload bit and where
it could be used) So isisSysL1State should not be read-only then, if it is
settable. Also what do states "on"/"off"/"waiting" mean in this context?
Also I still did not understand the relation with the isisSysSetOverload
object. Aren't they related? If we set the SysL1State to say "on", wouldn't
a get on SysSetOverload state return a setL1Overload(I know the answer is
no, but i am trying to understand)? Why two diff objects?
From dasnabendu@yahoo.com Wed Dec 26 13:27:12 2001
From: dasnabendu@yahoo.com (nabendu das)
Date: Wed, 26 Dec 2001 05:27:12 -0800 (PST)
Subject: [Isis-wg] minLSPTransmissionInterval
Message-ID: <20011226132712.63062.qmail@web13207.mail.yahoo.com>
hi list,
confusion about minLSPTransmissionInterval.
in ISO-10589 7.3.14.3 ,
"The Update Process scans the Link State Database for
Link Stat PDUs with SRMflags set. when one is found,
provided the timestamp lastSent indicates that it was
propagated no more recently than
minimumLSPTransmissionInterval, the IS shall
a) transmit it on all circuits with SRMflags set, and
b) update lastSent."
now here it is not being told whether above mentioned
check is for P2P link or Broadcast link, Do we need to
check this for p2p as well as for LAN case???? or
minimumBroadcastLSPTransmissionInterval takes care of
that, and if so " how does
minimumBroadcastLSPTransmissionInterval controls how
fast we send back-to-back LSPs as per the new
MIB(isisCircLevelLSPThrottle)???? is it like the way
as stated in ISO 10589 in 7.3.15.6, as "as IS is
permitted to transmit a small no of LSPs with a
shorter seperation interval, provided that no more
than 1000/minimumLSPTransmissionInterval LSPs are
transmitted in any one second period."????????
and again in 7.3.15.5,
" an IS shall perform the folln every
minimumLSPTransmissionInterval -
for all p2p circuits c transmit all LSPs that have
SRMflags set on circuit C."
and below that
" the interval between two consecutive transmission of
the same LSP shall be at least
minimumLSPTransmissionInterval"
the question is if the IS shall perform the action as
stated in 7.3.15.5 for every
minimumLSPTransmissionInterval, then the interval
between two consecutive transmission of the same LSP
will be at least minimumLSPTransmissionInterval
anyway. so why that has again been stated.???
Plz help.
thanking in advance.
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
From jparker@axiowave.com Thu Dec 27 15:51:21 2001
From: jparker@axiowave.com (Jeff Parker)
Date: Thu, 27 Dec 2001 10:51:21 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
> The reason some vendors (correctly) use level-1/level-2 as
> default is because a user can drop the router in any topology
> which [and it will] work.
>
> - Naiming
Excellent point.
> In any case, though, will this draft really affect how any vendor's
> implementation will default? Perhaps the default should be unspecified,
> since there are good arguments to go either way. (On the other hand,
> this IS a standards group!)
>
> [Jeff L]
I've seen a number of implementations that take an SNMP MIB
as -the- description of the default for CLI, DB, Web, or
whatever means you use to administer the box. And others
will refer to the default values we define, if only as a
starting point. So I do think it is worth getting this right.
Here is one argument against the suggestion of a
default value of L1. Since there is no way to have
a default area, if L1 is the default, the administrator
must touch this 'region' of the configuration.
I'm happy to return to L1L2. Other opinions?
- jeff parker
- axiowave networks
From jparker@axiowave.com Thu Dec 27 16:36:46 2001
From: jparker@axiowave.com (Jeff Parker)
Date: Thu, 27 Dec 2001 11:36:46 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
Thanks for your review comments. I'm responding to the list.
> VM> I was talking about the overview section, Section 4. At
> present it says
>
> - isisAreaAddr
>
> This table includes area addresses reported by peers.
>
> I thought it would be better if you clarifed this. It
> could say "area addresses reported in Level 1 LSP's."
I cannot find a match for the strings above in the 07 mib.
Perhaps you could give me a line number from the mib which
I will send you offline.
> Regarding DEFVAL for SysType, does any vendor use any other
> default but L1/L2?
There has been a recent discussion of this on the list.
One contributor is suggesting a value of L1.
> Also regarding the range for SysMaxLSPGenInt, MaxAge is given as an
> architectural constant in document ISO-10589, section 7.3.21.
ISO 10589 is an excellent document that reflected the experience
of it's authors when it was written. Time moves on, and things
change.
> So I guess anyone who does not follow the MaxAge limit
> would not follow the new range either(so no big deal).
> However setting the Max value of the range correctly
> would not allow a wrong setting of SysMaxLSPGenInt in an
> implementation that follows the architectural constants.
> Don't you think so? (A similar thing is done in OSPF)
I think it is important to have a default setting that respects
MaxAge, and we meet that today.
The value of MaxAge is not currently a variable in the
MIB, and it is not part of the negotiation phase in adjacency
bring up: it does not appear on the wire. Since this is an
area or domain wide context, it isn't really clear how
negotiation of this could take place. We could add MaxAge
to the MIB, but I think what needs to be discussed is what
the right action should be upon the receipt of an LSP that
has a larger MaxAge than you support.
> > 8. What does functional multicast address mean?
>
> You are asking about the definition of the object below.
>
> I have no idea what this is about, and have done a quick
> pass through 10589 without enlightenment. Is there someone
> out there who can shed light on this?
>
> isisCircMCAddr OBJECT-TYPE
> SYNTAX INTEGER{
> group (1),
> functional (2)
> }
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "Specifies which type of multicast address will
> be used for sending HELLO PDUs on this
> circuit."
> DEFVAL { group }
> ::= { isisCircEntry 16 }
>
> VM> Does it mean the value of 2, is not used at present?
I confess that I still have no idea what this controls.
If no one else does either, I will phase it out.
> > 11. What does isisSysL1state and SysL2state OFF mean? What
> > is the relation to isisSysSetOverload?(If any)
>
> There is a notion of an overload bit which is used to signal
> that a router is low on memory, and thus not to be trusted.
>
> In OSPF, we don't use a router as a transit node until it has
> finished the DataBase exchange. In ISIS, some implementations
> allow the administrator to bring up the router with the overload
> bit set for a given time period. This gives the router a
> chance to become synchronized.
>
> I have added text to the isisSysL1State and L2State definitions:
> see if that makes things clearer.
>
> VM> mmmmm.....I am still not very clear.(I understand
> overload bit and where
> it could be used) So isisSysL1State should not be read-only
> then, if it is
> settable. Also what do states "on"/"off"/"waiting" mean in
> this context?
>
> Also I still did not understand the relation with the
> isisSysSetOverload object. Aren't they related? If
> we set the SysL1State to say "on", wouldn't
> a get on SysSetOverload state return a setL1Overload
> (I know the answer is no, but i am trying to understand)?
> Why two diff objects?
I think I mispoke on this topic in my earlier private
mail this morning.
One is a gauge, one is a knob. You don't use the
speedometer in your car to accelerate: you use the
gas pedal. And if you are rolling down hill, the
position of the gas pedal may not reflect your speed.
The isisSysL1State tells you what state the system
is in, and is thus read-only. isisSysSetOverload
is the knob you use to try to change things. You
may try to bring the system out of Overload by
setting isisSysSetOverload to overloadClear when
the system is out of memory. In that case, you
expect the guage to move from wait to overloaded,
and you expect to continue to originate LSPs with
the O bit set.
isisSysL1State OBJECT-TYPE
SYNTAX LevelState
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The state of the Level 1 database.
The value 'overloaded' indicates a database that is
low on an essential resource, such as memory.
The administrator may set the state to 'wait' when
the router is initializing by setting the object
isisSysSetOverload.
If the state is waiting or overloaded, we
originate LSPs with the Overload bit set."
REFERENCE "{ISIS.aoi l1State (17)}"
::= { isisSysEntry 14 }
Let me know if this is any clearer.
- jeff parker
- axiowave networks
From VishwasM@netplane.com Thu Dec 27 17:15:56 2001
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Thu, 27 Dec 2001 12:15:56 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
Jeff,
Comments inline preceded by a VM>.
Thanks,
Vishwas
--------------------------------------
Thanks for your review comments. I'm responding to the list.
I cannot find a match for the strings above in the 07 mib.
Perhaps you could give me a line number from the mib which
I will send you offline.
VM> Its in the overview section(section 4), just before the definition of
the MIB section(Section 5). I will send you a private mail about the line
number.
--------------------------------------
There has been a recent discussion of this on the list.
One contributor is suggesting a value of L1.
VM>Well as far as I know Jeff L. does not work on ISIS in his company(and
his views in his own words dont necessarily represent Cisco, which uses as
default L1/L2(or so their documents say)) ;-)
--------------------------------------
I think it is important to have a default setting that respects
MaxAge, and we meet that today.
The value of MaxAge is not currently a variable in the
MIB, and it is not part of the negotiation phase in adjacency
bring up: it does not appear on the wire. Since this is an
area or domain wide context, it isn't really clear how
negotiation of this could take place. We could add MaxAge
to the MIB, but I think what needs to be discussed is what
the right action should be upon the receipt of an LSP that
has a larger MaxAge than you support.
VM> This is exactly the reason why MaxAge needs to be same in all routers in
the domain. It also is an anomaly, where at one place we say MaxAge is arch.
constant and so not configurable, and other place we say it is not a
constant.
Treating any LSP with age above Maxage could be done as if age was MaxAge.
May be we need to recommend that all routers in a domain have the same
Maxage(and the value of MaxLSPGenInt should be less than the value of the
smallest value of MaxAge in any router in the domain)value for things to
work ok(and then we can treat all LSP's with age greater than MaxAge as
MaxAge), we could raise a trap on getting an LSP with age greater than
MaxAge.
--------------------------------------
I confess that I still have no idea what this controls.
If no one else does either, I will phase it out.
VM> Ok, though I am sure someone will have an idea.
--------------------------------------
I think I mispoke on this topic in my earlier private
mail this morning.
One is a gauge, one is a knob. You don't use the
speedometer in your car to accelerate: you use the
gas pedal. And if you are rolling down hill, the
position of the gas pedal may not reflect your speed.
The isisSysL1State tells you what state the system
is in, and is thus read-only. isisSysSetOverload
is the knob you use to try to change things. You
may try to bring the system out of Overload by
setting isisSysSetOverload to overloadClear when
the system is out of memory. In that case, you
expect the guage to move from wait to overloaded,
and you expect to continue to originate LSPs with
the O bit set.
isisSysL1State OBJECT-TYPE
SYNTAX LevelState
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The state of the Level 1 database.
The value 'overloaded' indicates a database that is
low on an essential resource, such as memory.
The administrator may set the state to 'wait' when
the router is initializing by setting the object
isisSysSetOverload.
If the state is waiting or overloaded, we
originate LSPs with the Overload bit set."
REFERENCE "{ISIS.aoi l1State (17)}"
::= { isisSysEntry 14 }
Let me know if this is any clearer.
VM> Yes, now it is clearer and I thought some thing like this though. ;-)
However I am not sure how the administrator could set the state to "wait".
Its a read only object(as pointed out in the private mail).
From jparker@axiowave.com Thu Dec 27 17:16:17 2001
From: jparker@axiowave.com (Jeff Parker)
Date: Thu, 27 Dec 2001 12:16:17 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
I'm replying to the list. I'd like to expose the requests
for change, so that others can react. Witness the recent
discussion on the appropriate default system type.
> Also one more doubt. If you do go in for adding a table or
> object for the
> number of TLV's of type 128 and 130. I guess we could also
> have a couter for
> the number of TLV's with up/down bit set to 0 and same thing for 1.
I will add to the todo list.
> Also how about keeping a counter/trap when we get a mismatch in the
> configured MeshGroupEnabled i.e. getting an LSP even when the
> circuit state is blocked.
>
> Vishwas
Vishwas -
One of the limitations of the mesh group idea is that
there is no way to check that the configuration makes sense,
and no way to know what configuration the far end has.
So anything that would help catch errors would be welcome.
But mesh state is not symetric. You may be told not to speak,
but that doesn't mean you shouldn't listen. As noted above, you
really don't know what state the other side is in.
- jeff parker
- axiowave networks
From jparker@axiowave.com Thu Dec 27 17:29:58 2001
From: jparker@axiowave.com (Jeff Parker)
Date: Thu, 27 Dec 2001 12:29:58 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
> > There has been a recent discussion of this on the list.
> > One contributor is suggesting a value of L1.
>
> VM>Well as far as I know Jeff L. does not work on ISIS in his
> company(and his views in his own words dont necessarily
> represent Cisco, which uses as default L1/L2(or so their
> documents say)) ;-)
Jeff L. has presented arguments in favor of his position.
I think we need to read and respond to them, independent
of where he works and what his company does.
> > The value of MaxAge is not currently ... in the MIB
> VM> This is exactly the reason why MaxAge needs to be same in
> all routers in the domain. It also is an anomaly, where at
> one place we say MaxAge is arch. constant and so not
> configurable, and other place we say it is not a constant.
The idea of a variable constant always makes me laugh.
I could add a value parallel to isisSysOrigL1LSPBuffSize.
However, I don't think we have really sorted out how such a
variable should be used. I think dropping LSPs that are
larger than this has an adverse impact. It could be used
as the largest value used on originated packets.
> May be we need to recommend that all routers in a domain have the same
> Maxage(and the value of MaxLSPGenInt should be less than the
> value of the
> smallest value of MaxAge in any router in the domain)value
> for things to
> work ok(and then we can treat all LSP's with age greater than
> MaxAge as
> MaxAge), we could raise a trap on getting an LSP with age greater than
> MaxAge.
> > One is a gauge, one is a knob.
>
> VM> Yes, now it is clearer and I thought some thing like this
> though. ;-) However I am not sure how the administrator
> could set the state to "wait". Its a read only object(as
>pointed out in the private mail).
The administrator does not touch the gauge. The administrator
touches the knob, setting isisSysSetOverload. Please suggest
text changes that would make the following passages clearer on
this point.
Your speedometer is read-only: the gas pedal is not.
isisSysL2State OBJECT-TYPE
SYNTAX LevelState
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The state of the Level 2 database.
The value 'overloaded' indicates a database that is
low on an essential resource, such as memory.
The administrator may set the state to 'wait' when
the router is initializing by setting the object
isisSysSetOverload.
If the state is waiting or overloaded, we
originate LSPs with the Overload bit set."
REFERENCE "{ISIS.aoi l2State (28)}"
::= { isisSysEntry 24 }
and
isisSysSetOverload OBJECT-TYPE
SYNTAX INTEGER
{
setL1Overload(1),
setL2Overload(2),
setL1L2Overload(3),
overloadClear(4)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Administratively set the overload bit for each level.
The overload bit will continue to be set if the
implementation runs out of memory, independent of
this variable"
DEFVAL {overloadClear }
::= { isisSysEntry 35 }
- jeff parker
- axiowave networks
From VishwasM@netplane.com Thu Dec 27 17:42:19 2001
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Thu, 27 Dec 2001 12:42:19 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
Jeff,
Jeff L. has presented arguments in favor of his position.
I think we need to read and respond to them, independent
of where he works and what his company does.
VM> I did not question the validity of the argument. The following was what
my initial question was. Does any vendor support a value other than L1/L2 as
DEFVAL?(May be I did not make myself too clear)
The administrator does not touch the gauge. The administrator
touches the knob, setting isisSysSetOverload. Please suggest
text changes that would make the following passages clearer on
this point.
VM> Oops, sorry my fault now(I did not read carefully), the latest version
you sent is clear enough.
Thanks,
Vishwas
From VishwasM@netplane.com Thu Dec 27 17:45:56 2001
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Thu, 27 Dec 2001 12:45:56 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
Jeff,
Agreed, there is no way to negotiate the two ends configuration(we could
always add a TLV???). But doesn't Section 3a) RFC2973 mean that we prefer
mesh states are same at both ends. If we get an LSP via a blocked circuit,
doesn't it mean there is some config mismatch? Would it ever be required to
have a mismatch in the mesh states?
Also what should be done in case we get an LSP on a circuit C, where the
meshGroupEnabled attribute is blocked. Should we treat it similar to
meshGroupEnabled inactive state?
Thanks,
Vishwas
> Also how about keeping a counter/trap when we get a mismatch in the
> configured MeshGroupEnabled i.e. getting an LSP even when the
> circuit state is blocked.
>
> Vishwas
From sganguly@celoxnetworks.com Thu Dec 27 18:42:47 2001
From: sganguly@celoxnetworks.com (Ganguly, Shamik)
Date: Thu, 27 Dec 2001 13:42:47 -0500
Subject: [Isis-wg] Query for IS-IS in general
Message-ID: <1117F7D44159934FB116E36F4ABF221B0102E83E@celox-ma1-ems1.celoxnetworks.com>
Hi,
I am a newcomer to IS-IS. Can somebody refer a good book on IS-IS? Most of
the book I have looked into just have a small section on the subject.
I will really appreciate your help.
-Shamik Ganguly
Celox Networks
From jparker@axiowave.com Thu Dec 27 18:50:03 2001
From: jparker@axiowave.com (Jeff Parker)
Date: Thu, 27 Dec 2001 13:50:03 -0500
Subject: [Isis-wg] RE: Mesh Groups
Message-ID:
Subject changed to match topic
> Agreed, there is no way to negotiate the two ends
> configuration(we could always add a TLV???). But
> doesn't Section 3a) RFC2973 mean that we prefer
> mesh states are same at both ends. If we get an
> LSP via a blocked circuit, doesn't it mean there
> is some config mismatch? Would it ever be
> required to have a mismatch in the mesh states?
My reading of the RFC suggests that you shouldn't
use Mesh Groups at all. But given that they exist,
I don't see why we should restrict them to be
'blocked' symetricaly.
> Also what should be done in case we get an LSP on a
> circuit C, where the meshGroupEnabled attribute is
> blocked. Should we treat it similar to
> meshGroupEnabled inactive state?
>
> Vishwas
I can imagine an implementation that sets the
value of meshGroup for a meshBlocked circuit,
and uses that value to restrict flooding.
However, the RFC explicitly states that the
meshGroup value is not meaningful when the
circuit is meshBlocked.
The intent of mesh groups is to reduce
flooding, not to prevent it. I would
do as you suggest: flood it out non-
blocked circuits.
- jeff parker
- axiowave networks
From jlearman@cisco.com Thu Dec 27 18:57:53 2001
From: jlearman@cisco.com (Jeff Learman)
Date: Thu, 27 Dec 2001 13:57:53 -0500
Subject: [Isis-wg] Query for IS-IS in general
In-Reply-To: <1117F7D44159934FB116E36F4ABF221B0102E83E@celox-ma1-ems1.ce
loxnetworks.com>
Message-ID: <4.3.2.7.2.20011227135550.01f44ed8@dingdong.cisco.com>
The best book I know of is Interconnections, by Radia Perlman.
However, this covers "Bridges and Routers", and has a section on
link-state routing protocols, but not a specific section on IS-IS
alone.
Jeff
At 01:42 PM 12/27/2001, Ganguly, Shamik wrote:
>Hi,
>
>I am a newcomer to IS-IS. Can somebody refer a good book on IS-IS? Most of
>the book I have looked into just have a small section on the subject.
>
>I will really appreciate your help.
>
>-Shamik Ganguly
>Celox Networks
>_______________________________________________
>Isis-wg mailing list - Isis-wg@external.juniper.net
>http://external.juniper.net/mailman/listinfo/isis-wg
From dkatz@juniper.net Thu Dec 27 20:05:56 2001
From: dkatz@juniper.net (Dave Katz)
Date: Thu, 27 Dec 2001 12:05:56 -0800 (PST)
Subject: [Isis-wg] Query for IS-IS in general
In-Reply-To: <4.3.2.7.2.20011227135550.01f44ed8@dingdong.cisco.com> (message
from Jeff Learman on Thu, 27 Dec 2001 13:57:53 -0500)
References: <4.3.2.7.2.20011227135550.01f44ed8@dingdong.cisco.com>
Message-ID: <200112272005.fBRK5uF40246@cirrus.juniper.net>
Another resource is Piscitello and Chapin's book, which I believe is
entitled "Internetworking with TCP/IP and OSI."
X-Sender: jlearman@dingdong.cisco.com
From: Jeff Learman
Cc: "'IS-IS-WG (E-mail)'"
Content-Type: text/plain; charset="us-ascii"
Sender: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
Date: Thu, 27 Dec 2001 13:57:53 -0500
The best book I know of is Interconnections, by Radia Perlman.
However, this covers "Bridges and Routers", and has a section on
link-state routing protocols, but not a specific section on IS-IS
alone.
Jeff
At 01:42 PM 12/27/2001, Ganguly, Shamik wrote:
>Hi,
>
>I am a newcomer to IS-IS. Can somebody refer a good book on IS-IS? Most of
>the book I have looked into just have a small section on the subject.
>
>I will really appreciate your help.
>
>-Shamik Ganguly
>Celox Networks
>_______________________________________________
>Isis-wg mailing list - Isis-wg@external.juniper.net
>http://external.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list - Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg
From nagastabagamba@yahoo.com Thu Dec 27 21:41:38 2001
From: nagastabagamba@yahoo.com (Nagasta Bagamba)
Date: Thu, 27 Dec 2001 13:41:38 -0800 (PST)
Subject: [Isis-wg] IGP shortcuts
Message-ID: <20011227214138.86295.qmail@web21110.mail.yahoo.com>
Hi,
I have some wonders about several issues in the draft
"draft-hsmit-mpls-igp-spf-00.txt".
1. In secrion 6.1: "The relative metric is bounded by
minimum and maximum allowed metric values"
Is there any use for maximum value higher than 1?
As I see it, any positive relative metric causes the
TE-tunnel not to be used by the IGP, so there is no
need for more than one positive value.
2. In section 4: "Traffic to nodes that are downstream
of the tail-end nodes will also flow over those
TE-tunnels"
I find the word "downstream" a little bit problematic.
It can be downstream to the node on the SPF tree OR
downstream to the node on the IGP topology graph.
I think it refers to the SPF tree, but is there any
prevention from using TE-tunnels, as shortcuts, on the
IGP topology graph instead of on the SPF tree? It
looks like it will give more functionality and meaning
to the word "shortcuts". Of course we have to be
careful form routing loops, but with some basic rules
it is possible... :)
Regards,
Nagi
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
From jparker@axiowave.com Thu Dec 27 20:49:48 2001
From: jparker@axiowave.com (Jeff Parker)
Date: Thu, 27 Dec 2001 15:49:48 -0500
Subject: [Isis-wg] Query for IS-IS in general
Message-ID:
> From: Dave Katz [mailto:dkatz@juniper.net]
> Subject: Re: [Isis-wg] Query for IS-IS in general
>
>
> Another resource is Piscitello and Chapin's book, which I believe is
> entitled "Internetworking with TCP/IP and OSI."
>
Dave -
Thanks for the reference.
Title is "Open Systems Networking : Tcp/Ip and Osi". Amazon says
that it is now out of print, but you might be able to find in a library.
http://www.amazon.com/exec/obidos/ASIN/0201563347/qid=1009485562/sr=1-2/ref=
sr_1_8_2/102-7400645-5347329
- jeff parker
- axiowave networks
- All those who believe in psychokinesis, raise my hand.
From ginsberg@pluris.com Thu Dec 27 21:00:33 2001
From: ginsberg@pluris.com (Les Ginsberg)
Date: Thu, 27 Dec 2001 13:00:33 -0800
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F69D@avalon.pluris.com>
>
> Treating any LSP with age above Maxage could be done as if
> age was MaxAge.
> May be we need to recommend that all routers in a domain have the same
> Maxage(and the value of MaxLSPGenInt should be less than the
> value of the
> smallest value of MaxAge in any router in the domain)value
> for things to
> work ok(and then we can treat all LSP's with age greater than
> MaxAge as
> MaxAge), we could raise a trap on getting an LSP with age greater than
> MaxAge.
>
The change from an architectural constant to a configurable value was
presumably made based on customer demand. To require, or even suggest, that
an implementation treat an LSP received with a lifetime > the architectural
constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do.
Routers which did this could end up purging an LSP from their database
before the originating router's MaxLSPGenInt timer fired, which would cause
unnecessary flapping. If you want to argue that the current "de facto
standard" of making LSP lifetime configurable should be made invalid you
will at least be addressing the issue directly - though I suspect you will
get little support. Circumventing the issue by pretending the value is not
configurable is unwise.
It is also worth noting that, as you suggest, there is a necessary
relationship between LSP lifetime and MaxLSPGenInt, namely:
1)MaxLSPGenInt must be less than LSPlifetime
2)(LSPlifetime - MaxLSPGenInt) should be large enough to allow propagation
of the LSP throughout the area/domain before the old LSP ages out
If LSP lifetime is modified from the "default" value of 1200 seconds, it
makes sense to change MaxLSPGenInt in a like manner.
Les
From bertcameron@rogers.com Fri Dec 28 18:58:52 2001
From: bertcameron@rogers.com (Bert Cameron)
Date: Fri, 28 Dec 2001 13:58:52 -0500
Subject: [Isis-wg] (no subject)
Message-ID: <002501c18fd1$b161d480$0200a8c0@bert>
This is a multi-part message in MIME format.
------=_NextPart_000_0022_01C18FA7.C86A3AC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
who isis
------=_NextPart_000_0022_01C18FA7.C86A3AC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
who isis
------=_NextPart_000_0022_01C18FA7.C86A3AC0--
From bertcameron@rogers.com Fri Dec 28 19:07:19 2001
From: bertcameron@rogers.com (Bert Cameron)
Date: Fri, 28 Dec 2001 14:07:19 -0500
Subject: [Isis-wg] (no subject)
Message-ID: <004f01c18fd2$df8f5020$0200a8c0@bert>
This is a multi-part message in MIME format.
------=_NextPart_000_004C_01C18FA8.F697B660
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
who isis
------=_NextPart_000_004C_01C18FA8.F697B660
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
who isis
------=_NextPart_000_004C_01C18FA8.F697B660--
From naiming@redback.com Fri Dec 28 19:42:41 2001
From: naiming@redback.com (Naiming Shen)
Date: Fri, 28 Dec 2001 11:42:41 -0800
Subject: [Isis-wg] IGP shortcuts
In-Reply-To: Mail from Nagasta Bagamba
dated Thu, 27 Dec 2001 13:41:38 PST
<20011227214138.86295.qmail@web21110.mail.yahoo.com>
Message-ID: <20011228194241.755121DCC74@prattle.redback.com>
]Hi,
]
]I have some wonders about several issues in the draft
]"draft-hsmit-mpls-igp-spf-00.txt".
]
]1. In secrion 6.1: "The relative metric is bounded by
]minimum and maximum allowed metric values"
]Is there any use for maximum value higher than 1?
]As I see it, any positive relative metric causes the
]TE-tunnel not to be used by the IGP, so there is no
]need for more than one positive value.
yes, it is not useful for relative metric > +1 if the igp
load sharing scheme is equal-cost.
but there is no need to restrict it as long as you know it will not
be used. if a paricular native path has metric of 10, and you set
absolute metric to 15, assume the native path does not change,
it's equivalent to setting the relative metric to +5 here.
]
]2. In section 4: "Traffic to nodes that are downstream
]of the tail-end nodes will also flow over those
]TE-tunnels"
]I find the word "downstream" a little bit problematic.
]It can be downstream to the node on the SPF tree OR
]downstream to the node on the IGP topology graph.
]I think it refers to the SPF tree, but is there any
]prevention from using TE-tunnels, as shortcuts, on the
]
]IGP topology graph instead of on the SPF tree? It
]looks like it will give more functionality and meaning
]to the word "shortcuts". Of course we have to be
]careful form routing loops, but with some basic rules
]it is possible... :)
i can't parse your sentence here, what is "downstream to SPF"
vs "downstream to IGP topology graph"?
how can you "form routing loops"? can you give an example
which actually causes routing loops?
- Naiming
From jparker@axiowave.com Fri Dec 28 19:51:44 2001
From: jparker@axiowave.com (Jeff Parker)
Date: Fri, 28 Dec 2001 14:51:44 -0500
Subject: [Isis-wg] RE: New ISIS MIB Issue
Message-ID:
Thanks: will do.
- jeff parker
- axiowave networks
- All those who believe in psychokinesis, raise my hand.
> -----Original Message-----
> From: Les Ginsberg [mailto:ginsberg@pluris.com]
> Sent: Friday, December 28, 2001 2:50 PM
> To: 'Jeff Parker'
> Subject: New ISIS MIB Issue
>
>
>
>
> Jeff -
>
> Here's another cleanup issue. In regards to:
>
> isisSysLSPIgnoreErrors OBJECT-TYPE
> SYNTAX TruthValue
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "If true, allow the router to ignore IS-IS link
> state packets
> (LSPs) that are received with internal checksum
> errors rather
> than purging the LSPs."
> DEFVAL { false }
> ::= { isisSysEntry 27 }
>
> The truth of the matter is that the strategy of purging
> received LSPs w
> checksum errors was a defect in the 1992 spec which was corrected by
> Technical Corrigendum I years ago. This change has been
> incorporated into
> 10589:2001. The revised spec (7.3.14.2a) now reads:
>
> a) An Intermediate system receiving a Link State PDU with
> an incorrect
> LSP Checksum or with an invalid PDU syntax shall
>
> 1) generate a corruptedLSPReceived circuit event,
>
> 2) discard the PDU.
>
> Popular implementations that have knobs to control ignoring
> vs. purging
> notwithstanding, the fact is that a conformant implementation
> should always
> ignore LSPs with checksum errors. Therefore, I think the
> above should be
> removed from the MIB.
>
> If you need further references let me know - I can dig up the
> old defect
> reports if needed.
>
> Les
>
From dasnabendu@yahoo.com Sat Dec 29 09:25:13 2001
From: dasnabendu@yahoo.com (nabendu das)
Date: Sat, 29 Dec 2001 01:25:13 -0800 (PST)
Subject: [Isis-wg] minimumLSPTransmissionInterval
Message-ID: <20011229092513.39392.qmail@web13207.mail.yahoo.com>
hi list,
confusion about minLSPTransmissionInterval.
in ISO-10589 7.3.14.3 ,
"The Update Process scans the Link State Database for
Link Stat PDUs with SRMflags set. when one is found,
provided the timestamp lastSent indicates that it was
propagated no more recently than
minimumLSPTransmissionInterval, the IS shall
a) transmit it on all circuits with SRMflags set, and
b) update lastSent."
now here it is not being told whether above mentioned
check is for P2P link or Broadcast link, Do we need to
check this for p2p as well as for LAN case???? or
minimumBroadcastLSPTransmissionInterval takes care of
that, and if so " how does
minimumBroadcastLSPTransmissionInterval controls how
fast we send back-to-back LSPs as per the new
MIB(isisCircLevelLSPThrottle)???? is it like the way
as stated in ISO 10589 in 7.3.15.6, as "an IS is
permitted to transmit a small no of LSPs with a
shorter seperation interval, provided that no more
than 1000/minimumBroadcastLSPTransmissionInterval LSPs
are
transmitted in any one second period."????????
and again in 7.3.15.5,
" an IS shall perform the folln every
minimumLSPTransmissionInterval -
for all p2p circuits c transmit all LSPs that have
SRMflags set on circuit C."
and below that
" the interval between two consecutive transmission of
the same LSP shall be at least
minimumLSPTransmissionInterval"
the question is if the IS shall perform the action as
stated in 7.3.15.5 for every
minimumLSPTransmissionInterval, then the interval
between two consecutive transmission of the same LSP
will be at least minimumLSPTransmissionInterval
anyway. so why that has again been stated.???
Plz help.
thanking in advance.
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
From nagastabagamba@yahoo.com Sat Dec 29 21:24:54 2001
From: nagastabagamba@yahoo.com (Nagasta Bagamba)
Date: Sat, 29 Dec 2001 13:24:54 -0800 (PST)
Subject: [Isis-wg] IGP shortcuts
In-Reply-To: <20011228194241.755121DCC74@prattle.redback.com>
Message-ID: <20011229212454.55644.qmail@web21109.mail.yahoo.com>
Hi,
I'm sorry, my second question wasn't clear enough.
I'll try to explain my question through examples.
There are 3 ways to use TE-tunnels as shortcuts. I'll
explain each one of them through examples.
Topology A will be used for introducing case 1. This
case refers just to the nodes (ISs) in the topology,
not to the leafs (IPs).
Topology B will be used for introducing cases 2 and 3.
Those cases refers especially to the leafs (IPs) of
the tree.
Topology A:
10
A----B
9 | | 10
C----D
10
TE-tunnel from A to B, relative -5.
Source node - A.
SPT (without TE-tunnels):
A
10 / \ 9
B C
| 10
D
Case 1: Using TE-tunnels as IGP links
If we use TE-tunnels after building the SPF tree, we
will get:
A
5 / \ 9
B C
| 10
D
But, if we look at the TE-tunnel as a link with cost 5
(10-5), and use it through the build of the SPT, we'll
get:
A
5 / \ 9
B C
10 |
D
Topology B:
A
10 / \ 9
/ \
B----C
10
TE-tunnel from A to B, relative -5.
Source node - A.
There is network X between B and C.
SPT (without TE-tunnels):
A
10 / \ 9
B C
| 10
X
Case 2: Use TE-tunnels after building the nodes (ISs)
of the SPF tree, but before adding the leafs (IP
reachability).
The result:
A
5 / \ 9
B C
10 |
X
Case 3: Use TE-tunnels after building the whole SPF
tree (nodes and leafs).
The result:
A
5 / \ 9
B C
| 10
X
Case 3 is routing-loop-free.
Cases 1 and 2 can create routing-loops. To avoid it,
we must not allow negative links in the graph (it
seems impossible with the absolute metric type).
My question is - which of the above cases is the one
the draft refers to?
Nagi
--- Naiming Shen wrote:
> ]Hi,
> ]
> ]I have some wonders about several issues in the
> draft
> ]"draft-hsmit-mpls-igp-spf-00.txt".
> ]
> ]1. In secrion 6.1: "The relative metric is bounded
> by
> ]minimum and maximum allowed metric values"
> ]Is there any use for maximum value higher than 1?
> ]As I see it, any positive relative metric causes
> the
> ]TE-tunnel not to be used by the IGP, so there is
> no
> ]need for more than one positive value.
>
> yes, it is not useful for relative metric > +1 if
> the igp
> load sharing scheme is equal-cost.
>
> but there is no need to restrict it as long as you
> know it will not
> be used. if a paricular native path has metric of
> 10, and you set
> absolute metric to 15, assume the native path does
> not change,
> it's equivalent to setting the relative metric to +5
> here.
>
> ]
> ]2. In section 4: "Traffic to nodes that are
> downstream
> ]of the tail-end nodes will also flow over those
> ]TE-tunnels"
> ]I find the word "downstream" a little bit
> problematic.
> ]It can be downstream to the node on the SPF tree
> OR
> ]downstream to the node on the IGP topology graph.
> ]I think it refers to the SPF tree, but is there
> any
> ]prevention from using TE-tunnels, as shortcuts, on
> the
> ]
> ]IGP topology graph instead of on the SPF tree? It
> ]looks like it will give more functionality and
> meaning
> ]to the word "shortcuts". Of course we have to be
> ]careful form routing loops, but with some basic
> rules
> ]it is possible... :)
>
> i can't parse your sentence here, what is
> "downstream to SPF"
> vs "downstream to IGP topology graph"?
> how can you "form routing loops"? can you give an
> example
> which actually causes routing loops?
>
>
> - Naiming
> _______________________________________________
> Isis-wg mailing list -
> Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
From VishwasM@netplane.com Fri Dec 28 04:15:28 2001
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Thu, 27 Dec 2001 23:15:28 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
Les,
I meant "remaining lifetime" field in the LSP and not age(wrong use of
terminology on my part).
So this is what I meant:-
1. If the remaining Lifetime is > MaxAge value in the router, treat the
remaining lifetime as if it was MaxAge.
2. MaxLSPGenInt should be less than min value of MaxAge for all routers in
the domain.
3. The difference(as pointed out) should be at least enough so that the LSP
is propagated thruout the domain(so that no one purges the LSP before the
new version reaches it).
Thanks,
Vishwas
-----Original Message-----
From: Les Ginsberg [mailto:ginsberg@pluris.com]
Sent: Friday, December 28, 2001 2:31 AM
To: 'Manral, Vishwas'; 'Jeff Parker'
Cc: IS-IS-WG (E-mail)
Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
>
> Treating any LSP with age above Maxage could be done as if
> age was MaxAge.
> May be we need to recommend that all routers in a domain have the same
> Maxage(and the value of MaxLSPGenInt should be less than the
> value of the
> smallest value of MaxAge in any router in the domain)value
> for things to
> work ok(and then we can treat all LSP's with age greater than
> MaxAge as
> MaxAge), we could raise a trap on getting an LSP with age greater than
> MaxAge.
>
The change from an architectural constant to a configurable value was
presumably made based on customer demand. To require, or even suggest, that
an implementation treat an LSP received with a lifetime > the architectural
constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do.
Routers which did this could end up purging an LSP from their database
before the originating router's MaxLSPGenInt timer fired, which would cause
unnecessary flapping. If you want to argue that the current "de facto
standard" of making LSP lifetime configurable should be made invalid you
will at least be addressing the issue directly - though I suspect you will
get little support. Circumventing the issue by pretending the value is not
configurable is unwise.
It is also worth noting that, as you suggest, there is a necessary
relationship between LSP lifetime and MaxLSPGenInt, namely:
1)MaxLSPGenInt must be less than LSPlifetime
2)(LSPlifetime - MaxLSPGenInt) should be large enough to allow propagation
of the LSP throughout the area/domain before the old LSP ages out
If LSP lifetime is modified from the "default" value of 1200 seconds, it
makes sense to change MaxLSPGenInt in a like manner.
Les
From ginsberg@pluris.com Fri Dec 28 04:59:12 2001
From: ginsberg@pluris.com (Les Ginsberg)
Date: Thu, 27 Dec 2001 20:59:12 -0800
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F6A0@avalon.pluris.com>
Vishwas -
Makes no difference. From the point of view of the receiver of an LSP, it
has no way of knowing what the value of LSP lifetime may be on the
originating IS since the remaining lifetime field gets modified, based on
elapsed time, prior to flooding. All the receiver can say is that the
originating IS has a value for LSP lifetime which is >= the original
received remaining lifetime.
If an IS arbitrarily decreases the remaining lifetime of an LSP it has
received, then it is quite possible that the LSP will age out of the local
database before the originating router regenerates that LSP. The protocol
will eventually recover, but in order to do so the LSP will first be purged,
causing an SPF to be run on all routers (or many of them anyway) with this
LSP absent, and then the originating router will, on seeing the purged
version, regenerate that LSP, flood it, and a second SPF will be run on
every router. Reachability advertised in this LSP will temporarily disappear
from the forwarding databases throughout the area/domain and then be
restored. This is highly undesirable.
Les
>
>
> Les,
>
> I meant "remaining lifetime" field in the LSP and not age(wrong use of
> terminology on my part).
>
> So this is what I meant:-
>
> 1. If the remaining Lifetime is > MaxAge value in the router,
> treat the
> remaining lifetime as if it was MaxAge.
> 2. MaxLSPGenInt should be less than min value of MaxAge for
> all routers in
> the domain.
> 3. The difference(as pointed out) should be at least enough
> so that the LSP
> is propagated thruout the domain(so that no one purges the
> LSP before the
> new version reaches it).
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Les Ginsberg [mailto:ginsberg@pluris.com]
> Sent: Friday, December 28, 2001 2:31 AM
> To: 'Manral, Vishwas'; 'Jeff Parker'
> Cc: IS-IS-WG (E-mail)
> Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
>
>
> >
> > Treating any LSP with age above Maxage could be done as if
> > age was MaxAge.
> > May be we need to recommend that all routers in a domain
> have the same
> > Maxage(and the value of MaxLSPGenInt should be less than the
> > value of the
> > smallest value of MaxAge in any router in the domain)value
> > for things to
> > work ok(and then we can treat all LSP's with age greater than
> > MaxAge as
> > MaxAge), we could raise a trap on getting an LSP with age
> greater than
> > MaxAge.
> >
>
> The change from an architectural constant to a configurable value was
> presumably made based on customer demand. To require, or even
> suggest, that
> an implementation treat an LSP received with a lifetime > the
> architectural
> constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do.
> Routers which did this could end up purging an LSP from their database
> before the originating router's MaxLSPGenInt timer fired,
> which would cause
> unnecessary flapping. If you want to argue that the current "de facto
> standard" of making LSP lifetime configurable should be made
> invalid you
> will at least be addressing the issue directly - though I
> suspect you will
> get little support. Circumventing the issue by pretending the
> value is not
> configurable is unwise.
>
> It is also worth noting that, as you suggest, there is a necessary
> relationship between LSP lifetime and MaxLSPGenInt, namely:
>
> 1)MaxLSPGenInt must be less than LSPlifetime
> 2)(LSPlifetime - MaxLSPGenInt) should be large enough to
> allow propagation
> of the LSP throughout the area/domain before the old LSP ages out
>
> If LSP lifetime is modified from the "default" value of 1200
> seconds, it
> makes sense to change MaxLSPGenInt in a like manner.
>
> Les
>
From VishwasM@netplane.com Fri Dec 28 05:37:40 2001
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Fri, 28 Dec 2001 00:37:40 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
Les,
I get the point you are trying to make. The problem you say would happen
whenever there is a diff in MaxAge in IS's in the domain(and the LSP's for
some reason is not refreshed).
This is what I am trying to say. The MaxAge would be the value which would
be put in a self LSP, as remaining lifetime when we are originating a new
LSP. If the remaining life time is greater than MaxAge for some other IS, it
should treat the stuff as if MaxAge(in the sense it should not drop the LSP,
MIB ops on remaining lifetime shld give age as MaxAge(if any), SPF(age
value) etc), however it should start the purge(MaxAge) timer for that LSP
with the value of "remaining lifetime" field(So remaining lifetime would be
zero after remaining life time period). However this would cause the MaxAge
field to be used as in the remaining lifetime and not as configured in the
IS itself.(some problems/loopholes/against existing approach with this
approach??)
This way all people would purge the LSP at nearly the same time(so the
problem described would not arise).
Thanks,
Vishwas
-----Original Message-----
From: Les Ginsberg [mailto:ginsberg@pluris.com]
Sent: Friday, December 28, 2001 10:29 AM
To: 'Manral, Vishwas'; Les Ginsberg; 'Jeff Parker'
Cc: IS-IS-WG (E-mail)
Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Vishwas -
Makes no difference. From the point of view of the receiver of an LSP, it
has no way of knowing what the value of LSP lifetime may be on the
originating IS since the remaining lifetime field gets modified, based on
elapsed time, prior to flooding. All the receiver can say is that the
originating IS has a value for LSP lifetime which is >= the original
received remaining lifetime.
If an IS arbitrarily decreases the remaining lifetime of an LSP it has
received, then it is quite possible that the LSP will age out of the local
database before the originating router regenerates that LSP. The protocol
will eventually recover, but in order to do so the LSP will first be purged,
causing an SPF to be run on all routers (or many of them anyway) with this
LSP absent, and then the originating router will, on seeing the purged
version, regenerate that LSP, flood it, and a second SPF will be run on
every router. Reachability advertised in this LSP will temporarily disappear
from the forwarding databases throughout the area/domain and then be
restored. This is highly undesirable.
Les
>
>
> Les,
>
> I meant "remaining lifetime" field in the LSP and not age(wrong use of
> terminology on my part).
>
> So this is what I meant:-
>
> 1. If the remaining Lifetime is > MaxAge value in the router,
> treat the
> remaining lifetime as if it was MaxAge.
> 2. MaxLSPGenInt should be less than min value of MaxAge for
> all routers in
> the domain.
> 3. The difference(as pointed out) should be at least enough
> so that the LSP
> is propagated thruout the domain(so that no one purges the
> LSP before the
> new version reaches it).
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Les Ginsberg [mailto:ginsberg@pluris.com]
> Sent: Friday, December 28, 2001 2:31 AM
> To: 'Manral, Vishwas'; 'Jeff Parker'
> Cc: IS-IS-WG (E-mail)
> Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
>
>
> >
> > Treating any LSP with age above Maxage could be done as if
> > age was MaxAge.
> > May be we need to recommend that all routers in a domain
> have the same
> > Maxage(and the value of MaxLSPGenInt should be less than the
> > value of the
> > smallest value of MaxAge in any router in the domain)value
> > for things to
> > work ok(and then we can treat all LSP's with age greater than
> > MaxAge as
> > MaxAge), we could raise a trap on getting an LSP with age
> greater than
> > MaxAge.
> >
>
> The change from an architectural constant to a configurable value was
> presumably made based on customer demand. To require, or even
> suggest, that
> an implementation treat an LSP received with a lifetime > the
> architectural
> constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do.
> Routers which did this could end up purging an LSP from their database
> before the originating router's MaxLSPGenInt timer fired,
> which would cause
> unnecessary flapping. If you want to argue that the current "de facto
> standard" of making LSP lifetime configurable should be made
> invalid you
> will at least be addressing the issue directly - though I
> suspect you will
> get little support. Circumventing the issue by pretending the
> value is not
> configurable is unwise.
>
> It is also worth noting that, as you suggest, there is a necessary
> relationship between LSP lifetime and MaxLSPGenInt, namely:
>
> 1)MaxLSPGenInt must be less than LSPlifetime
> 2)(LSPlifetime - MaxLSPGenInt) should be large enough to
> allow propagation
> of the LSP throughout the area/domain before the old LSP ages out
>
> If LSP lifetime is modified from the "default" value of 1200
> seconds, it
> makes sense to change MaxLSPGenInt in a like manner.
>
> Les
>
From dkatz@juniper.net Sun Dec 30 18:44:51 2001
From: dkatz@juniper.net (Dave Katz)
Date: Sun, 30 Dec 2001 10:44:51 -0800 (PST)
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
In-Reply-To:
(VishwasM@netplane.com)
References:
Message-ID: <200112301844.fBUIipb50547@cirrus.juniper.net>
I haven't been paying a lot of attention to this conversation, but that
never stopped me from commenting before.
One of the nice things about ISIS (as compared to OSPF) is that there
are very few things that are truly architectural constants (as in, if
you don't use this value, the protocol won't work.) Further, there
are less settable parameters that must be coordinated between systems
in order for the network to function.
The LSP lifetime (along with the adjacency holding time) has the very
nice property that everybody can pick different values and the network
Just Works. This has operationally saved people more times than I can
count.
Any system that makes judgement on the choice of values of these parameters
set by another system is just plain broken.
--Dave
From: "Manral, Vishwas"
Cc: "'isis-wg@spider.juniper.net'"
Content-Type: text/plain;
charset="iso-8859-1"
Sender: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
Date: Fri, 28 Dec 2001 00:37:40 -0500
Les,
I get the point you are trying to make. The problem you say would happen
whenever there is a diff in MaxAge in IS's in the domain(and the LSP's for
some reason is not refreshed).
This is what I am trying to say. The MaxAge would be the value which would
be put in a self LSP, as remaining lifetime when we are originating a new
LSP. If the remaining life time is greater than MaxAge for some other IS, it
should treat the stuff as if MaxAge(in the sense it should not drop the LSP,
MIB ops on remaining lifetime shld give age as MaxAge(if any), SPF(age
value) etc), however it should start the purge(MaxAge) timer for that LSP
with the value of "remaining lifetime" field(So remaining lifetime would be
zero after remaining life time period). However this would cause the MaxAge
field to be used as in the remaining lifetime and not as configured in the
IS itself.(some problems/loopholes/against existing approach with this
approach??)
This way all people would purge the LSP at nearly the same time(so the
problem described would not arise).
Thanks,
Vishwas
-----Original Message-----
From: Les Ginsberg [mailto:ginsberg@pluris.com]
Sent: Friday, December 28, 2001 10:29 AM
To: 'Manral, Vishwas'; Les Ginsberg; 'Jeff Parker'
Cc: IS-IS-WG (E-mail)
Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Vishwas -
Makes no difference. From the point of view of the receiver of an LSP, it
has no way of knowing what the value of LSP lifetime may be on the
originating IS since the remaining lifetime field gets modified, based on
elapsed time, prior to flooding. All the receiver can say is that the
originating IS has a value for LSP lifetime which is >= the original
received remaining lifetime.
If an IS arbitrarily decreases the remaining lifetime of an LSP it has
received, then it is quite possible that the LSP will age out of the local
database before the originating router regenerates that LSP. The protocol
will eventually recover, but in order to do so the LSP will first be purged,
causing an SPF to be run on all routers (or many of them anyway) with this
LSP absent, and then the originating router will, on seeing the purged
version, regenerate that LSP, flood it, and a second SPF will be run on
every router. Reachability advertised in this LSP will temporarily disappear
from the forwarding databases throughout the area/domain and then be
restored. This is highly undesirable.
Les
>
>
> Les,
>
> I meant "remaining lifetime" field in the LSP and not age(wrong use of
> terminology on my part).
>
> So this is what I meant:-
>
> 1. If the remaining Lifetime is > MaxAge value in the router,
> treat the
> remaining lifetime as if it was MaxAge.
> 2. MaxLSPGenInt should be less than min value of MaxAge for
> all routers in
> the domain.
> 3. The difference(as pointed out) should be at least enough
> so that the LSP
> is propagated thruout the domain(so that no one purges the
> LSP before the
> new version reaches it).
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Les Ginsberg [mailto:ginsberg@pluris.com]
> Sent: Friday, December 28, 2001 2:31 AM
> To: 'Manral, Vishwas'; 'Jeff Parker'
> Cc: IS-IS-WG (E-mail)
> Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
>
>
> >
> > Treating any LSP with age above Maxage could be done as if
> > age was MaxAge.
> > May be we need to recommend that all routers in a domain
> have the same
> > Maxage(and the value of MaxLSPGenInt should be less than the
> > value of the
> > smallest value of MaxAge in any router in the domain)value
> > for things to
> > work ok(and then we can treat all LSP's with age greater than
> > MaxAge as
> > MaxAge), we could raise a trap on getting an LSP with age
> greater than
> > MaxAge.
> >
>
> The change from an architectural constant to a configurable value was
> presumably made based on customer demand. To require, or even
> suggest, that
> an implementation treat an LSP received with a lifetime > the
> architectural
> constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do.
> Routers which did this could end up purging an LSP from their database
> before the originating router's MaxLSPGenInt timer fired,
> which would cause
> unnecessary flapping. If you want to argue that the current "de facto
> standard" of making LSP lifetime configurable should be made
> invalid you
> will at least be addressing the issue directly - though I
> suspect you will
> get little support. Circumventing the issue by pretending the
> value is not
> configurable is unwise.
>
> It is also worth noting that, as you suggest, there is a necessary
> relationship between LSP lifetime and MaxLSPGenInt, namely:
>
> 1)MaxLSPGenInt must be less than LSPlifetime
> 2)(LSPlifetime - MaxLSPGenInt) should be large enough to
> allow propagation
> of the LSP throughout the area/domain before the old LSP ages out
>
> If LSP lifetime is modified from the "default" value of 1200
> seconds, it
> makes sense to change MaxLSPGenInt in a like manner.
>
> Les
>
_______________________________________________
Isis-wg mailing list - Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg
From VishwasM@netplane.com Mon Dec 31 05:02:12 2001
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Mon, 31 Dec 2001 00:02:12 -0500
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Message-ID:
Dave,
We have sort of agreed, that not all architectural constants described in
ISIS are "truly architectural constants" and may be configureable also the
fact that making assumptions based on a constant MaxAge/some other
parameters is wrong.
However this brings me to another issue. I have been reading thru the mail
archives and I find a lot of things that are not done in the RFC way in the
current implementations. Wouldn't it be helpful if we had a document that
described the "Best Current Practices"? (I had written to Tony regarding the
same and he felt "yes, we could if we find a volunteer but then again, new
verison of ISIS document is supposed to fix that stuff").
Thanks,
Vishwas
-----Original Message-----
From: Dave Katz [mailto:dkatz@juniper.net]
Sent: Monday, December 31, 2001 12:15 AM
To: VishwasM@netplane.com
Cc: ginsberg@pluris.com; isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
I haven't been paying a lot of attention to this conversation, but that
never stopped me from commenting before.
One of the nice things about ISIS (as compared to OSPF) is that there
are very few things that are truly architectural constants (as in, if
you don't use this value, the protocol won't work.) Further, there
are less settable parameters that must be coordinated between systems
in order for the network to function.
The LSP lifetime (along with the adjacency holding time) has the very
nice property that everybody can pick different values and the network
Just Works. This has operationally saved people more times than I can
count.
Any system that makes judgement on the choice of values of these parameters
set by another system is just plain broken.
--Dave
From: "Manral, Vishwas"
Cc: "'isis-wg@spider.juniper.net'"
Content-Type: text/plain;
charset="iso-8859-1"
Sender: isis-wg-admin@spider.juniper.net
X-BeenThere: isis-wg@external.juniper.net
X-Mailman-Version: 2.0rc1
Precedence: bulk
List-Help:
List-Post:
List-Subscribe: ,
List-Id: IETF IS-IS working group
List-Unsubscribe: ,
List-Archive:
Date: Fri, 28 Dec 2001 00:37:40 -0500
Les,
I get the point you are trying to make. The problem you say would happen
whenever there is a diff in MaxAge in IS's in the domain(and the LSP's
for
some reason is not refreshed).
This is what I am trying to say. The MaxAge would be the value which
would
be put in a self LSP, as remaining lifetime when we are originating a new
LSP. If the remaining life time is greater than MaxAge for some other IS,
it
should treat the stuff as if MaxAge(in the sense it should not drop the
LSP,
MIB ops on remaining lifetime shld give age as MaxAge(if any), SPF(age
value) etc), however it should start the purge(MaxAge) timer for that LSP
with the value of "remaining lifetime" field(So remaining lifetime would
be
zero after remaining life time period). However this would cause the
MaxAge
field to be used as in the remaining lifetime and not as configured in
the
IS itself.(some problems/loopholes/against existing approach with this
approach??)
This way all people would purge the LSP at nearly the same time(so the
problem described would not arise).
Thanks,
Vishwas
-----Original Message-----
From: Les Ginsberg [mailto:ginsberg@pluris.com]
Sent: Friday, December 28, 2001 10:29 AM
To: 'Manral, Vishwas'; Les Ginsberg; 'Jeff Parker'
Cc: IS-IS-WG (E-mail)
Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
Vishwas -
Makes no difference. From the point of view of the receiver of an LSP, it
has no way of knowing what the value of LSP lifetime may be on the
originating IS since the remaining lifetime field gets modified, based on
elapsed time, prior to flooding. All the receiver can say is that the
originating IS has a value for LSP lifetime which is >= the original
received remaining lifetime.
If an IS arbitrarily decreases the remaining lifetime of an LSP it has
received, then it is quite possible that the LSP will age out of the
local
database before the originating router regenerates that LSP. The protocol
will eventually recover, but in order to do so the LSP will first be
purged,
causing an SPF to be run on all routers (or many of them anyway) with
this
LSP absent, and then the originating router will, on seeing the purged
version, regenerate that LSP, flood it, and a second SPF will be run on
every router. Reachability advertised in this LSP will temporarily
disappear
from the forwarding databases throughout the area/domain and then be
restored. This is highly undesirable.
Les
>
>
> Les,
>
> I meant "remaining lifetime" field in the LSP and not age(wrong use of
> terminology on my part).
>
> So this is what I meant:-
>
> 1. If the remaining Lifetime is > MaxAge value in the router,
> treat the
> remaining lifetime as if it was MaxAge.
> 2. MaxLSPGenInt should be less than min value of MaxAge for
> all routers in
> the domain.
> 3. The difference(as pointed out) should be at least enough
> so that the LSP
> is propagated thruout the domain(so that no one purges the
> LSP before the
> new version reaches it).
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Les Ginsberg [mailto:ginsberg@pluris.com]
> Sent: Friday, December 28, 2001 2:31 AM
> To: 'Manral, Vishwas'; 'Jeff Parker'
> Cc: IS-IS-WG (E-mail)
> Subject: RE: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
>
>
> >
> > Treating any LSP with age above Maxage could be done as if
> > age was MaxAge.
> > May be we need to recommend that all routers in a domain
> have the same
> > Maxage(and the value of MaxLSPGenInt should be less than the
> > value of the
> > smallest value of MaxAge in any router in the domain)value
> > for things to
> > work ok(and then we can treat all LSP's with age greater than
> > MaxAge as
> > MaxAge), we could raise a trap on getting an LSP with age
> greater than
> > MaxAge.
> >
>
> The change from an architectural constant to a configurable value was
> presumably made based on customer demand. To require, or even
> suggest, that
> an implementation treat an LSP received with a lifetime > the
> architectural
> constant MAXAGE as if it were set to MAXAGE is a VERY BAD thing to do.
> Routers which did this could end up purging an LSP from their database
> before the originating router's MaxLSPGenInt timer fired,
> which would cause
> unnecessary flapping. If you want to argue that the current "de facto
> standard" of making LSP lifetime configurable should be made
> invalid you
> will at least be addressing the issue directly - though I
> suspect you will
> get little support. Circumventing the issue by pretending the
> value is not
> configurable is unwise.
>
> It is also worth noting that, as you suggest, there is a necessary
> relationship between LSP lifetime and MaxLSPGenInt, namely:
>
> 1)MaxLSPGenInt must be less than LSPlifetime
> 2)(LSPlifetime - MaxLSPGenInt) should be large enough to
> allow propagation
> of the LSP throughout the area/domain before the old LSP ages out
>
> If LSP lifetime is modified from the "default" value of 1200
> seconds, it
> makes sense to change MaxLSPGenInt in a like manner.
>
> Les
From dkatz@juniper.net Mon Dec 31 06:00:21 2001
From: dkatz@juniper.net (Dave Katz)
Date: Sun, 30 Dec 2001 22:00:21 -0800 (PST)
Subject: [Isis-wg] RE: Regarding draft-ietf-isis-wg-mib-06.txt
In-Reply-To:
(VishwasM@netplane.com)
References:
Message-ID: <200112310600.fBV60LH51764@cirrus.juniper.net>
X-JNPR-Received-From: outside
From: "Manral, Vishwas"
Cc: ginsberg@pluris.com, isis-wg@spider.juniper.net
Date: Mon, 31 Dec 2001 00:02:12 -0500
Content-Type: text/plain
X-OriginalArrivalTime: 31 Dec 2001 05:02:01.0453 (UTC) FILETIME=[483509D0:01C191B8]
Dave,
We have sort of agreed, that not all architectural constants described in
ISIS are "truly architectural constants" and may be configureable also the
fact that making assumptions based on a constant MaxAge/some other
parameters is wrong.
However this brings me to another issue. I have been reading thru the mail
archives and I find a lot of things that are not done in the RFC way in the
current implementations. Wouldn't it be helpful if we had a document that
described the "Best Current Practices"? (I had written to Tony regarding the
same and he felt "yes, we could if we find a volunteer but then again, new
verison of ISIS document is supposed to fix that stuff").
I think the number of things that are done in practical conflict with
the spec is vanishingly small, where "practical conflict" is
interpreted as "a reasonable implementation would notice."
Excessively pedantic boxes have a way of fixing themselves one way or
another.
Most of these things are pretty obvious to anyone reasonably versed in
the art, though the potentially sticky ones (like not bothering with
ISHs) should probably be documented.
--Dave
From aravindravikumar@yahoo.com Mon Dec 31 10:28:11 2001
From: aravindravikumar@yahoo.com (Aravind Ravikumar)
Date: Mon, 31 Dec 2001 02:28:11 -0800 (PST)
Subject: [Isis-wg] ISIS Adjacency IP Address Table
Message-ID: <20011231102811.98773.qmail@web11204.mail.yahoo.com>
--0-992764757-1009794491=:97979
Content-Type: text/plain; charset=us-ascii
Hi,
Currently, the entry in the Adjacency IP Address Table is indexed as follows:
1. Instance 2. Circuit Index 3. isisIsAdjIpAddrAdjIndex
If a neighbor IS advertises more than One IP Interface Address in its HELLO Packets, then we may need some mapping mechanism
to know that these IP Addresses were advertised by this specific IS.
In order to avoid such mechanisms, can't we have the Adjacency IP Address Table as part of the Adjacency Table.
( This will help in properly identifying each and all the Interfaces advertised by each IS).
Therefore is'nt it better to have the following Index:
1. Instance 2. Circuit Index 3. Adjacency Index 4. Adjacency IP Address Index
Or can we have the following index:
1. Instance 2. Circuit Index 3. isisIsAdjIpAddrAdjIndex 4. Ip Address
Is the above understanding correct ?
Please clear my doubt.
Thanking in advance.
---------------------------------
Do You Yahoo!?
Send your FREE holiday greetings online at Yahoo! Greetings.
--0-992764757-1009794491=:97979
Content-Type: text/html; charset=us-ascii
Hi,
Currently, the entry in the Adjacency IP Address Table is indexed as follows:
1. Instance 2. Circuit Index 3. isisIsAdjIpAddrAdjIndex
If a neighbor IS advertises more than One IP Interface Address in its HELLO Packets, then we may need some mapping mechanism
to know that these IP Addresses were advertised by this specific IS.
In order to avoid such mechanisms, can't we have the Adjacency IP Address Table as part of the Adjacency Table.
( This will help in properly identifying each and all the Interfaces advertised by each IS).
Therefore is'nt it better to have the following Index:
1. Instance 2. Circuit Index 3. Adjacency Index 4. Adjacency IP Address Index
Or can we have the following index:
1. Instance 2. Circuit Index 3. isisIsAdjIpAddrAdjIndex 4. Ip Address
Is the above understanding correct ?
Please clear my doubt.
Thanking in advance.
Do You Yahoo!?
Send your FREE holiday greetings online at Yahoo! Greetings.
--0-992764757-1009794491=:97979--
From Sivakumar A"
--=_MAILER_ATTACH_BOUNDARY_200112296193658659639006
Content-Type: text/plain; charset=us-ascii
Message from "" forwarded as attachment:
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in
--=_MAILER_ATTACH_BOUNDARY_200112296193658659639006
Content-Type: message/rfc822
From: ""
Full-Name: ""
To: "workgroup"
CC: "Jeff Parker" ,"Radia Perlman - Boston Center for Networking"
Reply-To:
Subject: External IPRA
Date: Mon, 24 Dec 2001 11:55:22 +0530
X-URL: http://indiatimes.com
Content-Type: multipart/alternative;
boundary="=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868"
MIME-Version: 1.0
--=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868
Content-type: text/plain; charset="us-ascii"
Hi,
Kindly clarify the following
Whether External IPRA needs to be summarized? If yes, then consider the following.
External IPRA with Internal Metric matches Summary Address Table Entry S1. We announce S1 with what ever metric that is configured in the Summary Address Table
Note: SA table does not have a field indicating the type of metric whether internal or external.
External IPRA with External Metric matches Summary Address Table Entry S2. What should be done now, since the metric configured in the summary Address Table does not specify whether it is internal or external can S2 now be announced for the External IPRA. Will this not violate the specification which says, that external metrics are not camparable to internal metrics?
Any help on this is greatly appreciated
Thanks & Regards
Sivakumar A
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in
--=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868
Content-type: text/html; charset="us-ascii"
Hi,
Kindly clarify the following
Whether External IPRA needs to be summarized? If yes, then consider the following.
External IPRA with Internal Metric matches Summary Address Table Entry S1. We announce S1 with what ever metric that is configured in the Summary Address Table
Note: SA table does not have a field indicating the type of metric whether internal or external.
External IPRA with External Metric matches Summary Address Table Entry S2. What should be done now, since the metric configured in the summary Address Table does not specify whether it is internal or external can S2 now be announced for the External IPRA. Will this not violate the specification which says, that external metrics are not camparable to internal metrics?
Any help on this is greatly appreciated
Thanks & Regards
Sivakumar A
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in
--=_MAILER_ATTACH_BOUNDARY1_200112241115522950390868--
--=_MAILER_ATTACH_BOUNDARY_200112296193658659639006--