> In ISIS MIB, circuit Level table does not contain metric type
> (Internal or External). How is it possible for a manager to
> configure circuit level Default Metric as Internal or
> External as it has SYNTAX Default Metric (Integer Value from
> 1 to 63).This seems to be missing even in the mib-07.
>
> Kindly help in this regard
>
> Thanks and Regards
> Sivakumar A
Sivakumar -
My understanding is that external/internal is
an issue of the provenance, not the metric itself.
No one makes imported beer. They make domestic
beer, and then someone imports it to a new country.
Thus an external metric is something I learn from
another protocol, such as BGP.
If there is a need to lie about where the
metric came from, I'm sure someone on the list
will rise up and smite me.
- jeff parker
From lliu@chiaro.com Wed Jan 23 16:49:32 2002
From: lliu@chiaro.com (Laura Liu)
Date: Wed, 23 Jan 2002 10:49:32 -0600
Subject: [Isis-wg] Questions on cird IDs in isis mib
Message-ID: <2383E22BDFF6D311BB8400B0D021A50701B94A90@MAIL>
--=_IS_MIME_Boundary
Content-Type: text/plain;
charset="iso-8859-1"
Hello,
I need some clarification on the three circuit Id related mib objects.
1. isisCircIndex and isisCircIfIndex are defined as Integer32. My
understanding is isisCircIndex refers to a logical id, while isisCircIfIndex
are the physical id of the interface to which this circuit corresponds.
2. isisCircLocalID is Integer32(0..255), is the locally assigned one octet
Local Circuit ID used for "maintaining more than 255 circuits in IS-IS".
Am I correct?
Another question, there is isisCircLevelDesIS object, it only report the
DR's system ID part. How can I retrieve the circuit ID part of DR's LAN ID?
please help, and thanks!
Laura
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
----------------------------------------- (on Chiaro SMTP Relay)
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.
---------------------------------------------------------
--=_IS_MIME_Boundary--
From koen.vermeulen@alcatel.be Wed Jan 23 18:24:42 2002
From: koen.vermeulen@alcatel.be (Koen Vermeulen)
Date: Wed, 23 Jan 2002 19:24:42 +0100
Subject: [Isis-wg] Making the update reliable
Message-ID: <3C4EFFEA.4A5C778F@alcatel.be>
--------------EA764333897CC61BD4B8DBD6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
I have a question concerning ISO/IEC 10589 7.3.17 'Making the
update reliable'. At the end of this section is written for
point-to-point circuits:
When a point-to-point circuit (including non-DA DED circuits
and virtual links) starts (or restarts), the IS shall
a) set SRMflag for that circuit on all LSPs, and
b) send a Complete set of Complete Sequence Numbers PDUs
on that circuit.
My question is now: what is actually meant with this
'start' (or 'restart') of a circuit? Do they mean an
adjacency state change to 'up', or is it really the circuit
which physically gets ready to send l2-frames?
If the second answer is what is meant, then I don't
understand why a CSNP is sent. This PDU will
be thrown away anyhow by the receiving side if there is
no adjacency (see 7.3.15.2 7:
If the SNP is received on a non-broadcast circuit and
there is no adjacency of the same level (e.g. a level 1 SNP
with a level 1 or level 1 & 2 adjacency) on the circuit
over which the SNP was received, then the IS shall
discard the SNP without generating a event.
).
So how can this mechanism make the update reliable? Or am I
missing something?
Regards,
Koen
--------------EA764333897CC61BD4B8DBD6
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hello,
I have a question concerning ISO/IEC 10589 7.3.17 'Making the
update reliable'. At the end of this section is written for
point-to-point circuits:
When a point-to-point circuit (including non-DA
DED circuits
and virtual links) starts (or restarts), the
IS shall
a) set SRMflag for that
circuit on all LSPs, and
b) send a Complete set
of Complete Sequence Numbers PDUs
on
that circuit.
My question is now: what is actually meant with this
'start' (or 'restart') of a circuit? Do they mean an
adjacency state change to 'up', or is it really the circuit
which physically gets ready to send l2-frames?
If the second answer is what is meant, then I don't
understand why a CSNP is sent. This PDU will
be thrown away anyhow by the receiving side if there is
no adjacency (see 7.3.15.2 7:
If the SNP is received on a non-broadcast circuit
and
there is no adjacency of the same level (e.g.
a level 1 SNP
with a level 1 or level 1 & 2 adjacency)
on the circuit
over which the SNP was received, then the IS
shall
discard the SNP without generating a event.
).
So how can this mechanism make the update reliable? Or am I
missing something?
Regards,
Koen
--------------EA764333897CC61BD4B8DBD6--
From jparker@axiowave.com Wed Jan 23 19:32:54 2002
From: jparker@axiowave.com (Jeff Parker)
Date: Wed, 23 Jan 2002 14:32:54 -0500
Subject: [Isis-wg] Questions on cird IDs in isis mib
Message-ID:
> 1. isisCircIndex and isisCircIfIndex are defined as Integer32. My
> understanding is isisCircIndex refers to a logical id, while
isisCircIndex OBJECT-TYPE
SYNTAX Integer32 (1..2000000000)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The identifier of this circuit, unique within the
instance of the IS-IS protocol. This object follows
the index behavior. This is for SNMP Indexing
purposes only and need not have any relation to
any protocol value."
::= { isisCircEntry 1 }
So this can be an index into an array, a hash value, or
it could be the index of a port in your box.
However, many devices allow multiple circuits to
run over the same physical port, and would not
be able to use a physical port number as the index.
In brief, it is whatever you would like it to be.
It could be the same as isisCircIfIndex.
> isisCircIfIndex are the physical id of the
> interface to which this circuit corresponds.
isisCircIfIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of ifIndex for the interface to which this
circuit corresponds. This object cannot be modified
after creation"
::= { isisCircEntry 2 }
Nope, this is the MIB II IfIndex. There are rules
about doling this out. What we're trying to do here
is to have a value that lines up with the value of
the manager will see in the Interface table.
> 2. isisCircLocalID is Integer32(0..255), is the locally
> assigned one octet
> Local Circuit ID used for "maintaining more than 255 circuits
> in IS-IS".
isisCircLocalID OBJECT-TYPE
SYNTAX Integer32(0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An identification that can be used in protocol packets
to identify a circuit. Values of isisCircLocalID do
not need to be unique. They are only required to differ
on LANs where the Intermediate System is the Designated
Intermediate System."
::= { isisCircEntry 4 }
The MIB does not try to address the issue of how to
maintain a presence as the DIS on more than 256 LANs.
Briefly, this is the octet that you use to augment
the system ID to provide a unique PNodeID. This can
be related to one of the other indicies, or can be
independent. The implementer gets to allocate this.
> Another question, there is isisCircLevelDesIS object, it only
> report the
> DR's system ID part. How can I retrieve the circuit ID part
> of DR's LAN ID?
>
> please help, and thanks!
>
> Laura
Laura -
I think that is an error: thanks for catching that.
The syntax should be an octet string of length 7 or 0.
isisCircLevelDesIS OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..7))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ID of the LAN Designated Intermediate System
on this circuit at this level. If, for any reason,
this system is not partaking in the relevant
Designated Intermediate System election process,
then the value returned is the zero length OCTET STRING."
REFERENCE "{ISIS.aoi l2DesignatedIntermediateSystem (75)}"
::= { isisCircLevelEntry 4 }
- jeff parker
- axiowave networks
From swaminathanr@netplane.com Thu Jan 24 07:12:15 2002
From: swaminathanr@netplane.com (Ramalingam, Swaminathan)
Date: Thu, 24 Jan 2002 02:12:15 -0500
Subject: [Isis-wg] Making the update reliable
Message-ID:
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_01C1A4A6.7375C930
Content-Type: text/plain;
charset="iso-8859-1"
Keon,
Whenever an adjacency comes up (may be because of start/restart) , CSNPs are
sent on p2p links.You can't send control packets without adjacency.
"Making the update reliable" means how the flooding made reliable using
periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending
CSNPs on p2p network when it start/restarts.
- Swami
-----Original Message-----
From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
Sent: Wednesday, January 23, 2002 11:55 PM
To: Isis-wg
Subject: [Isis-wg] Making the update reliable
Hello,
I have a question concerning ISO/IEC 10589 7.3.17 'Making the
update reliable'. At the end of this section is written for
point-to-point circuits:
When a point-to-point circuit (including non-DA DED circuits
and virtual links) starts (or restarts), the IS shall
a) set SRMflag for that circuit on all LSPs, and
b) send a Complete set of Complete Sequence Numbers PDUs
on that circuit.
My question is now: what is actually meant with this
'start' (or 'restart') of a circuit? Do they mean an
adjacency state change to 'up', or is it really the circuit
which physically gets ready to send l2-frames?
If the second answer is what is meant, then I don't
understand why a CSNP is sent. This PDU will
be thrown away anyhow by the receiving side if there is
no adjacency (see 7.3.15.2 7:
If the SNP is received on a non-broadcast circuit and
there is no adjacency of the same level (e.g. a level 1 SNP
with a level 1 or level 1 & 2 adjacency) on the circuit
over which the SNP was received, then the IS shall
discard the SNP without generating a event.
).
So how can this mechanism make the update reliable? Or am I
missing something?
Regards,
Koen
------_=_NextPart_001_01C1A4A6.7375C930
Content-Type: text/html;
charset="iso-8859-1"
Keon,
Whenever an adjacency comes up (may be because of
start/restart) , CSNPs are sent on p2p links.You can't send control packets
without adjacency.
"Making the update reliable" means how the flooding
made reliable using periodic CSNPs in bcast network, ack to PSNPs in p2p
networks and sending CSNPs on p2p network when it
start/restarts.
-
Swami
Hello,
I have a question concerning ISO/IEC 10589 7.3.17 'Making the
update reliable'. At the end of this section is written for
point-to-point circuits:
When a point-to-point circuit (including non-DA DED
circuits
and virtual links) starts (or
restarts), the IS shall
a) set SRMflag for that
circuit on all LSPs, and
b) send a Complete set of
Complete Sequence Numbers PDUs
on that
circuit.
My question is now: what is actually meant with this
'start' (or 'restart') of a circuit? Do they mean an
adjacency state change to 'up', or is it really the circuit
which physically gets ready to send l2-frames?
If the
second answer is what is meant, then I don't
understand why a
CSNP is sent. This PDU will
be thrown away anyhow by the
receiving side if there is
no adjacency (see 7.3.15.2
7:
If the SNP is received on a non-broadcast circuit
and
there is no adjacency of the same level
(e.g. a level 1 SNP
with a level 1 or level 1
& 2 adjacency) on the circuit
over which
the SNP was received, then the IS shall
discard the SNP without generating a event.
).
So how can this mechanism make the update reliable? Or
am I
missing something?
Regards,
Koen
------_=_NextPart_001_01C1A4A6.7375C930--
From mshand@cisco.com Thu Jan 24 08:26:39 2002
From: mshand@cisco.com (mike shand)
Date: Thu, 24 Jan 2002 08:26:39 +0000
Subject: [Isis-wg] Making the update reliable
In-Reply-To:
Message-ID: <4.3.2.7.2.20020124082227.00b3be80@jaws.cisco.com>
At 02:12 24/01/2002 -0500, Ramalingam, Swaminathan wrote:
Keon,
Whenever an adjacency comes up
(may be because of start/restart) , CSNPs are sent on p2p links.You can't
send control packets without adjacency.
Yes.
"Making the update
reliable" means how the flooding made reliable using periodic
CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on
p2p network when it start/restarts.
The heading is something of a misnomer here. The CSNP has NOTHING to do
with reliability in the case of a p2p circuit. (It does of course on a
broadcast circuit). On a P2P, the CSNP is simply an optimization which
avoid the need to flood the entire LSP database when the adjacency comes
up between two routers which already have (most of) the database.
Reliability is of course achieved by setting SRMflags on all LSPs when
the circuit comes up and using PSNPs to ACK.
Mike
- Swami
- -----Original Message-----
- From: Koen Vermeulen
[mailto:koen.vermeulen@alcatel.be]
- Sent: Wednesday, January 23, 2002 11:55 PM
- To: Isis-wg
- Subject: [Isis-wg] Making the update reliable
- Hello,
- I have a question concerning ISO/IEC 10589 7.3.17 'Making the
- update reliable'. At the end of this section is written for
- point-to-point circuits:
- When a point-to-point circuit (including non-DA DED circuits
- and virtual links) starts (or restarts), the IS shall
- a) set SRMflag for that circuit on all LSPs, and
- b) send a Complete set of Complete Sequence Numbers PDUs
- on that circuit.
- My question is now: what is actually meant with this
- 'start' (or 'restart') of a circuit? Do they mean an
- adjacency state change to 'up', or is it really the circuit
- which physically gets ready to send l2-frames?
- If the second answer is what is meant, then I don't
- understand why a CSNP is sent. This PDU will
- be thrown away anyhow by the receiving side if there is
- no adjacency (see 7.3.15.2 7:
- If the SNP is received on a non-broadcast circuit and
- there is no adjacency of the same level (e.g. a level 1 SNP
- with a level 1 or level 1 & 2 adjacency) on the circuit
- over which the SNP was received, then the IS shall
- discard the SNP without generating a event.
- ).
- So how can this mechanism make the update reliable? Or am I
- missing something?
- Regards,
- Koen
-
From jlearman@cisco.com Thu Jan 24 13:25:55 2002
From: jlearman@cisco.com (Jeff Learman)
Date: Thu, 24 Jan 2002 08:25:55 -0500
Subject: [Isis-wg] Making the update reliable
In-Reply-To:
Message-ID: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com>
--=====================_27549323==_.ALT
Content-Type: text/plain; charset="us-ascii"
Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
so the update reliability isn't there for PPP unless you also use the 3-way
handshake. Fortunately, loss of the initial CNSP would only cause problems
until every router had regenerated its LSP -- within 20 minutes using default
LSP regen timer. See the 3-way draft for other problems that can happen
because of running IS-IS over an unreliable link.
Jeff
At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
>Keon,
>
>Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency.
>
>"Making the update reliable" means how the flooding made reliable using periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts.
>
>- Swami
>-----Original Message-----
>From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
>Sent: Wednesday, January 23, 2002 11:55 PM
>To: Isis-wg
>Subject: [Isis-wg] Making the update reliable
>
>Hello,
>
>I have a question concerning ISO/IEC 10589 7.3.17 'Making the
>update reliable'. At the end of this section is written for
>point-to-point circuits:
>
> When a point-to-point circuit (including non-DA DED circuits
> and virtual links) starts (or restarts), the IS shall
>
> a) set SRMflag for that circuit on all LSPs, and
>
> b) send a Complete set of Complete Sequence Numbers PDUs
> on that circuit.
>
>My question is now: what is actually meant with this
>'start' (or 'restart') of a circuit? Do they mean an
>adjacency state change to 'up', or is it really the circuit
>which physically gets ready to send l2-frames?
>If the second answer is what is meant, then I don't
>understand why a CSNP is sent. This PDU will
>be thrown away anyhow by the receiving side if there is
>no adjacency (see 7.3.15.2 7:
>
> If the SNP is received on a non-broadcast circuit and
> there is no adjacency of the same level (e.g. a level 1 SNP
> with a level 1 or level 1 & 2 adjacency) on the circuit
> over which the SNP was received, then the IS shall
> discard the SNP without generating a event.
>
>).
>So how can this mechanism make the update reliable? Or am I
>missing something?
>
>Regards,
>Koen
>
--=====================_27549323==_.ALT
Content-Type: text/html; charset="us-ascii"
Keep in mind that in 10589, IS-IS requires reliable point-to-point
links,
so the update reliability isn't there for PPP unless you also use the
3-way
handshake. Fortunately, loss of the initial CNSP would only cause
problems
until every router had regenerated its LSP -- within 20 minutes using
default
LSP regen timer. See the 3-way draft for other problems that can
happen
because of running IS-IS over an unreliable link.
Jeff
At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
Keon,
Whenever an adjacency comes up
(may be because of start/restart) , CSNPs are sent on p2p links.You can't
send control packets without adjacency.
"Making the update
reliable" means how the flooding made reliable using periodic
CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on
p2p network when it start/restarts.
- Swami
- -----Original Message-----
- From: Koen Vermeulen
[mailto:koen.vermeulen@alcatel.be]
- Sent: Wednesday, January 23, 2002 11:55 PM
- To: Isis-wg
- Subject: [Isis-wg] Making the update reliable
- Hello,
- I have a question concerning ISO/IEC 10589 7.3.17 'Making the
- update reliable'. At the end of this section is written for
- point-to-point circuits:
- When a point-to-point circuit (including non-DA DED circuits
- and virtual links) starts (or restarts), the IS shall
- a) set SRMflag for that circuit on all LSPs, and
- b) send a Complete set of Complete Sequence Numbers PDUs
- on that circuit.
- My question is now: what is actually meant with this
- 'start' (or 'restart') of a circuit? Do they mean an
- adjacency state change to 'up', or is it really the circuit
- which physically gets ready to send l2-frames?
- If the second answer is what is meant, then I don't
- understand why a CSNP is sent. This PDU will
- be thrown away anyhow by the receiving side if there is
- no adjacency (see 7.3.15.2 7:
- If the SNP is received on a non-broadcast circuit and
- there is no adjacency of the same level (e.g. a level 1 SNP
- with a level 1 or level 1 & 2 adjacency) on the circuit
- over which the SNP was received, then the IS shall
- discard the SNP without generating a event.
- ).
- So how can this mechanism make the update reliable? Or am I
- missing something?
- Regards,
- Koen
-
--=====================_27549323==_.ALT--
From jlearman@cisco.com Thu Jan 24 13:56:19 2002
From: jlearman@cisco.com (Jeff Learman)
Date: Thu, 24 Jan 2002 08:56:19 -0500
Subject: [Isis-wg] Making the update reliable
In-Reply-To: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com>
References:
Message-ID: <4.3.2.7.2.20020124085424.01d01c40@dingdong.cisco.com>
--=====================_29328442==_.ALT
Content-Type: text/plain; charset="us-ascii"
Evidently I should have read Mike's reply before sending this, which
is evidently wrong about the consequences of losing the first CSNP.
At 08:25 AM 1/24/2002, Jeff Learman wrote:
>Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
>so the update reliability isn't there for PPP unless you also use the 3-way
>handshake. Fortunately, loss of the initial CNSP would only cause problems
>until every router had regenerated its LSP -- within 20 minutes using default
>LSP regen timer. See the 3-way draft for other problems that can happen
>because of running IS-IS over an unreliable link.
>
>Jeff
>
>At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
>>Keon,
>>
>>Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency.
>>
>>"Making the update reliable" means how the flooding made reliable using periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts.
>>
>>- Swami
>>-----Original Message-----
>>From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
>>Sent: Wednesday, January 23, 2002 11:55 PM
>>To: Isis-wg
>>Subject: [Isis-wg] Making the update reliable
>>
>>Hello,
>>
>>I have a question concerning ISO/IEC 10589 7.3.17 'Making the
>>update reliable'. At the end of this section is written for
>>point-to-point circuits:
>>
>> When a point-to-point circuit (including non-DA DED circuits
>> and virtual links) starts (or restarts), the IS shall
>>
>> a) set SRMflag for that circuit on all LSPs, and
>>
>> b) send a Complete set of Complete Sequence Numbers PDUs
>> on that circuit.
>>
>>My question is now: what is actually meant with this
>>'start' (or 'restart') of a circuit? Do they mean an
>>adjacency state change to 'up', or is it really the circuit
>>which physically gets ready to send l2-frames?
>>If the second answer is what is meant, then I don't
>>understand why a CSNP is sent. This PDU will
>>be thrown away anyhow by the receiving side if there is
>>no adjacency (see 7.3.15.2 7:
>>
>> If the SNP is received on a non-broadcast circuit and
>> there is no adjacency of the same level (e.g. a level 1 SNP
>> with a level 1 or level 1 & 2 adjacency) on the circuit
>> over which the SNP was received, then the IS shall
>> discard the SNP without generating a event.
>>
>>).
>>So how can this mechanism make the update reliable? Or am I
>>missing something?
>>
>>Regards,
>>Koen
>>
--=====================_29328442==_.ALT
Content-Type: text/html; charset="us-ascii"
Evidently I should have read Mike's reply before sending this,
which
is evidently wrong about the consequences of losing the first CSNP.
At 08:25 AM 1/24/2002, Jeff Learman wrote:
Keep in mind that in 10589, IS-IS requires
reliable point-to-point links,
so the update reliability isn't there for PPP unless you also use the
3-way
handshake. Fortunately, loss of the initial CNSP would only cause
problems
until every router had regenerated its LSP -- within 20 minutes using
default
LSP regen timer. See the 3-way draft for other problems that can
happen
because of running IS-IS over an unreliable link.
Jeff
At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
Keon,
Whenever an adjacency comes up
(may be because of start/restart) , CSNPs are sent on p2p links.You can't
send control packets without adjacency.
"Making the update
reliable" means how the flooding made reliable using periodic
CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on
p2p network when it start/restarts.
- Swami
- -----Original Message-----
- From: Koen Vermeulen
[mailto:koen.vermeulen@alcatel.be]
- Sent: Wednesday, January 23, 2002 11:55 PM
- To: Isis-wg
- Subject: [Isis-wg] Making the update reliable
- Hello,
- I have a question concerning ISO/IEC 10589 7.3.17 'Making the
- update reliable'. At the end of this section is written for
- point-to-point circuits:
- When a point-to-point circuit (including non-DA DED circuits
- and virtual links) starts (or restarts), the IS shall
- a) set SRMflag for that circuit on all LSPs, and
- b) send a Complete set of Complete Sequence Numbers PDUs
- on that circuit.
- My question is now: what is actually meant with this
- 'start' (or 'restart') of a circuit? Do they mean an
- adjacency state change to 'up', or is it really the circuit
- which physically gets ready to send l2-frames?
- If the second answer is what is meant, then I don't
- understand why a CSNP is sent. This PDU will
- be thrown away anyhow by the receiving side if there is
- no adjacency (see 7.3.15.2 7:
- If the SNP is received on a non-broadcast circuit and
- there is no adjacency of the same level (e.g. a level 1 SNP
- with a level 1 or level 1 & 2 adjacency) on the circuit
- over which the SNP was received, then the IS shall
- discard the SNP without generating a event.
- ).
- So how can this mechanism make the update reliable? Or am I
- missing something?
- Regards,
- Koen
-
--=====================_29328442==_.ALT--
From Larmer@CommSense.Net Thu Jan 24 15:11:35 2002
From: Larmer@CommSense.Net (Ken Larmer)
Date: Thu, 24 Jan 2002 10:11:35 -0500
Subject: [Isis-wg] Making the update reliable
In-Reply-To: <4.3.2.7.2.20020124082227.00b3be80@jaws.cisco.com>
Message-ID:
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C1A4BF.8162D010
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Mike Shand Wrote:
The heading is something of a misnomer here. The CSNP has NOTHING to do with
reliability in the case of a p2p circuit. (It does of course on a broadcast
circuit). On a P2P, the CSNP is simply an optimization which avoid the need
to flood the entire LSP database when the adjacency comes up between two
routers which already have (most of) the database. Reliability is of course
achieved by setting SRMflags on all LSPs when the circuit comes up and using
PSNPs to ACK.
Hi Mike,
Doesn't a PSNP actually serve dual roles in this capacity, as a request
and as an acknowledgement?
After a circuit restarts and we form an adjacency, ISH and IIH PDUs are
exchanged (not all implementations send ISH PDUs). Next, some
implementations transmit newly generated LSP(s) as a result of the newly
formed adjacency. By sending this LSP prior to issuing a CSNP, this
eliminates the need for the remote IS to issue a PSNP as a request for this
LSP and then issue a PSNP again as an acknowledgement for this LSP. Next,
both sides of the link set the SRMflag for all LSPs in the appropriate LSP
Ln Database, based on the adjacencyUsage (send these LSPs upon expiration of
minimumLSPTransmissionInterval). They then transmit a CSNP with entries for
all LSPs contained within the appropriate Ln LSPDB, regardless of the
SSNflag settings.
The receiving IS processes the newly received CSNP(s) and sets the
SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP LSP
Entry reference which is non-existent in the local LSPDB, it will create an
entry in its LSPDB with a LSP Seq # = zero. It next sets the SSNflag for
this entry (request this LSP from the remote adjacency). Once the
partialSNPInterval timer expires, the PSNP shall be transmitted to the
remote IS (clear SSNflag for this LSP entry upon successful transmission of
the LSP in question). Upon receipt of this PSNP, the remote IS will think
that the adjacent IS possesses an LSP which is older than the same LSPID it
possesses in its local LSPDB (this is why the LSP Seq # is set to zero).
Consequently, the SRMflag for this LSPID entry within the local LSPDB never
gets cleared. Upon expiration of minimumLSPTransmissionInterval, this LSP is
transmitted to the adjacent IS. Upon receipt of this LSP, the receiving IS
sets the SSNflag so as to acknowledge receipt of this LSP. The LSPDBs should
now be synchronized, of course, that is if all other LSP Entries are also
processed properly.
So, if one or both of the CSNPs were to get dropped, the LSPDBs should
still get synchronized when minimumLSPTransmissionInterval expires. This is
because the SRMflags are set when ever a CSNP is generated on a PtP link.
Mike, does this make sense or am I just out in the weeds again?
Cheers,
Ken Larmer
CommSense Networks
------=_NextPart_000_000C_01C1A4BF.8162D010
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mike =
Shand=20
Wrote:
The heading is something of a misnomer here. The CSNP has NOTHING =
to do=20
with reliability in the case of a p2p circuit. (It does of =
course on a=20
broadcast circuit). On a P2P, the CSNP is simply an optimization which =
avoid the=20
need to flood the entire LSP database when the adjacency comes up =
between two=20
routers which already have (most of) the database. Reliability is of =
course=20
achieved by setting SRMflags on all LSPs when the circuit comes up and =
using=20
PSNPs to ACK.
Hi=20
Mike,
Doesn't a PSNP actually serve dual roles in this capacity, =
as a=20
request and as an acknowledgement?
=20
After a circuit restarts and we form an adjacency, ISH and IIH PDUs are=20
exchanged (not all implementations send ISH PDUs).=20
Next, some implementations transmit newly generated =
LSP(s) as a=20
result of the newly formed adjacency. By sending this LSP prior to =
issuing=20
a CSNP, this eliminates the need for the remote IS to issue a =
PSNP as=20
a request for this LSP and then issue a PSNP again as an =
acknowledgement=20
for this LSP. Next, both sides of the link set the SRMflag for all LSPs =
in the=20
appropriate LSP Ln Database, based on the adjacencyUsage (send =
these LSPs=20
upon expiration of minimumLSPTransmissionInterval). They then transmit a =
CSNP=20
with entries for all LSPs contained within the appropriate Ln LSPDB, =
regardless=20
of the SSNflag settings.
The receiving IS processes the newly received CSNP(s) and sets =
the=20
SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP =
LSP Entry=20
reference which is non-existent in the local LSPDB, it will create an =
entry in=20
its LSPDB with a LSP Seq # =3D zero. It next sets the SSNflag for this =
entry=20
(request this LSP from the remote adjacency). Once the =
partialSNPInterval timer=20
expires, the PSNP shall be transmitted to the remote IS (clear SSNflag =
for this=20
LSP entry upon successful transmission of the LSP in question). Upon =
receipt of=20
this PSNP, the remote IS will think that the adjacent IS possesses an =
LSP which=20
is older than the same LSPID it possesses in its local LSPDB (this is =
why the=20
LSP Seq # is set to zero). Consequently, the SRMflag for this LSPID =
entry within=20
the local LSPDB never gets cleared. Upon expiration of=20
minimumLSPTransmissionInterval, this LSP is transmitted to the adjacent =
IS. Upon=20
receipt of this LSP, the receiving IS sets the SSNflag so as to =
acknowledge=20
receipt of this LSP. The LSPDBs should now be synchronized, of course, =
that is=20
if all other LSP Entries are also processed =
properly.
So, if one or both of the CSNPs were to get dropped, the LSPDBs =
should=20
still get synchronized when minimumLSPTransmissionInterval expires. This =
is=20
because the SRMflags are set when ever a CSNP is generated on =
a PtP=20
link.
Mike, does this make sense or am I just out in =
the weeds=20
again?
Cheers,
Ken Larmer
CommSense Networks
------=_NextPart_000_000C_01C1A4BF.8162D010--
From sboddapa@hotmail.com Thu Jan 24 15:12:48 2002
From: sboddapa@hotmail.com (Suresh Boddapati)
Date: Thu, 24 Jan 2002 15:12:48
Subject: [Isis-wg] Making the update reliable
Message-ID:
The loss of the initial CSNP on ptop links causing inconsistent databases
per the three-way-handshake draft brings up a question. Once the adjacency
is up, why should CSNPs be sent only ONCE on ptop links? If the PSNPs are
serving as Acks on a ptop link, why not resend CSNPs for those LSPs that
have not been acked within a period of time, until all LSPs get acked and
the database is synchronized? Any new LSPs received in the meantime can
still be flooded normally. There is nothing in the state machine either that
precludes receiving CSNPs on ptop links at any point of time.
Regards,
Suresh
>From: Jeff Learman
>To: "Ramalingam, Swaminathan"
>CC: "'Koen Vermeulen'" , Isis-wg
>
>Subject: RE: [Isis-wg] Making the update reliable
>Date: Thu, 24 Jan 2002 08:25:55 -0500
>
>
>Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
>so the update reliability isn't there for PPP unless you also use the 3-way
>handshake. Fortunately, loss of the initial CNSP would only cause problems
>until every router had regenerated its LSP -- within 20 minutes using
>default
>LSP regen timer. See the 3-way draft for other problems that can happen
>because of running IS-IS over an unreliable link.
>
>Jeff
>
>At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
> >Keon,
> >
> >Whenever an adjacency comes up (may be because of start/restart) , CSNPs
>are sent on p2p links.You can't send control packets without adjacency.
> >
> >"Making the update reliable" means how the flooding made reliable using
>periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending
>CSNPs on p2p network when it start/restarts.
> >
> >- Swami
> >-----Original Message-----
> >From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
> >Sent: Wednesday, January 23, 2002 11:55 PM
> >To: Isis-wg
> >Subject: [Isis-wg] Making the update reliable
> >
> >Hello,
> >
> >I have a question concerning ISO/IEC 10589 7.3.17 'Making the
> >update reliable'. At the end of this section is written for
> >point-to-point circuits:
> >
> > When a point-to-point circuit (including non-DA DED circuits
> > and virtual links) starts (or restarts), the IS shall
> >
> > a) set SRMflag for that circuit on all LSPs, and
> >
> > b) send a Complete set of Complete Sequence Numbers PDUs
> > on that circuit.
> >
> >My question is now: what is actually meant with this
> >'start' (or 'restart') of a circuit? Do they mean an
> >adjacency state change to 'up', or is it really the circuit
> >which physically gets ready to send l2-frames?
> >If the second answer is what is meant, then I don't
> >understand why a CSNP is sent. This PDU will
> >be thrown away anyhow by the receiving side if there is
> >no adjacency (see 7.3.15.2 7:
> >
> > If the SNP is received on a non-broadcast circuit and
> > there is no adjacency of the same level (e.g. a level 1 SNP
> > with a level 1 or level 1 & 2 adjacency) on the circuit
> > over which the SNP was received, then the IS shall
> > discard the SNP without generating a event.
> >
> >).
> >So how can this mechanism make the update reliable? Or am I
> >missing something?
> >
> >Regards,
> >Koen
> >
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
From mshand@cisco.com Thu Jan 24 15:18:51 2002
From: mshand@cisco.com (mike shand)
Date: Thu, 24 Jan 2002 15:18:51 +0000
Subject: [Isis-wg] Making the update reliable
In-Reply-To:
References: <4.3.2.7.2.20020124082227.00b3be80@jaws.cisco.com>
Message-ID: <4.3.2.7.2.20020124151116.033c0e00@jaws.cisco.com>
At 10:11 24/01/2002 -0500, Ken Larmer wrote:
>Mike Shand Wrote:
>
>The heading is something of a misnomer here. The CSNP has NOTHING to do
>with reliability in the case of a p2p circuit. (It does of course on a
>broadcast circuit). On a P2P, the CSNP is simply an optimization which
>avoid the need to flood the entire LSP database when the adjacency comes
>up between two routers which already have (most of) the database.
>Reliability is of course achieved by setting SRMflags on all LSPs when the
>circuit comes up and using PSNPs to ACK.
>
>Hi Mike,
>
> Doesn't a PSNP actually serve dual roles in this capacity, as a
> request and as an acknowledgement?
Well, yes, but I didn't want to get into a complete description of the
operation of the update process. I was just pointing out the fact that the
CSNP was completely unnecessary for effective synchronization. Its function
is ONLY to attempt to limit the amount of LSP traffic exchanged.
>
> After a circuit restarts and we form an adjacency, ISH and IIH PDUs
> are exchanged (not all implementations send ISH PDUs). Next, some
> implementations transmit newly generated LSP(s) as a result of the newly
> formed adjacency. By sending this LSP prior to issuing a CSNP, this
> eliminates the need for the remote IS to issue a PSNP as a request for
> this LSP and then issue a PSNP again as an acknowledgement for this LSP.
> Next, both sides of the link set the SRMflag for all LSPs in the
> appropriate LSP Ln Database, based on the adjacencyUsage (send these LSPs
> upon expiration of minimumLSPTransmissionInterval). They then transmit a
> CSNP with entries for all LSPs contained within the appropriate Ln LSPDB,
> regardless of the SSNflag settings.
>
> The receiving IS processes the newly received CSNP(s) and sets the
> SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP
> LSP Entry reference which is non-existent in the local LSPDB, it will
> create an entry in its LSPDB with a LSP Seq # = zero. It next sets the
> SSNflag for this entry (request this LSP from the remote adjacency). Once
> the partialSNPInterval timer expires, the PSNP shall be transmitted to
> the remote IS (clear SSNflag for this LSP entry upon successful
> transmission of the LSP in question). Upon receipt of this PSNP, the
> remote IS will think that the adjacent IS possesses an LSP which is older
> than the same LSPID it possesses in its local LSPDB (this is why the LSP
> Seq # is set to zero). Consequently, the SRMflag for this LSPID entry
> within the local LSPDB never gets cleared.
Never is a bit strong!
>Upon expiration of minimumLSPTransmissionInterval, this LSP is transmitted
>to the adjacent IS.
possibly for the second time
> Upon receipt of this LSP, the receiving IS sets the SSNflag so as to
> acknowledge receipt of this LSP. The LSPDBs should now be synchronized,
> of course, that is if all other LSP Entries are also processed properly.
>
> So, if one or both of the CSNPs were to get dropped, the LSPDBs
> should still get synchronized when minimumLSPTransmissionInterval
> expires. This is because the SRMflags are set when ever a CSNP is
> generated on a PtP link.
Well, yes sort of. they are set whenever the adjacency goes up.
>
> Mike, does this make sense or am I just out in the weeds again?
It sounds a lot more complicated than what I said :-) I just didn't want to
get dragged down this hole. The whole point about the update process is
that it works correctly by magic. That's all you need to know :-) :-)
Mike
>
>Cheers,
>Ken Larmer
>CommSense Networks
From jlearman@cisco.com Thu Jan 24 15:58:06 2002
From: jlearman@cisco.com (Jeff Learman)
Date: Thu, 24 Jan 2002 10:58:06 -0500
Subject: [Isis-wg] Making the update reliable
In-Reply-To:
Message-ID: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com>
First of all, I think I made a mistake as evident from Mike S's reply.
Since flags are set for all LSPs, they would all be sent and the CSNP
is simply an optimization. The problem I referred to happens when only
one side resets on an unreliable link AND the initial CSNP is lost.
Without the 3-way handshake, if one side resets, the other side doesn't
set the flags. If it also doesn't receive the CSNP, it won't forward
any LSPs. This problem persists until every IS regens its LSP.
While this would be remedied more quickly using a periodic CSNP on
unreliable PTP links, the 3-way fixes this problem promptly and more
efficiently.
So I don't see any benefit to sending periodic CSNPs. It was worth
considering, though.
Regards,
Jeff
At 10:12 AM 1/24/2002, Suresh Boddapati wrote:
>The loss of the initial CSNP on ptop links causing inconsistent databases per the three-way-handshake draft brings up a question. Once the adjacency is up, why should CSNPs be sent only ONCE on ptop links? If the PSNPs are serving as Acks on a ptop link, why not resend CSNPs for those LSPs that have not been acked within a period of time, until all LSPs get acked and the database is synchronized? Any new LSPs received in the meantime can still be flooded normally. There is nothing in the state machine either that precludes receiving CSNPs on ptop links at any point of time.
>
>Regards,
>
>Suresh
>
>
>>From: Jeff Learman
>>To: "Ramalingam, Swaminathan"
>>CC: "'Koen Vermeulen'" , Isis-wg
>>Subject: RE: [Isis-wg] Making the update reliable
>>Date: Thu, 24 Jan 2002 08:25:55 -0500
>>
>>
>>Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
>>so the update reliability isn't there for PPP unless you also use the 3-way
>>handshake. Fortunately, loss of the initial CNSP would only cause problems
>>until every router had regenerated its LSP -- within 20 minutes using default
>>LSP regen timer. See the 3-way draft for other problems that can happen
>>because of running IS-IS over an unreliable link.
>>
>>Jeff
>>
>>At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
>>>Keon,
>>>
>>>Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency.
>>>
>>>"Making the update reliable" means how the flooding made reliable using
>>periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts.
>>>
>>>- Swami
>>>-----Original Message-----
>>>From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
>>>Sent: Wednesday, January 23, 2002 11:55 PM
>>>To: Isis-wg
>>>Subject: [Isis-wg] Making the update reliable
>>>
>>>Hello,
>>>
>>>I have a question concerning ISO/IEC 10589 7.3.17 'Making the
>>>update reliable'. At the end of this section is written for
>>>point-to-point circuits:
>>>
>>> When a point-to-point circuit (including non-DA DED circuits
>>> and virtual links) starts (or restarts), the IS shall
>>>
>>> a) set SRMflag for that circuit on all LSPs, and
>>>
>>> b) send a Complete set of Complete Sequence Numbers PDUs
>>> on that circuit.
>>>
>>>My question is now: what is actually meant with this
>>>'start' (or 'restart') of a circuit? Do they mean an
>>>adjacency state change to 'up', or is it really the circuit
>>>which physically gets ready to send l2-frames?
>>>If the second answer is what is meant, then I don't
>>>understand why a CSNP is sent. This PDU will
>>>be thrown away anyhow by the receiving side if there is
>>>no adjacency (see 7.3.15.2 7:
>>>
>>> If the SNP is received on a non-broadcast circuit and
>>> there is no adjacency of the same level (e.g. a level 1 SNP
>>> with a level 1 or level 1 & 2 adjacency) on the circuit
>>> over which the SNP was received, then the IS shall
>>> discard the SNP without generating a event.
>>>
>>>).
>>>So how can this mechanism make the update reliable? Or am I
>>>missing something?
>>>
>>>Regards,
>>>Koen
>>>
>
>
>
>
>_________________________________________________________________
>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
From dkatz@juniper.net Thu Jan 24 16:52:00 2002
From: dkatz@juniper.net (Dave Katz)
Date: Thu, 24 Jan 2002 08:52:00 -0800 (PST)
Subject: [Isis-wg] Making the update reliable
In-Reply-To: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com> (message
from Jeff Learman on Thu, 24 Jan 2002 08:25:55 -0500)
References: <4.3.2.7.2.20020124082204.01cfad48@dingdong.cisco.com>
Message-ID: <200201241652.g0OGq0835808@cirrus.juniper.net>
Additionally, some routers send periodic CSNPs on point-to-point links
by default.
X-Sender: jlearman@dingdong.cisco.com
From: Jeff Learman
Cc: "'Koen Vermeulen'" ,
Isis-wg
Content-Type: multipart/alternative;
boundary="=====================_27549323==_.ALT"
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, 24 Jan 2002 08:25:55 -0500
--=====================_27549323==_.ALT
Content-Type: text/plain; charset="us-ascii"
Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
so the update reliability isn't there for PPP unless you also use the 3-way
handshake. Fortunately, loss of the initial CNSP would only cause problems
until every router had regenerated its LSP -- within 20 minutes using default
LSP regen timer. See the 3-way draft for other problems that can happen
because of running IS-IS over an unreliable link.
Jeff
At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
>Keon,
>
>Whenever an adjacency comes up (may be because of start/restart) , CSNPs are sent on p2p links.You can't send control packets without adjacency.
>
>"Making the update reliable" means how the flooding made reliable using periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on p2p network when it start/restarts.
>
>- Swami
>-----Original Message-----
>From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
>Sent: Wednesday, January 23, 2002 11:55 PM
>To: Isis-wg
>Subject: [Isis-wg] Making the update reliable
>
>Hello,
>
>I have a question concerning ISO/IEC 10589 7.3.17 'Making the
>update reliable'. At the end of this section is written for
>point-to-point circuits:
>
> When a point-to-point circuit (including non-DA DED circuits
> and virtual links) starts (or restarts), the IS shall
>
> a) set SRMflag for that circuit on all LSPs, and
>
> b) send a Complete set of Complete Sequence Numbers PDUs
> on that circuit.
>
>My question is now: what is actually meant with this
>'start' (or 'restart') of a circuit? Do they mean an
>adjacency state change to 'up', or is it really the circuit
>which physically gets ready to send l2-frames?
>If the second answer is what is meant, then I don't
>understand why a CSNP is sent. This PDU will
>be thrown away anyhow by the receiving side if there is
>no adjacency (see 7.3.15.2 7:
>
> If the SNP is received on a non-broadcast circuit and
> there is no adjacency of the same level (e.g. a level 1 SNP
> with a level 1 or level 1 & 2 adjacency) on the circuit
> over which the SNP was received, then the IS shall
> discard the SNP without generating a event.
>
>).
>So how can this mechanism make the update reliable? Or am I
>missing something?
>
>Regards,
>Koen
>
--=====================_27549323==_.ALT
Content-Type: text/html; charset="us-ascii"
Keep in mind that in 10589, IS-IS requires reliable point-to-point
links,
so the update reliability isn't there for PPP unless you also use the
3-way
handshake. Fortunately, loss of the initial CNSP would only cause
problems
until every router had regenerated its LSP -- within 20 minutes using
default
LSP regen timer. See the 3-way draft for other problems that can
happen
because of running IS-IS over an unreliable link.
Jeff
At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
Keon,
Whenever an adjacency comes up
(may be because of start/restart) , CSNPs are sent on p2p links.You can't
send control packets without adjacency.
"Making the update
reliable" means how the flooding made reliable using periodic
CSNPs in bcast network, ack to PSNPs in p2p networks and sending CSNPs on
p2p network when it start/restarts.
- Swami
- -----Original Message-----
- From: Koen Vermeulen
[mailto:koen.vermeulen@alcatel.be]
- Sent: Wednesday, January 23, 2002 11:55 PM
- To: Isis-wg
- Subject: [Isis-wg] Making the update reliable
- Hello,
- I have a question concerning ISO/IEC 10589 7.3.17 'Making the
- update reliable'. At the end of this section is written for
- point-to-point circuits:
- When a point-to-point circuit (including non-DA DED circuits
- and virtual links) starts (or restarts), the IS shall
- a) set SRMflag for that circuit on all LSPs, and
- b) send a Complete set of Complete Sequence Numbers PDUs
- on that circuit.
- My question is now: what is actually meant with this
- 'start' (or 'restart') of a circuit? Do they mean an
- adjacency state change to 'up', or is it really the circuit
- which physically gets ready to send l2-frames?
- If the second answer is what is meant, then I don't
- understand why a CSNP is sent. This PDU will
- be thrown away anyhow by the receiving side if there is
- no adjacency (see 7.3.15.2 7:
- If the SNP is received on a non-broadcast circuit and
- there is no adjacency of the same level (e.g. a level 1 SNP
- with a level 1 or level 1 & 2 adjacency) on the circuit
- over which the SNP was received, then the IS shall
- discard the SNP without generating a event.
- ).
- So how can this mechanism make the update reliable? Or am I
- missing something?
- Regards,
- Koen
-
--=====================_27549323==_.ALT--
_______________________________________________
Isis-wg mailing list - Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg
From dkatz@juniper.net Thu Jan 24 16:54:37 2002
From: dkatz@juniper.net (Dave Katz)
Date: Thu, 24 Jan 2002 08:54:37 -0800 (PST)
Subject: [Isis-wg] Making the update reliable
In-Reply-To:
References:
Message-ID: <200201241654.g0OGsbR35811@cirrus.juniper.net>
It does server as a reliability mechanism when pruned flooding topologies
are used (so as to make sure that the flooding topology is not partitioned)
but it is only a last-ditch mechanism in this case.
From: "Ken Larmer"
Cc: "Ken Larmer" ,
"Isis-wg" ,
"'Koen Vermeulen'"
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_000C_01C1A4BF.8162D010"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
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, 24 Jan 2002 10:11:35 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C1A4BF.8162D010
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Mike Shand Wrote:
The heading is something of a misnomer here. The CSNP has NOTHING to do with
reliability in the case of a p2p circuit. (It does of course on a broadcast
circuit). On a P2P, the CSNP is simply an optimization which avoid the need
to flood the entire LSP database when the adjacency comes up between two
routers which already have (most of) the database. Reliability is of course
achieved by setting SRMflags on all LSPs when the circuit comes up and using
PSNPs to ACK.
Hi Mike,
Doesn't a PSNP actually serve dual roles in this capacity, as a request
and as an acknowledgement?
After a circuit restarts and we form an adjacency, ISH and IIH PDUs are
exchanged (not all implementations send ISH PDUs). Next, some
implementations transmit newly generated LSP(s) as a result of the newly
formed adjacency. By sending this LSP prior to issuing a CSNP, this
eliminates the need for the remote IS to issue a PSNP as a request for this
LSP and then issue a PSNP again as an acknowledgement for this LSP. Next,
both sides of the link set the SRMflag for all LSPs in the appropriate LSP
Ln Database, based on the adjacencyUsage (send these LSPs upon expiration of
minimumLSPTransmissionInterval). They then transmit a CSNP with entries for
all LSPs contained within the appropriate Ln LSPDB, regardless of the
SSNflag settings.
The receiving IS processes the newly received CSNP(s) and sets the
SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP LSP
Entry reference which is non-existent in the local LSPDB, it will create an
entry in its LSPDB with a LSP Seq # = zero. It next sets the SSNflag for
this entry (request this LSP from the remote adjacency). Once the
partialSNPInterval timer expires, the PSNP shall be transmitted to the
remote IS (clear SSNflag for this LSP entry upon successful transmission of
the LSP in question). Upon receipt of this PSNP, the remote IS will think
that the adjacent IS possesses an LSP which is older than the same LSPID it
possesses in its local LSPDB (this is why the LSP Seq # is set to zero).
Consequently, the SRMflag for this LSPID entry within the local LSPDB never
gets cleared. Upon expiration of minimumLSPTransmissionInterval, this LSP is
transmitted to the adjacent IS. Upon receipt of this LSP, the receiving IS
sets the SSNflag so as to acknowledge receipt of this LSP. The LSPDBs should
now be synchronized, of course, that is if all other LSP Entries are also
processed properly.
So, if one or both of the CSNPs were to get dropped, the LSPDBs should
still get synchronized when minimumLSPTransmissionInterval expires. This is
because the SRMflags are set when ever a CSNP is generated on a PtP link.
Mike, does this make sense or am I just out in the weeds again?
Cheers,
Ken Larmer
CommSense Networks
------=_NextPart_000_000C_01C1A4BF.8162D010
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mike =
Shand=20
Wrote:
The heading is something of a misnomer here. The CSNP has NOTHING =
to do=20
with reliability in the case of a p2p circuit. (It does of =
course on a=20
broadcast circuit). On a P2P, the CSNP is simply an optimization which =
avoid the=20
need to flood the entire LSP database when the adjacency comes up =
between two=20
routers which already have (most of) the database. Reliability is of =
course=20
achieved by setting SRMflags on all LSPs when the circuit comes up and =
using=20
PSNPs to ACK.
Hi=20
Mike,
Doesn't a PSNP actually serve dual roles in this capacity, =
as a=20
request and as an acknowledgement?
=20
After a circuit restarts and we form an adjacency, ISH and IIH PDUs are=20
exchanged (not all implementations send ISH PDUs).=20
Next, some implementations transmit newly generated =
LSP(s) as a=20
result of the newly formed adjacency. By sending this LSP prior to =
issuing=20
a CSNP, this eliminates the need for the remote IS to issue a =
PSNP as=20
a request for this LSP and then issue a PSNP again as an =
acknowledgement=20
for this LSP. Next, both sides of the link set the SRMflag for all LSPs =
in the=20
appropriate LSP Ln Database, based on the adjacencyUsage (send =
these LSPs=20
upon expiration of minimumLSPTransmissionInterval). They then transmit a =
CSNP=20
with entries for all LSPs contained within the appropriate Ln LSPDB, =
regardless=20
of the SSNflag settings.
The receiving IS processes the newly received CSNP(s) and sets =
the=20
SRMflags and SSNflags accordingly. If the receiving IS receives a CSNP =
LSP Entry=20
reference which is non-existent in the local LSPDB, it will create an =
entry in=20
its LSPDB with a LSP Seq # =3D zero. It next sets the SSNflag for this =
entry=20
(request this LSP from the remote adjacency). Once the =
partialSNPInterval timer=20
expires, the PSNP shall be transmitted to the remote IS (clear SSNflag =
for this=20
LSP entry upon successful transmission of the LSP in question). Upon =
receipt of=20
this PSNP, the remote IS will think that the adjacent IS possesses an =
LSP which=20
is older than the same LSPID it possesses in its local LSPDB (this is =
why the=20
LSP Seq # is set to zero). Consequently, the SRMflag for this LSPID =
entry within=20
the local LSPDB never gets cleared. Upon expiration of=20
minimumLSPTransmissionInterval, this LSP is transmitted to the adjacent =
IS. Upon=20
receipt of this LSP, the receiving IS sets the SSNflag so as to =
acknowledge=20
receipt of this LSP. The LSPDBs should now be synchronized, of course, =
that is=20
if all other LSP Entries are also processed =
properly.
So, if one or both of the CSNPs were to get dropped, the LSPDBs =
should=20
still get synchronized when minimumLSPTransmissionInterval expires. This =
is=20
because the SRMflags are set when ever a CSNP is generated on =
a PtP=20
link.
Mike, does this make sense or am I just out in =
the weeds=20
again?
Cheers,
Ken Larmer
CommSense Networks
------=_NextPart_000_000C_01C1A4BF.8162D010--
_______________________________________________
Isis-wg mailing list - Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg
From lliu@chiaro.com Thu Jan 24 22:23:49 2002
From: lliu@chiaro.com (Laura Liu)
Date: Thu, 24 Jan 2002 16:23:49 -0600
Subject: [Isis-wg] Questions on cird IDs in isis mib
Message-ID: <2383E22BDFF6D311BB8400B0D021A50701B94F77@MAIL>
--=_IS_MIME_Boundary
Content-Type: text/plain;
charset="iso-8859-1"
Hi Jeff,
I have another question on isis mib.
For those table index entries, they are defined as
MAX-ACCESS not-accessible
Does this mean, this entry cannot be access through snmp get command, are
they only used in part of oid?
thanks,
Laura
-----Original Message-----
From: Jeff Parker [mailto:jparker@axiowave.com]
Sent: Wednesday, January 23, 2002 1:33 PM
To: 'Laura Liu'
Cc: IS-IS-WG (E-mail)
Subject: RE: [Isis-wg] Questions on cird IDs in isis mib
> 1. isisCircIndex and isisCircIfIndex are defined as Integer32. My
> understanding is isisCircIndex refers to a logical id, while
isisCircIndex OBJECT-TYPE
SYNTAX Integer32 (1..2000000000)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The identifier of this circuit, unique within the
instance of the IS-IS protocol. This object follows
the index behavior. This is for SNMP Indexing
purposes only and need not have any relation to
any protocol value."
::= { isisCircEntry 1 }
So this can be an index into an array, a hash value, or
it could be the index of a port in your box.
However, many devices allow multiple circuits to
run over the same physical port, and would not
be able to use a physical port number as the index.
In brief, it is whatever you would like it to be.
It could be the same as isisCircIfIndex.
> isisCircIfIndex are the physical id of the
> interface to which this circuit corresponds.
isisCircIfIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The value of ifIndex for the interface to which this
circuit corresponds. This object cannot be modified
after creation"
::= { isisCircEntry 2 }
Nope, this is the MIB II IfIndex. There are rules
about doling this out. What we're trying to do here
is to have a value that lines up with the value of
the manager will see in the Interface table.
> 2. isisCircLocalID is Integer32(0..255), is the locally
> assigned one octet
> Local Circuit ID used for "maintaining more than 255 circuits
> in IS-IS".
isisCircLocalID OBJECT-TYPE
SYNTAX Integer32(0..255)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An identification that can be used in protocol packets
to identify a circuit. Values of isisCircLocalID do
not need to be unique. They are only required to differ
on LANs where the Intermediate System is the Designated
Intermediate System."
::= { isisCircEntry 4 }
The MIB does not try to address the issue of how to
maintain a presence as the DIS on more than 256 LANs.
Briefly, this is the octet that you use to augment
the system ID to provide a unique PNodeID. This can
be related to one of the other indicies, or can be
independent. The implementer gets to allocate this.
> Another question, there is isisCircLevelDesIS object, it only
> report the
> DR's system ID part. How can I retrieve the circuit ID part
> of DR's LAN ID?
>
> please help, and thanks!
>
> Laura
Laura -
I think that is an error: thanks for catching that.
The syntax should be an octet string of length 7 or 0.
isisCircLevelDesIS OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..7))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ID of the LAN Designated Intermediate System
on this circuit at this level. If, for any reason,
this system is not partaking in the relevant
Designated Intermediate System election process,
then the value returned is the zero length OCTET STRING."
REFERENCE "{ISIS.aoi l2DesignatedIntermediateSystem (75)}"
::= { isisCircLevelEntry 4 }
- jeff parker
- axiowave networks
--=_IS_MIME_Boundary
Content-Type: text/plain;charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
----------------------------------------- (on Chiaro SMTP Relay)
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.
---------------------------------------------------------
--=_IS_MIME_Boundary--
From dhudek@ma.ultranet.com Thu Jan 24 23:20:58 2002
From: dhudek@ma.ultranet.com (David Hudek)
Date: Thu, 24 Jan 2002 18:20:58 -0500
Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-04.txt
Message-ID: <3C5096DA.C8B51ED@ma.ultranet.com>
I have a comment/concern about the current description of
subTLV 6 (IPv4 Iface Addr) in the new TLV type 22
(Extended IS Reach) assuming that the doc is intended
to cover unnumbered point to point interfaces as well
as numbered interfaces (did not see any scope statement
which restricted it to numbered only?)
If one is supporting traffic engineering, the doc currently
specifies that subTLV6 is mandatory... but on an unnumbered
interface by definition there is no IPv4 address, and
one would not have a valid IPv4 Iface Addr to place
in this mandatory subTLV.
There is stuff in draft-ietf-isis-gmpls-extensions-04
which provides a means of exchanging interface IDs
(in the Hellos) applicable to unnumbered p2p's, and
new subTLVs for TLV type 22 to convey iface IDs...
I presume that is the intended behavior for unnumbered p2p's.
It seems like the text for subTLV6 should state that
if one is supporting traffic engineering, subTLV 6
is only mandatory for numbered interfaces and must not
be used for unnumbered P2Ps (and possibly give a pointer to
the gmpls extensions doc).
Thanks,
dave hudek
dhudek@ma.ultranet.com
From tli@procket.com Fri Jan 25 02:53:36 2002
From: tli@procket.com (Tony Li)
Date: Thu, 24 Jan 2002 18:53:36 -0800
Subject: [Isis-wg] Comment on draft-ietf-isis-traffic-04.txt
In-Reply-To: <3C5096DA.C8B51ED@ma.ultranet.com>
References: <3C5096DA.C8B51ED@ma.ultranet.com>
Message-ID: <15440.51376.725664.842316@alpha-tli.procket.com>
We were only supporting numbered interfaces.
Tony
David Hudek writes:
|
| I have a comment/concern about the current description of
| subTLV 6 (IPv4 Iface Addr) in the new TLV type 22
| (Extended IS Reach) assuming that the doc is intended
| to cover unnumbered point to point interfaces as well
| as numbered interfaces (did not see any scope statement
| which restricted it to numbered only?)
|
| If one is supporting traffic engineering, the doc currently
| specifies that subTLV6 is mandatory... but on an unnumbered
| interface by definition there is no IPv4 address, and
| one would not have a valid IPv4 Iface Addr to place
| in this mandatory subTLV.
|
| There is stuff in draft-ietf-isis-gmpls-extensions-04
| which provides a means of exchanging interface IDs
| (in the Hellos) applicable to unnumbered p2p's, and
| new subTLVs for TLV type 22 to convey iface IDs...
| I presume that is the intended behavior for unnumbered p2p's.
|
| It seems like the text for subTLV6 should state that
| if one is supporting traffic engineering, subTLV 6
| is only mandatory for numbered interfaces and must not
| be used for unnumbered P2Ps (and possibly give a pointer to
| the gmpls extensions doc).
|
| Thanks,
| dave hudek
| dhudek@ma.ultranet.com
| _______________________________________________
| Isis-wg mailing list - Isis-wg@external.juniper.net
| http://external.juniper.net/mailman/listinfo/isis-wg
| _______________________________________________
| Isis-wg-external mailing list
| Isis-wg-external@mailist.procket.com
| http://mailist.procket.com/mailman/listinfo/isis-wg-external
From sachidananda_k@hotmail.com Fri Jan 25 05:36:18 2002
From: sachidananda_k@hotmail.com (Sachidananda K)
Date: Fri, 25 Jan 2002 05:36:18 +0000
Subject: [Isis-wg] CSNP from Designated IS
Message-ID:
Hi All,
When an intermediate system just comes up on a broadcast circuit it would
typically not be having any LSPs in its database. Co-incidently, if this IS
happens to be the designated IS for that broadcast circuit, then what start
LSP ID and the end LSP ID shall be put in the CSNP constructed by this IS?
To be more generic, how can we ensure that this new IS's database is
synchronised with that of all the othre IS's in the LAN?
Thanking you in advance for all the responses.
Sachi.
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
From tli@Procket.com Fri Jan 25 05:47:19 2002
From: tli@Procket.com (Tony Li)
Date: Thu, 24 Jan 2002 21:47:19 -0800
Subject: [Isis-wg] CSNP from Designated IS
In-Reply-To:
References:
Message-ID: <15440.61799.591910.482779@alpha-tli.procket.com>
| When an intermediate system just comes up on a broadcast circuit it would
| typically not be having any LSPs in its database.
It should generate at least its own, even if it doesn't have any adjacencies.
| Co-incidently, if this IS
| happens to be the designated IS for that broadcast circuit, then what start
| LSP ID and the end LSP ID shall be put in the CSNP constructed by this IS?
Then it should also generate a pseudo-node LSP. The CSNP should contain
the full range of the database from LSP ID 0 (zero) to the all-ones LSP ID.
| To be more generic, how can we ensure that this new IS's database is
| synchronised with that of all the othre IS's in the LAN?
It should send out CSNPs. Anyone disagreeing should speak up.
Tony
From swaminathanr@netplane.com Fri Jan 25 06:28:17 2002
From: swaminathanr@netplane.com (Ramalingam, Swaminathan)
Date: Fri, 25 Jan 2002 01:28:17 -0500
Subject: [Isis-wg] CSNP from Designated IS
Message-ID:
comments inlined
> -----Original Message-----
> From: Tony Li [mailto:tli@procket.com]
> Sent: Friday, January 25, 2002 11:17 AM
> To: Sachidananda K
> Cc: isis-wg@spider.juniper.net
> Subject: [Isis-wg] CSNP from Designated IS
>
>
>
>
> | When an intermediate system just comes up on a broadcast
> circuit it would
> | typically not be having any LSPs in its database.
>
>
> It should generate at least its own, even if it doesn't have
> any adjacencies.
>
>
> | Co-incidently, if this IS
> | happens to be the designated IS for that broadcast
> circuit, then what start
> | LSP ID and the end LSP ID shall be put in the CSNP
> constructed by this IS?
>
>
> Then it should also generate a pseudo-node LSP. The CSNP
> should contain
> the full range of the database from LSP ID 0 (zero) to the
> all-ones LSP ID.
>
>
> | To be more generic, how can we ensure that this new IS's
> database is
> | synchronised with that of all the othre IS's in the LAN?
>
>
> It should send out CSNPs. Anyone disagreeing should speak up.
>
>
Adding to Tony's reply, DIS sends out CSNPs. When the receiver finds DIS is
out of date, it will multicast the missing information (so that other IS
receiving CSNP will not send again).
If DIS has new information, the receiving IS multicast PSNP for missing
information.Here only DIS should send the missing info, others should not.
Hope this helps
~ Swami
> Tony
> _______________________________________________
> Isis-wg mailing list - Isis-wg@external.juniper.net
> http://external.juniper.net/mailman/listinfo/isis-wg
>
From naiming@redback.com Fri Jan 25 06:33:57 2002
From: naiming@redback.com (Naiming Shen)
Date: Thu, 24 Jan 2002 22:33:57 -0800
Subject: [Isis-wg] Making the update reliable
In-Reply-To: Mail from "Suresh Boddapati"
dated Thu, 24 Jan 2002 15:12:48
Message-ID: <20020125063357.9028A4BA219@prattle.redback.com>
] The loss of the initial CSNP on ptop links causing inconsistent databases
] per the three-way-handshake draft brings up a question. Once the adjacency
] is up, why should CSNPs be sent only ONCE on ptop links? If the PSNPs are
] serving as Acks on a ptop link, why not resend CSNPs for those LSPs that
] have not been acked within a period of time, until all LSPs get acked and
] the database is synchronized? Any new LSPs received in the meantime can
] still be flooded normally. There is nothing in the state machine either that
] precludes receiving CSNPs on ptop links at any point of time.
]
True. But it does not seem to help much if you keep sending CSNPs either.
In the case no 3way hello is running, the first CSNP is lost, and
the link becomes unidirectional, no matter how many CSNPs being
sent later on, the two sides still can not syncronize, or it does get
syncronized but one side will keep sending out LSPs due to no Ack
back from the peer.
In the case of the link being bidirectional, the initial CSNP got lost.
All LSPs will be sent over the link, and the other side has to send back
the PSNPs to Ack. Say A->B csnp is lost, B has to send all its LSPs to A.
A has to response with PSNPs. Even A keeps sending csnps to B, A still
need to send those PSNPs. And they basically contain the same info: don't
send them anymore!
It does seem to help, if before you send any LSPs, just send a couple
of CSNP sets fast, hopefully one set gets through. Or PSNP also be able to
Ack the CSNPs received, so both sides are sure CSNPs get through fine.
But it does seem over optimization. And it only matters when two
isolated portion of the network being first brought up through this p2p
link. It does not sound like in a fast reroute of the VoIP traffic case;-)
So just let it take some time, allow all the LSPs take their own pace
through the poor p2p link...
] Regards,
]
] Suresh
]
]
] >From: Jeff Learman
] >To: "Ramalingam, Swaminathan"
] >CC: "'Koen Vermeulen'" , Isis-wg
] >
] >Subject: RE: [Isis-wg] Making the update reliable
] >Date: Thu, 24 Jan 2002 08:25:55 -0500
] >
] >
] >Keep in mind that in 10589, IS-IS requires reliable point-to-point links,
] >so the update reliability isn't there for PPP unless you also use the 3-way
] >handshake. Fortunately, loss of the initial CNSP would only cause problems
] >until every router had regenerated its LSP -- within 20 minutes using
] >default
] >LSP regen timer. See the 3-way draft for other problems that can happen
] >because of running IS-IS over an unreliable link.
] >
] >Jeff
] >
] >At 02:12 AM 1/24/2002, Ramalingam, Swaminathan wrote:
] > >Keon,
] > >
] > >Whenever an adjacency comes up (may be because of start/restart) , CSNPs
] >are sent on p2p links.You can't send control packets without adjacency.
] > >
] > >"Making the update reliable" means how the flooding made reliable using
] >periodic CSNPs in bcast network, ack to PSNPs in p2p networks and sending
] >CSNPs on p2p network when it start/restarts.
] > >
] > >- Swami
] > >-----Original Message-----
] > >From: Koen Vermeulen [mailto:koen.vermeulen@alcatel.be]
] > >Sent: Wednesday, January 23, 2002 11:55 PM
] > >To: Isis-wg
] > >Subject: [Isis-wg] Making the update reliable
] > >
] > >Hello,
] > >
] > >I have a question concerning ISO/IEC 10589 7.3.17 'Making the
] > >update reliable'. At the end of this section is written for
] > >point-to-point circuits:
] > >
] > > When a point-to-point circuit (including non-DA DED circuits
] > > and virtual links) starts (or restarts), the IS shall
] > >
] > > a) set SRMflag for that circuit on all LSPs, and
] > >
] > > b) send a Complete set of Complete Sequence Numbers PDUs
] > > on that circuit.
] > >
] > >My question is now: what is actually meant with this
] > >'start' (or 'restart') of a circuit? Do they mean an
] > >adjacency state change to 'up', or is it really the circuit
] > >which physically gets ready to send l2-frames?
] > >If the second answer is what is meant, then I don't
] > >understand why a CSNP is sent. This PDU will
] > >be thrown away anyhow by the receiving side if there is
] > >no adjacency (see 7.3.15.2 7:
] > >
] > > If the SNP is received on a non-broadcast circuit and
] > > there is no adjacency of the same level (e.g. a level 1 SNP
] > > with a level 1 or level 1 & 2 adjacency) on the circuit
> > over which the SNP was received, then the IS shall
] > > discard the SNP without generating a event.
] > >
] > >).
] > >So how can this mechanism make the update reliable? Or am I
] > >missing something?
] > >
] > >Regards,
] > >Koen
] > >
]
]
]
]
] _________________________________________________________________
] Chat with friends online, try MSN Messenger: http://messenger.msn.com
]
] _______________________________________________
] Isis-wg mailing list - Isis-wg@external.juniper.net
] http://external.juniper.net/mailman/listinfo/isis-wg
- Naiming
From naiming@redback.com Fri Jan 25 06:44:12 2002
From: naiming@redback.com (Naiming Shen)
Date: Thu, 24 Jan 2002 22:44:12 -0800
Subject: [Isis-wg] CSNP from Designated IS
In-Reply-To: Mail from Tony Li
dated Thu, 24 Jan 2002 21:47:19 PST
<15440.61799.591910.482779@alpha-tli.procket.com>
Message-ID: <20020125064412.658FBCAB70@prattle.redback.com>
] | To be more generic, how can we ensure that this new IS's database is
] | synchronised with that of all the othre IS's in the LAN?
]
]
] It should send out CSNPs. Anyone disagreeing should speak up.
yes. this one is the DR, sending out csnp is all he can do. basically
he is saying "I know for sure there is no LSPs except my own", then all
the other ISs on the LAN saying "you are wrong, here is ours", then they
supply the DR with their LSPs. then the DR gets all the LSPs simply
by being wrong. what a nice protocol.
]
]
] Tony
- Naiming
From dasnabendu@yahoo.com Fri Jan 25 07:34:09 2002
From: dasnabendu@yahoo.com (nabendu das)
Date: Thu, 24 Jan 2002 23:34:09 -0800 (PST)
Subject: [Isis-wg] checksum calculation doubt
Message-ID: <20020125073409.46690.qmail@web13201.mail.yahoo.com>
hello all,
As per ISO-10589 7.3.11(Generation of checksum)
" An IS shall start with C0 & C1 initialised to what
they would be after computing for the systemID portion
of its Source ID, The IS shall then resume Checksum
computation on the contents of the PDU after the first
ID Length octets of the Source ID field,"
& in NOTE" All checksum calculations on the LSP are
performed treating the Source ID field as the first
octet. This procedure prevents the source from
accidentally sending out LSP with some other system'd
ID as source"
Now the Question is while generating the checksum what
will happen if we do not initailize C0 & C1 to the
computed checksum of the System ID portion of Source
ID, what will be the problem if we initialize C0 & C1
to zero, as ISO document anyway is saying to
initialize C0 & C1 to the calclated value of the
checksum of System ID portion of the Source ID & then
to resume checksum calculation on the contents of the
PDU after the first ID Length octets of the Source ID
field.
And when a router receives an LSP, how should it
verify, should it start from the LSPID field because
"All checksum calculations on the LSP are performed
treating the Source ID field as the first octet." is
bit ambiguous, how can we take Source ID field as
first octet as it is of 6 octets, Does it mean to
start from the first Octet of the LSPID portion.
__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
From dkatz@juniper.net Fri Jan 25 08:00:49 2002
From: dkatz@juniper.net (Dave Katz)
Date: Fri, 25 Jan 2002 00:00:49 -0800 (PST)
Subject: [Isis-wg] Making the update reliable
In-Reply-To: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> (message
from Jeff Learman on Thu, 24 Jan 2002 10:58:06 -0500)
References: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com>
Message-ID: <200201250800.g0P80nZ37529@cirrus.juniper.net>
So I don't see any benefit to sending periodic CSNPs. It was worth
considering, though.
We send 'em anyhow. I think I made the cisco code do the same thing,
but it's been a lot of years. Or maybe you can just configure it
on the cisco box, I don't remember offhand.
Cheap insurance when working with the ill-named mesh groups.
--Dave
From mshand@cisco.com Fri Jan 25 18:06:44 2002
From: mshand@cisco.com (mike shand)
Date: Fri, 25 Jan 2002 18:06:44 +0000
Subject: [Isis-wg] checksum calculation doubt
In-Reply-To: <20020125073409.46690.qmail@web13201.mail.yahoo.com>
Message-ID: <4.3.2.7.2.20020125175100.033cb130@jaws.cisco.com>
At 23:34 24/01/2002 -0800, nabendu das wrote:
>hello all,
>
>As per ISO-10589 7.3.11(Generation of checksum)
>" An IS shall start with C0 & C1 initialised to what
>they would be after computing for the systemID portion
>of its Source ID, The IS shall then resume Checksum
>computation on the contents of the PDU after the first
>ID Length octets of the Source ID field,"
>
>& in NOTE" All checksum calculations on the LSP are
>performed treating the Source ID field as the first
>octet. This procedure prevents the source from
>accidentally sending out LSP with some other system'd
>ID as source"
>
>Now the Question is while generating the checksum what
>will happen if we do not initailize C0 & C1 to the
>computed checksum of the System ID portion of Source
>ID, what will be the problem if we initialize C0 & C1
>to zero, as ISO document anyway is saying to
>initialize C0 & C1 to the calclated value of the
>checksum of System ID portion of the Source ID & then
>to resume checksum calculation on the contents of the
>PDU after the first ID Length octets of the Source ID
>field.
As I recall, the idea was that the router's checksum code knew what the
system ID was supposed to be (it was initialized when the router was
booted). So if when generating the LSP, it accidentally put the wrong
source ID, or more likely if the LSP somehow got corrupted as it was being
built, the LSP would get sent out with a bogus checksum and so would be
ignored.
The protection it gives is I think marginal, and I'm not sure it is very
important. In fact it is arguable whether it should appear in the standard
at all, since it is not possible to tell by looking at the packet whether
it is being done or not. I suppose one could try installing flakey RAM in
the router and seeing if it does the wrong thing?
However, this is similar to statements that you must not recompute the
checksum of an IP packet when you change it, but should rather use an
incremental checksum modifier, hence giving protection between the time
that the packet is received (and the checksum verified) and when it is
modified. Again, its very hard to tell if you are doing this right, but it
is still a good idea to do it.
But perhaps Radia has stronger opinions on this one, since I think it was
her idea.
>And when a router receives an LSP, how should it
>verify, should it start from the LSPID field because
>"All checksum calculations on the LSP are performed
>treating the Source ID field as the first octet." is
>bit ambiguous, how can we take Source ID field as
>first octet as it is of 6 octets, Does it mean to
>start from the first Octet of the LSPID portion.
From the start of the source ID, i.e. octet 13 counting the first octet as
octet one.
>__________________________________________________
>Do You Yahoo!?
>Great stuff seeking new owners in Yahoo! Auctions!
>http://auctions.yahoo.com
>_______________________________________________
>Isis-wg mailing list - Isis-wg@external.juniper.net
>http://external.juniper.net/mailman/listinfo/isis-wg
From naiming@redback.com Fri Jan 25 18:14:10 2002
From: naiming@redback.com (Naiming Shen)
Date: Fri, 25 Jan 2002 10:14:10 -0800
Subject: [Isis-wg] Making the update reliable
In-Reply-To: Mail from "Ken Larmer"
dated Fri, 25 Jan 2002 10:06:21 EST
Message-ID: <20020125181410.2B18B262804@prattle.redback.com>
I was referring to how much useful if one send repeated resend CSNPs.
My understanding is: very little, why bother.
] Naiming Wrote:
]
] > In the case no 3way hello is running, the first CSNP is lost, and
] > the link becomes unidirectional, no matter how many CSNPs being
] > sent later on, the two sides still can not syncronize, or it does get
] > syncronized but one side will keep sending out LSPs due to no Ack
] > back from the peer.
I think I had the second paragraph from 3way draft below in mind,
which is the link came up, the initial CSNP got lost and also the
link became unidirectional.
----->--- X ------
A B
-----<------------
in the above diagram, the connection from A to B is down, but from
B to A is up.
Assume both sides are out of sync.
1) A -> B initial csnp is lost
well, the link is down, no matter how many CSNPs A trys to resend,
obviously they are wasted.
2) B -> A initial csnp is lost
If B do not resend CSNP, A will try to send all its LSPs over the
broken link and get lost. If B do resend CSNPs, A will only try to
resend partial of its LSPs, and all get lost.
So it does not matter CSNPs get resend or not. Actually, if a link
is unidirectional, out sync maybe is better, since it can be
noticed by operators sooner.
If A and B has parallel links, then both sides are always synced,
assume the other link is ok, then resend or not of CSNP does not
matter either.
These days, one can hardly find any routers do not do 3way by
default, so its not a very interesting subject; for 3way draft,
it is THE subject.
]
] >In the case of the link being bidirectional, the initial CSNP got lost.
] >All LSPs will be sent over the link, and the other side has to send back
] >the PSNPs to Ack. Say A->B csnp is lost, B has to send all its LSPs to A.
] >A has to response with PSNPs. Even A keeps sending csnps to B, A still
] >need to send those PSNPs. And they basically contain the same info: don't
] >send them anymore!
----->------------
A B
-----<------------
borrow the same diagram, only the link is good, bi-directional.
but this has no relation with the 3way draft.
If A -> B initial CSNP is lost. B has to send all its LSPs over this
link to A. Due to the Ack mechanism, A needs to send PSNPs to ack those
LSPs from B, or send its LSPs to B if they are more recent. This is
what A has to do after receiving LSPs from B. This is regardless of
B resend CSNPs to A or not. Which means those resent CSNPs are wasted.
The only time it seems to help for repeated resending CSNPs seems
if both side initial CSNPs get lost, and also some of the LSPs
also get lost during the transmission. Then resend CSNPs can
reduce keep resending those lost LSPs which has no need to sync
on both sides in the first place. So its just an optimization.
That's why I suggested some "over-optimization" steps before
sending out your LSPs over this link:
- at link comes up, keep sending a couple of sets CSNP, hope
at least one set gets through.
- have some kind of Ack for p2p initial CSNPs.
But this is not without a price to pay, obviously any one of
those will delay the sending out LSPs, which will delay the
network convergence.
]
] Hi Naming, can you please explain the two scenarios above in more detail?
] Are they the same as the scenarios referenced in the "Three-Way Handshake
] for IS-IS Point-to-Point Adjacencies" draft as referenced below:
]
] Three failure modes are known. First, if the link goes down and then
] comes back up, or one of the systems restarts, and the CSNP packet is
] lost, and the network has a cut set of one through the link, the link
] state databases on either side of the link will not synchronize for a
] full LSP refresh period (up to eighteen hours).
]
] A second, more serious failure, is that if the link fails in only one
] direction, the failure will only be detected by one of the systems.
] Normally, this is not a serious issue; only one of the two systems
] will announce the adjacency in its link state packets, and the SPF
] algorithm will thus ignore the link. However, if there are two
] parallel links between systems and one of them fails in one
] direction, SPF will still calculate paths between the two systems,
] and the system that does not notice the failure will attempt to pass
] traffic down the failed link (in the direction that does not work).
]
] The third issue is that on some physical layers, the
] interconnectivity between endpoints can change without causing a
] link-layer-down condition. In this case, a system may receive packets
] that are actually destined for a different system (or a different
] link on the same system). The receiving system may end up thinking
] that it has an adjacency with the remote system when in fact the
] remote system is adjacent with a third system.
]
]
] Cheers,
] Ken Larmer
] CommSense Networks
]
]
- Naiming
From naiming@redback.com Fri Jan 25 18:24:55 2002
From: naiming@redback.com (Naiming Shen)
Date: Fri, 25 Jan 2002 10:24:55 -0800
Subject: [Isis-wg] Making the update reliable
In-Reply-To: Mail from Dave Katz
dated Fri, 25 Jan 2002 00:00:49 PST
<200201250800.g0P80nZ37529@cirrus.juniper.net>
Message-ID: <20020125182455.7D1D01531CB@prattle.redback.com>
] So I don't see any benefit to sending periodic CSNPs. It was worth
] considering, though.
Yes. I was just referring to the case at initial stage of syncing up, I don't
see a reason of lots of CSNPs flowing through.
But send them periodically, say once every 15 minutes may not be a
bad network insurance approach. Especially the router software is just
upgraded:-)
]
] We send 'em anyhow. I think I made the cisco code do the same thing,
] but it's been a lot of years. Or maybe you can just configure it
] on the cisco box, I don't remember offhand.
]
] Cheap insurance when working with the ill-named mesh groups.
Yes, its definitely recommended if the link is configured as
mesh-group blocking lsps. Then periodically exchange of CSNPs
over the p2p links makes lots of sense. But again, you were
the one created those problems at the first place...
]
] --Dave
- Naiming
From jharper@cisco.com Fri Jan 25 19:13:58 2002
From: jharper@cisco.com (John Harper)
Date: Fri, 25 Jan 2002 11:13:58 -0800
Subject: [Isis-wg] checksum calculation doubt
In-Reply-To: <4.3.2.7.2.20020125175100.033cb130@jaws.cisco.com>
References: <20020125073409.46690.qmail@web13201.mail.yahoo.com>
Message-ID: <4.3.2.7.2.20020125111331.03fbfaf0@jaws.cisco.com>
Nah, I bet you dinner it was Tony. This is exactly the kind of thing he got
excited
about.
John
At 18:06 25/01/2002 +0000, mike shand wrote:
>But perhaps Radia has stronger opinions on this one, since I think it was
>her idea.
From tli@Procket.com Fri Jan 25 19:29:13 2002
From: tli@Procket.com (Tony Li)
Date: Fri, 25 Jan 2002 11:29:13 -0800
Subject: [Isis-wg] Making the update reliable
In-Reply-To: <200201250800.g0P80nZ37529@cirrus.juniper.net>
References: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com>
<200201250800.g0P80nZ37529@cirrus.juniper.net>
Message-ID: <15441.45577.649058.450053@alpha-tli.procket.com>
| So I don't see any benefit to sending periodic CSNPs. It was worth
| considering, though.
|
| We send 'em anyhow. I think I made the cisco code do the same thing,
| but it's been a lot of years. Or maybe you can just configure it
| on the cisco box, I don't remember offhand.
|
| Cheap insurance when working with the ill-named mesh groups.
I'd say they're damn cheap insurance period. But then I was always a belt
and suspenders kinda guy.
Tony
From jparker@axiowave.com Fri Jan 25 14:49:43 2002
From: jparker@axiowave.com (Jeff Parker)
Date: Fri, 25 Jan 2002 09:49:43 -0500
Subject: [Isis-wg] Questions on cird IDs in isis mib
Message-ID:
> For those table index entries, [that] are defined as
>
> MAX-ACCESS not-accessible
>
> Does this mean, this entry cannot be access through
> snmp get command, are they only used in part of oid?
>
> Laura
I believe you are right. They -can- be discovered
through a get-next walk of the table.
- jeff parker
From Radia Perlman - Boston Center for Networking Sat Jan 26 04:43:59 2002
From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking)
Date: Fri, 25 Jan 2002 23:43:59 -0500 (EST)
Subject: [Isis-wg] checksum calculation doubt
Message-ID: <200201260443.XAA07143@bcn.East.Sun.COM>
Yeah, I think Mike owes you dinner, John. I may have typed the words in, but
it was Tony that got excited about that sort of stuff, and it was his
idea. It seemed harmless to put it in. Obviously it
doesn't prevent malicious errors. I suspect that in all the years of
running IS-IS it didn't catch any accidental errors, either, but who knows.
Was the quoted text correct, by the way? "treating the source ID
field as the first octet" Wouldn't it be the first 6 octets (oh yeah,
the ID-length number of octets)?
And without looking at the packet format, I assume that the first
thing in the packet must be the source ID? Otherwise you'd get a different
checksum if you just ignore that text and do the checksum from the beginning
and initialize to 0. If the first thing is the source ID (it must be),
then starting after the source ID, with the value that the checksum would
be at that point, and starting at the beginning with checksums initialized
to 0 would be the same answer, and as Mike pointed out, you'd never
be able to detect from the outside of the box which strategy the router
was doing.
I could claim I was saving computation because the checksum could be
precomputed for the first 6 bytes. :-)
Radia
>>John Harper said:
>> Nah, I bet you dinner it was Tony. This is exactly the kind of thing he
got
>> excited
>> about.
At 18:06 25/01/2002 +0000, mike shand wrote:
>But perhaps Radia has stronger opinions on this one, since I think it
was
>her idea.
_______________________________________________
Isis-wg mailing list - Isis-wg@external.juniper.net
http://external.juniper.net/mailman/listinfo/isis-wg
From prz@redback.com Sat Jan 26 06:30:34 2002
From: prz@redback.com (Tony Przygienda)
Date: Fri, 25 Jan 2002 22:30:34 -0800
Subject: [Isis-wg] last call on draft-ietf-isis-wg-tlv-codepoints-01
Message-ID: <3C524D0A.49EAA9D4@redback.com>
We are starting last call on draft-ietf-isis-wg-tlv-codepoints-01. The last call will end 2/9/02
thanks
-- tony
From Chaitanya77@postmark.net Sat Jan 26 14:19:37 2002
From: Chaitanya77@postmark.net (Chaitanya Huilgol)
Date: Sat, 26 Jan 2002 14:19:37 +0000
Subject: [Isis-wg] SPF optimization
Message-ID: <20020126141937.2979.qmail@venus.postmark.net>
hi all
I have a Question regarding addition of IP reachability entries
in to the forwarding database, without recomputation of SPF.
ref rfc1195 AnnexC:
3) If only End System LSP information has changed,it is not
necessary to recompute the entire Dijkstra tree. If the proper
data structures are used, End Systems (including IP reachability
entries) may be attached and detached as leaves of the tree and
their forwarding information base entries altered as appropriate.
-- I believe IF the IP reachibality entries are taken from a static
Table
there is very little chance of such a change in info.
now my question is
(1)If an IS advertise a new IP reachability, How can you be
sure that the shortest PATH to this network is through this IS.
it is quite possible that a route already exists with a
smaller/larger
cost through another IS in the forwarding database.
(2)Again if you want to remove an entry how can be sure that the path
was calculated through the IS.
for Eg:
10 10
R1------R2------R3
| |--IP/24
| 10 |
|---------------R4
if R1 runs SPF.route to IP/24 through R4
later if R3 reports IP/24..How do u Know that the entry
in forwarding database was through R4 which is the shortest
and you should not replace.
--In case R3 and R4 have advertised IP/24
and R1 calculates path through R4
and then R3 dose not advertise IP/24
--you should not be removing the entry for the forwarding DB
---finally do the implementations support this optimization.
---------------------------------------------
Chaitanya Huilgol.
Chaitanya77@postmark.net
B.M.S college of Engineering.
Bangalore,India.
---------------------------------------------
From sachidananda_k@hotmail.com Mon Jan 28 08:35:54 2002
From: sachidananda_k@hotmail.com (Sachidananda K)
Date: Mon, 28 Jan 2002 08:35:54 +0000
Subject: [Isis-wg] CSNP from Designated IS
Message-ID:
Thank you for the clarification.
I would like to know as to, whether is it permissible to keep the start LSP
ID of the first CSNP as all 0's and the end LSP ID of the last CSNP packet
as all 1's in a complete set of CSNP.
Thanking you in advance for the clarification.
Regards,
Sachi.
----Original Message Follows----
From: "Ramalingam, Swaminathan"
To: Sachidananda K
CC: isis-wg@spider.juniper.net, "'Tony Li'"
Subject: RE: [Isis-wg] CSNP from Designated IS
Date: Fri, 25 Jan 2002 01:28:17 -0500
comments inlined
> -----Original Message-----
> From: Tony Li [mailto:tli@procket.com]
> Sent: Friday, January 25, 2002 11:17 AM
> To: Sachidananda K
> Cc: isis-wg@spider.juniper.net
> Subject: [Isis-wg] CSNP from Designated IS
>
>
>
>
> | When an intermediate system just comes up on a broadcast
> circuit it would
> | typically not be having any LSPs in its database.
>
>
> It should generate at least its own, even if it doesn't have
> any adjacencies.
>
>
> | Co-incidently, if this IS
> | happens to be the designated IS for that broadcast
> circuit, then what start
> | LSP ID and the end LSP ID shall be put in the CSNP
> constructed by this IS?
>
>
> Then it should also generate a pseudo-node LSP. The CSNP
> should contain
> the full range of the database from LSP ID 0 (zero) to the
> all-ones LSP ID.
>
>
> | To be more generic, how can we ensure that this new IS's
> database is
> | synchronised with that of all the othre IS's in the LAN?
>
>
> It should send out CSNPs. Anyone disagreeing should speak up.
>
>
Adding to Tony's reply, DIS sends out CSNPs. When the receiver finds DIS is
out of date, it will multicast the missing information (so that other IS
receiving CSNP will not send again).
If DIS has new information, the receiving IS multicast PSNP for missing
information.Here only DIS should send the missing info, others should not.
Hope this helps
~ Swami
> Tony
> _______________________________________________
> 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
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
From tli@Procket.com Mon Jan 28 09:03:13 2002
From: tli@Procket.com (Tony Li)
Date: Mon, 28 Jan 2002 01:03:13 -0800
Subject: [Isis-wg] CSNP from Designated IS
In-Reply-To:
References:
Message-ID: <15445.5073.780922.258651@alpha-tli.procket.com>
| I would like to know as to, whether is it permissible to keep the start LSP
| ID of the first CSNP as all 0's and the end LSP ID of the last CSNP packet
| as all 1's in a complete set of CSNP.
Not only is that permissible, but it is also required if you want true
database synchronization. If a complete set of CSNPs does not completely
cover the LSP ID space, then the receiver could have an LSP in any space
that is not included and thereby it might not be synchronized with the DIS.
Tony
From mshand@cisco.com Mon Jan 28 09:58:02 2002
From: mshand@cisco.com (mike shand)
Date: Mon, 28 Jan 2002 09:58:02 +0000
Subject: [Isis-wg] checksum calculation doubt
In-Reply-To: <200201260443.XAA07143@bcn.East.Sun.COM>
Message-ID: <4.3.2.7.2.20020128095414.01a12008@jaws.cisco.com>
At 23:43 25/01/2002 -0500, Radia Perlman - Boston Center for Networking wrote:
>Yeah, I think Mike owes you dinner, John. I may have typed the words in, but
>it was Tony that got excited about that sort of stuff, and it was his
>idea. It seemed harmless to put it in. Obviously it
>doesn't prevent malicious errors. I suspect that in all the years of
>running IS-IS it didn't catch any accidental errors, either, but who knows.
My apologies Radia. I should have guessed that this had Tony's hallmark:-)
For those reading this list who may otherwise be confused, we are not of
course referring to either of our illustrious WG chairs, but to Tony Lauck
who ran the network architecture group in DEC when Radia, John and I worked
there sometime last century.
Mike
From Larmer@CommSense.Net Fri Jan 25 15:06:21 2002
From: Larmer@CommSense.Net (Ken Larmer)
Date: Fri, 25 Jan 2002 10:06:21 -0500
Subject: [Isis-wg] Making the update reliable
In-Reply-To: <20020125063357.9028A4BA219@prattle.redback.com>
Message-ID:
Naiming Wrote:
> In the case no 3way hello is running, the first CSNP is lost, and
> the link becomes unidirectional, no matter how many CSNPs being
> sent later on, the two sides still can not syncronize, or it does get
> syncronized but one side will keep sending out LSPs due to no Ack
> back from the peer.
>In the case of the link being bidirectional, the initial CSNP got lost.
>All LSPs will be sent over the link, and the other side has to send back
>the PSNPs to Ack. Say A->B csnp is lost, B has to send all its LSPs to A.
>A has to response with PSNPs. Even A keeps sending csnps to B, A still
>need to send those PSNPs. And they basically contain the same info: don't
>send them anymore!
Hi Naming, can you please explain the two scenarios above in more detail?
Are they the same as the scenarios referenced in the "Three-Way Handshake
for IS-IS Point-to-Point Adjacencies" draft as referenced below:
Three failure modes are known. First, if the link goes down and then
comes back up, or one of the systems restarts, and the CSNP packet is
lost, and the network has a cut set of one through the link, the link
state databases on either side of the link will not synchronize for a
full LSP refresh period (up to eighteen hours).
A second, more serious failure, is that if the link fails in only one
direction, the failure will only be detected by one of the systems.
Normally, this is not a serious issue; only one of the two systems
will announce the adjacency in its link state packets, and the SPF
algorithm will thus ignore the link. However, if there are two
parallel links between systems and one of them fails in one
direction, SPF will still calculate paths between the two systems,
and the system that does not notice the failure will attempt to pass
traffic down the failed link (in the direction that does not work).
The third issue is that on some physical layers, the
interconnectivity between endpoints can change without causing a
link-layer-down condition. In this case, a system may receive packets
that are actually destined for a different system (or a different
link on the same system). The receiving system may end up thinking
that it has an adjacency with the remote system when in fact the
remote system is adjacent with a third system.
Cheers,
Ken Larmer
CommSense Networks
From rameshrr@future.futsoft.com Mon Jan 28 14:36:43 2002
From: rameshrr@future.futsoft.com (Rayapureddi Ramesh)
Date: Mon, 28 Jan 2002 20:06:43 +0530
Subject: [Isis-wg] Reg: route preference
Message-ID: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com>
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C1A837.4F5913B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hi,
In ISIS we can add manual adjacencies also, they are nothing but static
routes.
We can add prefix addresses (reachable address) also these also static
routes only.
When we want to send some data to some destination "DST"
if there three routes with different next hops with "same cost"
1. route learned by ISIS with next hop NH1
2. Static route (manual adjacency) with next hop NH2
3. Reachable address with next hop NH3
Which route I should take as a best route?
If any one knows pl tell me.
Regards,
Ramesh
------=_NextPart_000_000C_01C1A837.4F5913B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
In =
ISIS we can=20
add manual adjacencies also, they are nothing but static=20
routes.
We can =
add prefix=20
addresses (reachable address) also these also static routes=20
only.
When =
we want to send=20
some data to some destination "DST"
if =
there three=20
routes with different next hops with "same cost"
1. =
route learned by=20
ISIS with next hop NH1
2. =
Static route=20
(manual adjacency) with next hop NH2
3. =
Reachable address=20
with next hop NH3
Which=20
route I should take as a best route?
If any =
one knows pl=20
tell me.
Regards,
Ramesh
------=_NextPart_000_000C_01C1A837.4F5913B0--
From Larmer@commsense.net Mon Jan 28 15:08:20 2002
From: Larmer@commsense.net (Ken Larmer)
Date: Mon, 28 Jan 2002 10:08:20 -0500
Subject: [Isis-wg] Reg: route preference
In-Reply-To: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com>
Message-ID:
This is a multi-part message in MIME format.
------=_NextPart_000_0044_01C1A7E3.B69D2010
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hi Ramesh,
> We can add prefix addresses (reachable address) also these also static
routes only.
>When we want to send some data to some destination "DST"
>if there three routes with different next hops with "same cost"
>1. route learned by ISIS with next hop NH1
>2. Static route (manual adjacency) with next hop NH 2
>3. Reachable address with next hop NH3
>Which route I should take as a best route?
This depends upon whether or not you have path splitting enabled? If you do,
then you follow the guidelines specified in ISO-10589v2-2001-07-04 section
"7.2.7 Removal of excess paths"
Cheers,
Ken Larmer
CommSense Networks
------=_NextPart_000_0044_01C1A7E3.B69D2010
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi=20
Ramesh,
> We can add prefix addresses =
(reachable=20
address) also these also static routes only.
>When we want to send some data to some =
destination=20
"DST"
>if there three routes with different next =
hops with=20
"same cost"
>1. route learned by ISIS with next hop =
NH1
>2. Static route (manual =
adjacency) with=20
next hop NH 2
>3. Reachable address with next hop NH3
>Which route I should take as a =
best=20
route?
This depends upon whether =
or=20
not you have path splitting enabled? If you do, then you follow the =
guidelines specified in ISO-10589v2-2001-07-04 section "7.2.7=20
Removal of excess paths"
Cheers,
Ken=20
Larmer
CommSense=20
Networks
------=_NextPart_000_0044_01C1A7E3.B69D2010--
From jlearman@cisco.com Mon Jan 28 15:29:14 2002
From: jlearman@cisco.com (Jeff Learman)
Date: Mon, 28 Jan 2002 10:29:14 -0500
Subject: [Isis-wg] Reg: route preference
In-Reply-To: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com>
Message-ID: <4.3.2.7.2.20020128102326.01e81490@dingdong.cisco.com>
--=====================_1298386==_.ALT
Content-Type: text/plain; charset="us-ascii"
See 10589:1992 section 7.2.7., Removal of excess paths.
Jeff
At 09:36 AM 1/28/2002, Rayapureddi Ramesh wrote:
>Hi,
>
>In ISIS we can add manual adjacencies also, they are nothing but static routes.
>We can add prefix addresses (reachable address) also these also static routes only.
>
>When we want to send some data to some destination "DST"
>
>if there three routes with different next hops with "same cost"
>
>1. route learned by ISIS with next hop NH1
>2. Static route (manual adjacency) with next hop NH2
>3. Reachable address with next hop NH3
>
>Which route I should take as a best route?
>
>If any one knows pl tell me.
>
>
>Regards,
>Ramesh
--=====================_1298386==_.ALT
Content-Type: text/html; charset="us-ascii"
See 10589:1992 section 7.2.7., Removal of excess paths.
Jeff
At 09:36 AM 1/28/2002, Rayapureddi Ramesh wrote:
Hi,
In ISIS we can add manual adjacencies
also, they are nothing but static routes.
We can add prefix addresses (reachable address)
also these also static routes only.
When we want to send some data to some
destination "DST"
if there three routes with different next hops
with "same cost"
1. route learned by ISIS with next hop
NH1
2. Static route (manual adjacency)
with next hop NH2
3. Reachable address with next hop
NH3
Which route I should take as a
best route?
If any one knows pl tell me.
Regards,
Ramesh
--=====================_1298386==_.ALT--
From jlearman@cisco.com Mon Jan 28 16:25:09 2002
From: jlearman@cisco.com (Jeff Learman)
Date: Mon, 28 Jan 2002 11:25:09 -0500
Subject: [Isis-wg] Reg: route preference
In-Reply-To:
References: <000b01c1a809$359f5110$1305a8c0@future.futsoft.com>
Message-ID: <4.3.2.7.2.20020128112138.01e82ab8@dingdong.cisco.com>
--=====================_4653371==_.ALT
Content-Type: text/plain; charset="us-ascii"
Ken, you need to follow those rules whenever the number of next hops
exceeds maximumPathSplits, so you need the logic regardless of what
an implementation supports. One that doesn't support load balancing
would simply have maximumPathSplits set to 1.
Jeff
At 10:08 AM 1/28/2002, you wrote:
>Hi Ramesh,
>
>> We can add prefix addresses (reachable address) also these also static routes only.
>
> >When we want to send some data to some destination "DST"
>
> >if there three routes with different next hops with "same cost"
>
> >1. route learned by ISIS with next hop NH1
>
> >2. Static route (manual adjacency) with next hop NH 2
>
> >3. Reachable address with next hop NH3
>
> >Which route I should take as a best route?
>
>This depends upon whether or not you have path splitting enabled? If you do, then you follow the guidelines specified in ISO-10589v2-2001-07-04 section "7.2.7 Removal of excess paths"
>
>Cheers,
>Ken Larmer
>CommSense Networks
--=====================_4653371==_.ALT
Content-Type: text/html; charset="us-ascii"
Ken, you need to follow those rules whenever the number of next
hops
exceeds maximumPathSplits, so you need the logic regardless of what
an implementation supports. One that doesn't support load
balancing
would simply have maximumPathSplits set to 1.
Jeff
At 10:08 AM 1/28/2002, you wrote:
Hi
Ramesh,
> We can add prefix addresses (reachable
address) also these also static routes only.
>When we want to send some data to
some destination "DST"
>if there three routes with different
next hops with "same cost"
>1. route learned by ISIS with next
hop NH1
>2. Static route (manual
adjacency) with next hop NH 2
>3. Reachable address with next hop
NH3
>Which route I should
take as a best route?
This depends upon whether or not you have path splitting enabled? If you
do, then you follow the guidelines specified in ISO-10589v2-2001-07-04
section "7.2.7 Removal of excess paths"
Cheers,
Ken Larmer
CommSense Networks<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />
--=====================_4653371==_.ALT--
From Larmer@commsense.net Mon Jan 28 16:58:47 2002
From: Larmer@commsense.net (Ken Larmer)
Date: Mon, 28 Jan 2002 11:58:47 -0500
Subject: [Isis-wg] Reg: route preference
In-Reply-To: <4.3.2.7.2.20020128112138.01e82ab8@dingdong.cisco.com>
Message-ID:
This is a multi-part message in MIME format.
------=_NextPart_000_0050_01C1A7F3.24B02660
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Yes Jeff, you are quite right! This is not phase IV is it.
Cheers,
Ken Larmer
CommSense Networks
-----Original Message-----
From: isis-wg-admin@external.juniper.net
[mailto:isis-wg-admin@external.juniper.net]On Behalf Of Jeff Learman
Sent: Monday, January 28, 2002 11:25 AM
To: Ken Larmer
Cc: isis-wg@juniper.net
Subject: RE: [Isis-wg] Reg: route preference
Ken, you need to follow those rules whenever the number of next hops
exceeds maximumPathSplits, so you need the logic regardless of what
an implementation supports. One that doesn't support load balancing
would simply have maximumPathSplits set to 1.
Jeff
At 10:08 AM 1/28/2002, you wrote:
Hi Ramesh,
> We can add prefix addresses (reachable address) also these also static
routes only.
>When we want to send some data to some destination "DST"
>if there three routes with different next hops with "same cost"
>1. route learned by ISIS with next hop NH1
>2. Static route (manual adjacency) with next hop NH 2
>3. Reachable address with next hop NH3
>Which route I should take as a best route?
This depends upon whether or not you have path splitting enabled? If you
do, then you follow the guidelines specified in ISO-10589v2-2001-07-04
section "7.2.7 Removal of excess paths"
Cheers,
Ken Larmer
CommSense Networks
------=_NextPart_000_0050_01C1A7F3.24B02660
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Yes =
Jeff, you are=20
quite right! This is not phase IV is it.
Cheers,
Ken=20
Larmer
CommSense=20
Networks
Ken, you need to follow those =
rules=20
whenever the number of next hops
exceeds maximumPathSplits, so you =
need the=20
logic regardless of what
an implementation supports. One that =
doesn't=20
support load balancing
would simply have maximumPathSplits set to=20
1.
Jeff
At 10:08 AM 1/28/2002, you wrote:
Hi=20
Ramesh,
> We can add prefix addresses (reachable address) also =
these also=20
static routes only.
>When we want to send some data to some =
destination "DST"=20
>if there =
three routes=20
with different next hops with "same cost"
>1. route learned by ISIS with next =
hop NH1 =20
>2. Static =
route=20
(manual adjacency) with next hop NH =
2
>3. Reachable address with next hop =
NH3=20
>Which =
route =20
I should take as a best route?
This depends =
upon=20
whether or not you have path splitting enabled? If you do, then you =
follow=20
the guidelines specified in ISO-10589v2-2001-07-04 section "7.2.7 =
Removal of=20
excess paths"
Cheers,
Ken Larmer
CommSense=20
Networks<?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" />=20
------=_NextPart_000_0050_01C1A7F3.24B02660--
From rameshrr@future.futsoft.com Tue Jan 29 07:43:29 2002
From: rameshrr@future.futsoft.com (Rayapureddi Ramesh)
Date: Tue, 29 Jan 2002 13:13:29 +0530
Subject: [Isis-wg] Reg: route preference
Message-ID: <002101c1a898$a5990990$1305a8c0@future.futsoft.com>
This is a multi-part message in MIME format.
------=_NextPart_000_0022_01C1A8C6.BF52CC30
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hello,
I think I asked question in a wrong way.
Actaully my doubt is
if we are maintaining three different databases for
1. routes learned from ISIS ---route information data base RDB1
2. manual adjacencies ( is-neighbors OR es-neighbors) -- route information
data base RDB2
3. reachable address (Prefix routes) -- route information data base RDB3
Is it maintaining three different data base correct?
if yes if we want a route to some destination "DST" then
which database should I search first RDB1 or RDB2 or RDB3 ?
which is next RDB1 or RDB2 or RDB3 ? And which is last RDB1 or RDB2 or
RDB3?
regards,
Ramesh
-----Original Message-----
From: Jeff Learman [mailto:jlearman@cisco.com]
Sent: Monday, January 28, 2002 9:12 PM
To: rameshrr@future.futsoft.com
Subject: Fwd: Re: [Isis-wg] Reg: route preference
By the way, don't be confused by the inclusion of "metric sum"
in this list. It confused me at first, because we normally think of
all of the paths having equal cost before reaching this point. However,
this item only relates to routers that, rather than computing the set
of equal minimum cost paths (7.2.6.2-b), compute downstream paths
(7.2.6.2-c). I haven't ever heard of anyone using that method.
Regards,
Jeff
Date: Mon, 28 Jan 2002 10:29:14 -0500
To:
From: Jeff Learman
Subject: Re: [Isis-wg] Reg: route preference
Cc: "ISIS (E-mail)" , "ISISWG
(E-mail)"
See 10589:1992 section 7.2.7., Removal of excess paths.
Jeff
At 09:36 AM 1/28/2002, Rayapureddi Ramesh wrote:
Hi,
In ISIS we can add manual adjacencies also, they are nothing but
static routes.
We can add prefix addresses (reachable address) also these also static
routes only.
When we want to send some data to some destination "DST"
if there three routes with different next hops with "same cost"
1. route learned by ISIS with next hop NH1
2. Static route (manual adjacency) with next hop NH2
3. Reachable address with next hop NH3
Which route I should take as a best route?
If any one knows pl tell me.
Regards,
Ramesh
------=_NextPart_000_0022_01C1A8C6.BF52CC30
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hello,
I=20
think I asked question in a wrong way.
Actaully my doubt is
if we=20
are maintaining three different databases for
1.=20
routes learned from ISIS ---route information data base=20
RDB1
2.=20
manual adjacencies ( is-neighbors OR es-neighbors) -- route information =
data=20
base RDB2
3.=20
reachable address (Prefix routes) -- route information data base=20
RDB3
Is it=20
maintaining three different data base correct?
if yes=20
if we want a route to some destination=20
"DST" then
which=20
database should I search first RDB1 or RDB2 or RDB3 ?
which is next RDB1 or RDB2 or RDB3 ? And which is last RDB1 or RDB2 or=20
RDB3?
regards,
Ramesh
By the way, =
don't be=20
confused by the inclusion of "metric sum"
in this list. It =
confused=20
me at first, because we normally think of
all of the paths having =
equal=20
cost before reaching this point. However,
this item only =
relates to=20
routers that, rather than computing the set
of equal minimum cost =
paths=20
(7.2.6.2-b), compute downstream paths
(7.2.6.2-c). I haven't =
ever=20
heard of anyone using that method.
Regards,
Jeff
Date: Mon, 28 Jan 2002 10:29:14 =
-0500
To:=20
<rameshrr@future.futsoft.com>
From: Jeff Learman=20
<jlearman@cisco.com>
Subject: Re: [Isis-wg] Reg: route=20
preference
Cc: "ISIS (E-mail)" =
<isis-wg-admin@spider.juniper.net>,=20
"ISISWG (E-mail)" <isis-wg@juniper.net>
See =
10589:1992=20
section 7.2.7., Removal of excess paths.
Jeff
At 09:36 =
AM=20
1/28/2002, Rayapureddi Ramesh wrote:
Hi,
In =
ISIS we =20
can add manual adjacencies also, they are nothing but static=20
routes.
We can add prefix =
addresses=20
(reachable address) also these also static routes=20
only.
When we want =
to send=20
some data to some destination "DST"
if there three routes with different next hops with "same =
cost"
1. route =
learned by ISIS=20
with next hop NH1
2. =
Static route=20
(manual adjacency) with next hop NH2
3. Reachable address with next hop=20
NH3
Which =
route I=20
should take as a best route?
If any one knows pl tell =
me.
Regards,
Ramesh
------=_NextPart_000_0022_01C1A8C6.BF52CC30--
From rameshrr@future.futsoft.com Tue Jan 29 07:44:33 2002
From: rameshrr@future.futsoft.com (Rayapureddi Ramesh)
Date: Tue, 29 Jan 2002 13:14:33 +0530
Subject: [Isis-wg] FW: reg IS & ES neighbors
Message-ID: <002601c1a898$cb941720$1305a8c0@future.futsoft.com>
This is a multi-part message in MIME format.
------=_NextPart_000_0027_01C1A8C6.E54C5320
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hi,
In Cisco there are two commands
and at the
interface level.
If we enable both ISIS and CLNS routing on Cisco router.
In both the commands whatever (area Id will be equal to areaID given in
command)
neighbor SNPA address we are giving ISIS is advertising as ES neighbors in
neighbor
options of LSP. Then what is the difference between these commands?
example :
config> clns routing
config-router>net 47.0004.004d.1300.0102.0304.00
config-router>interface eth 1/0
config-if>clns es-neighbor 47.0004.004d.3100.0102.0304.00 1111.2222.3333
config-if>clns is-neighbor 47.0004.004d.4100.0102.0304.00 1111.2222.3333
ISIS is advertising in L1 LSP as ES neighbors (3100.0102.0304 &
4100.0102.0304) in neighbor options.
Can anybody explain me.
Regards,
Ramesh
------=_NextPart_000_0027_01C1A8C6.E54C5320
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi,
In=20
Cisco there are two commands
<clns is-neighbor =
SNPA=20
NSAP> and <clns es-neighbor SNPA =
NSAP>=20
at the interface level.
If we=20
enable both ISIS and CLNS routing on Cisco router.
In both the commands whatever (area Id =
will be=20
equal to areaID given in <net> command)
neighbor SNPA address we are giving ISIS is=20
advertising as ES neighbors in neighbor=20
options of LSP. Then what is the difference =
between=20
these commands?
example=20
: =20
config> clns routing
config-router>net=20
47.0004.004d.1300.0102.0304.00
config-router>interface eth =
1/0
config-if>clns es-neighbor=20
47.0004.004d.3100.0102.0304.00 1111.2222.3333
config-if>clns is-neighbor =20
47.0004.004d.4100.0102.0304.00 1111.2222.3333
ISIS=20
is advertising in L1 LSP as ES neighbors (3100.0102.0304 &=20
4100.0102.0304) in neighbor options.
Can anybody explain =
me.
Regards,
Ramesh
------=_NextPart_000_0027_01C1A8C6.E54C5320--
From Internet-Drafts@ietf.org Tue Jan 29 12:42:10 2002
From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org)
Date: Tue, 29 Jan 2002 07:42:10 -0500
Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-07.txt
Message-ID: <200201291242.HAA01151@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-07.txt
Pages : 9
Date : 28-Jan-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-07.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-07.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-07.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: <20020128150952.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-isis-gmpls-extensions-07.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20020128150952.I-D@ietf.org>
--OtherAccess--
--NextPart--
From Internet-Drafts@ietf.org Tue Jan 29 12:42:15 2002
From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org)
Date: Tue, 29 Jan 2002 07:42:15 -0500
Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-02.txt
Message-ID: <200201291242.HAA01169@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 : M-ISIS: Multi Topology Routing in IS-IS
Author(s) : T. Przygienda et al.
Filename : draft-ietf-isis-wg-multi-topology-02.txt
Pages : 7
Date : 28-Jan-02
This draft describes an optional implementation technique within
IS-IS [ISO90 , Cal90a , Cal90b] used today by many ISPs for
routing within their clouds. IS-IS is an interior gateway routing
protocol developed originally by OSI and used with IP extensions as
IGP. This draft describes how to run within a single ISIS domain a
set of independent IP topologies that we call Multi-Topologies
(MTs), or Multiple views of Topology. This MT extension can be used
for variety of purposes such as an in-band management network
on top' of the original IGP topology, transport multiple
overlapping IP address spaces in the same protocol, force a subset
of an address space to follow a different topology, or finally,
even maintain a restricted number of protocol based VPNs.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-wg-multi-topology-02.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-wg-multi-topology-02.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-wg-multi-topology-02.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: <20020128151007.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-isis-wg-multi-topology-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-isis-wg-multi-topology-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20020128151007.I-D@ietf.org>
--OtherAccess--
--NextPart--
From jlearman@cisco.com Tue Jan 29 16:11:26 2002
From: jlearman@cisco.com (Jeff Learman)
Date: Tue, 29 Jan 2002 11:11:26 -0500
Subject: [Isis-wg] FW: reg IS & ES neighbors
In-Reply-To: <002601c1a898$cb941720$1305a8c0@future.futsoft.com>
Message-ID: <4.3.2.7.2.20020129110619.01ec71c0@dingdong.cisco.com>
--=====================_93148740==_.ALT
Content-Type: text/plain; charset="us-ascii"
Ramesh,
Implementation-specific questions are not permitted on this exploder.
Please direct any Cisco implementation questions to your Cisco support
representative.
I do not work on IS-IS at Cisco and have no insider knowledge of
the Cisco implementation. Fortunately, this question is answerable
knowing only the standards. (Note that you could have asked this
question in a vendor-unspecific fashion, by stating that you had
configured an IS manual adjacency and an ES manual adjacency but
saw both appear in the LSPs as end-system neighbors and wondered
whether this is correct.)
IS-IS can't advertise a neighbor as an IS neighbor unless it has
established an adjacency in the 'UP' state according to 10598.
You can't manually put an adjacency in the 'UP' state. IS-IS is
treating this system like an intermediate system that is not running
IS-IS, which is equivalent to how it would treat an end system.
Best Regards,
Jeff
At 02:44 AM 1/29/2002, Rayapureddi Ramesh wrote:
>
>Hi,
>
>In Cisco there are two commands
>
> and at the interface level.
>
>
>If we enable both ISIS and CLNS routing on Cisco router.
>
>In both the commands whatever (area Id will be equal to areaID given in command)
>neighbor SNPA address we are giving ISIS is advertising as ES neighbors in neighbor
>options of LSP. Then what is the difference between these commands?
>
>example :
>config> clns routing
>config-router>net 47.0004.004d.1300.0102.0304.00
>config-router>interface eth 1/0
>config-if>clns es-neighbor 47.0004.004d.3100.0102.0304.00 1111.2222.3333
>config-if>clns is-neighbor 47.0004.004d.4100.0102.0304.00 1111.2222.3333
>
>ISIS is advertising in L1 LSP as ES neighbors (3100.0102.0304 & 4100.0102.0304) in neighbor options.
>
>
>Can anybody explain me.
>
>
>Regards,
>Ramesh
--=====================_93148740==_.ALT
Content-Type: text/html; charset="us-ascii"
Ramesh,
Implementation-specific questions are not permitted on this
exploder.
Please direct any Cisco implementation questions to your Cisco
support
representative.
I do not work on IS-IS at Cisco and have no insider knowledge of
the Cisco implementation. Fortunately, this question is
answerable
knowing only the standards. (Note that you could have asked
this
question in a vendor-unspecific fashion, by stating that you had
configured an IS manual adjacency and an ES manual adjacency but
saw both appear in the LSPs as end-system neighbors and wondered
whether this is correct.)
IS-IS can't advertise a neighbor as an IS neighbor unless it has
established an adjacency in the 'UP' state according to 10598.
You can't manually put an adjacency in the 'UP' state. IS-IS
is
treating this system like an intermediate system that is not
running
IS-IS, which is equivalent to how it would treat an end system.
Best Regards,
Jeff
At 02:44 AM 1/29/2002, Rayapureddi Ramesh wrote:
Hi,
In Cisco there are two
commands
<clns is-neighbor
SNPA NSAP> and <clns es-neighbor SNPA
NSAP> at the interface level.
If we enable both ISIS and CLNS
routing on Cisco router.
In both the commands whatever
(area Id will be equal to areaID given in <net> command)
neighbor SNPA address we are
giving ISIS is advertising as ES neighbors in neighbor
options of LSP. Then what is
the difference between these commands?
example
:
config> clns
routing
config-router>net
47.0004.004d.1300.0102.0304.00
config-router>interface eth
1/0
config-if>clns es-neighbor
47.0004.004d.3100.0102.0304.00 1111.2222.3333
config-if>clns
is-neighbor 47.0004.004d.4100.0102.0304.00
1111.2222.3333
ISIS is advertising in L1 LSP
as ES neighbors (3100.0102.0304 & 4100.0102.0304) in neighbor
options.
Can anybody explain
me.
Regards,
Ramesh
--=====================_93148740==_.ALT--
From naiming@redback.com Tue Jan 29 23:27:39 2002
From: naiming@redback.com (Naiming Shen)
Date: Tue, 29 Jan 2002 15:27:39 -0800
Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-wg-multi-topology-02.txt
In-Reply-To: Mail from Internet-Drafts@ietf.org
dated Tue, 29 Jan 2002 07:42:15 EST
<200201291242.HAA01169@ietf.org>
Message-ID: <20020129232739.67BAE1DCC76@prattle.redback.com>
this paragraph is added to the 02.txt of M-ISIS draft, section 2.2.
pls comment.
Two Routers on a LAN SHOULD always establish adjacency regardless
whether they have common MT set or not. This is to ensure all
the routers on the LAN can correctly elect the same DIS. The IS
may not contain the MT IS TLV in its LSP if none of the adjacencies
on the LAN contains this MT.
thanks.
- Naiming
From tli@procket.com Tue Jan 29 09:13:11 2002
From: tli@procket.com (Tony Li)
Date: Tue, 29 Jan 2002 01:13:11 -0800
Subject: [Isis-wg] FW: reg IS & ES neighbors
In-Reply-To: <002601c1a898$cb941720$1305a8c0@future.futsoft.com>
References: <002601c1a898$cb941720$1305a8c0@future.futsoft.com>
Message-ID: <15446.26535.813528.563467@alpha-tli.procket.com>
| Can anybody explain me.
Please consult with your vendor. This is not a technical support mailing
list.
Tony
From jlearman@cisco.com Fri Jan 25 15:05:49 2002
From: jlearman@cisco.com (Jeff Learman)
Date: Fri, 25 Jan 2002 10:05:49 -0500
Subject: [Isis-wg] Making the update reliable
In-Reply-To: <200201250800.g0P80nZ37529@cirrus.juniper.net>
References: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com>
<4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com>
Message-ID: <4.3.2.7.2.20020125092121.01e51f28@dingdong.cisco.com>
At 03:00 AM 1/25/2002, Dave Katz wrote:
> So I don't see any benefit to sending periodic CSNPs. It was worth
> considering, though.
>
>We send 'em anyhow. I think I made the cisco code do the same thing,
>but it's been a lot of years. Or maybe you can just configure it
>on the cisco box, I don't remember offhand.
>
>Cheap insurance when working with the ill-named mesh groups.
I bet you did this before 3-way handshake was proposed. Without it,
systems would recover from a one-sided restart much more quickly than
waiting for all LSPs to be regenerated. Even with 3-way, I can't
imagine them doing any harm.
Any system that runs IS-IS on an unreliable PTP link and does not support
3-way handshake would be strongly advised to send periodic CSNPs.
Regards,
Jeff
>--Dave
From dkatz@juniper.net Fri Jan 25 16:21:40 2002
From: dkatz@juniper.net (Dave Katz)
Date: Fri, 25 Jan 2002 08:21:40 -0800 (PST)
Subject: [Isis-wg] Making the update reliable
In-Reply-To: <4.3.2.7.2.20020125092121.01e51f28@dingdong.cisco.com> (message
from Jeff Learman on Fri, 25 Jan 2002 10:05:49 -0500)
References: <4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com>
<4.3.2.7.2.20020124104357.01c96548@dingdong.cisco.com> <4.3.2.7.2.20020125092121.01e51f28@dingdong.cisco.com>
Message-ID: <200201251621.g0PGLen38607@cirrus.juniper.net>
>We send 'em anyhow. I think I made the cisco code do the same thing,
>but it's been a lot of years. Or maybe you can just configure it
>on the cisco box, I don't remember offhand.
>
>Cheap insurance when working with the ill-named mesh groups.
I bet you did this before 3-way handshake was proposed. Without it,
systems would recover from a one-sided restart much more quickly than
waiting for all LSPs to be regenerated. Even with 3-way, I can't
imagine them doing any harm.
Can't remember; I'm old and doddering. But they were intended to solve
separate problems.
Any system that runs IS-IS on an unreliable PTP link and does not support
3-way handshake would be strongly advised to send periodic CSNPs.
Until the mid 90s, this described pretty much every deployed ISIS PTP
link, but somehow we all survived. The case we were actually trying
to solve with the 3way hack was the one where there were two parallel
links between the same pair of routers, but only one of them came up
fully. The half-up side would happily pump traffic down the link, and
the rest of the network would route to it (since the two links cannot
be distinguished from a distance) and much unhappiness resulted. (In
the single link case, the SPF would fail to calculate a path through
the half-up link, so nobody would use it.)
--Dave
From jlearman@cisco.com Tue Jan 29 17:05:22 2002
From: jlearman@cisco.com (Jeff Learman)
Date: Tue, 29 Jan 2002 12:05:22 -0500
Subject: [Isis-wg] Reg: route preference
In-Reply-To: <002101c1a898$a5990990$1305a8c0@future.futsoft.com>
Message-ID: <4.3.2.7.2.20020129120243.03bd7298@dingdong.cisco.com>
--=====================_93695446==_.ALT
Content-Type: text/plain; charset="us-ascii"
At 02:43 AM 1/29/2002, Rayapureddi Ramesh wrote:
>
>Hello,
>
>I think I asked question in a wrong way.
>Actaully my doubt is
>
>if we are maintaining three different databases for
>
>1. routes learned from ISIS ---route information data base RDB1
>2. manual adjacencies ( is-neighbors OR es-neighbors) -- route information data base RDB2
>3. reachable address (Prefix routes) -- route information data base RDB3
>
>Is it maintaining three different data base correct?
By RDB, I assume you mean the result of running SPF -- called
a forwarding database (FDB) in 10589. You can keep them separate
as long as you can follow the rules in section 7.2.7. I think that
may be tricky.
>if yes if we want a route to some destination "DST" then
>
>which database should I search first RDB1 or RDB2 or RDB3 ?
>which is next RDB1 or RDB2 or RDB3 ? And which is last RDB1 or RDB2 or RDB3?
If the same destination can appear in all three RDBs with different
metric sums, which is likely the case, then you will have a little
trouble meeting the second criteria in 7.2.7 without consulting
all RDBs and keeping the metric sum in the RDB entries, and
choosing an entry with the minimum metric sum.
The thing to do here is to imagine the behavior of a system that
meets the criteria, and make sure that your system exhibits
indistinguishable behavior. By the way, the requirement for
determinism seemed very important to the designers, and from my
point of view that was a very helpful property. The fact that
the same routing decisions would always be made regardless of
the order in which systems or links came up made debugging problem
cases much easier -- as the problems would tend to be more reproducable.
This was especially the case when investigating problems in our
customers' customers' networks. This was before I joined Cisco,
and we sold OSI middleware used in SONET network elements.
Regards,
Jeff
>regards,
>Ramesh
>
>-----Original Message-----
>From: Jeff Learman [mailto:jlearman@cisco.com]
>Sent: Monday, January 28, 2002 9:12 PM
>To: rameshrr@future.futsoft.com
>Subject: Fwd: Re: [Isis-wg] Reg: route preference
>
>By the way, don't be confused by the inclusion of "metric sum"
>in this list. It confused me at first, because we normally think of
>all of the paths having equal cost before reaching this point. However,
>this item only relates to routers that, rather than computing the set
>of equal minimum cost paths (7.2.6.2-b), compute downstream paths
>(7.2.6.2-c). I haven't ever heard of anyone using that method.
>
>Regards,
>Jeff
>
>>Date: Mon, 28 Jan 2002 10:29:14 -0500
>>To:
>>From: Jeff Learman
>>Subject: Re: [Isis-wg] Reg: route preference
>>Cc: "ISIS (E-mail)" , "ISISWG (E-mail)"
>>
>>
>>
>>See 10589:1992 section 7.2.7., Removal of excess paths.
>>
>>Jeff
>>
>>At 09:36 AM 1/28/2002, Rayapureddi Ramesh wrote:
>>>Hi,
>>>
>>>In ISIS we can add manual adjacencies also, they are nothing but static routes.
>>>We can add prefix addresses (reachable address) also these also static routes only.
>>>
>>>When we want to send some data to some destination "DST"
>>>
>>>if there three routes with different next hops with "same cost"
>>>
>>>1. route learned by ISIS with next hop NH1
>>>2. Static route (manual adjacency) with next hop NH2
>>>3. Reachable address with next hop NH3
>>>
>>>Which route I should take as a best route?
>>>
>>>If any one knows pl tell me.
>>>
>>>
>>>Regards,
>>>Ramesh
--=====================_93695446==_.ALT
Content-Type: text/html; charset="us-ascii"
At 02:43 AM 1/29/2002, Rayapureddi Ramesh wrote:
Hello,
I think I asked question in a
wrong way.
Actaully my doubt
is
if we are maintaining three
different databases for
1. routes learned from ISIS
---route information data base RDB1
2. manual adjacencies (
is-neighbors OR es-neighbors) -- route information data base
RDB2
3. reachable address (Prefix
routes) -- route information data base RDB3
Is it maintaining three
different data base correct?
By RDB, I assume you mean the result of running SPF -- called
a forwarding database (FDB) in 10589. You can keep them
separate
as long as you can follow the rules in section 7.2.7. I think
that
may be tricky.
if
yes if we want a route to some destination "DST"
then
which database should I search
first RDB1 or RDB2 or RDB3 ?
which is next RDB1
or RDB2 or RDB3 ? And which is last RDB1 or RDB2 or
RDB3?
If the same destination can appear in all three RDBs with different
metric sums, which is likely the case, then you will have a little
trouble meeting the second criteria in 7.2.7 without consulting
all RDBs and keeping the metric sum in the RDB entries, and
choosing an entry with the minimum metric sum.
The thing to do here is to imagine the behavior of a system that
meets the criteria, and make sure that your system exhibits
indistinguishable behavior. By the way, the requirement for
determinism seemed very important to the designers, and from my
point of view that was a very helpful property. The fact that
the same routing decisions would always be made regardless of
the order in which systems or links came up made debugging problem
cases much easier -- as the problems would tend to be more
reproducable.
This was especially the case when investigating problems in our
customers' customers' networks. This was before I joined
Cisco,
and we sold OSI middleware used in SONET network elements.
Regards,
Jeff
regards,
Ramesh