dated Fri, 19 Apr 2002 10:11:02 EDT
<4.3.2.7.2.20020419093101.035eb2a8@dingdong.cisco.com>
Message-ID: <20020419213656.08008262811@prattle.redback.com>
] >
] >1)All packets could be sent with the broadcast address. This is functionally
] >equivalent to what the implied destination address is on PtPt links - and
] >seems as functional as a new multicast address with the advantage that we
] >don't have to carve out a new multicast address and potentially stress the
] >limits of multicast address registration in the hardware.
]
] I think that a new multicast address would be far better than a broadcast
] address because it would cause fewer problems when (not IF, but WHEN) an
] interface configured for PTP is attached to a broadcast LAN. It should
] not be difficult to assign a multicast address.
It may not be much better. I have seen people run IGP over the LAN on
some of the NAPs between their own peering routers. Assume multicast
mac is used, and they run p2p-over-lan for the IGP adjacency. The data
packets can be picked up by multiple routers on the LAN other than your
neighbor and this will cause serious problems.
I agree with Les that, an implementation can offer a configuration
knob to allow broadcast MAC address being used if the user is sure about
there is only two devices on the physical LAN. Its up to the implementation
and the user. Yes, a multicast MAC will also work in this case, but why
bother? why should every piece of hardware be touched to recognize this new
MAC just for this p2p-over-lan? Its not like the existing mechanisms all
fail.
thanks.
- Naiming
From sprevidi@cisco.com Fri Apr 19 23:02:21 2002
From: sprevidi@cisco.com (stefano previdi)
Date: Sat, 20 Apr 2002 00:02:21 +0200
Subject: [Isis-wg] RE: draft-ietf-isis-igp-p2p-over-lan-00.txt
In-Reply-To: <20020419213656.08008262811@prattle.redback.com>
References: <20020419213656.08008262811@prattle.redback.com>
Message-ID: <200204192202.AAA23375@strange-brew.cisco.com>
On Friday 19 April 2002 23:36, Naiming Shen wrote:
> ] >
> ] >1)All packets could be sent with the broadcast address. This is
functionally
> ] >equivalent to what the implied destination address is on PtPt links -
and
> ] >seems as functional as a new multicast address with the advantage that
we
> ] >don't have to carve out a new multicast address and potentially stress
the
> ] >limits of multicast address registration in the hardware.
> ]
> ] I think that a new multicast address would be far better than a broadcast
> ] address because it would cause fewer problems when (not IF, but WHEN) an
> ] interface configured for PTP is attached to a broadcast LAN. It should
> ] not be difficult to assign a multicast address.
>
> It may not be much better. I have seen people run IGP over the LAN on
> some of the NAPs between their own peering routers. Assume multicast
> mac is used, and they run p2p-over-lan for the IGP adjacency. The data
> packets can be picked up by multiple routers on the LAN other than your
> neighbor and this will cause serious problems.
>
> I agree with Les that, an implementation can offer a configuration
> knob to allow broadcast MAC address being used if the user is sure about
> there is only two devices on the physical LAN. Its up to the implementation
> and the user.
absolutely. I woudn't force the use of any specifc address. I believe the
scope of the draft is to give flexibility on the way the igp sees the link,
but not on the way forwarding is done on the wire. So, give generic
recommendations but not at the point of which mac address is supposed to be
used.
s.
> Yes, a multicast MAC will also work in this case, but why
> bother? why should every piece of hardware be touched to recognize this new
> MAC just for this p2p-over-lan? Its not like the existing mechanisms all
> fail.
>
> thanks.
> - Naiming
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>
From lqmao@yahoo.com Sat Apr 20 00:33:23 2002
From: lqmao@yahoo.com (Lawrence Mao)
Date: Fri, 19 Apr 2002 16:33:23 -0700 (PDT)
Subject: [Isis-wg] IS-IS on UPSR ring
Message-ID: <20020419233323.98158.qmail@web11604.mail.yahoo.com>
Hi all,
If the IS-IS needs to be supported on a SONET
UPSR ring, throught its DCC channel (note that
the ring is uni-directional), say, if I have 4
nodes on a ring:
A --> B --> C --> D -
^ |
|--------------------
what kind of modifications need to be made in
order to let the protocol work properly (note
all interfaces are p2p type)?
2nd question is, if the interface is unnumbered,
how is its routing table generated? Use routerID?
Thanks,
--
Lawrence
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
From naiming@redback.com Sat Apr 20 07:52:30 2002
From: naiming@redback.com (Naiming Shen)
Date: Fri, 19 Apr 2002 23:52:30 -0700
Subject: [Isis-wg] a few comments on ietf restart isis draft
Message-ID: <20020420065230.CDC0039B5AF@prattle.redback.com>
Hi Mike,
I have a few comments on draft-ietf-isis-restart-00.txt, I apologize
for the late discussion. It was in my "stuff I gotta read" folder
for too long (something just learned from Jeff) ;-)
(1) TLV code [TBD]
seems we have a code for this now.
(2) page 4, the 2nd paragraph,
"a) DO NOT refresh the timer on the adjacency, ..."
I have big problem with this. The receiving router has a good
adjacency to the neighbor which just restarted, this neighbor
asks for help. The restarting neighbor sent out an IIH
containing RR bit set, and also has its "holding time" value
in this IIH. Why should the receiving router not to refresh the
timer using the latest "holding time" value in this re-start IIH?
I think in this case, the receiving router is "lucky" enough to
get an IIH(with RR bit) from the restarting router before it times
this adjacency out, so the receiving router should do everything
to help the neighbor to complete the restart process.
for example: the receiving router only has 1 second left on this
adjacency, and received the RR bit set IIH on this adjacency. This
IIH has the "holding time" of 30 seconds. If it wants to help
the neighbor to complete a good restart, should the receiving
router times out this adjacency in 1 second, or should the receiving
router holds on this adjacency for another 30 seconds? I would
definitely go for the later.
The only "harm" I can see if updating the timer is that, if the
restart router after sending out the re-start IIHs, then crashed
again and never come back. If this happens, then the convergence
is a little slow, but this may not affect the forwarding and its
a very rare case.
Yes, the vendors should make the restart come back way before the
neighbors holding time expires, but it may not always be so easy;
Yes, the normal holding time can be configured long enough so it
always handles whatever time restart takes, but that seems going
the opposite direction from IGP milli-second convergence.
I would change "DO NOT" into "MUST" here.
3) page 4, paragraph 3 and 4
Probably need to say something explicitly about the ordering of
those packets. If we have IIH(with RA bit), CSNPs and LSPs to be
sent to help the neighbor restart, we need to make sure the IIH goes
out first. Otherwise the CSNPs or LSPs can be dropped by
the re-starting neighbor since it does not have an adjacency yet.
"without waiting for any currently running timer interval to expire"
may refer to the same idea, but it should be spelled out.
4) page 4, paragraph 5
"i.e. if there was no adjacency"
Should add "or the adjacency is not in the "UP" state".
5) page 4, last two paragraphs
"contains an empty ..." and "option with state "Down" and with empty .."
Probably those two sentences should be removed. Because on page 4 the
first paragraph says:
"irrespective of the other contents of the "Intermediate System
Neighbors" option (LAN circuits), or the "Point-to-Point Adjacency
State" option"...
Which means, as long as the RR bit is set in this re-start tlv,
we don't care about the ISN tlv is empty or NOT empty and we don't
care about what state this IIH has. Which is good.
I'm not just nit-picking on language here, basically this RR bit
is a mechanism for IS-IS to re-acquire LSPs from neighbors. It can
be used for some other applications other than graceful restart.
In those cases, we don't want to send out empty ISN TLVs or in
a "Down" state. Also we don't want the neighbors to ignore my
"holding time" either;-) (see the comment #2).
6) levels of IIH with RR bit set
The draft probably should say clearly about the levels:
on the LAN, if both levels are active on the interface, it
should send out two IIHs with the RR bit set, one for each
level. The receiving router may respond with two IIHs with RA
bit, one for each level where the adjacencies are in UP state.
a) b) and c) on page 4 is for each level. on p2p intf, only send
one IIH, but the receiving router still needs to check for
both levels base on the adjacency usage to send out csnps and lsps.
7) page 3, last paragraph
This comment is closely related to comment #2.
Assume we DO(opposite from the current draft) update the adjacency
timer by the receiving router, then this "Remaining Time" field is
no use here. This value set by the Receiving router would be the
same as the "holding time" value in the IIH the re-start router
just sent out. Thus this re-start TLV can use just one octet in
length.
The T3 is the minimum value of all the IS-IS intf holding times.
And it can be figured out immediately without waiting for
neighbors to tell us. It is based on local configure settings.
I think about this way: it's reasonable to expect all the interfaces
go through the similar amount of time to finish this re-start
job. But if we ask the neighbors NOT updating the timers on
the adjacencies, it will be very random. Some adjacencies will be
timed out in 1 second, some will be in 20 seconds, etc. It's much
better to ask them to time out me in, say 20 seconds, across
the board. "Since I'm back, give me another chance, and I know
my restart process takes xx seconds". Implementations can
even offer a config knob to send a different(base on the
local configuration size, network topology size and database size,
also the vendor implementation, those are all closely related
to the re-start time) holding time in this re-start IIH.
T3 is the minimum of this "Remaining Time" right now. So if T3
times out, all the normal IIHs are starting to go out on all
the interfaces, this means, if one adjacency has low timeout
from our neighbors, all our adjacencies may be affected during
the restart since they sees the incomplete ISN TLVs in normal IIHs.
8) page 4, paragraph 4
"excluding the transmitting router"
An optimization would be, "excluding the transmitting router
and only include the routers on the LAN who had re-start
TLV in their IIHs". There maybe someone on the LAN running old
code, that router just happen to have the highest priority but
it can not help the restart neighbor with CSNP and LSPs. So
some router with new code should step in now since the information
is available.
9) page 5, first paragraph
"On expiry of the timer T1, it is restarted and the IIH is
re-transmitted as above."
I take it that, this is to avoid the first IIH packet got
lost, so let's retry. and have a maximum number of retry
mentioned in page 6.
I think we should not even retry. This graceful restart is
not meant to be bullet proof. If the IIHs happen to get lost,
we just have a bad day. This is also the same problem if you
have multiple neighbors on the same LAN. Your IIH can be lost
to one of the neighbors, but as soon as you receive from
other neighbors and complete the CSNPs, the T1 will be cancelled.
But you have no way to know, that one neighbor didn't
receive your re-start IIH, and it will reset the adjacency.
The current scheme does not cover that case, and I think its
not worth to have retries in general. Thus actually we don't
even need the T1.
10) page 8, the 5th paragraph
"are then flooded with the overload bit set to indicate that
the router's LSPDB is not yet synchronized"
I would be very careful setting OL bit here. T3 times out just
means we are sending out normal IIHs, that should not affect
anything even we have not acquired all the LSPs from neighbors
or we haven't finished our SPF.
The goal of this graceful restart is to do non-stop forwarding,
if we send out our LSPs with OL on, it's not non-stop forwarding
any more. Yes our SPF has not finished yet, so what's the hurry?
why not let it to finish? Its much better to delay sending out
our LSPs(assume topology has not changed during re-start) since
routers in the area has our old LSPs containing the same
information, than to send out LSPs immaturely with OL bit set.
Also in 4.3.1.1, "with the overload bit clear", just a simple
comment, some implementation/configurations couple this OL bit
with bgp convergence, and usually bgp "converge" takes longer
than the IGP lsp synchronization.
11) 3way hello state
The draft suggested to send the re-start IIH, with RR bit set,
and 3way state in "Down" on the p2p interface. Assume the
neighbor sends back the IIH with "UP" state with RA bit set.
If we follow the 3way hello draft, we are in "Down", when
receives an "Up", the result state is still "Down". And this
is not good. We need to setup this adjacency to "Up" state
immediately because we need to receive and accept CSNPs and
LSPs over this link soon. So the draft needs to suggest the
re-starting router either sending out the re-start IIH with
"Init" or "Up" state, or specifying not to follow the 3way
hello state table in this case and bring the adjacency up
immediately. I think the former is better.
12) re-start router lsp acquiring and flooding optimization?
If the re-start router has one hundred IS-IS interfaces, at
restart, it will receive 100 copies of the databases from
all the interfaces assume all the neighbors can help. We
also need to flooding all of them to the other 99 interfaces
100 times. If we have a huge database, it can take a while;-)
I'm wondering if the re-starting router and all its neighbors
can periodically exchange a number of CSNP sets during this
synchronization process until the T3 expires on the re-starting
router, and until the neighbors sees a "normal" IIH from the
re-starting router. This way, the neighbors may not need to
send some redundant lsps, and the re-starting router may not
need to do unnecessary lsp flooding.
thanks.
- Naiming
From christi@nortelnetworks.com Sat Apr 20 12:45:43 2002
From: christi@nortelnetworks.com (Philip Christian)
Date: Sat, 20 Apr 2002 12:45:43 +0100
Subject: [Isis-wg] IS-IS on UPSR ring
Message-ID: <4103264BC8D3D51180B7002048400C454FB635@zhard0jd.europe.nortel.com>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C1E860.E5D46B14
Content-Type: text/plain;
charset="iso-8859-1"
I cannot answer the question about unidirectional rings. UPSR is a North
American thing. My expertise is International market SDH.
However I can give you an OPINION on the second question,
I would advice anyone building Integrated IS-IS into a SONET/SDH ADM to
address the next hop using the System Identifier (NSAP) of the next hop.
Because the routing instance on SONET/SDH ADMs is often running on very
limited resourses, it can be important to keep the size of routing tables
down.
One solution that people are looking at is to use a single prefix per ADM,
as a circuitless interface, and to run the PPP or LAPD over DCC links
unnumbered. There is even some discussion around connecting ADMs together
using Ethernet cables, and not assigning any IP address/subnet mask to the
LAN ports either.
If a link is unnumbered then I suppose that you should put your circuitless
interface IP address in as the "Interface IP address" TLV in Hellos. I
haven't figured out yet if this will enable ICMP redirects to work on LAN
ports.
In order to interwork with such a solution, your cannot rely on ARP to find
a neighbouring router (you have to use IS-IS to resolve MAC address to
NSAP), and you can't refer to the next hop as an IP address (it might not
have one). Better to use NSAPs.
Note that Integrated IS-IS does allow IP subnetting rules to be broken for
connecting routers together, but of course the router needs a correct subnet
to be able to ARP for hosts on a LAN port. However if there are no hosts,
just two routers then you can't rely on ARP working.
You could argue that ARP and correct subnetting isn't needed for connecting
two routers together.
That said, if you want to guarantee interop with stand alone Integrated
IS-IS routers, then you had better support ARPing on LAN interfaces too (if
your customer has configured in an IP address / subnet mask). Note that SOME
standalone routers will not bring up an adjacency on LAN ports unless they
consider their neighbour to be in the same subnet as themselves.
That's my opinion.
Philip
-----Original Message-----
From: Lawrence Mao [mailto:lqmao@yahoo.com]
Sent: Saturday, April 20, 2002 12:33 AM
To: isis-wg@spider.juniper.net
Subject: [Isis-wg] IS-IS on UPSR ring
Hi all,
If the IS-IS needs to be supported on a SONET
UPSR ring, throught its DCC channel (note that
the ring is uni-directional), say, if I have 4
nodes on a ring:
A --> B --> C --> D -
^ |
|--------------------
what kind of modifications need to be made in
order to let the protocol work properly (note
all interfaces are p2p type)?
2nd question is, if the interface is unnumbered,
how is its routing table generated? Use routerID?
Thanks,
--
Lawrence
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
_______________________________________________
Isis-wg mailing list - Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg
------_=_NextPart_001_01C1E860.E5D46B14
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
RE: [Isis-wg] IS-IS on UPSR ring
I cannot answer the question about unidirectional =
rings. UPSR is a North American thing. My expertise is International =
market SDH.
However I can give you an OPINION on the second =
question,
I would advice anyone building Integrated IS-IS into =
a SONET/SDH ADM to address the next hop using the System Identifier =
(NSAP) of the next hop.
Because the routing instance on SONET/SDH ADMs is =
often running on very limited resourses, it can be important to keep =
the size of routing tables down.
One solution that people are looking at is to use a =
single prefix per ADM, as a circuitless interface, and to run the PPP =
or LAPD over DCC links unnumbered. There is even some discussion =
around connecting ADMs together using Ethernet cables, and not =
assigning any IP address/subnet mask to the LAN ports =
either.
If a link is unnumbered then I suppose that you =
should put your circuitless interface IP address in as the =
"Interface IP address" TLV in Hellos. I haven't figured =
out yet if this will enable ICMP redirects to work on LAN =
ports.
In order to interwork with such a solution, your =
cannot rely on ARP to find a neighbouring router (you have to use IS-IS =
to resolve MAC address to NSAP), and you can't refer to the next hop as =
an IP address (it might not have one). Better to use NSAPs.
Note that Integrated IS-IS does allow IP subnetting =
rules to be broken for connecting routers together, but of course the =
router needs a correct subnet to be able to ARP for hosts on a LAN =
port. However if there are no hosts, just two routers then you =
can't rely on ARP working.
You could argue that ARP and correct subnetting isn't =
needed for connecting two routers together.
That said, if you want to guarantee interop with =
stand alone Integrated IS-IS routers, then you had better support =
ARPing on LAN interfaces too (if your customer has configured in an IP =
address / subnet mask). Note that SOME standalone routers will not =
bring up an adjacency on LAN ports unless they consider their neighbour =
to be in the same subnet as themselves.
That's my opinion.
Philip
-----Original Message-----
From: Lawrence Mao [mailto:lqmao@yahoo.com]
Sent: Saturday, April 20, 2002 12:33 AM
To: isis-wg@spider.juniper.net
Subject: [Isis-wg] IS-IS on UPSR ring
Hi all,
If the IS-IS needs to be supported on a SONET
UPSR ring, throught its DCC channel (note =
that
the ring is uni-directional), say, if I have =
4
nodes on a ring:
A --> B --> C --> D =
-
=
^  =
; |
|--------------------
what kind of modifications need to be made in
order to let the protocol work properly (note
all interfaces are p2p type)?
2nd question is, if the interface is =
unnumbered,
how is its routing table generated? Use =
routerID?
Thanks,
--
Lawrence
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with =
TurboTax
http://taxes.yahoo.com/
_______________________________________________
Isis-wg mailing list - =
Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg=
------_=_NextPart_001_01C1E860.E5D46B14--
From dkatz@juniper.net Sat Apr 20 18:31:16 2002
From: dkatz@juniper.net (Dave Katz)
Date: Sat, 20 Apr 2002 10:31:16 -0700 (PDT)
Subject: [Isis-wg] a few comments on ietf restart isis draft
In-Reply-To: <20020420065230.CDC0039B5AF@prattle.redback.com> (message from
Naiming Shen on Fri, 19 Apr 2002 23:52:30 -0700)
References: <20020420065230.CDC0039B5AF@prattle.redback.com>
Message-ID: <200204201731.g3KHVGU03946@cirrus.juniper.net>
(2) page 4, the 2nd paragraph,
"a) DO NOT refresh the timer on the adjacency, ..."
I have big problem with this. The receiving router has a good
adjacency to the neighbor which just restarted, this neighbor
asks for help. The restarting neighbor sent out an IIH
containing RR bit set, and also has its "holding time" value
in this IIH. Why should the receiving router not to refresh the
timer using the latest "holding time" value in this re-start IIH?
Nischal came up with a variant of this which accomplishes both goals--
accept the hold time from the IIH that causes you to become a restart
helper, and then don't refresh after that.
This allows scheduled restarts while normally using hold times too
short to accomplish the restart. Imagine running with one second hold
times--the restarting router could change its announced hold time to
20 seconds in the RR IIH and then restart at its leisure.
This still provides bounding for the restart period, just a wee bit longer
than it would have been otherwise (at worst the "normal" hold time plus
the "restart" hold time.)
From naiming@redback.com Sat Apr 20 20:24:03 2002
From: naiming@redback.com (Naiming Shen)
Date: Sat, 20 Apr 2002 12:24:03 -0700
Subject: [Isis-wg] a few comments on ietf restart isis draft
In-Reply-To: Mail from Dave Katz
dated Sat, 20 Apr 2002 10:31:16 PDT
<200204201731.g3KHVGU03946@cirrus.juniper.net>
Message-ID: <20020420192403.C6FB64F41B9@prattle.redback.com>
] (2) page 4, the 2nd paragraph,
]
] "a) DO NOT refresh the timer on the adjacency, ..."
]
] I have big problem with this. The receiving router has a good
] adjacency to the neighbor which just restarted, this neighbor
] asks for help. The restarting neighbor sent out an IIH
] containing RR bit set, and also has its "holding time" value
] in this IIH. Why should the receiving router not to refresh the
] timer using the latest "holding time" value in this re-start IIH?
]
] Nischal came up with a variant of this which accomplishes both goals--
] accept the hold time from the IIH that causes you to become a restart
] helper, and then don't refresh after that.
why not refresh after that? I think we should always refresh. Well,
it's an implementation issue also, then I don't go into that.
there are two cases of restart, scheduled and unscheduled.
for scheduled one: since you know you are going down, and you know
how long it will take, then send out a "normal"(not with RR bit set)
IIH with long-holding-time value, so the neighbor does not even
know its a helper, but will hold this adjacnecy for that long.
If you set RR bit on this IIH before you going down, I don't think
this is good. Since the helper will keep sending LSPs to you
which is a waste of resource.
At scheduled restart come back, you should send the IIH with RR bit
one, this is just part of the the normal re-start. This turns the
neighbor into the helper, and it SHOULD refresh the holdtime.
for unscheduled scheduled one: its the same as the last paragraph,
the IIH turns the neighbor into the helper. So the only difference
between those two cases should be the first one will send a normal
IIH with large value of holdtime before going down.
There is no problem of refreshing it afterwards, since the re-start
router is not suppose to send any IIH until the all the adjacencies
are well established(T3 expires as in the draft), so it will be
good to always refresh the holdtime, no exceptions.
thanks.
]
] This allows scheduled restarts while normally using hold times too
] short to accomplish the restart. Imagine running with one second hold
] times--the restarting router could change its announced hold time to
] 20 seconds in the RR IIH and then restart at its leisure.
]
] This still provides bounding for the restart period, just a wee bit longer
] than it would have been otherwise (at worst the "normal" hold time plus
] the "restart" hold time.)
- Naiming
From jlearman@cisco.com Mon Apr 22 15:15:17 2002
From: jlearman@cisco.com (Jeff Learman)
Date: Mon, 22 Apr 2002 10:15:17 -0400
Subject: [Isis-wg] IS-IS on UPSR ring
In-Reply-To: <20020419233323.98158.qmail@web11604.mail.yahoo.com>
Message-ID: <4.3.2.7.2.20020422094230.038f1b78@dingdong.cisco.com>
Laurence,
This isn't really an IS-IS question, it's a SONET question. For SONET
DCC, you run IS-IS over LAP-B (or possibly PPP). In either case, dual
fiber counter-directional rings are required. To the software, you must
make it look like there is a bidirectional link between A and B, using
the clockwise ring for transmit and the counterclockwise ring for
receive.
For single-fiber rings, you would need a proprietary solution. You
could try something like Token Ring at the link layer and make the
ring look like a TR broadcast LAN.
Regards,
Jeff
At 07:33 PM 4/19/2002, Lawrence Mao wrote:
>Hi all,
>
>If the IS-IS needs to be supported on a SONET
>UPSR ring, throught its DCC channel (note that
>the ring is uni-directional), say, if I have 4
>nodes on a ring:
>
> A --> B --> C --> D -
> ^ |
> |--------------------
>
>what kind of modifications need to be made in
>order to let the protocol work properly (note
>all interfaces are p2p type)?
>
>2nd question is, if the interface is unnumbered,
>how is its routing table generated? Use routerID?
>
>Thanks,
>--
>Lawrence
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Tax Center - online filing with TurboTax
>http://taxes.yahoo.com/
>_______________________________________________
>Isis-wg mailing list - Isis-wg@spider.juniper.net
>http://spider.juniper.net/mailman/listinfo/isis-wg
From christi@nortelnetworks.com Mon Apr 22 15:26:27 2002
From: christi@nortelnetworks.com (Philip Christian)
Date: Mon, 22 Apr 2002 15:26:27 +0100
Subject: [Isis-wg] IS-IS on UPSR ring
Message-ID: <4103264BC8D3D51180B7002048400C454FB63A@zhard0jd.europe.nortel.com>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C1EA09.B04306F4
Content-Type: text/plain;
charset="iso-8859-1"
Specifically (according to G.7712):-
IP-only Integrated IS-IS NEs use PPP over HDLC in DCC.
OSI-only IS-IS NEs use LAPD over DCC.
Dual Integrated IS-IS NEs need a switchable (PPP or LAPD) data link layer.
Philip
> -----Original Message-----
> From: Jeff Learman [mailto:jlearman@cisco.com]
> Sent: 22 April 2002 15:15
> To: Lawrence Mao
> Cc: isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] IS-IS on UPSR ring
>
>
>
> Laurence,
>
> This isn't really an IS-IS question, it's a SONET question. For SONET
> DCC, you run IS-IS over LAP-B (or possibly PPP). In either case, dual
> fiber counter-directional rings are required. To the
> software, you must
> make it look like there is a bidirectional link between A and B, using
> the clockwise ring for transmit and the counterclockwise ring for
> receive.
>
> For single-fiber rings, you would need a proprietary solution. You
> could try something like Token Ring at the link layer and make the
> ring look like a TR broadcast LAN.
>
> Regards,
> Jeff
>
> At 07:33 PM 4/19/2002, Lawrence Mao wrote:
> >Hi all,
> >
> >If the IS-IS needs to be supported on a SONET
> >UPSR ring, throught its DCC channel (note that
> >the ring is uni-directional), say, if I have 4
> >nodes on a ring:
> >
> > A --> B --> C --> D -
> > ^ |
> > |--------------------
> >
> >what kind of modifications need to be made in
> >order to let the protocol work properly (note
> >all interfaces are p2p type)?
> >
> >2nd question is, if the interface is unnumbered,
> >how is its routing table generated? Use routerID?
> >
> >Thanks,
> >--
> >Lawrence
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Tax Center - online filing with TurboTax
> >http://taxes.yahoo.com/
> >_______________________________________________
> >Isis-wg mailing list - Isis-wg@spider.juniper.net
> >http://spider.juniper.net/mailman/listinfo/isis-wg
>
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>
------_=_NextPart_001_01C1EA09.B04306F4
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
RE: [Isis-wg] IS-IS on UPSR ring
Specifically (according to G.7712):-
IP-only Integrated IS-IS NEs use PPP over HDLC in =
DCC.
OSI-only IS-IS NEs use LAPD over DCC.
Dual Integrated IS-IS NEs need a switchable (PPP or =
LAPD) data link layer.
Philip
> -----Original Message-----
> From: Jeff Learman [mailto:jlearman@cisco.com]=
> Sent: 22 April 2002 15:15
> To: Lawrence Mao
> Cc: isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] IS-IS on UPSR =
ring
>
>
>
> Laurence,
>
> This isn't really an IS-IS question, it's a =
SONET question. For SONET
> DCC, you run IS-IS over LAP-B (or possibly =
PPP). In either case, dual
> fiber counter-directional rings are =
required. To the
> software, you must
> make it look like there is a bidirectional link =
between A and B, using
> the clockwise ring for transmit and the =
counterclockwise ring for
> receive.
>
> For single-fiber rings, you would need a =
proprietary solution. You
> could try something like Token Ring at the link =
layer and make the
> ring look like a TR broadcast LAN.
>
> Regards,
> Jeff
>
> At 07:33 PM 4/19/2002, Lawrence Mao =
wrote:
> >Hi all,
> >
> >If the IS-IS needs to be supported on a =
SONET
> >UPSR ring, throught its DCC channel (note =
that
> >the ring is uni-directional), say, if I =
have 4
> >nodes on a ring:
> >
> > A --> B --> C =
--> D -
> > =
^  =
; |
> > =
|--------------------
> >
> >what kind of modifications need to be made =
in
> >order to let the protocol work properly =
(note
> >all interfaces are p2p type)?
> >
> >2nd question is, if the interface is =
unnumbered,
> >how is its routing table generated? Use =
routerID?
> >
> >Thanks,
> >--
> >Lawrence
> >
> =
>__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Tax Center - online filing with =
TurboTax
> >http://taxes.yahoo.com/
> =
>_______________________________________________
> >Isis-wg mailing list - =
Isis-wg@spider.juniper.net
> >http://spider.juniper.net/mailman/listinfo/isis-wg=
>
> =
_______________________________________________
> Isis-wg mailing list - =
Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg=
>
------_=_NextPart_001_01C1EA09.B04306F4--
From truskows@cisco.com Mon Apr 22 15:28:41 2002
From: truskows@cisco.com (Mike Truskowski)
Date: Mon, 22 Apr 2002 07:28:41 -0700 (PDT)
Subject: [Isis-wg] IS-IS on UPSR ring
In-Reply-To: <4.3.2.7.2.20020422094230.038f1b78@dingdong.cisco.com> from Jeff Learman at Apr "22," 2002 "10:15:17" am
Message-ID: <200204221428.HAA23847@wells.cisco.com>
Lawrence,
Who do you work for?
Mike
>
> Laurence,
>
> This isn't really an IS-IS question, it's a SONET question. For SONET
> DCC, you run IS-IS over LAP-B (or possibly PPP). In either case, dual
> fiber counter-directional rings are required. To the software, you must
> make it look like there is a bidirectional link between A and B, using
> the clockwise ring for transmit and the counterclockwise ring for
> receive.
>
> For single-fiber rings, you would need a proprietary solution. You
> could try something like Token Ring at the link layer and make the
> ring look like a TR broadcast LAN.
>
> Regards,
> Jeff
>
> At 07:33 PM 4/19/2002, Lawrence Mao wrote:
> >Hi all,
> >
> >If the IS-IS needs to be supported on a SONET
> >UPSR ring, throught its DCC channel (note that
> >the ring is uni-directional), say, if I have 4
> >nodes on a ring:
> >
> > A --> B --> C --> D -
> > ^ |
> > |--------------------
> >
> >what kind of modifications need to be made in
> >order to let the protocol work properly (note
> >all interfaces are p2p type)?
> >
> >2nd question is, if the interface is unnumbered,
> >how is its routing table generated? Use routerID?
> >
> >Thanks,
> >--
> >Lawrence
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Tax Center - online filing with TurboTax
> >http://taxes.yahoo.com/
> >_______________________________________________
> >Isis-wg mailing list - Isis-wg@spider.juniper.net
> >http://spider.juniper.net/mailman/listinfo/isis-wg
>
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>
From truskows@cisco.com Mon Apr 22 15:52:28 2002
From: truskows@cisco.com (Mike Truskowski)
Date: Mon, 22 Apr 2002 07:52:28 -0700 (PDT)
Subject: [Isis-wg] IS-IS on UPSR ring
In-Reply-To: <4103264BC8D3D51180B7002048400C454FB63A@zhard0jd.europe.nortel.com> from Philip Christian at Apr "22," 2002 "03:26:27" pm
Message-ID: <200204221452.HAA17224@wells.cisco.com>
--ELM1019487148-21486-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
G.7712 also states that OSPF is an option.
:-)
Mike
--ELM1019487148-21486-0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Description: /tmp/BAAa21486
Content-Transfer-Encoding: 7bit
Specifically (according to G.7712):-
IP-only Integrated IS-IS NEs use PPP over HDLC in DCC.
OSI-only IS-IS NEs use LAPD over DCC.
Dual Integrated IS-IS NEs need a switchable (PPP or LAPD) data link layer.
Philip
> -----Original Message-----
> From: Jeff Learman [mailto:jlearman@cisco.com]
> Sent: 22 April 2002 15:15
> To: Lawrence Mao
> Cc: isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] IS-IS on UPSR ring
>
>
>
> Laurence,
>
> This isn't really an IS-IS question, it's a SONET question. For SONET
> DCC, you run IS-IS over LAP-B (or possibly PPP). In either case, dual
> fiber counter-directional rings are required. To the
> software, you must
> make it look like there is a bidirectional link between A and B, using
> the clockwise ring for transmit and the counterclockwise ring for
> receive.
>
> For single-fiber rings, you would need a proprietary solution. You
> could try something like Token Ring at the link layer and make the
> ring look like a TR broadcast LAN.
>
> Regards,
> Jeff
>
> At 07:33 PM 4/19/2002, Lawrence Mao wrote:
> >Hi all,
> >
> >If the IS-IS needs to be supported on a SONET
> >UPSR ring, throught its DCC channel (note that
> >the ring is uni-directional), say, if I have 4
> >nodes on a ring:
> >
> > A --> B --> C --> D -
> > ^ |
> > |--------------------
> >
> >what kind of modifications need to be made in
> >order to let the protocol work properly (note
> >all interfaces are p2p type)?
> >
> >2nd question is, if the interface is unnumbered,
> >how is its routing table generated? Use routerID?
> >
> >Thanks,
> >--
> >Lawrence
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Tax Center - online filing with TurboTax
> >http://taxes.yahoo.com/
> >_______________________________________________
> >Isis-wg mailing list - Isis-wg@spider.juniper.net
> >http://spider.juniper.net/mailman/listinfo/isis-wg
>
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>
--ELM1019487148-21486-0_
Content-Type: text/html; charset="iso-8859-1"
Content-Disposition: inline
Content-Description: /tmp/CAAa21486
Content-Transfer-Encoding: quoted-printable
RE: [Isis-wg] IS-IS on UPSR ring
Specifically (according to G.7712):-
IP-only Integrated IS-IS NEs use PPP over HDLC in =
DCC.
OSI-only IS-IS NEs use LAPD over DCC.
Dual Integrated IS-IS NEs need a switchable (PPP or =
LAPD) data link layer.
Philip
> -----Original Message-----
> From: Jeff Learman [mailto:jlearman@cisco.com]=
> Sent: 22 April 2002 15:15
> To: Lawrence Mao
> Cc: isis-wg@spider.juniper.net
> Subject: Re: [Isis-wg] IS-IS on UPSR =
ring
>
>
>
> Laurence,
>
> This isn't really an IS-IS question, it's a =
SONET question. For SONET
> DCC, you run IS-IS over LAP-B (or possibly =
PPP). In either case, dual
> fiber counter-directional rings are =
required. To the
> software, you must
> make it look like there is a bidirectional link =
between A and B, using
> the clockwise ring for transmit and the =
counterclockwise ring for
> receive.
>
> For single-fiber rings, you would need a =
proprietary solution. You
> could try something like Token Ring at the link =
layer and make the
> ring look like a TR broadcast LAN.
>
> Regards,
> Jeff
>
> At 07:33 PM 4/19/2002, Lawrence Mao =
wrote:
> >Hi all,
> >
> >If the IS-IS needs to be supported on a =
SONET
> >UPSR ring, throught its DCC channel (note =
that
> >the ring is uni-directional), say, if I =
have 4
> >nodes on a ring:
> >
> > A --> B --> C =
--> D -
> > =
^  =
; |
> > =
|--------------------
> >
> >what kind of modifications need to be made =
in
> >order to let the protocol work properly =
(note
> >all interfaces are p2p type)?
> >
> >2nd question is, if the interface is =
unnumbered,
> >how is its routing table generated? Use =
routerID?
> >
> >Thanks,
> >--
> >Lawrence
> >
> =
>__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Tax Center - online filing with =
TurboTax
> >http://taxes.yahoo.com/
> =
>_______________________________________________
> >Isis-wg mailing list - =
Isis-wg@spider.juniper.net
> >http://spider.juniper.net/mailman/listinfo/isis-wg=
>
> =
_______________________________________________
> Isis-wg mailing list - =
Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg=
>
--ELM1019487148-21486-0_--
From nsheth@juniper.net Mon Apr 22 18:53:42 2002
From: nsheth@juniper.net (Nischal Sheth)
Date: Mon, 22 Apr 2002 10:53:42 -0700
Subject: [Isis-wg] a few comments on ietf restart isis draft
References: <20020420192403.C6FB64F41B9@prattle.redback.com>
Message-ID: <3CC44E26.4090909@juniper.net>
Naiming Shen wrote:
> ] (2) page 4, the 2nd paragraph,
> ]
> ] "a) DO NOT refresh the timer on the adjacency, ..."
> ]
> ] I have big problem with this. The receiving router has a good
> ] adjacency to the neighbor which just restarted, this neighbor
> ] asks for help. The restarting neighbor sent out an IIH
> ] containing RR bit set, and also has its "holding time" value
> ] in this IIH. Why should the receiving router not to refresh the
> ] timer using the latest "holding time" value in this re-start IIH?
> ]
> ] Nischal came up with a variant of this which accomplishes both goals--
> ] accept the hold time from the IIH that causes you to become a restart
> ] helper, and then don't refresh after that.
>
> why not refresh after that? I think we should always refresh. Well,
> it's an implementation issue also, then I don't go into that.
>
Naiming,
Not refreshing after the first time can help cover two possible corner
cases:
o the restarting router crashes again while coming up
o the hello with the restart ACK gets lost
I agree that it's much better to refresh the timer on the adjacency than
not to (like the draft says currently). Whether to do it the first time
or every time is up to the implementation.
Thanks,
Nischal.
From lqmao@yahoo.com Mon Apr 22 21:45:27 2002
From: lqmao@yahoo.com (Lawrence Mao)
Date: Mon, 22 Apr 2002 13:45:27 -0700 (PDT)
Subject: [Isis-wg] IS-IS on UPSR ring
Message-ID: <20020422204527.79867.qmail@web11607.mail.yahoo.com>
Thanks for all the replies.
I understand the approach of Token Ring at layer 2
for single-fiber rings. But what if we could not
change the code in the link layer (PPP or LAPD), and
modifying the IS-IS code would be the only way to do?
Then I am wondering what the minimum code changes are
needed, areas such as neighbor adjacency, PSNP ACK,
SPF calculation, etc.?
Thanks,
--
Lawrence
------------------------------------------------------
Laurence,
This isn't really an IS-IS question, it's a SONET
question. For SONET
DCC, you run IS-IS over LAP-B (or possibly PPP). In
either case, dual
fiber counter-directional rings are required. To the
software, you must
make it look like there is a bidirectional link
between A and B, using
the clockwise ring for transmit and the
counterclockwise ring for
receive.
For single-fiber rings, you would need a proprietary
solution. You
could try something like Token Ring at the link layer
and make the
ring look like a TR broadcast LAN.
Regards,
Jeff
At 07:33 PM 4/19/2002, Lawrence Mao wrote:
>Hi all,
>
>If the IS-IS needs to be supported on a SONET
>UPSR ring, throught its DCC channel (note that
>the ring is uni-directional), say, if I have 4
>nodes on a ring:
>
> A --> B --> C --> D -
> ^ |
> |--------------------
>
>what kind of modifications need to be made in
>order to let the protocol work properly (note
>all interfaces are p2p type)?
>
>2nd question is, if the interface is unnumbered,
>how is its routing table generated? Use routerID?
>
>Thanks,
>--
>Lawrence
__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
From naiming@redback.com Tue Apr 23 05:48:18 2002
From: naiming@redback.com (Naiming Shen)
Date: Mon, 22 Apr 2002 21:48:18 -0700
Subject: [Isis-wg] a few comments on ietf restart isis draft
In-Reply-To: Mail from Nischal Sheth
dated Mon, 22 Apr 2002 10:53:42 PDT
<3CC44E26.4090909@juniper.net>
Message-ID: <20020423044818.B06A5CAB7A@prattle.redback.com>
Hi Nischal,
I agree that "first time" or "every time" is an implementation detail.
Here I just want to cover the two corner cases for someone wants to
implement "every time" refresh.
] o the restarting router crashes again while coming up
If we want to prevent a neighbor repeated restart again and again,
we can put a counter for the restart adjacency, if exceeds the limit,
tear down the adjacency. So even if we refresh the holding time
for every re-start IIH, thats ok. The advantage of refreshing every
time in this case is that, it gives every restart the same chance.
Why does anyone need this? for some implementation, if a router tries
a new version of software 3 times and all crashes, it can bring back
the older version of software. In this case, the 4th restart will still
have enough time to succeed.
Just some implementation detail.
] o the hello with the restart ACK gets lost
If the restart ACK gets lost, or if the restart IIH gets lost,
according to the draft, we'll resend the restart IIH again. If they
are lost again, .... So basically the same issue as the first case,
do we want to deduct time from each restart IIH, or do we want to
give each the same chance. Thus it's the same implementation detail.
I personally don't even think we should resend again if they got lost.
thanks.
]
] I agree that it's much better to refresh the timer on the adjacency than
] not to (like the draft says currently). Whether to do it the first time
] or every time is up to the implementation.
]
] Thanks,
] Nischal.
- Naiming
From VishwasM@netplane.com Tue Apr 23 10:06:28 2002
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Tue, 23 Apr 2002 05:06:28 -0400
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Message-ID:
Hi Amir/Stefano/Mike,
I read thru ur draft and had an alternate idea in mind. I wanted to know
what you thought of it.
Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
The idea is to have a new TLV, which tells the actual LSP number. The LSP
number in the psudonode-id is not used. The changes required are minimum. We
anyway scan thru TLV's for authentication information, we can find the LSP
number TLV then. We instead use this TLV.
To migrate to such a method all we need to do is to, use same LSP numbers in
the header and the TLV, and once all routers recognize the TLV, we actually
can use different numbers. This does not create any backward compatibility
issues and so we dont need two methods. In this case we do not need to worry
about Attached bit, Partition repair bit or change to SPF calculations etc.
The solution also seems a logical extension, to the constraint caused by 8
bit LSP number value. Rather than a solution that has multiple system id's
which is like fooling the IS to believe all the systems are the same.
Thanks,
Vishwas
From Internet-Drafts@ietf.org Tue Apr 23 12:13:22 2002
From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org)
Date: Tue, 23 Apr 2002 07:13:22 -0400
Subject: [Isis-wg] I-D ACTION:draft-ietf-isis-gmpls-extensions-10.txt
Message-ID: <200204231113.HAA11739@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 et al.
Filename : draft-ietf-isis-gmpls-extensions-10.txt
Pages : 11
Date : 22-Apr-02
This document specifies encoding of extensions to the IS-IS routing
protocol in support of Generalized Multi-Protocol Label Switching.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-10.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-10.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-10.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: <20020422135137.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-isis-gmpls-extensions-10.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-isis-gmpls-extensions-10.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20020422135137.I-D@ietf.org>
--OtherAccess--
--NextPart--
From mshand@cisco.com Tue Apr 23 13:43:28 2002
From: mshand@cisco.com (mike shand)
Date: Tue, 23 Apr 2002 13:43:28 +0100
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
In-Reply-To:
Message-ID: <4.3.2.7.2.20020423133001.00b71660@jaws.cisco.com>
I'm not sure I fully understand this proposal. I assume that when you
actually start using extended numbers you still need to invent additional
system ID's for the extra "fragments" so that the update process can
distinguish them. In which case it is semantically identical to the current
scheme.
Or are you proposing changing the update process so that it looks at the
new TLV? I guess that must be what you have in mind. This has fairly
serious consequences if you have migrated to extended numbers, but you then
introduce a router which doesn't understand the new update process. I
thought we had already considered and rejected solutions of this type.
Mike
At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
>Hi Amir/Stefano/Mike,
>
>I read thru ur draft and had an alternate idea in mind. I wanted to know
>what you thought of it.
>
>Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
>
>The idea is to have a new TLV, which tells the actual LSP number. The LSP
>number in the psudonode-id is not used. The changes required are minimum. We
>anyway scan thru TLV's for authentication information, we can find the LSP
>number TLV then. We instead use this TLV.
>
>To migrate to such a method all we need to do is to, use same LSP numbers in
>the header and the TLV, and once all routers recognize the TLV, we actually
>can use different numbers. This does not create any backward compatibility
>issues and so we dont need two methods. In this case we do not need to worry
>about Attached bit, Partition repair bit or change to SPF calculations etc.
>The solution also seems a logical extension, to the constraint caused by 8
>bit LSP number value. Rather than a solution that has multiple system id's
>which is like fooling the IS to believe all the systems are the same.
>
>Thanks,
>Vishwas
>_______________________________________________
>Isis-wg mailing list - Isis-wg@spider.juniper.net
>http://spider.juniper.net/mailman/listinfo/isis-wg
From VishwasM@netplane.com Tue Apr 23 16:21:28 2002
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Tue, 23 Apr 2002 11:21:28 -0400
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Message-ID:
Hi Mike,
Thanks for the reply.
I do not understand if we have migrated to a bigger LSp number, why we would
bring in a router that still uses a smaller LSP number, even when we know it
could create problems. This problem can occur in all cases of migration
a) to domain wide
b) wide metrics
I do not see why we should introduce a two pronged method to do something
which we can do pretty easily with just a TLV change, when similar
approaches have been taken for other cases. Even in domain wide if a router
came in which did not use external reachability in cases of L1 area the same
problem would occur. I do not find the reason convincing enough to be
rejected. ;-)
Thanks,
Vishwas
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: Tuesday, April 23, 2002 6:13 PM
To: Manral, Vishwas
Cc: 'isis-wg@spider.juniper.net'
Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
I'm not sure I fully understand this proposal. I assume that when you
actually start using extended numbers you still need to invent additional
system ID's for the extra "fragments" so that the update process can
distinguish them. In which case it is semantically identical to the current
scheme.
Or are you proposing changing the update process so that it looks at the
new TLV? I guess that must be what you have in mind. This has fairly
serious consequences if you have migrated to extended numbers, but you then
introduce a router which doesn't understand the new update process. I
thought we had already considered and rejected solutions of this type.
Mike
At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
>Hi Amir/Stefano/Mike,
>
>I read thru ur draft and had an alternate idea in mind. I wanted to know
>what you thought of it.
>
>Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
>
>The idea is to have a new TLV, which tells the actual LSP number. The LSP
>number in the psudonode-id is not used. The changes required are minimum.
We
>anyway scan thru TLV's for authentication information, we can find the LSP
>number TLV then. We instead use this TLV.
>
>To migrate to such a method all we need to do is to, use same LSP numbers
in
>the header and the TLV, and once all routers recognize the TLV, we actually
>can use different numbers. This does not create any backward compatibility
>issues and so we dont need two methods. In this case we do not need to
worry
>about Attached bit, Partition repair bit or change to SPF calculations etc.
>The solution also seems a logical extension, to the constraint caused by 8
>bit LSP number value. Rather than a solution that has multiple system id's
>which is like fooling the IS to believe all the systems are the same.
>
>Thanks,
>Vishwas
>_______________________________________________
>Isis-wg mailing list - Isis-wg@spider.juniper.net
>http://spider.juniper.net/mailman/listinfo/isis-wg
From Radia Perlman - Boston Center for Networking Wed Apr 24 00:45:53 2002
From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking)
Date: Tue, 23 Apr 2002 19:45:53 -0400 (EDT)
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
Message-ID: <200204232345.TAA10336@bcn.East.Sun.COM>
Assuming I'm not misreading the spec, it looks like the assumption is
that there are the following secrets:
a) an area-wide secret
b) a link secret, for each link
c) a domain secret
And it looks like Hellos use the link secret, LSPs and SNPs use the
area-wide secret (unless they are level 2 in which case they use the
domain secret).
A few questions:
1) I'd assume that SNPs should use the link secret, since they are
not forwarded
2) I remember IS-IS having a set of acceptable receive secrets,
and a single transmit password, so that secret rollover wouldn't
be a problem. This draft seems to imply there's only a single one.
3) Shouldn't there be a separate layer 1 and layer 2 link secret?
(Again, I think I remember that from DECnet).
Also, it's not traditional for an author to thank himself in
the acknowledgements :-)
Radia
From tli@procket.com Wed Apr 24 01:52:53 2002
From: tli@procket.com (Tony Li)
Date: Tue, 23 Apr 2002 17:52:53 -0700
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
In-Reply-To: <200204232345.TAA10336@bcn.East.Sun.COM>
References: <200204232345.TAA10336@bcn.East.Sun.COM>
Message-ID: <15558.485.501119.780417@alpha-tli.procket.com>
| 1) I'd assume that SNPs should use the link secret, since they are
| not forwarded
Yes, but they can be replicated on multiple links. This simplifies
implementation.
| 2) I remember IS-IS having a set of acceptable receive secrets,
| and a single transmit password, so that secret rollover wouldn't
| be a problem. This draft seems to imply there's only a single one.
That is certainly an implementation option.
| 3) Shouldn't there be a separate layer 1 and layer 2 link secret?
| (Again, I think I remember that from DECnet).
What is gained from this? [Side question: what is gained from multiple
secrets anyhow?] I know of no installations where someone would allow an
L1 adjacency but not an L2. Seems like it could be simplified...
Tony
From ginsberg@pluris.com Wed Apr 24 03:34:41 2002
From: ginsberg@pluris.com (Les Ginsberg)
Date: Tue, 23 Apr 2002 19:34:41 -0700
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F97B@avalon.pluris.com>
> 1) I'd assume that SNPs should use the link secret, since they are
> not forwarded
>
SNPs use area/domain passwords as specified in ISO 10589 7.3.15.3a.
(and other places)
> 3) Shouldn't there be a separate layer 1 and layer 2 link secret?
> (Again, I think I remember that from DECnet).
>
ISO 10589 does not mention separate authentication info for Level1/Level2,
but some implementations support this.
Les
From mshand@cisco.com Wed Apr 24 14:53:26 2002
From: mshand@cisco.com (mike shand)
Date: Wed, 24 Apr 2002 14:53:26 +0100
Subject: [Isis-wg] Re: a few comments on ietf restart isis draft
In-Reply-To: <20020420065230.CDC0039B5AF@prattle.redback.com>
Message-ID: <4.3.2.7.2.20020424135645.04152420@jaws.cisco.com>
At 23:52 19/04/2002 -0700, Naiming Shen wrote:
>Hi Mike,
>
>I have a few comments on draft-ietf-isis-restart-00.txt, I apologize
>for the late discussion. It was in my "stuff I gotta read" folder
>for too long (something just learned from Jeff) ;-)
>
> (1) TLV code [TBD]
>
> seems we have a code for this now.
Yes. That needs to go in.
> (2) page 4, the 2nd paragraph,
>
> "a) DO NOT refresh the timer on the adjacency, ..."
>
> I have big problem with this. The receiving router has a good
> adjacency to the neighbor which just restarted, this neighbor
> asks for help. The restarting neighbor sent out an IIH
> containing RR bit set, and also has its "holding time" value
> in this IIH. Why should the receiving router not to refresh the
> timer using the latest "holding time" value in this re-start IIH?
>
> I think in this case, the receiving router is "lucky" enough to
> get an IIH(with RR bit) from the restarting router before it times
> this adjacency out, so the receiving router should do everything
> to help the neighbor to complete the restart process.
>
> for example: the receiving router only has 1 second left on this
> adjacency, and received the RR bit set IIH on this adjacency. This
> IIH has the "holding time" of 30 seconds. If it wants to help
> the neighbor to complete a good restart, should the receiving
> router times out this adjacency in 1 second, or should the receiving
> router holds on this adjacency for another 30 seconds? I would
> definitely go for the later.
>
> The only "harm" I can see if updating the timer is that, if the
> restart router after sending out the re-start IIHs, then crashed
> again and never come back. If this happens, then the convergence
> is a little slow, but this may not affect the forwarding and its
> a very rare case.
>
> Yes, the vendors should make the restart come back way before the
> neighbors holding time expires, but it may not always be so easy;
> Yes, the normal holding time can be configured long enough so it
> always handles whatever time restart takes, but that seems going
> the opposite direction from IGP milli-second convergence.
>
> I would change "DO NOT" into "MUST" here.
I think, given the various scenarios, we need a bit of flexibility here. My
intent was that the whole thing was "fail safe". i.e. if the restarting
router didn't come back up properly, the neighbors would drop their
adjacencies as if it had just plain failed. I didn't want the restarting
to delay the normal recovery.
However, I understand that some implementations may not be able to get back
up within this time, especially for short hello times, and that some
measure of "hello I'm back, could you just give me a little extra time to
get my act together" would be helpful. I like Nischal's suggestion here.
> 3) page 4, paragraph 3 and 4
>
> Probably need to say something explicitly about the ordering of
> those packets. If we have IIH(with RA bit), CSNPs and LSPs to be
> sent to help the neighbor restart, we need to make sure the IIH goes
> out first. Otherwise the CSNPs or LSPs can be dropped by
> the re-starting neighbor since it does not have an adjacency yet.
> "without waiting for any currently running timer interval to expire"
> may refer to the same idea, but it should be spelled out.
Yes. That was the idea. You need to get the IIH out first, but saying so
explicitly wouldn't hurt.
> 4) page 4, paragraph 5
>
> "i.e. if there was no adjacency"
>
> Should add "or the adjacency is not in the "UP" state".
Yes. Agreed.
> 5) page 4, last two paragraphs
>
> "contains an empty ..." and "option with state "Down" and with empty .."
>
> Probably those two sentences should be removed. Because on page 4 the
> first paragraph says:
>
> "irrespective of the other contents of the "Intermediate System
> Neighbors" option (LAN circuits), or the "Point-to-Point Adjacency
> State" option"...
>
> Which means, as long as the RR bit is set in this re-start tlv,
> we don't care about the ISN tlv is empty or NOT empty and we don't
> care about what state this IIH has. Which is good.
>
> I'm not just nit-picking on language here, basically this RR bit
> is a mechanism for IS-IS to re-acquire LSPs from neighbors. It can
> be used for some other applications other than graceful restart.
> In those cases, we don't want to send out empty ISN TLVs or in
> a "Down" state. Also we don't want the neighbors to ignore my
> "holding time" either;-) (see the comment #2).
Yes. I agree. I was being over prescriptive. I think I was just pointing
out that you didn't need to "know" that information or include it. But as
you say, there is no reason why you shouldn't if you want to.
> 6) levels of IIH with RR bit set
>
> The draft probably should say clearly about the levels:
>
> on the LAN, if both levels are active on the interface, it
> should send out two IIHs with the RR bit set, one for each
> level. The receiving router may respond with two IIHs with RA
> bit, one for each level where the adjacencies are in UP state.
> a) b) and c) on page 4 is for each level. on p2p intf, only send
> one IIH, but the receiving router still needs to check for
> both levels base on the adjacency usage to send out csnps and lsps.
Yes. I think someone else already pointed this out.
> 7) page 3, last paragraph
>
> This comment is closely related to comment #2.
>
> Assume we DO(opposite from the current draft) update the adjacency
> timer by the receiving router, then this "Remaining Time" field is
> no use here. This value set by the Receiving router would be the
> same as the "holding time" value in the IIH the re-start router
> just sent out. Thus this re-start TLV can use just one octet in
> length.
Yes. Of course the idea was to figure out how long you had been unconscious
when you woke up, and hence how much time you still had left.
You are right that if we refresh when we come back up we don't need this.
> The T3 is the minimum value of all the IS-IS intf holding times.
> And it can be figured out immediately without waiting for
> neighbors to tell us. It is based on local configure settings.
>
> I think about this way: it's reasonable to expect all the interfaces
> go through the similar amount of time to finish this re-start
> job. But if we ask the neighbors NOT updating the timers on
> the adjacencies, it will be very random. Some adjacencies will be
> timed out in 1 second, some will be in 20 seconds, etc. It's much
> better to ask them to time out me in, say 20 seconds, across
> the board. "Since I'm back, give me another chance, and I know
> my restart process takes xx seconds". Implementations can
> even offer a config knob to send a different(base on the
> local configuration size, network topology size and database size,
> also the vendor implementation, those are all closely related
> to the re-start time) holding time in this re-start IIH.
>
> T3 is the minimum of this "Remaining Time" right now. So if T3
> times out, all the normal IIHs are starting to go out on all
> the interfaces, this means, if one adjacency has low timeout
> from our neighbors, all our adjacencies may be affected during
> the restart since they sees the incomplete ISN TLVs in normal IIHs.
I think you've convinced me. Anyone think otherwise?
> 8) page 4, paragraph 4
>
> "excluding the transmitting router"
>
> An optimization would be, "excluding the transmitting router
> and only include the routers on the LAN who had re-start
> TLV in their IIHs". There maybe someone on the LAN running old
> code, that router just happen to have the highest priority but
> it can not help the restart neighbor with CSNP and LSPs. So
> some router with new code should step in now since the information
> is available.
Good idea. Yes.
> 9) page 5, first paragraph
>
> "On expiry of the timer T1, it is restarted and the IIH is
> re-transmitted as above."
>
> I take it that, this is to avoid the first IIH packet got
> lost, so let's retry. and have a maximum number of retry
> mentioned in page 6.
Yes.
> I think we should not even retry. This graceful restart is
> not meant to be bullet proof. If the IIHs happen to get lost,
> we just have a bad day. This is also the same problem if you
> have multiple neighbors on the same LAN. Your IIH can be lost
> to one of the neighbors, but as soon as you receive from
> other neighbors and complete the CSNPs, the T1 will be cancelled.
> But you have no way to know, that one neighbor didn't
> receive your re-start IIH, and it will reset the adjacency.
> The current scheme does not cover that case, and I think its
> not worth to have retries in general. Thus actually we don't
> even need the T1.
I'm not sure. I didn't like the idea that we may be stalled waiting for
multiple retries, but OTOH it goes against the grain to design a protocol
which "fails" on the loss of a single packet :-)
I guess the question is how many times will we sit around waiting for a
response when we will never get one, as opposed to the times when we
genuinely loose a packet and this allows us to re-start when we otherwise
wouldn't.
Any other opinions?
> 10) page 8, the 5th paragraph
>
> "are then flooded with the overload bit set to indicate that
> the router's LSPDB is not yet synchronized"
>
> I would be very careful setting OL bit here. T3 times out just
> means we are sending out normal IIHs, that should not affect
> anything even we have not acquired all the LSPs from neighbors
> or we haven't finished our SPF.
>
> The goal of this graceful restart is to do non-stop forwarding,
> if we send out our LSPs with OL on, it's not non-stop forwarding
> any more. Yes our SPF has not finished yet, so what's the hurry?
> why not let it to finish? Its much better to delay sending out
> our LSPs(assume topology has not changed during re-start) since
> routers in the area has our old LSPs containing the same
> information, than to send out LSPs immaturely with OL bit set.
The point is that we have time that we are prepared to run headless. That
time has expired. We may be generating all sorts of loops and confusion (or
we may not of course - we don't know). What do we do? Continue to screw up
the traffic, or admit defeat and take ourselves out? I suggest that the
only honest thing to do is the latter. We COULD do this by dropping all our
adjacencies and getting our neighbors to sends LSPs saying we had gone
away. However it seems cleaner simply to set our overload bit. This is
after all what we would expect to do if we were coming up without re-start
and we we were using the OL bit in this way.
However, it may be undesirable to actually insist on this behaviour. Maybe
it should say that if you are following the setting the OL bit when you
come up stuff, now would be a good time to do it.
> Also in 4.3.1.1, "with the overload bit clear", just a simple
> comment, some implementation/configurations couple this OL bit
> with bgp convergence, and usually bgp "converge" takes longer
> than the IGP lsp synchronization.
Yes, absolutely. It shouldn't say turn it off it should say stop turning it
on for this reason (or words to that effect).
> 11) 3way hello state
>
> The draft suggested to send the re-start IIH, with RR bit set,
> and 3way state in "Down" on the p2p interface. Assume the
> neighbor sends back the IIH with "UP" state with RA bit set.
> If we follow the 3way hello draft, we are in "Down", when
> receives an "Up", the result state is still "Down". And this
> is not good. We need to setup this adjacency to "Up" state
> immediately because we need to receive and accept CSNPs and
> LSPs over this link soon. So the draft needs to suggest the
> re-starting router either sending out the re-start IIH with
> "Init" or "Up" state, or specifying not to follow the 3way
> hello state table in this case and bring the adjacency up
> immediately. I think the former is better.
To be honest, I've completely forgotten why I wanted to send it in down
state. I agree absolutely that it needs to go straight into up on receipt
of the reply (and I thought it said that somewhere, but I can't find it).
So I guess what I thought was happening was the latter. If there is no
problem with sending in init or up, then I wouldn't object, but I'm sure
there was a good reason to avoid it. Maybe it will come back to me....
> 12) re-start router lsp acquiring and flooding optimization?
>
> If the re-start router has one hundred IS-IS interfaces, at
> restart, it will receive 100 copies of the databases from
> all the interfaces assume all the neighbors can help. We
> also need to flooding all of them to the other 99 interfaces
> 100 times.
Um... 100 times? Why? Yes we flood the first copy we see of each LSP to all
the other 99, but subsequent copies are just acked.
> If we have a huge database, it can take a while;-)
> I'm wondering if the re-starting router and all its neighbors
> can periodically exchange a number of CSNP sets during this
> synchronization process until the T3 expires on the re-starting
> router, and until the neighbors sees a "normal" IIH from the
> re-starting router.
I'm not sure how much this helps. 'A' sends us a bunch of LSPs, and we
flood them out to B through Z, which causes B through Z to clear SRMflags
for those LSPs (and set SSNflags instead on a p2p). Or if we already
receive it from (say B) we won't flood it - just set SSNflags back to A. It
would help of course if we randomized the order of LSP transmission. 10589
says to do this on LANs for exactly this reason, but doesn't require it on p2p.
I don't quite see how the extra CSNPs help. Unless you are saying you can
get a set of CSNPs out BEFORE you actually flood.
Or you could just start up on a few interfaces to begin with, and get the
bulk of LSPs over them, then turn on the rest and just get any remaining
LSPs. Of course you have to choose the "right" few:-)
I'm not sure whether these sort of optimizations need to be spelled out in
the spec. There is some considerable scope for individual implementations
ingenuity within the basic framework here. I don't think we want to
over-constrain.
> This way, the neighbors may not need to
> send some redundant lsps, and the re-starting router may not
> need to do unnecessary lsp flooding.
>
>
>thanks.
>- Naiming
Thanks for some good comments.
Mike
From VishwasM@netplane.com Wed Apr 24 15:07:47 2002
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Wed, 24 Apr 2002 10:07:47 -0400
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Message-ID:
Hi folks,
As I have not got the reply to my mail, I will try and restate(I guess I
wasn't clear) what the proposal is.
The idea is to have a new TLV called LSP Number TLV, which contains a 32 bit
LSP number. The new TLV is propagated in all LSP's and overrides the LSP
Number field in the header.
To migrate to this scheme, as long as all the routers in the network do not
support the new TLV, we use the same value in LSP number field in the header
as well as the TLV. Once all the routers in the network support the new TLV,
we can actually use the value of the LSP number TLV and ignore the LSP
number field in the header.
The solution in this scheme seems to be a logical extension to the limit
caused by an 8 bit LSP number field, using a 32 bit sequence number, rather
than the scheme where we need multiple system id's and then equating the
ID's.
The advantages of the scheme relative to the other scheme is: -
a) We use a simple migration scheme rather than a two step highly complex
scheme.
b) We need not worry about any change to routing table calculations.
c) No taking care of attached bit.
d) No taking care of partition bit.
e) We need not worry about which links use what system id(as in the other
scheme) and hence a lot of configuration.
f) The amount of code changes are minimal.
Regarding Mike's comment(I hope I got it right, Mike?) what happens when a
new router that does not support the functionality comes up. Although the
assumption with the other drafts like domain-wide and wide metrics is that
once we migrate to a scheme, we will not try and bother about the older
scheme, the same problem would occur in the other draft too if a new router
came up after we had migrated to method 2, and someone did not understand
the ISIS Alias TLV described there. Routing loops could very easily occur
there.
Any comments/criticism invited.
Thanks a lot,
Vishwas
-----Original Message-----
From: Manral, Vishwas [mailto:VishwasM@netplane.com]
Sent: Tuesday, April 23, 2002 8:51 PM
To: 'mike shand'
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Hi Mike,
Thanks for the reply.
I do not understand if we have migrated to a bigger LSp number, why we would
bring in a router that still uses a smaller LSP number, even when we know it
could create problems. This problem can occur in all cases of migration
a) to domain wide
b) wide metrics
I do not see why we should introduce a two pronged method to do something
which we can do pretty easily with just a TLV change, when similar
approaches have been taken for other cases. Even in domain wide if a router
came in which did not use external reachability in cases of L1 area the same
problem would occur. I do not find the reason convincing enough to be
rejected. ;-)
Thanks,
Vishwas
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: Tuesday, April 23, 2002 6:13 PM
To: Manral, Vishwas
Cc: 'isis-wg@spider.juniper.net'
Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
I'm not sure I fully understand this proposal. I assume that when you
actually start using extended numbers you still need to invent additional
system ID's for the extra "fragments" so that the update process can
distinguish them. In which case it is semantically identical to the current
scheme.
Or are you proposing changing the update process so that it looks at the
new TLV? I guess that must be what you have in mind. This has fairly
serious consequences if you have migrated to extended numbers, but you then
introduce a router which doesn't understand the new update process. I
thought we had already considered and rejected solutions of this type.
Mike
At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
>Hi Amir/Stefano/Mike,
>
>I read thru ur draft and had an alternate idea in mind. I wanted to know
>what you thought of it.
>
>Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
>
>The idea is to have a new TLV, which tells the actual LSP number. The LSP
>number in the psudonode-id is not used. The changes required are minimum.
We
>anyway scan thru TLV's for authentication information, we can find the LSP
>number TLV then. We instead use this TLV.
>
>To migrate to such a method all we need to do is to, use same LSP numbers
in
>the header and the TLV, and once all routers recognize the TLV, we actually
>can use different numbers. This does not create any backward compatibility
>issues and so we dont need two methods. In this case we do not need to
worry
>about Attached bit, Partition repair bit or change to SPF calculations etc.
>The solution also seems a logical extension, to the constraint caused by 8
>bit LSP number value. Rather than a solution that has multiple system id's
>which is like fooling the IS to believe all the systems are the same.
>
>Thanks,
>Vishwas
From mshand@cisco.com Wed Apr 24 15:25:29 2002
From: mshand@cisco.com (mike shand)
Date: Wed, 24 Apr 2002 15:25:29 +0100
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
In-Reply-To:
Message-ID: <4.3.2.7.2.20020424151507.041004a8@jaws.cisco.com>
At 10:07 24/04/2002 -0400, Manral, Vishwas wrote:
>Hi folks,
>
>As I have not got the reply to my mail, I will try and restate(I guess I
>wasn't clear) what the proposal is.
>
>The idea is to have a new TLV called LSP Number TLV, which contains a 32 bit
>LSP number. The new TLV is propagated in all LSP's and overrides the LSP
>Number field in the header.
>
>To migrate to this scheme, as long as all the routers in the network do not
>support the new TLV, we use the same value in LSP number field in the header
>as well as the TLV. Once all the routers in the network support the new TLV,
>we can actually use the value of the LSP number TLV and ignore the LSP
>number field in the header.
>
>The solution in this scheme seems to be a logical extension to the limit
>caused by an 8 bit LSP number field, using a 32 bit sequence number, rather
>than the scheme where we need multiple system id's and then equating the
>ID's.
>
>The advantages of the scheme relative to the other scheme is: -
>
>a) We use a simple migration scheme rather than a two step highly complex
>scheme.
>b) We need not worry about any change to routing table calculations.
>c) No taking care of attached bit.
>d) No taking care of partition bit.
>e) We need not worry about which links use what system id(as in the other
>scheme) and hence a lot of configuration.
>f) The amount of code changes are minimal.
>
>Regarding Mike's comment(I hope I got it right, Mike?) what happens when a
>new router that does not support the functionality comes up. Although the
>assumption with the other drafts like domain-wide and wide metrics is that
>once we migrate to a scheme, we will not try and bother about the older
>scheme, the same problem would occur in the other draft too if a new router
>came up after we had migrated to method 2, and someone did not understand
>the ISIS Alias TLV described there. Routing loops could very easily occur
>there.
Where do you put the extended numbers in xSNPs? Or are you proposing a new
"extended" LSP entry TLV? What do you do for migration? send both?
Even if you do this, if you have a router which doesn't understand the new
stuff and you are using the extended number space, you will get perpetual
re-transmission if you have two LSPs with the same "natural" number but
different extended numbers sent to a non-participating router. It will only
ACK one of them. et.c etc.
Mike
>Any comments/criticism invited.
>
>Thanks a lot,
>Vishwas
>
>-----Original Message-----
>From: Manral, Vishwas [mailto:VishwasM@netplane.com]
>Sent: Tuesday, April 23, 2002 8:51 PM
>To: 'mike shand'
>Cc: 'isis-wg@spider.juniper.net'
>Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
>Hi Mike,
>
>Thanks for the reply.
>
>I do not understand if we have migrated to a bigger LSp number, why we would
>bring in a router that still uses a smaller LSP number, even when we know it
>could create problems. This problem can occur in all cases of migration
>a) to domain wide
>b) wide metrics
>
>I do not see why we should introduce a two pronged method to do something
>which we can do pretty easily with just a TLV change, when similar
>approaches have been taken for other cases. Even in domain wide if a router
>came in which did not use external reachability in cases of L1 area the same
>problem would occur. I do not find the reason convincing enough to be
>rejected. ;-)
>
>Thanks,
>Vishwas
>
>-----Original Message-----
>From: mike shand [mailto:mshand@cisco.com]
>Sent: Tuesday, April 23, 2002 6:13 PM
>To: Manral, Vishwas
>Cc: 'isis-wg@spider.juniper.net'
>Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
>I'm not sure I fully understand this proposal. I assume that when you
>actually start using extended numbers you still need to invent additional
>system ID's for the extra "fragments" so that the update process can
>distinguish them. In which case it is semantically identical to the current
>scheme.
>
>Or are you proposing changing the update process so that it looks at the
>new TLV? I guess that must be what you have in mind. This has fairly
>serious consequences if you have migrated to extended numbers, but you then
>introduce a router which doesn't understand the new update process. I
>thought we had already considered and rejected solutions of this type.
>
> Mike
>
>At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
> >Hi Amir/Stefano/Mike,
> >
> >I read thru ur draft and had an alternate idea in mind. I wanted to know
> >what you thought of it.
> >
> >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
> >
> >The idea is to have a new TLV, which tells the actual LSP number. The LSP
> >number in the psudonode-id is not used. The changes required are minimum.
>We
> >anyway scan thru TLV's for authentication information, we can find the LSP
> >number TLV then. We instead use this TLV.
> >
> >To migrate to such a method all we need to do is to, use same LSP numbers
>in
> >the header and the TLV, and once all routers recognize the TLV, we actually
> >can use different numbers. This does not create any backward compatibility
> >issues and so we dont need two methods. In this case we do not need to
>worry
> >about Attached bit, Partition repair bit or change to SPF calculations etc.
> >The solution also seems a logical extension, to the constraint caused by 8
> >bit LSP number value. Rather than a solution that has multiple system id's
> >which is like fooling the IS to believe all the systems are the same.
> >
> >Thanks,
> >Vishwas
From jparker@axiowave.com Wed Apr 24 15:24:26 2002
From: jparker@axiowave.com (Jeff Parker)
Date: Wed, 24 Apr 2002 10:24:26 -0400
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
Message-ID:
> > 1) I'd assume that SNPs should use the link secret, since they are
> > not forwarded
> >
> > Radia
>
> SNPs use area/domain passwords as specified in ISO 10589 7.3.15.3a.
> (and other places)
>
> Les
Les -
That is the standard, but Radia has an interesting point.
Doesn't the use of an area secret allow some replay attacks?
- jeff parker
From rja@extremenetworks.com Wed Apr 24 16:26:44 2002
From: rja@extremenetworks.com (RJ Atkinson)
Date: Wed, 24 Apr 2002 11:26:44 -0400
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
In-Reply-To:
Message-ID:
On Wednesday, April 24, 2002, at 10:24 , Jeff Parker wrote:
>
> That is the standard, but Radia has an interesting point.
> Doesn't the use of an area secret allow some replay attacks?
The objective is to document what ISPs have already widely deployed,
not invent something new. The other thing to keep in mind is that
the ISPs merely want to have protection from eavesdropping on cleartext
IS-IS passwords. The deployed approach totally solves that problem.
Note also that when I proposed something different than what is deployed,
there was overwhelming push-back from operators saying the above.
This thing was *deployed* several years ago. We just need to document
what has been deployed in an Informational RFC.
If folks want to do something different, then that should be
a separate activity in a separate document and should NOT
delay publication of the deployed mechanism.
Ran
rja@extremenetworks.com
From jparker@axiowave.com Wed Apr 24 16:40:41 2002
From: jparker@axiowave.com (Jeff Parker)
Date: Wed, 24 Apr 2002 11:40:41 -0400
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
Message-ID:
Ran -
I appreciate the force of your argument to document
rather than invent, and I may borrow some of your prose
in the future. I'm not suggesting we delay the document.
But I would think this is an appropriate place to
discuss potential vulnerabilities in the protocol. We
have a few authentication types left, and someone could
draft a newer protocol if there is a need.
But perhaps this line of questioning is misguided.
Is this a threat you have evaluated, and decided we
don't need to worry about this?
- jeff parker
> On Wednesday, April 24, 2002, at 10:24 , Jeff Parker wrote:
> >
> > That is the standard, but Radia has an interesting point.
> > Doesn't the use of an area secret allow some replay attacks?
>
> The objective is to document what ISPs have already widely deployed,
> not invent something new. The other thing to keep in mind is that
> the ISPs merely want to have protection from eavesdropping on
> cleartext
> IS-IS passwords. The deployed approach totally solves that problem.
>
> Note also that when I proposed something different than what
> is deployed,
> there was overwhelming push-back from operators saying the above.
>
> This thing was *deployed* several years ago. We just need to document
> what has been deployed in an Informational RFC.
>
> If folks want to do something different, then that should be
> a separate activity in a separate document and should NOT
> delay publication of the deployed mechanism.
>
> Ran
> rja@extremenetworks.com
From VishwasM@netplane.com Wed Apr 24 19:37:05 2002
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Wed, 24 Apr 2002 14:37:05 -0400
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Message-ID:
Hi Mike,
Thanks a lot for the reply. That helped clarify a lot. I was actually
thinking things from the LSP aspect and forgot all about the xSNP thing
altogather. ;-)
> Where do you put the extended numbers in xSNPs? Or are you proposing a new
> "extended" LSP entry TLV? What do you do for migration? send both?
I guess we need to send both, so it would actually be more than one(two) new
TLV's added because of the draft, agreed.
> Even if you do this, if you have a router which doesn't understand the new
> stuff and you are using the extended number space, you will get perpetual
> re-transmission if you have two LSPs with the same "natural" number but
> different extended numbers sent to a non-participating router. It will
only
> ACK one of them. et.c etc.
Though I do not understand what you mean by
"with the same "natural" number but different extended numbers sent to a
non-participating router"
Well the ack with either of the TLV's can be treated as the ack for the
element. Or are you talking about a case after migrating we get a guy who
doesn't understand the new TLV? If thats the case I have already given the
instance of domain wide and wide metrics.;-)
Do you think the method is not worth it?(My view is that this seems the
logical extension and if the number of changes this way are lesser we could
as well go in for it) (any other changes you think would be required?);-)
Thanks,
Vishwas
>-----Original Message-----
>From: Manral, Vishwas [mailto:VishwasM@netplane.com]
>Sent: Tuesday, April 23, 2002 8:51 PM
>To: 'mike shand'
>Cc: 'isis-wg@spider.juniper.net'
>Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
>Hi Mike,
>
>Thanks for the reply.
>
>I do not understand if we have migrated to a bigger LSp number, why we
would
>bring in a router that still uses a smaller LSP number, even when we know
it
>could create problems. This problem can occur in all cases of migration
>a) to domain wide
>b) wide metrics
>
>I do not see why we should introduce a two pronged method to do something
>which we can do pretty easily with just a TLV change, when similar
>approaches have been taken for other cases. Even in domain wide if a router
>came in which did not use external reachability in cases of L1 area the
same
>problem would occur. I do not find the reason convincing enough to be
>rejected. ;-)
>
>Thanks,
>Vishwas
>
>-----Original Message-----
>From: mike shand [mailto:mshand@cisco.com]
>Sent: Tuesday, April 23, 2002 6:13 PM
>To: Manral, Vishwas
>Cc: 'isis-wg@spider.juniper.net'
>Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
>I'm not sure I fully understand this proposal. I assume that when you
>actually start using extended numbers you still need to invent additional
>system ID's for the extra "fragments" so that the update process can
>distinguish them. In which case it is semantically identical to the current
>scheme.
>
>Or are you proposing changing the update process so that it looks at the
>new TLV? I guess that must be what you have in mind. This has fairly
>serious consequences if you have migrated to extended numbers, but you then
>introduce a router which doesn't understand the new update process. I
>thought we had already considered and rejected solutions of this type.
>
> Mike
>
>At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
> >Hi Amir/Stefano/Mike,
> >
> >I read thru ur draft and had an alternate idea in mind. I wanted to know
> >what you thought of it.
> >
> >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
> >
> >The idea is to have a new TLV, which tells the actual LSP number. The LSP
> >number in the psudonode-id is not used. The changes required are minimum.
>We
> >anyway scan thru TLV's for authentication information, we can find the
LSP
> >number TLV then. We instead use this TLV.
> >
> >To migrate to such a method all we need to do is to, use same LSP numbers
>in
> >the header and the TLV, and once all routers recognize the TLV, we
actually
> >can use different numbers. This does not create any backward
compatibility
> >issues and so we dont need two methods. In this case we do not need to
>worry
> >about Attached bit, Partition repair bit or change to SPF calculations
etc.
> >The solution also seems a logical extension, to the constraint caused by
8
> >bit LSP number value. Rather than a solution that has multiple system
id's
> >which is like fooling the IS to believe all the systems are the same.
> >
> >Thanks,
> >Vishwas
From rja@extremenetworks.com Wed Apr 24 19:41:43 2002
From: rja@extremenetworks.com (RJ Atkinson)
Date: Wed, 24 Apr 2002 14:41:43 -0400
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
In-Reply-To:
Message-ID:
On Wednesday, April 24, 2002, at 11:40 , Jeff Parker wrote:
> Ran -
> I appreciate the force of your argument to document
> rather than invent, and I may borrow some of your prose
> in the future. I'm not suggesting we delay the document.
Thanks.
> But I would think this is an appropriate place to
> discuss potential vulnerabilities in the protocol. We
> have a few authentication types left, and someone could
> draft a newer protocol if there is a need.
Certainly someone could define a different approach
in a separate document if there were interest. My main
concern is that we not gate publishing the current draft
on some new project.
And it is well known that I believe that documents
discussing potential vulnerabilities of protocol X are
always in-scope for a working group focused on protocol X.
So if some folks wanted to write up a separate informational
document with a security analysis of I/IS-IS, that would be
all goodness in my book.
> But perhaps this line of questioning is misguided.
> Is this a threat you have evaluated, and decided we
> don't need to worry about this?
I'll answer this question, but maybe in a different way
than some expect.
I've thought a lot about routing protocol security. And
I think the next useful increment of security (beyond the simple
cryptographic authentication in the current draft) is probably
to go to a public-key approach. At a high-level, routing
protocols already need to be able to handle duplicate
packets (i.e. replays) because packet/frame duplication
happens by accident (no malice) in the global Internet anyway.
So a robust IS-IS implementation probably won't be very badly
affected by packet replay. For non-robust implementations,
any number of things could be a problem -- but that is an
implementation quality issue IMHO.
For OSPF, RFC-2154 outlines the use of public-key digital
signatures to improve the protection beyond OSPF MD5.
So my suggestion is that if folks want to go beyond the
current IS-IS cryptographic authentication, those folks should
look into a digital signature approach comparable to RFC-2154.
Now my conversations with users/operators makes me believe
that operators are very unlikely to deploy anything other than
the currently deployed MD5 spec. But a digital signature approach
to IS-IS would certainly make interesting research.
Cheers,
Ran
rja@extremenetworks.com
From Radia Perlman - Boston Center for Networking Wed Apr 24 22:31:00 2002
From: Radia Perlman - Boston Center for Networking (Radia Perlman - Boston Center for Networking)
Date: Wed, 24 Apr 2002 17:31:00 -0400 (EDT)
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
Message-ID: <200204242131.RAA12111@bcn.East.Sun.COM>
Answering Tony Li's comments on my comments (my original comments have
a line in front, and are most indented, Tony's comments are indented
and unlined):
| 1) I'd assume that SNPs should use the link secret, since they are
| not forwarded
Yes, but they can be replicated on multiple links. This simplifies
implementation.
I guess the CSNP would be identical on each link, but a PSNP would not.
But I guess that's a plausible reason for making it the area secret.
| 2) I remember IS-IS having a set of acceptable receive secrets,
| and a single transmit password, so that secret rollover wouldn't
| be a problem. This draft seems to imply there's only a single one.
That is certainly an implementation option.
Wouldn't it affect the management, i.e., that setting the receive secret
would involve a set of things rather than a single thing? I think it's
important to do this (allow multiple receive secrets)
so it is easy to migrate from one secret to another. I remember designing
that for IS-IS a long time ago, and being very explicit about the multiple
receive secrets. Is there still text around in some document recommending
this, or does all the text these days mention a single secret? Does
the MIB allow setting multiple receive secrets?
| 3) Shouldn't there be a separate layer 1 and layer 2 link secret?
| (Again, I think I remember that from DECnet).
What is gained from this?
So that layer 1 routers can't generate layer 2 messages (and vice versa).
[Side question: what is gained from multiple
secrets anyhow?]
Do you mean layer 1 plus layer 2 secrets? That's to keep each logical
trust group separate. Or do you mean multiple receive secrets? That's
for easy secret rollover. To get from secret a to secret b, one
by one have routers add secret b to their allowable receive secrets.
Then once everyone accepts both, one by one change their transmit
secret to b. Once everyone has their transmit secret as b, then
one by one remove a from the acceptable receive set.
I know of no installations where someone would allow an
L1 adjacency but not an L2. Seems like it could be simplified...
Well again, working from ancient memory...it was designed so that
L2 routers could form adjacencies over the same wire as L1 routers,
and even allowed mutliple L1 areas on the same LAN. It's good
cryptographic practice to have each separate community of trust have
a different secret.
Radia
From jparker@axiowave.com Wed Apr 24 23:00:20 2002
From: jparker@axiowave.com (Jeff Parker)
Date: Wed, 24 Apr 2002 18:00:20 -0400
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
Message-ID:
> Does the MIB allow setting multiple receive secrets?
>
> Radia
In the past the MIB discussed authentication, but I was
asked to remove it to improve security.
- jeff parker
From Alex Zinin Wed Apr 24 23:35:56 2002
From: Alex Zinin (Alex Zinin)
Date: Wed, 24 Apr 2002 15:35:56 -0700
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
In-Reply-To: <200204242131.RAA12111@bcn.East.Sun.COM>
References: <200204242131.RAA12111@bcn.East.Sun.COM>
Message-ID: <6629208368.20020424153556@psg.com>
Radia,
Just one comment:
> | 2) I remember IS-IS having a set of acceptable receive secrets,
> | and a single transmit password, so that secret rollover wouldn't
> | be a problem. This draft seems to imply there's only a single one.
> That is certainly an implementation option.
> Wouldn't it affect the management, i.e., that setting the receive secret
> would involve a set of things rather than a single thing? I think it's
> important to do this (allow multiple receive secrets)
> so it is easy to migrate from one secret to another. I remember designing
> that for IS-IS a long time ago, and being very explicit about the multiple
> receive secrets. Is there still text around in some document recommending
> this, or does all the text these days mention a single secret? Does
> the MIB allow setting multiple receive secrets?
The draft actually talks about this:
An implementation MAY check a set of passwords when verifying the
Authentication Value. This provides a mechanism for incrementally
changing passwords in a network.
I don't know about the MIB part.
Cheers!
Alex
From ginsberg@pluris.com Thu Apr 25 00:11:52 2002
From: ginsberg@pluris.com (Les Ginsberg)
Date: Wed, 24 Apr 2002 16:11:52 -0700
Subject: [Isis-wg] Comments on draft-ietf-isis-hmac-03.txt
Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F986@avalon.pluris.com>
Section 2.1 of "draft-ietf-isis-hmac-03.txt" discusses a problem associated
with password rollover immediately preceeding a router restart. If the
restarted router has not yet regenerated and propagated its own LSPs based
on the new password configuration then the restarted router is not able
to accept its own stale LSPs as propagated by its neighbors and would
therefore not increase the sequence # of its locally generated LSPs to
allow other routers to recognize these copies as "newer".
The draft suggests that an implementation cautiously accept the
LSPs which fail authentication if these LSPs have the local system ID
in the first portion of the LSPID field AND have a higher sequence
number than the local copy. The authors admit this leaves the system open
to replay attacks.
Text below discusses alternative solutions to the problem which present
no backwards compatibility problems and eliminate the need for bypassing
authentication. We propose that the solutions be incorporated into a revised
version of the draft.
Les Ginsberg/Satish Dattatri
--------------------------------------------------
The likelihood of this problem occurring is significantly reduced by
proper implementation of a Defect Report against ISO 10589 filed in
April 1993. At that time it was noted that:
"While ISO 10589 adequately covers all the conditions for processing
received LSPs and determining whether a received LSP is
newer than an LSP already stored by an IS, the same level
of description is not available for the processing of SNPs.
The intention is that the same procedures apply to SNPs as
to LSPs, but this is not explicitly stated in the applicable
clause(7.3.15.2)."
The remedy for this omission is to apply the description
of LSP confusion(7.3.16.2) and Remaining Lifetime(7.3.16.3) to the
processing of SNPs. The textual changes have been incorporated into
ISO 10589:2001 (see 7.3.16.2, 7.3.16.3, and 7.3.15.2b).
Most relevant to the issue raised in Section 2.1 of the draft is
to note that if an IS receives an SNP entry which specifies an LSP
generated by the local system which is newer than the local copy,
it must regenerate its local copy with a sequence number one greater
than that in the corresponding SNP entry. Since the SNP contains
current authentication it is accepted and all SNP entries it contains
are processed. This means that in most scenarios the problem
described in the draft is resolved by the normal exchange of CSNPs following
Pt-Pt adjacency establishment and the processing of periodic CSNPs
from the DIS on a LAN.
A few "corner cases" remain:
Case 1:
If the restarted router becomes the DIS on a LAN, it will generate,
not receive, periodic CSNPs. Systems which have a stale LSP generated
by a previous incarnation of the restarted system will respond to
the corresponding SNP entry by sending that stale LSP onto the LAN.
Case 2:
If the link layer on a Pt-Pt circuit does not provide reliable delivery,
then it is possible for one or more of the initial CSNPs to be lost. In
this case the restarted router may never receive an SNP entry for
one or more stale LSPs.
Case 3:
On a Pt-Pt circuit a stale LSP may arrive at
a neighbor from some other IS (not a neighbor of the restarted router)
shortly after the exchange of initial CSNPs. This LSP will never
be seen by the restarted router as an entry in a CSNP.
(Note: Periodic CSNPs will overcome cases 2 and 3, but periodic CSNPs
are not required on a Pt-Pt circuit.)
In all of these cases, the stale LSPs will be sent by neighbors of
the restarted router but will be ignored by the restarted router
due to authentication failure. Two solutions are available to resolve
these cases without the need to bypass authentication checks.
Solution #1:
The rules for processing a received LSP generated by some other
system which is "older" than the local copy, as described in
7.3.15.1e)3) of ISO 10589:1992 must be amended as follows:
"If the (received)LSP is older than the one in the database
and the copy in the database contains Authentication
Information then a recheck of the authentication information
shall be performed. If this check fails, the Remaining
Lifetime in the local copy shall be set to 0 and the actions
described in 7.3.16.4 shall be taken. Otherwise Set SRMflag for C
and Clear SSNflag for C"
Similarly, the rules for processing a received SNP entry which describe
an LSP older than the one in the local database, as described in
7.3.15.2b)2) of ISO 10589:1992 must be amended as follows:
"If the reported value is older than the database value
and the LSP source is some other system and the copy in the
database contains Authentication Information then a recheck
of the authentication information shall be performed. If this
check fails, the Remaining Lifetime in the local copy shall be
set to 0 and the actions described in 7.3.16.4 shall be taken.
Otherwise Set SRMflag for C and Clear SSNflag for C"
Solution #2:
When a router restarts and authentication is enabled locally at the
corresponding level, the router assigns itself a temporary LAN priority of
0,
making it the least likely system to be elected DIS. This temporary priority
shall be maintained until a complete set of CSNPs has been received and
no SRMflags have been set on that circuit for any local LSPs which were
reported in that set of CSNPs. (NOTE: If all systems on the LAN are set
to priority 0 then it is still possible for the restarted router to be
elected DIS - so this solution is not bullet-proof.)
Discussion:
Solution #1 requires routers to recheck authentication on the LSP
copy in their database in the
event they receive an LSP/SNP entry for an LSP generated by another
system and is OLDER than the one in the local database. If the
authentication
recheck fails the LSP is purged. Since the system is required to insert
current authentication information when purging an LSP, this resolves the
problem without requiring the system to be vulnerable to replay attacks.
(It is important to note that when purging an LSP a router must always
include authentication information based on the current local
password configuration.)
Solution #1 addresses all problem cases noted above. But until
all routers implement solution #1, there is some possibility that
some of the problem cases identified above may not be resolved.
Of the three mentioned, Case #1 is the most likely to happen.
Solution # 2 is offered to handle that case. Cases #2 and #3
are very unlikely to occur. If they do occur, then LSP DB synchronization
will be incomplete until all stale LSPs age out. The possibility of
this occurring exists in current networks i.e. this problem has not been
introduced by the HMAC extension - it can occur using plain text
passwords as well. Accepting the low probability
of the occurence of Problems #2 and #3 (until all routers can be
upgraded to support Solution #1) may be preferable to bypassing
authentication. However, network administrators may still prefer to
have a knob which bypasses password authentication for locally
generated LSPs so as to be able to overcome the rare instance when the
extensions to the protocol are insufficient. The period of time this
knob is enabled should be minimized so as to minimize risk to the
network.
From tli@procket.com Thu Apr 25 01:19:37 2002
From: tli@procket.com (Tony Li)
Date: Wed, 24 Apr 2002 17:19:37 -0700
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
In-Reply-To: <200204242131.RAA12111@bcn.East.Sun.COM>
References: <200204242131.RAA12111@bcn.East.Sun.COM>
Message-ID: <15559.19353.830992.907168@alpha-tli.procket.com>
Radia
| Well again, working from ancient memory...it was designed so that
| L2 routers could form adjacencies over the same wire as L1 routers,
| and even allowed mutliple L1 areas on the same LAN. It's good
| cryptographic practice to have each separate community of trust have
| a different secret.
My point is that in modern deployment, the trust area is the entire routing
domain.
And not one more micron. ;-)
Tony
From VishwasM@netplane.com Thu Apr 25 07:46:53 2002
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Thu, 25 Apr 2002 02:46:53 -0400
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Message-ID:
Hi Mike,
I actually thought over it, and simplified things a bit further, so that we
never have to send both entry TLV's at one time.
1. All routers use small LSP numbers at init time.
2. As routers with new functionality come up, they need to send the same
value in header and TLV LSP numbers. They need to be ready to accept the
"extended LSP entry TLV. We however still send the old LSP entry TLV.
3. Once all routers have the capability, we start using different values in
LSP number in the header and the TLV(extended LSP number) and use only
extended LSP entry TLV.
Does this sound ok? ;-)
Thanks,
Vishwas
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: Wednesday, April 24, 2002 7:55 PM
To: Manral, Vishwas
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
At 10:07 24/04/2002 -0400, Manral, Vishwas wrote:
>Hi folks,
>
>As I have not got the reply to my mail, I will try and restate(I guess I
>wasn't clear) what the proposal is.
>
>The idea is to have a new TLV called LSP Number TLV, which contains a 32
bit
>LSP number. The new TLV is propagated in all LSP's and overrides the LSP
>Number field in the header.
>
>To migrate to this scheme, as long as all the routers in the network do not
>support the new TLV, we use the same value in LSP number field in the
header
>as well as the TLV. Once all the routers in the network support the new
TLV,
>we can actually use the value of the LSP number TLV and ignore the LSP
>number field in the header.
>
>The solution in this scheme seems to be a logical extension to the limit
>caused by an 8 bit LSP number field, using a 32 bit sequence number, rather
>than the scheme where we need multiple system id's and then equating the
>ID's.
>
>The advantages of the scheme relative to the other scheme is: -
>
>a) We use a simple migration scheme rather than a two step highly complex
>scheme.
>b) We need not worry about any change to routing table calculations.
>c) No taking care of attached bit.
>d) No taking care of partition bit.
>e) We need not worry about which links use what system id(as in the other
>scheme) and hence a lot of configuration.
>f) The amount of code changes are minimal.
>
>Regarding Mike's comment(I hope I got it right, Mike?) what happens when a
>new router that does not support the functionality comes up. Although the
>assumption with the other drafts like domain-wide and wide metrics is that
>once we migrate to a scheme, we will not try and bother about the older
>scheme, the same problem would occur in the other draft too if a new router
>came up after we had migrated to method 2, and someone did not understand
>the ISIS Alias TLV described there. Routing loops could very easily occur
>there.
Where do you put the extended numbers in xSNPs? Or are you proposing a new
"extended" LSP entry TLV? What do you do for migration? send both?
Even if you do this, if you have a router which doesn't understand the new
stuff and you are using the extended number space, you will get perpetual
re-transmission if you have two LSPs with the same "natural" number but
different extended numbers sent to a non-participating router. It will only
ACK one of them. et.c etc.
Mike
>Any comments/criticism invited.
>
>Thanks a lot,
>Vishwas
>
>-----Original Message-----
>From: Manral, Vishwas [mailto:VishwasM@netplane.com]
>Sent: Tuesday, April 23, 2002 8:51 PM
>To: 'mike shand'
>Cc: 'isis-wg@spider.juniper.net'
>Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
>Hi Mike,
>
>Thanks for the reply.
>
>I do not understand if we have migrated to a bigger LSp number, why we
would
>bring in a router that still uses a smaller LSP number, even when we know
it
>could create problems. This problem can occur in all cases of migration
>a) to domain wide
>b) wide metrics
>
>I do not see why we should introduce a two pronged method to do something
>which we can do pretty easily with just a TLV change, when similar
>approaches have been taken for other cases. Even in domain wide if a router
>came in which did not use external reachability in cases of L1 area the
same
>problem would occur. I do not find the reason convincing enough to be
>rejected. ;-)
>
>Thanks,
>Vishwas
>
>-----Original Message-----
>From: mike shand [mailto:mshand@cisco.com]
>Sent: Tuesday, April 23, 2002 6:13 PM
>To: Manral, Vishwas
>Cc: 'isis-wg@spider.juniper.net'
>Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
>I'm not sure I fully understand this proposal. I assume that when you
>actually start using extended numbers you still need to invent additional
>system ID's for the extra "fragments" so that the update process can
>distinguish them. In which case it is semantically identical to the current
>scheme.
>
>Or are you proposing changing the update process so that it looks at the
>new TLV? I guess that must be what you have in mind. This has fairly
>serious consequences if you have migrated to extended numbers, but you then
>introduce a router which doesn't understand the new update process. I
>thought we had already considered and rejected solutions of this type.
>
> Mike
>
>At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
> >Hi Amir/Stefano/Mike,
> >
> >I read thru ur draft and had an alternate idea in mind. I wanted to know
> >what you thought of it.
> >
> >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
> >
> >The idea is to have a new TLV, which tells the actual LSP number. The LSP
> >number in the psudonode-id is not used. The changes required are minimum.
>We
> >anyway scan thru TLV's for authentication information, we can find the
LSP
> >number TLV then. We instead use this TLV.
> >
> >To migrate to such a method all we need to do is to, use same LSP numbers
>in
> >the header and the TLV, and once all routers recognize the TLV, we
actually
> >can use different numbers. This does not create any backward
compatibility
> >issues and so we dont need two methods. In this case we do not need to
>worry
> >about Attached bit, Partition repair bit or change to SPF calculations
etc.
> >The solution also seems a logical extension, to the constraint caused by
8
> >bit LSP number value. Rather than a solution that has multiple system
id's
> >which is like fooling the IS to believe all the systems are the same.
> >
> >Thanks,
> >Vishwas
From mshand@cisco.com Thu Apr 25 08:01:51 2002
From: mshand@cisco.com (mike shand)
Date: Thu, 25 Apr 2002 08:01:51 +0100
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
In-Reply-To:
Message-ID: <4.3.2.7.2.20020425075004.04165290@jaws.cisco.com>
At 14:37 24/04/2002 -0400, Manral, Vishwas wrote:
>Hi Mike,
>
>Thanks a lot for the reply. That helped clarify a lot. I was actually
>thinking things from the LSP aspect and forgot all about the xSNP thing
>altogather. ;-)
>
> > Where do you put the extended numbers in xSNPs? Or are you proposing a new
>
> > "extended" LSP entry TLV? What do you do for migration? send both?
>I guess we need to send both, so it would actually be more than one(two) new
>TLV's added because of the draft, agreed.
So this means we more than double the size of any xSNPs we send during the
migration period (which probably needs to last a long time so that we can
be SURE there will never be an old router anywhere). Even so I am very
nervous about the catastrophe which would result if an old router
subsequently crept in.
> > Even if you do this, if you have a router which doesn't understand the new
>
> > stuff and you are using the extended number space, you will get perpetual
> > re-transmission if you have two LSPs with the same "natural" number but
> > different extended numbers sent to a non-participating router. It will
>only
> > ACK one of them. et.c etc.
>Though I do not understand what you mean by
>
>"with the same "natural" number but different extended numbers sent to a
>non-participating router"
I mean that a router that doesn't understand the new TLVs receives two LSPs
with the same LSP number in the header, but different LSP numbers in the
new TLV. It will treat them as duplicates of the same LSP and so when it
acknowledges the second one it will just send a normal PSNP and the
originator will not be able to tell which one was being acknowledged. I
haven't thought it through in detail, but it seems to me that for various
scenarios you will get the possibility of perpetual retransmissions, and
certainly loss of information.
>Well the ack with either of the TLV's can be treated as the ack for the
>element. Or are you talking about a case after migrating we get a guy who
>doesn't understand the new TLV? If thats the case I have already given the
>instance of domain wide and wide metrics.;-)
>
>Do you think the method is not worth it?(My view is that this seems the
>logical extension and if the number of changes this way are lesser we could
>as well go in for it) (any other changes you think would be required?);-)
My view is that the update process is extremely subtle (but has been proved
correct in its current form) and that changing it in any way is very risky.
I would MUCH rather have a solution which left the update process unchanged.
>Thanks,
>Vishwas
>
>
> >-----Original Message-----
> >From: Manral, Vishwas [mailto:VishwasM@netplane.com]
> >Sent: Tuesday, April 23, 2002 8:51 PM
> >To: 'mike shand'
> >Cc: 'isis-wg@spider.juniper.net'
> >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
> >
> >
> >Hi Mike,
> >
> >Thanks for the reply.
> >
> >I do not understand if we have migrated to a bigger LSp number, why we
>would
> >bring in a router that still uses a smaller LSP number, even when we know
>it
> >could create problems. This problem can occur in all cases of migration
> >a) to domain wide
> >b) wide metrics
> >
> >I do not see why we should introduce a two pronged method to do something
> >which we can do pretty easily with just a TLV change, when similar
> >approaches have been taken for other cases. Even in domain wide if a router
> >came in which did not use external reachability in cases of L1 area the
>same
> >problem would occur. I do not find the reason convincing enough to be
> >rejected. ;-)
> >
> >Thanks,
> >Vishwas
> >
> >-----Original Message-----
> >From: mike shand [mailto:mshand@cisco.com]
> >Sent: Tuesday, April 23, 2002 6:13 PM
> >To: Manral, Vishwas
> >Cc: 'isis-wg@spider.juniper.net'
> >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
> >
> >
> >I'm not sure I fully understand this proposal. I assume that when you
> >actually start using extended numbers you still need to invent additional
> >system ID's for the extra "fragments" so that the update process can
> >distinguish them. In which case it is semantically identical to the current
> >scheme.
> >
> >Or are you proposing changing the update process so that it looks at the
> >new TLV? I guess that must be what you have in mind. This has fairly
> >serious consequences if you have migrated to extended numbers, but you then
> >introduce a router which doesn't understand the new update process. I
> >thought we had already considered and rejected solutions of this type.
> >
> > Mike
> >
> >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
> > >Hi Amir/Stefano/Mike,
> > >
> > >I read thru ur draft and had an alternate idea in mind. I wanted to know
> > >what you thought of it.
> > >
> > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
> > >
> > >The idea is to have a new TLV, which tells the actual LSP number. The LSP
> > >number in the psudonode-id is not used. The changes required are minimum.
> >We
> > >anyway scan thru TLV's for authentication information, we can find the
>LSP
> > >number TLV then. We instead use this TLV.
> > >
> > >To migrate to such a method all we need to do is to, use same LSP numbers
> >in
> > >the header and the TLV, and once all routers recognize the TLV, we
>actually
> > >can use different numbers. This does not create any backward
>compatibility
> > >issues and so we dont need two methods. In this case we do not need to
> >worry
> > >about Attached bit, Partition repair bit or change to SPF calculations
>etc.
> > >The solution also seems a logical extension, to the constraint caused by
>8
> > >bit LSP number value. Rather than a solution that has multiple system
>id's
> > >which is like fooling the IS to believe all the systems are the same.
> > >
> > >Thanks,
> > >Vishwas
From VishwasM@netplane.com Thu Apr 25 08:25:45 2002
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Thu, 25 Apr 2002 03:25:45 -0400
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Message-ID:
Mike,
Thanks a lot for the reply. My comments inline, prefixed by a VM>.
Thanks,
Vishwas
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: Thursday, April 25, 2002 12:32 PM
To: Manral, Vishwas
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
At 14:37 24/04/2002 -0400, Manral, Vishwas wrote:
>Hi Mike,
>
>Thanks a lot for the reply. That helped clarify a lot. I was actually
>thinking things from the LSP aspect and forgot all about the xSNP thing
>altogather. ;-)
>
> > Where do you put the extended numbers in xSNPs? Or are you proposing a
new
>
> > "extended" LSP entry TLV? What do you do for migration? send both?
>I guess we need to send both, so it would actually be more than one(two)
new
>TLV's added because of the draft, agreed.
So this means we more than double the size of any xSNPs we send during the
migration period (which probably needs to last a long time so that we can
be SURE there will never be an old router anywhere). Even so I am very
nervous about the catastrophe which would result if an old router
subsequently crept in.
VM> I guess we could do with just one TLV at a time, as in my previous mail.
Talking about problems. I guess there would be routing table problems in
case a new router came in after we migrated to method 2.
> > Even if you do this, if you have a router which doesn't understand the
new
>
> > stuff and you are using the extended number space, you will get
perpetual
> > re-transmission if you have two LSPs with the same "natural" number but
> > different extended numbers sent to a non-participating router. It will
>only
> > ACK one of them. et.c etc.
>Though I do not understand what you mean by
>
>"with the same "natural" number but different extended numbers sent to a
>non-participating router"
I mean that a router that doesn't understand the new TLVs receives two LSPs
with the same LSP number in the header, but different LSP numbers in the
new TLV. It will treat them as duplicates of the same LSP and so when it
acknowledges the second one it will just send a normal PSNP and the
originator will not be able to tell which one was being acknowledged. I
haven't thought it through in detail, but it seems to me that for various
scenarios you will get the possibility of perpetual retransmissions, and
certainly loss of information.
VM> Same answer as above. A similar thing could happen of the ext_lsp_frag
too if a router came without which did not understand the new TLV, it would
cause routing loops too.
>Well the ack with either of the TLV's can be treated as the ack for the
>element. Or are you talking about a case after migrating we get a guy who
>doesn't understand the new TLV? If thats the case I have already given the
>instance of domain wide and wide metrics.;-)
>
>Do you think the method is not worth it?(My view is that this seems the
>logical extension and if the number of changes this way are lesser we could
>as well go in for it) (any other changes you think would be required?);-)
My view is that the update process is extremely subtle (but has been proved
correct in its current form) and that changing it in any way is very risky.
I would MUCH rather have a solution which left the update process unchanged.
VM> Mike, I think the only change to the update process would be to use new
TLV's. The Update process as such would not change much but treating both
the TLV's as the same. The point here is that we need to do the check only
at the time of migrating and not after we have migrated, and there is no
change once we have migrated.
I agree a big change to the Update process causes more problems than a
change to the SPF and a lot of extra configuration.
>Thanks,
>Vishwas
>
>
> >-----Original Message-----
> >From: Manral, Vishwas [mailto:VishwasM@netplane.com]
> >Sent: Tuesday, April 23, 2002 8:51 PM
> >To: 'mike shand'
> >Cc: 'isis-wg@spider.juniper.net'
> >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
> >
> >
> >Hi Mike,
> >
> >Thanks for the reply.
> >
> >I do not understand if we have migrated to a bigger LSp number, why we
>would
> >bring in a router that still uses a smaller LSP number, even when we know
>it
> >could create problems. This problem can occur in all cases of migration
> >a) to domain wide
> >b) wide metrics
> >
> >I do not see why we should introduce a two pronged method to do something
> >which we can do pretty easily with just a TLV change, when similar
> >approaches have been taken for other cases. Even in domain wide if a
router
> >came in which did not use external reachability in cases of L1 area the
>same
> >problem would occur. I do not find the reason convincing enough to be
> >rejected. ;-)
> >
> >Thanks,
> >Vishwas
> >
> >-----Original Message-----
> >From: mike shand [mailto:mshand@cisco.com]
> >Sent: Tuesday, April 23, 2002 6:13 PM
> >To: Manral, Vishwas
> >Cc: 'isis-wg@spider.juniper.net'
> >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
> >
> >
> >I'm not sure I fully understand this proposal. I assume that when you
> >actually start using extended numbers you still need to invent additional
> >system ID's for the extra "fragments" so that the update process can
> >distinguish them. In which case it is semantically identical to the
current
> >scheme.
> >
> >Or are you proposing changing the update process so that it looks at the
> >new TLV? I guess that must be what you have in mind. This has fairly
> >serious consequences if you have migrated to extended numbers, but you
then
> >introduce a router which doesn't understand the new update process. I
> >thought we had already considered and rejected solutions of this type.
> >
> > Mike
> >
> >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
> > >Hi Amir/Stefano/Mike,
> > >
> > >I read thru ur draft and had an alternate idea in mind. I wanted to
know
> > >what you thought of it.
> > >
> > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
> > >
> > >The idea is to have a new TLV, which tells the actual LSP number. The
LSP
> > >number in the psudonode-id is not used. The changes required are
minimum.
> >We
> > >anyway scan thru TLV's for authentication information, we can find the
>LSP
> > >number TLV then. We instead use this TLV.
> > >
> > >To migrate to such a method all we need to do is to, use same LSP
numbers
> >in
> > >the header and the TLV, and once all routers recognize the TLV, we
>actually
> > >can use different numbers. This does not create any backward
>compatibility
> > >issues and so we dont need two methods. In this case we do not need to
> >worry
> > >about Attached bit, Partition repair bit or change to SPF calculations
>etc.
> > >The solution also seems a logical extension, to the constraint caused
by
>8
> > >bit LSP number value. Rather than a solution that has multiple system
>id's
> > >which is like fooling the IS to believe all the systems are the same.
> > >
> > >Thanks,
> > >Vishwas
From mshand@cisco.com Thu Apr 25 08:16:34 2002
From: mshand@cisco.com (mike shand)
Date: Thu, 25 Apr 2002 08:16:34 +0100
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
In-Reply-To:
Message-ID: <4.3.2.7.2.20020425080623.04406378@jaws.cisco.com>
At 02:46 25/04/2002 -0400, Manral, Vishwas wrote:
>Hi Mike,
>
>I actually thought over it, and simplified things a bit further, so that we
>never have to send both entry TLV's at one time.
>
>1. All routers use small LSP numbers at init time.
>2. As routers with new functionality come up, they need to send the same
>value in header and TLV LSP numbers. They need to be ready to accept the
>"extended LSP entry TLV. We however still send the old LSP entry TLV.
>3. Once all routers have the capability, we start using different values in
>LSP number in the header and the TLV(extended LSP number) and use only
>extended LSP entry TLV.
I think you need a multi stage migration process.
1. Deploy new software everywhere which understands the new TLVs, and sends
the same LSP number in both the LSP header and the extended TLV, but still
only sends the old LSP entry TLV.
2. Once you have all routers with the new software, you can go to each
router in turn and tell it to use new LSP entries instead of old.
3. Once you have all routers doing this, you can start using extended LSP
numbers (i.e. different values in the TLV and the header).
It would probably be wise to include some capability bits in the IIHs to
prevent forming adjacencies with old routers once you have started using
extended LSP numbers.
But, note that this is a complex process and requires changes to all the
update process code AND the SPF process code to recognize the additional
LSP numbers, AND the hello processing code (if we want to make it
reasonably safe).
I'd MUCH rather confine the changes to the SPF.
Mike
>Does this sound ok? ;-)
>
>Thanks,
>Vishwas
>
>-----Original Message-----
>From: mike shand [mailto:mshand@cisco.com]
>Sent: Wednesday, April 24, 2002 7:55 PM
>To: Manral, Vishwas
>Cc: 'isis-wg@spider.juniper.net'
>Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
>At 10:07 24/04/2002 -0400, Manral, Vishwas wrote:
> >Hi folks,
> >
> >As I have not got the reply to my mail, I will try and restate(I guess I
> >wasn't clear) what the proposal is.
> >
> >The idea is to have a new TLV called LSP Number TLV, which contains a 32
>bit
> >LSP number. The new TLV is propagated in all LSP's and overrides the LSP
> >Number field in the header.
> >
> >To migrate to this scheme, as long as all the routers in the network do not
> >support the new TLV, we use the same value in LSP number field in the
>header
> >as well as the TLV. Once all the routers in the network support the new
>TLV,
> >we can actually use the value of the LSP number TLV and ignore the LSP
> >number field in the header.
> >
> >The solution in this scheme seems to be a logical extension to the limit
> >caused by an 8 bit LSP number field, using a 32 bit sequence number, rather
> >than the scheme where we need multiple system id's and then equating the
> >ID's.
> >
> >The advantages of the scheme relative to the other scheme is: -
> >
> >a) We use a simple migration scheme rather than a two step highly complex
> >scheme.
> >b) We need not worry about any change to routing table calculations.
> >c) No taking care of attached bit.
> >d) No taking care of partition bit.
> >e) We need not worry about which links use what system id(as in the other
> >scheme) and hence a lot of configuration.
> >f) The amount of code changes are minimal.
> >
> >Regarding Mike's comment(I hope I got it right, Mike?) what happens when a
> >new router that does not support the functionality comes up. Although the
> >assumption with the other drafts like domain-wide and wide metrics is that
> >once we migrate to a scheme, we will not try and bother about the older
> >scheme, the same problem would occur in the other draft too if a new router
> >came up after we had migrated to method 2, and someone did not understand
> >the ISIS Alias TLV described there. Routing loops could very easily occur
> >there.
>
>Where do you put the extended numbers in xSNPs? Or are you proposing a new
>"extended" LSP entry TLV? What do you do for migration? send both?
>
>Even if you do this, if you have a router which doesn't understand the new
>stuff and you are using the extended number space, you will get perpetual
>re-transmission if you have two LSPs with the same "natural" number but
>different extended numbers sent to a non-participating router. It will only
>ACK one of them. et.c etc.
>
> Mike
>
>
> >Any comments/criticism invited.
> >
> >Thanks a lot,
> >Vishwas
> >
> >-----Original Message-----
> >From: Manral, Vishwas [mailto:VishwasM@netplane.com]
> >Sent: Tuesday, April 23, 2002 8:51 PM
> >To: 'mike shand'
> >Cc: 'isis-wg@spider.juniper.net'
> >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
> >
> >
> >Hi Mike,
> >
> >Thanks for the reply.
> >
> >I do not understand if we have migrated to a bigger LSp number, why we
>would
> >bring in a router that still uses a smaller LSP number, even when we know
>it
> >could create problems. This problem can occur in all cases of migration
> >a) to domain wide
> >b) wide metrics
> >
> >I do not see why we should introduce a two pronged method to do something
> >which we can do pretty easily with just a TLV change, when similar
> >approaches have been taken for other cases. Even in domain wide if a router
> >came in which did not use external reachability in cases of L1 area the
>same
> >problem would occur. I do not find the reason convincing enough to be
> >rejected. ;-)
> >
> >Thanks,
> >Vishwas
> >
> >-----Original Message-----
> >From: mike shand [mailto:mshand@cisco.com]
> >Sent: Tuesday, April 23, 2002 6:13 PM
> >To: Manral, Vishwas
> >Cc: 'isis-wg@spider.juniper.net'
> >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
> >
> >
> >I'm not sure I fully understand this proposal. I assume that when you
> >actually start using extended numbers you still need to invent additional
> >system ID's for the extra "fragments" so that the update process can
> >distinguish them. In which case it is semantically identical to the current
> >scheme.
> >
> >Or are you proposing changing the update process so that it looks at the
> >new TLV? I guess that must be what you have in mind. This has fairly
> >serious consequences if you have migrated to extended numbers, but you then
> >introduce a router which doesn't understand the new update process. I
> >thought we had already considered and rejected solutions of this type.
> >
> > Mike
> >
> >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
> > >Hi Amir/Stefano/Mike,
> > >
> > >I read thru ur draft and had an alternate idea in mind. I wanted to know
> > >what you thought of it.
> > >
> > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
> > >
> > >The idea is to have a new TLV, which tells the actual LSP number. The LSP
> > >number in the psudonode-id is not used. The changes required are minimum.
> >We
> > >anyway scan thru TLV's for authentication information, we can find the
>LSP
> > >number TLV then. We instead use this TLV.
> > >
> > >To migrate to such a method all we need to do is to, use same LSP numbers
> >in
> > >the header and the TLV, and once all routers recognize the TLV, we
>actually
> > >can use different numbers. This does not create any backward
>compatibility
> > >issues and so we dont need two methods. In this case we do not need to
> >worry
> > >about Attached bit, Partition repair bit or change to SPF calculations
>etc.
> > >The solution also seems a logical extension, to the constraint caused by
>8
> > >bit LSP number value. Rather than a solution that has multiple system
>id's
> > >which is like fooling the IS to believe all the systems are the same.
> > >
> > >Thanks,
> > >Vishwas
From VishwasM@netplane.com Thu Apr 25 08:29:31 2002
From: VishwasM@netplane.com (Manral, Vishwas)
Date: Thu, 25 Apr 2002 03:29:31 -0400
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Message-ID:
Maybe we could get someone elses views too, of what they feel. That would
help. ;-)
The idea of extended option in IIH is good, and may be nice for the
exp_lsp_fragment draft too(and same with domain wide etc too).
Thanks again,
Vishwas
-----Original Message-----
From: mike shand [mailto:mshand@cisco.com]
Sent: Thursday, April 25, 2002 12:47 PM
To: Manral, Vishwas
Cc: 'isis-wg@spider.juniper.net'
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
At 02:46 25/04/2002 -0400, Manral, Vishwas wrote:
>Hi Mike,
>
>I actually thought over it, and simplified things a bit further, so that we
>never have to send both entry TLV's at one time.
>
>1. All routers use small LSP numbers at init time.
>2. As routers with new functionality come up, they need to send the same
>value in header and TLV LSP numbers. They need to be ready to accept the
>"extended LSP entry TLV. We however still send the old LSP entry TLV.
>3. Once all routers have the capability, we start using different values in
>LSP number in the header and the TLV(extended LSP number) and use only
>extended LSP entry TLV.
I think you need a multi stage migration process.
1. Deploy new software everywhere which understands the new TLVs, and sends
the same LSP number in both the LSP header and the extended TLV, but still
only sends the old LSP entry TLV.
2. Once you have all routers with the new software, you can go to each
router in turn and tell it to use new LSP entries instead of old.
3. Once you have all routers doing this, you can start using extended LSP
numbers (i.e. different values in the TLV and the header).
It would probably be wise to include some capability bits in the IIHs to
prevent forming adjacencies with old routers once you have started using
extended LSP numbers.
But, note that this is a complex process and requires changes to all the
update process code AND the SPF process code to recognize the additional
LSP numbers, AND the hello processing code (if we want to make it
reasonably safe).
I'd MUCH rather confine the changes to the SPF.
Mike
>Does this sound ok? ;-)
>
>Thanks,
>Vishwas
>
>-----Original Message-----
>From: mike shand [mailto:mshand@cisco.com]
>Sent: Wednesday, April 24, 2002 7:55 PM
>To: Manral, Vishwas
>Cc: 'isis-wg@spider.juniper.net'
>Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
>At 10:07 24/04/2002 -0400, Manral, Vishwas wrote:
> >Hi folks,
> >
> >As I have not got the reply to my mail, I will try and restate(I guess I
> >wasn't clear) what the proposal is.
> >
> >The idea is to have a new TLV called LSP Number TLV, which contains a 32
>bit
> >LSP number. The new TLV is propagated in all LSP's and overrides the LSP
> >Number field in the header.
> >
> >To migrate to this scheme, as long as all the routers in the network do
not
> >support the new TLV, we use the same value in LSP number field in the
>header
> >as well as the TLV. Once all the routers in the network support the new
>TLV,
> >we can actually use the value of the LSP number TLV and ignore the LSP
> >number field in the header.
> >
> >The solution in this scheme seems to be a logical extension to the limit
> >caused by an 8 bit LSP number field, using a 32 bit sequence number,
rather
> >than the scheme where we need multiple system id's and then equating the
> >ID's.
> >
> >The advantages of the scheme relative to the other scheme is: -
> >
> >a) We use a simple migration scheme rather than a two step highly complex
> >scheme.
> >b) We need not worry about any change to routing table calculations.
> >c) No taking care of attached bit.
> >d) No taking care of partition bit.
> >e) We need not worry about which links use what system id(as in the other
> >scheme) and hence a lot of configuration.
> >f) The amount of code changes are minimal.
> >
> >Regarding Mike's comment(I hope I got it right, Mike?) what happens when
a
> >new router that does not support the functionality comes up. Although the
> >assumption with the other drafts like domain-wide and wide metrics is
that
> >once we migrate to a scheme, we will not try and bother about the older
> >scheme, the same problem would occur in the other draft too if a new
router
> >came up after we had migrated to method 2, and someone did not understand
> >the ISIS Alias TLV described there. Routing loops could very easily occur
> >there.
>
>Where do you put the extended numbers in xSNPs? Or are you proposing a new
>"extended" LSP entry TLV? What do you do for migration? send both?
>
>Even if you do this, if you have a router which doesn't understand the new
>stuff and you are using the extended number space, you will get perpetual
>re-transmission if you have two LSPs with the same "natural" number but
>different extended numbers sent to a non-participating router. It will only
>ACK one of them. et.c etc.
>
> Mike
>
>
> >Any comments/criticism invited.
> >
> >Thanks a lot,
> >Vishwas
> >
> >-----Original Message-----
> >From: Manral, Vishwas [mailto:VishwasM@netplane.com]
> >Sent: Tuesday, April 23, 2002 8:51 PM
> >To: 'mike shand'
> >Cc: 'isis-wg@spider.juniper.net'
> >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
> >
> >
> >Hi Mike,
> >
> >Thanks for the reply.
> >
> >I do not understand if we have migrated to a bigger LSp number, why we
>would
> >bring in a router that still uses a smaller LSP number, even when we know
>it
> >could create problems. This problem can occur in all cases of migration
> >a) to domain wide
> >b) wide metrics
> >
> >I do not see why we should introduce a two pronged method to do something
> >which we can do pretty easily with just a TLV change, when similar
> >approaches have been taken for other cases. Even in domain wide if a
router
> >came in which did not use external reachability in cases of L1 area the
>same
> >problem would occur. I do not find the reason convincing enough to be
> >rejected. ;-)
> >
> >Thanks,
> >Vishwas
> >
> >-----Original Message-----
> >From: mike shand [mailto:mshand@cisco.com]
> >Sent: Tuesday, April 23, 2002 6:13 PM
> >To: Manral, Vishwas
> >Cc: 'isis-wg@spider.juniper.net'
> >Subject: Re: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
> >
> >
> >I'm not sure I fully understand this proposal. I assume that when you
> >actually start using extended numbers you still need to invent additional
> >system ID's for the extra "fragments" so that the update process can
> >distinguish them. In which case it is semantically identical to the
current
> >scheme.
> >
> >Or are you proposing changing the update process so that it looks at the
> >new TLV? I guess that must be what you have in mind. This has fairly
> >serious consequences if you have migrated to extended numbers, but you
then
> >introduce a router which doesn't understand the new update process. I
> >thought we had already considered and rejected solutions of this type.
> >
> > Mike
> >
> >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
> > >Hi Amir/Stefano/Mike,
> > >
> > >I read thru ur draft and had an alternate idea in mind. I wanted to
know
> > >what you thought of it.
> > >
> > >Using the LSP number a 32 bit(or 16 bit as desired) quantity in TLV: -
> > >
> > >The idea is to have a new TLV, which tells the actual LSP number. The
LSP
> > >number in the psudonode-id is not used. The changes required are
minimum.
> >We
> > >anyway scan thru TLV's for authentication information, we can find the
>LSP
> > >number TLV then. We instead use this TLV.
> > >
> > >To migrate to such a method all we need to do is to, use same LSP
numbers
> >in
> > >the header and the TLV, and once all routers recognize the TLV, we
>actually
> > >can use different numbers. This does not create any backward
>compatibility
> > >issues and so we dont need two methods. In this case we do not need to
> >worry
> > >about Attached bit, Partition repair bit or change to SPF calculations
>etc.
> > >The solution also seems a logical extension, to the constraint caused
by
>8
> > >bit LSP number value. Rather than a solution that has multiple system
>id's
> > >which is like fooling the IS to believe all the systems are the same.
> > >
> > >Thanks,
> > >Vishwas
From Russ White Thu Apr 25 13:30:33 2002
From: Russ White (Russ White)
Date: Thu, 25 Apr 2002 08:30:33 -0400 (EDT)
Subject: [Isis-wg] Re: a few comments on ietf restart isis draft
In-Reply-To: <4.3.2.7.2.20020424135645.04152420@jaws.cisco.com>
Message-ID:
> I think, given the various scenarios, we need a bit of
> flexibility here. My intent was that the whole thing was
> "fail safe". i.e. if the restarting router didn't come back
> up properly, the neighbors would drop their adjacencies as if
> it had just plain failed. I didn't want the restarting to
> delay the normal recovery.
>
> However, I understand that some implementations may not be
> able to get back up within this time, especially for short
> hello times, and that some measure of "hello I'm back, could
> you just give me a little extra time to get my act together"
> would be helpful. I like Nischal's suggestion here.
Agreed.... It's better to assume that since we've received a
hello with the proper bits set, we should give the adjacent is a
little more time.
> > not meant to be bullet proof. If the IIHs happen to get lost,
> > we just have a bad day. This is also the same problem if you
> > have multiple neighbors on the same LAN. Your IIH can be lost
> > to one of the neighbors, but as soon as you receive from
> > other neighbors and complete the CSNPs, the T1 will be cancelled.
> > But you have no way to know, that one neighbor didn't
> > receive your re-start IIH, and it will reset the adjacency.
> > The current scheme does not cover that case, and I think its
> > not worth to have retries in general. Thus actually we don't
> > even need the T1.
>
> I'm not sure. I didn't like the idea that we may be stalled
> waiting for multiple retries, but OTOH it goes against the
> grain to design a protocol which "fails" on the loss of a
> single packet :-)
>
> I guess the question is how many times will we sit around
> waiting for a response when we will never get one, as opposed
> to the times when we genuinely loose a packet and this allows
> us to re-start when we otherwise wouldn't.
We could prescribe a smaller number of retries, perhaps. I don't
like the idea of dropping a single packet causing the restart to
fail, either.
:-)
Russ
__________________________________
riw@cisco.com CCIE <>< Grace Alone
From wangxp@huawei.com Sat Apr 27 13:44:14 2002
From: wangxp@huawei.com (Wang xuepu)
Date: Sat, 27 Apr 2002 20:44:14 +0800
Subject: [Isis-wg] About MTU?
Message-ID: <000f01c1ede9$3d485d00$3b336e0a@HUAWEI.COM>
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C1EE2C.4B20D860
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: base64
U3VwcG9zZSB0aGVyZSBhcmUgdGhyZWUgcm91dGVycyBpbiB0aGUgc2FtZSBhcmVhLGFuZCB0aGV5
IGFyZSBjb25uZWN0ZWQgYnkgdGhlIGV0aGVybmV0Lg0Kc3VjaCBhczoNCg0KIF9fXyAgICAgICAg
X19fICAgICAgICAgX19fICAgIA0KfCBBIHxfX19fX198IEIgfF9fX19fX198IEMgfCANCnxfX198
ZTAgIGUwfF9fX3xlMSAgIGUwfF9fX3wNCiAgICAgICANClN1cHBvc2U6DQpSb3V0ZXIgQTogDQog
ICAgICAgICB0aGUgbXR1IG9mIGUwIGlzIDE1MDAuDQpSb3V0ZXIgQjoNCiAgICAgICAgIHRoZSBt
dHUgb2YgZTAgaXMgMTUwMC4gICAgDQogICAgICAgICB0aGUgbXR1IG9mIGUxIGlzIDEwMDAuICAg
IA0KUm91dGVyIEM6DQogICAgICAgICB0aGUgbXR1IG9mIGUwIGlzIDEwMDAuICAgIA0KTm93Og0K
V2hlbiBSb3V0ZXIgQiByZWNlaXZlIGEgUm91dGVyIEEncyBMU1AgZnJvbSBlMCx0aGUgc2l6ZSBv
ZiB0aGlzIExTUCBzaG91bGQgYmUgMTUwMCx0aGUgUm91dGVyIEIgc2hvdWxkIGZsb29kDQp0aGUg
TFNQLGJ1dCBCIGNhbiBub3Qgc2VuZCB0aGlzIExTUCB0aHJvdWdodCBlMS5iZWNhc2UgdGhlIG10
dSBpcyB0b28gc21hbGwuDQpJcyBpdCBjb3JyZWN0Pw0KaWYgaXQgaXMgcmlnaHQsaG93IGNhbiB3
ZSBzb2x1dGUgdGhpcyBwcm9ibGVtPw0KDQo=
------=_NextPart_000_000C_01C1EE2C.4B20D860
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi
MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w
MC4zMzE0LjIxMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8
Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5TdXBwb3NlIHRoZXJlIGFy
ZSB0aHJlZSByb3V0ZXJzIGluIHRoZSBzYW1lIGFyZWEsYW5kIHRoZXkgYXJlIA0KY29ubmVjdGVk
IGJ5IHRoZSBldGhlcm5ldC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5zdWNoIGFz
OjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJz
cDtfX18mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpfX18mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgX19fJm5ic3A7Jm5i
c3A7Jm5ic3A7IA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+fCBBIHxfX19fX198
IEIgfF9fX19fX198Jm5ic3A7QyB8IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgDQpzaXplPTI+
fF9fX3xlMCZuYnNwOyZuYnNwO2UwfF9fX3xlMSZuYnNwOyZuYnNwOyZuYnNwO2UwfF9fX3w8L0ZP
TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+U3VwcG9zZTo8L0ZPTlQ+
PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5Sb3V0ZXIgQTogPC9GT05UPjwvRElWPg0KPERJVj48
Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHRoZSBtdHUgDQpvZiZuYnNwO2UwIGlzIDE1MDAuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O
VCBzaXplPTI+Um91dGVyIEI6PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3RoZSBtdHUgDQpvZiZu
YnNwO2UwIGlzJm5ic3A7MTUwMC4mbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPjwvRElWPg0KPERJ
Vj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHRoZSBtdHUgDQpvZiZuYnNwO2UxIGlzJm5ic3A7MTAwMC4mbmJzcDsmbmJzcDsmbmJz
cDsgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Um91dGVyIEM6PC9GT05UPjwvRElW
Pg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHRoZSBtdHUgDQpvZiZuYnNwO2UwIGlzJm5ic3A7MTAwMC4mbmJzcDsmbmJz
cDsmbmJzcDsgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Tm93OjwvRk9OVD48L0RJ
Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPldoZW4gUm91dGVyIEIgcmVjZWl2ZSBhIFJvdXRlciBBJ3Mg
TFNQIGZyb20gZTAsdGhlIHNpemUgb2YgDQp0aGlzIExTUCBzaG91bGQgYmUgMTUwMCx0aGUgUm91
dGVyIEIgc2hvdWxkIGZsb29kPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+dGhlIExT
UCxidXQgQiBjYW4gbm90IHNlbmQgdGhpcyBMU1AgdGhyb3VnaHQgZTEuYmVjYXNlIHRoZSBtdHUg
DQppcyB0b28gc21hbGwuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SXMgaXQgY29y
cmVjdD88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5pZiBpdCBpcyByaWdodCxob3cg
Y2FuIHdlIHNvbHV0ZSB0aGlzIHByb2JsZW0/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ
Vj48L0JPRFk+PC9IVE1MPg0K
------=_NextPart_000_000C_01C1EE2C.4B20D860--
From rja@extremenetworks.com Thu Apr 25 14:50:54 2002
From: rja@extremenetworks.com (RJ Atkinson)
Date: Thu, 25 Apr 2002 09:50:54 -0400
Subject: [Isis-wg] Re: draft-ietf-isis-hmac-03.txt
In-Reply-To:
Message-ID: <769E9C5B-5853-11D6-AD10-00039357A82A@extremenetworks.com>
On Wednesday, April 24, 2002, at 06:00 , Jeff Parker wrote:
>> Does the MIB allow setting multiple receive secrets?
>>
>> Radia
>
> In the past the MIB discussed authentication, but I was
> asked to remove it to improve security.
Letting the MIB add/delete/view/modify any of the
cryptographic keys (or whether cryptography is enabled)
is a very very bad idea -- creates a cascading security
vulnerability.
Ran
From jparker@axiowave.com Thu Apr 25 15:11:11 2002
From: jparker@axiowave.com (Jeff Parker)
Date: Thu, 25 Apr 2002 10:11:11 -0400
Subject: [Isis-wg] *SNP replay
Message-ID:
Just to be clear I have removed the draft name
from the subject line.
> > I'm not suggesting we delay the document.
>
>
> So a robust IS-IS implementation probably won't be very badly
> affected by packet replay. For non-robust implementations,
> any number of things could be a problem -- but that is an
> implementation quality issue IMHO.
True. I hope that improving implementation quality
is something worth discussing on this list.
What is interesting about replaying *SNP packets is
that it is one of the few ways in ISIS to introduce
a multiplier. The worst of the DOS attack depend
upon other machines doing the work, and an out of
date *SNP will cause other machines to retransmit
LSPs. I agree that there are rate limits on how
fast you resend an LSP, but with a large configuration,
SNPs with stale info could force constant updates.
(The only other packet I can think of with leverage
is changing the priority on a hello to force a
DIS election. If I send a duplicate of a hello
from a low-status IS with high priority, can't I
force all of the machines on a network to swing
back and forth between two DISs?)
- jeff parker
From jlearman@cisco.com Thu Apr 25 16:13:12 2002
From: jlearman@cisco.com (Jeff Learman)
Date: Thu, 25 Apr 2002 11:13:12 -0400
Subject: [Isis-wg] About MTU?
In-Reply-To: <000f01c1ede9$3d485d00$3b336e0a@HUAWEI.COM>
Message-ID: <4.3.2.7.2.20020425110929.024318c8@dingdong.cisco.com>
--=====================_97632267==_.ALT
Content-Type: text/plain; charset="us-ascii"
ISO 10589:1992 is not clear what should be done in this case -- the
answer seems to be to purge the PDU.
ISO 10589:2001 clears up what the router should do, but it doesn't
solve the problem -- it just makes the problem less severe and defines
management events to help indicate the existence of the problem.
It's a configuration error, and the network administrator must fix it
by reducing the maximum originate LSP size on all routers in the
subdomain (area or L2 backbone).
Regards,
Jeff
At 08:44 AM 4/27/2002, Wang xuepu wrote:
>Suppose there are three routers in the same area,and they are connected by the ethernet.
>such as:
>
> ___ ___ ___
>| A |______| B |_______| C |
>|___|e0 e0|___|e1 e0|___|
>
>Suppose:
>Router A:
> the mtu of e0 is 1500.
>Router B:
> the mtu of e0 is 1500.
> the mtu of e1 is 1000.
>Router C:
> the mtu of e0 is 1000.
>Now:
>When Router B receive a Router A's LSP from e0,the size of this LSP should be 1500,the Router B should flood
>the LSP,but B can not send this LSP throught e1.becase the mtu is too small.
>Is it correct?
>if it is right,how can we solute this problem?
>
--=====================_97632267==_.ALT
Content-Type: text/html; charset="us-ascii"
ISO 10589:1992 is not clear what should be done in this case -- the
answer seems to be to purge the PDU.
ISO 10589:2001 clears up what the router should do, but it doesn't
solve the problem -- it just makes the problem less severe and
defines
management events to help indicate the existence of the problem.
It's a configuration error, and the network administrator must fix
it
by reducing the maximum originate LSP size on all routers in the
subdomain (area or L2 backbone).
Regards,
Jeff
At 08:44 AM 4/27/2002, Wang xuepu wrote:
Suppose there are three routers
in the same area,and they are connected by the ethernet.
such as:
___
___ ___
| A |______| B |_______| C |
|___|e0 e0|___|e1 e0|___|
Suppose:
Router A:
the mtu of
e0 is 1500.
Router B:
the mtu of
e0 is 1500.
the mtu of
e1 is 1000.
Router C:
the mtu of
e0 is 1000.
Now:
When Router B receive a Router A's LSP from e0,the size of
this LSP should be 1500,the Router B should flood
the LSP,but B can not send this LSP throught e1.becase the
mtu is too small.
Is it correct?
if it is right,how can we solute this problem?
--=====================_97632267==_.ALT--
From ginsberg@pluris.com Thu Apr 25 16:35:17 2002
From: ginsberg@pluris.com (Les Ginsberg)
Date: Thu, 25 Apr 2002 08:35:17 -0700
Subject: [Isis-wg] About MTU?
Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F98A@avalon.pluris.com>
The short answer is that you must configure the maximum LSP size that any
router in the area/domain will generate to be no larger than the smallest
MTU of any link in the area/domain that will be used for propagation - in
your example originatingLxLSPSize must be set to 997 (1000 - 3 bytes for
LLC1 header) on all routers.
The longer answer can be found at:
ftp://ftp.juniper.net/pub/isis/lspsize.PDF
This solution has been incorporated into the ISO 10589:2001 draft.
Les
-----Original Message-----
From: Wang xuepu
To: isis-wg@juniper.net
Sent: 4/27/02 5:44 AM
Subject: [Isis-wg] About MTU?
Suppose there are three routers in the same area,and they are connected
by the ethernet.
such as:
___ ___ ___
| A |______| B |_______| C |
|___|e0 e0|___|e1 e0|___|
Suppose:
Router A:
the mtu of e0 is 1500.
Router B:
the mtu of e0 is 1500.
the mtu of e1 is 1000.
Router C:
the mtu of e0 is 1000.
Now:
When Router B receive a Router A's LSP from e0,the size of this LSP
should be 1500,the Router B should flood
the LSP,but B can not send this LSP throught e1.becase the mtu is too
small.
Is it correct?
if it is right,how can we solute this problem?
From Ravindra.Sunkad@VivaceNetworks.com Thu Apr 25 17:49:14 2002
From: Ravindra.Sunkad@VivaceNetworks.com (Ravindra Sunkad)
Date: Thu, 25 Apr 2002 09:49:14 -0700
Subject: [Isis-wg] About MTU?
Message-ID:
This is a multi-part message in MIME format.
------_=_NextPart_001_01C1EC79.21D797D3
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
If an implementation brings down IS-IS on interfaces with MTU <
LSP_BUF_SIZE this problem will not arise.
=20
-----Original Message-----
From: Jeff Learman [mailto:jlearman@cisco.com]=20
Sent: Thursday, April 25, 2002 8:13 AM
To: Wang xuepu
Cc: isis-wg@juniper.net
Subject: Re: [Isis-wg] About MTU?
=09
ISO 10589:1992 is not clear what should be done in this case --
the
answer seems to be to purge the PDU.
=09
ISO 10589:2001 clears up what the router should do, but it
doesn't
solve the problem -- it just makes the problem less severe and
defines
management events to help indicate the existence of the problem.
=09
It's a configuration error, and the network administrator must
fix it
by reducing the maximum originate LSP size on all routers in the
subdomain (area or L2 backbone).
=09
Regards,
Jeff
=09
At 08:44 AM 4/27/2002, Wang xuepu wrote:
=09
Suppose there are three routers in the same area,and
they are connected by the ethernet.
such as:
=20
___ ___ ___ =20
| A |______| B |_______| C |=20
|___|e0 e0|___|e1 e0|___|
=20
Suppose:
Router A:=20
the mtu of e0 is 1500.
Router B:
the mtu of e0 is 1500. =20
the mtu of e1 is 1000. =20
Router C:
the mtu of e0 is 1000. =20
Now:
When Router B receive a Router A's LSP from e0,the size
of this LSP should be 1500,the Router B should flood
the LSP,but B can not send this LSP throught e1.becase
the mtu is too small.
Is it correct?
if it is right,how can we solute this problem?
=20
------_=_NextPart_001_01C1EC79.21D797D3
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message
If an=20
implementation brings down IS-IS on interfaces with MTU <=20
LSP_BUF_SIZE this problem will not arise.
-----Original =
Message-----
From: Jeff=20
Learman [mailto:jlearman@cisco.com]
Sent: Thursday, April 25, =
2002=20
8:13 AM
To: Wang xuepu
Cc:=20
isis-wg@juniper.net
Subject: Re: [Isis-wg] About=20
MTU?
ISO 10589:1992 is not =
clear what=20
should be done in this case -- the
answer seems to be to purge the=20
PDU.
ISO 10589:2001 clears up what the router should do, but it =
doesn't
solve the problem -- it just makes the problem less severe =
and=20
defines
management events to help indicate the existence of the=20
problem.
It's a configuration error, and the network =
administrator must=20
fix it
by reducing the maximum originate LSP size on all routers in =
the
subdomain (area or L2 =
backbone).
Regards,
Jeff
At=20
08:44 AM 4/27/2002, Wang xuepu wrote:
Suppose there are three =
routers in=20
the same area,and they are connected by the =
ethernet.
such as:
___ =20
___ =
___ =20
| A |______| B |_______| C | =
|___|e0 e0|___|e1 e0|___|
Suppose:
Router A: =
the mtu of =
e0 is=20
1500.
Router B:
the mtu of =
e0 is=20
1500.
the mtu of =
e1 is=20
1000.
Router =
C:
the mtu of =
e0 is=20
1000.
Now:
When Router B receive a Router A's LSP from e0,the size of =
this LSP=20
should be 1500,the Router B should flood
the LSP,but=20
B can not send this LSP throught e1.becase the mtu is too=20
small.
Is it correct?
if it is=20
right,how can we solute this=20
problem?
=00
------_=_NextPart_001_01C1EC79.21D797D3--
From ramsrm@tdd.sj.nec.com"
Hi all,
I have a doubt in ISIS. could u please explain me?
In ISIS we have authentication TLV. There is no restriction on this
TLV whether to come in the front or not. so it can come in any place in all
pdus( hello/LSP).
So a receiver of the PDU has to go thro' the entire packet to reach
to the authentication TLV and then check whether the authentication
condition is satisfied or not. But it seems to me a big overhead, we need
to scan the complete packet or to the point where that TLV is available. is
there any reason behind this(i.e having the authentication TLV at any
position, usually at the end)?.
Generally we have checksum computation, that involves going thro'
the whole packet and finally that result will be put in the packet header,
so that receiving end can easily get the value and check it. similarly why
not we can have a restriction that the Authentication TLV shud appear
before all the TLVs so that processing will be easier.
thanks
rams.
From Alex Zinin Thu Apr 25 20:46:47 2002
From: Alex Zinin (Alex Zinin)
Date: Thu, 25 Apr 2002 12:46:47 -0700
Subject: [Isis-wg] authentication.
In-Reply-To: <01C1EC4F.E9EE88E0.ramsrm@tdd.sj.nec.com>
References: <01C1EC4F.E9EE88E0.ramsrm@tdd.sj.nec.com>
Message-ID: <44105465351.20020425124647@psg.com>
Ramanathan,
I brought this up a while ago.
If we were sure that _all_ implementations already do
put the Auth TLV at the beginning or at the end, one
could take advantage of this. However, there seems to
be no confidence in this, so you still have to be ready
for the case where the TLV can appear anywhere in the PDU,
and hence you don't really gain anything.
--
Alex
Thursday, April 25, 2002, 11:54:10 AM, you wrote:
> Hi all,
> I have a doubt in ISIS. could u please explain me?
> In ISIS we have authentication TLV. There is no restriction on this
> TLV whether to come in the front or not. so it can come in any place in all
> pdus( hello/LSP).
> So a receiver of the PDU has to go thro' the entire packet to reach
> to the authentication TLV and then check whether the authentication
> condition is satisfied or not. But it seems to me a big overhead, we need
> to scan the complete packet or to the point where that TLV is available. is
> there any reason behind this(i.e having the authentication TLV at any
> position, usually at the end)?.
> Generally we have checksum computation, that involves going thro'
> the whole packet and finally that result will be put in the packet header,
> so that receiving end can easily get the value and check it. similarly why
> not we can have a restriction that the Authentication TLV shud appear
> before all the TLVs so that processing will be easier.
> thanks
> rams.
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
From jparker@axiowave.com Thu Apr 25 21:12:27 2002
From: jparker@axiowave.com (Jeff Parker)
Date: Thu, 25 Apr 2002 16:12:27 -0400
Subject: [Isis-wg] authentication.
Message-ID:
> why not we can have a restriction that the Authentication
> TLV shud appear before all the TLVs so that processing
> will be easier.
>
> thanks
> rams.
It is probably time to quote
"Be conservative in what you send and
liberal in what you recieve"
Since you cannot count on the other side to put
the TLV in the right spot, you need to include
the logic to find it anywhere.
Perhaps we should add
"and Libertarian in what you require
others to do"
- jeff parker
From prz@redback.com Fri Apr 26 02:05:46 2002
From: prz@redback.com (Tony Przygienda)
Date: Thu, 25 Apr 2002 18:05:46 -0700
Subject: [Isis-wg] About MTU?
References:
Message-ID: <3CC8A7E9.E759A617@redback.com>
Ravindra Sunkad wrote:
> If an implementation brings down IS-IS on interfaces with MTU < LSP_BUF_SIZE this problem
> will not arise.
>
>
> not good enough, the problem is transitive, you may have interface with MTU 4096,
> your LSP_BUF_SIZE is 1024
> and you receive from your neighbor an LSP with size 2048 since his LSP_BUF_SIZE is set to 2048
>
> -- tony
From prz@redback.com Fri Apr 26 02:21:01 2002
From: prz@redback.com (Tony Przygienda)
Date: Thu, 25 Apr 2002 18:21:01 -0700
Subject: [Isis-wg] About MTU?
References:
Message-ID: <3CC8AB7D.ADB6C864@redback.com>
Ravindra Sunkad wrote:
> True. But, LSP acceptance tests in 10589 already take care of this case.
either you or me seems confused here? You make a statement taht does
not seem to be 100% true and when I correct it, you go off on a tangent??
The problem mentioned in the mail at the beginning of this thread
is real, the solutions given by Jeff & Les are here with pros & cons and
what you said was at best only partially true
-=-= tony
> > -----Original Message-----
> > From: Tony Przygienda [mailto:prz@redback.com]
> > Sent: Thursday, April 25, 2002 6:06 PM
> > To: Ravindra Sunkad
> > Cc: Jeff Learman; Wang xuepu; isis-wg@juniper.net
> > Subject: Re: [Isis-wg] About MTU?
> >
> >
> > Ravindra Sunkad wrote:
> >
> > > If an implementation brings down IS-IS on interfaces with MTU <
> > > LSP_BUF_SIZE this problem will not arise.
> > >
> > >
> > > not good enough, the problem is transitive, you may have interface
> > > with MTU 4096, your LSP_BUF_SIZE is 1024 and you receive from your
> > > neighbor an LSP with size 2048 since his LSP_BUF_SIZE is set to 2048
> > >
> > > -- tony
From Ravindra.Sunkad@VivaceNetworks.com Fri Apr 26 03:27:38 2002
From: Ravindra.Sunkad@VivaceNetworks.com (Ravindra Sunkad)
Date: Thu, 25 Apr 2002 19:27:38 -0700
Subject: [Isis-wg] About MTU?
Message-ID:
True. But, LSP acceptance tests in 10589 already take care of this case.
> -----Original Message-----
> From: Tony Przygienda [mailto:prz@redback.com]
> Sent: Thursday, April 25, 2002 6:06 PM
> To: Ravindra Sunkad
> Cc: Jeff Learman; Wang xuepu; isis-wg@juniper.net
> Subject: Re: [Isis-wg] About MTU?
>
>
> Ravindra Sunkad wrote:
>
> > If an implementation brings down IS-IS on interfaces with MTU <
> > LSP_BUF_SIZE this problem will not arise.
> >
> >
> > not good enough, the problem is transitive, you may have interface
> > with MTU 4096, your LSP_BUF_SIZE is 1024 and you receive from your
> > neighbor an LSP with size 2048 since his LSP_BUF_SIZE is set to 2048
> >
> > -- tony
>
>
From ginsberg@pluris.com Fri Apr 26 04:49:59 2002
From: ginsberg@pluris.com (Les Ginsberg)
Date: Thu, 25 Apr 2002 20:49:59 -0700
Subject: [Isis-wg] About MTU?
Message-ID: <17C81AD1F1FED411991E006008F6D1CA01B3F992@avalon.pluris.com>
Tony is quite right. The protocol has no way to prevent this problem
completely, since configuration must be consistent throughout the
area/domain - not just with your neighbors. Checks when bringing up an
adjacency help, but do not eliminate the problem - and the extensions added
into ISO 10589:2001 do not prevent the problem either - though if used
area/domain wide they will detect and report misconfigurations - in some
cases before propagation failures actually occur.
It is still up to the network administrator to correct the misconfiguration.
Les
>
>
> True. But, LSP acceptance tests in 10589 already take care of
> this case.
>
> > -----Original Message-----
> > From: Tony Przygienda [mailto:prz@redback.com]
> > Sent: Thursday, April 25, 2002 6:06 PM
> > To: Ravindra Sunkad
> > Cc: Jeff Learman; Wang xuepu; isis-wg@juniper.net
> > Subject: Re: [Isis-wg] About MTU?
> >
> >
> > Ravindra Sunkad wrote:
> >
> > > If an implementation brings down IS-IS on interfaces with MTU <
> > > LSP_BUF_SIZE this problem will not arise.
> > >
> > >
> > > not good enough, the problem is transitive, you may have
> interface
> > > with MTU 4096, your LSP_BUF_SIZE is 1024 and you receive
> from your
> > > neighbor an LSP with size 2048 since his LSP_BUF_SIZE is
> set to 2048
> > >
> > > -- tony
> >
> >
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>
From selvarajr@future.futsoft.com Fri Apr 26 06:53:36 2002
From: selvarajr@future.futsoft.com (SelvarajR)
Date: Fri, 26 Apr 2002 11:23:36 +0530
Subject: [Isis-wg] About MTU?
In-Reply-To: <3CC8A7E9.E759A617@redback.com>
Message-ID: <001001c1ece6$b598ae80$2006040a@future.futsoft.com>
Hi,
I guess the latest 10589v2 address this by defining new TLV.
But apologies in advance that I'm not well sure about that.
The idea is that all the ISIS process in the domain agreeing upon for the
least MTU in the domain. All ISIS process should advertise their least
interface MTU(among on which ISIS is enabled, ofcourse) in their LSPs. Then,
each ISIS process shall scan there LSP data base and select the least MTU
among those advertised in the LSP, including its own LSP. This least MTU
shall be used as the LSPBufferSize. If there is any change in the current
LSPBufferSize then the ISIS process shall restart.
For this all the ISIS process should support the new TLV.
This mechanism may have quite few number of ISIS process restart as an
overhead.
No Pain No Gain ;)
I guess this may solve the problem.
Selva.
| -----Original Message-----
| From: isis-wg-admin@spider.juniper.net
| [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Tony Przygienda
| Sent: Friday, 26 April 2002 6:36 AM
| To: Ravindra Sunkad
| Cc: Jeff Learman; Wang xuepu; isis-wg@juniper.net
| Subject: Re: [Isis-wg] About MTU?
|
|
| Ravindra Sunkad wrote:
|
| > If an implementation brings down IS-IS on interfaces with
| MTU < LSP_BUF_SIZE this problem
| > will not arise.
| >
| >
| > not good enough, the problem is transitive, you may have
| interface with MTU 4096,
| > your LSP_BUF_SIZE is 1024
| > and you receive from your neighbor an LSP with size 2048
| since his LSP_BUF_SIZE is set to 2048
| >
| > -- tony
|
| _______________________________________________
| Isis-wg mailing list - Isis-wg@spider.juniper.net
| http://spider.juniper.net/mailman/listinfo/isis-wg
|
***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.
If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************
From naiming@redback.com Fri Apr 26 07:25:45 2002
From: naiming@redback.com (Naiming Shen)
Date: Thu, 25 Apr 2002 23:25:45 -0700
Subject: [Isis-wg] Re: a few comments on ietf restart isis draft
In-Reply-To: Mail from Russ White
dated Thu, 25 Apr 2002 08:30:33 EDT
Message-ID: <20020426062545.B3FB11DCC6C@prattle.redback.com>
Hi Russ,
]
] Agreed.... It's better to assume that since we've received a
] hello with the proper bits set, we should give the adjacent is a
] little more time.
]
] > > not meant to be bullet proof. If the IIHs happen to get lost,
] > > we just have a bad day. This is also the same problem if you
] > > have multiple neighbors on the same LAN. Your IIH can be lost
] > > to one of the neighbors, but as soon as you receive from
] > > other neighbors and complete the CSNPs, the T1 will be cancelled.
] > > But you have no way to know, that one neighbor didn't
] > > receive your re-start IIH, and it will reset the adjacency.
] > > The current scheme does not cover that case, and I think its
] > > not worth to have retries in general. Thus actually we don't
] > > even need the T1.
] >
] > I'm not sure. I didn't like the idea that we may be stalled
] > waiting for multiple retries, but OTOH it goes against the
] > grain to design a protocol which "fails" on the loss of a
] > single packet :-)
] >
] > I guess the question is how many times will we sit around
] > waiting for a response when we will never get one, as opposed
] > to the times when we genuinely loose a packet and this allows
] > us to re-start when we otherwise wouldn't.
]
] We could prescribe a smaller number of retries, perhaps. I don't
] like the idea of dropping a single packet causing the restart to
] fail, either.
"prescribe" is a little strong for me:-) even though I've nothing
against retries.
retries, at least the mechanism in the current draft, only solves
some easy cases, such as the re-start IIHs get lost on p2p
links. Let's see what can happen on a LAN: assume we have routers
A, B, C and D on the LAN. A is the re-start router. A sends out
a re-start IIH on the LAN, only C and D get it. There is a way
for A to know B is on the LAN by looking the re-start ACKs sent
back by C and D(assume they didn't get lost). B should be listed
as one of the neighbors of C and D. should we retry?
- if we don't retry, than its the same "dropping a single packet
causing the restart to fail".
- if we do try,
(a) just send the re-start IIH again on this LAN, then C and
D will go through this re-start again.
(b) somehow to only inform B to ack on this re-start IIH.
we can include systemIDs in the re-start TLV, and have a bit
to indicate only below systems need to respond to re-start.
- a new mechansim, since C and D all sent re-start Ack, if B sees
those Acks, B knows it missed the re-start IIH. it would be
equivalent of recv a re-start IIH:-) but it does not know who
restarted.
- need to do this for both levels. what if B received re-start
IIH on level-1 but not level-2? since re-start usually
affects both levels, maybe should let level-1 inform the
level-2 on B.
thanks.
- Naiming
From prz@net4u.ch Fri Apr 26 08:32:14 2002
From: prz@net4u.ch (Tony Przygienda)
Date: Fri, 26 Apr 2002 00:32:14 -0700
Subject: [Isis-wg] *SNP replay
References:
Message-ID: <3CC9027E.4060400@net4u.ch>
>
>
>>So a robust IS-IS implementation probably won't be very badly
>>affected by packet replay. For non-robust implementations,
>>any number of things could be a problem -- but that is an
>>implementation quality issue IMHO.
>>
>
>True. I hope that improving implementation quality
>is something worth discussing on this list.
>
yes, to some extent,
but it shouldn't be or become this list main activity, we are about
interoperating
implementations, we are not in business of protecting people from
themselves or
helping people build businesses ;-)
>What is interesting about replaying *SNP packets is
>that it is one of the few ways in ISIS to introduce
>a multiplier. The worst of the DOS attack depend
>upon other machines doing the work, and an out of
>date *SNP will cause other machines to retransmit
>LSPs. I agree that there are rate limits on how
>fast you resend an LSP, but with a large configuration,
>SNPs with stale info could force constant updates.
>
yes, also corrupted SNPs can lead to interesting effects, e.g. just sending
large SNPs full of rubish can lead to many routers running around trying to
find out what's going on ;-) Few package but large damage, I think that's
the metric you are alluring to ;-)
>(The only other packet I can think of with leverage
>is changing the priority on a hello to force a
>DIS election. If I send a duplicate of a hello
>from a low-status IS with high priority, can't I
>force all of the machines on a network to swing
>back and forth between two DISs?)
>
I don't remember of the top of my head whether ISIS spec prescribes that
but many good implementations tend to artificially bump their DIS priority
significantly when elected
to prevent other routers with same or just slightly higher priority
to bump them of the DIS. This stops a problem if e.g. a router with
highest ID
on a LAN with everyone being same priority is flacky. This has a good
chance
to prevent this kind of attack as well. Loosing DIS is
unplesant for everyone, that's why e.g. OSPF went the whole nine-yards
to get the BDR working.
thanks
-- tony
From prz@redback.com Fri Apr 26 06:19:35 2002
From: prz@redback.com (Tony Przygienda)
Date: Thu, 25 Apr 2002 22:19:35 -0700
Subject: [Isis-wg] About MTU?
References: <001001c1ece6$b598ae80$2006040a@future.futsoft.com>
Message-ID: <3CC8E367.169B1CBE@redback.com>
SelvarajR wrote:
> Hi,
> I guess the latest 10589v2 address this by defining new TLV.
> But apologies in advance that I'm not well sure about that.
> The idea is that all the ISIS process in the domain agreeing upon for the
> least MTU in the domain. All ISIS process should advertise their least
> interface MTU(among on which ISIS is enabled, ofcourse) in their LSPs. Then,
> each ISIS process shall scan there LSP data base and select the least MTU
> among those advertised in the LSP, including its own LSP. This least MTU
> shall be used as the LSPBufferSize. If there is any change in the current
> LSPBufferSize then the ISIS process shall restart.
>
> For this all the ISIS process should support the new TLV.
> This mechanism may have quite few number of ISIS process restart as an
> overhead.
> No Pain No Gain ;)
> I guess this may solve the problem.
yes, there is a proposal hanging, other people are better informed than
me. It was forwarded to this list or it's on my or maybe jeff's plate to
get it forwarded to this list via a liason if I'm not mistaken.
I better go and check my to-do list ;-)
- -tony
From jparker@axiowave.com Fri Apr 26 15:23:24 2002
From: jparker@axiowave.com (Jeff Parker)
Date: Fri, 26 Apr 2002 10:23:24 -0400
Subject: [Isis-wg] *SNP replay
Message-ID:
> >(The only other packet I can think of with leverage
> >is changing the priority on a hello to force a
> >DIS election. If I send a duplicate of a hello
> >from a low-status IS with high priority, can't I
> >force all of the machines on a network to swing
> >back and forth between two DISs?)
> >
> I don't remember of the top of my head whether ISIS spec
> prescribes that but many good implementations tend to
> artificially bump their DIS priority significantly when
> elected....
....
> OSPF went the whole nine-yards to get the BDR working.
>
> -- tony
Even if you promote yourself when you become DIS, if someone has a copy
of a valid old packet in which you had low priority, they can
send that, alternating the old with your new copy, and create churn
until the key rolls over.
It was interesting that Les's suggestion yesterday included just
such a low-priority packet when a router reboots.
- jeff parker
From jparker@axiowave.com Fri Apr 26 15:27:33 2002
From: jparker@axiowave.com (Jeff Parker)
Date: Fri, 26 Apr 2002 10:27:33 -0400
Subject: [Isis-wg] About MTU?
Message-ID:
> It was forwarded to this list or it's on my or maybe
> jeff's plate to get it forwarded to this list via a
> liason if I'm not mistaken. I better go and check my
> to-do list ;-)
>
> - -tony
Right. This is on the "update list"'s plate. I should
have replied earlier. Here is the text I have at present:
the major work is Les' while the errors are mine.
- jdp
8.0 ReceiveLSPBufferSize
Since IS-IS does not allow segmentation of protocol PDUs, Link State
PDUs (LSPs) must be propagated without modification on all IS-IS
enabled links throughout the area/domain. Thus it is essential to
configure a maximum size that all routers can forward, receive, and
store.
This affects three aspects, which we discuss in turn:
(1) The largest LSP we can receive (ReceiveLSPBufferSize)
(2) The size of the largest LSP we can generate
(originatingL1LSPBufferSize and originatingL2LSPBufferSize)
(3) Available Link MTU for supported Circuits (MTU). Note this
may differ from the MTU available to IP clients.
The protocol provides the architectural constant ReceiveLSPBufferSize
with value 1492 bytes, and two private management parameters,
originatingL1LSPBufferSize for level 1 PDUs and
originatingL2LSPBufferSize for level 2 PDUs. The originating Buffer
Size parameters define the maximum size of an LSP that a router can
generate. The protocol directs the implementor to treat a PDU larger
than ReceiveLSPBufferSize as an error.
It is crucial that
originatingL1LSPBufferSize <= ReceiveLSPBufferSize
originatingL2LSPBufferSize <= ReceiveLSPBufferSize
and that for all L1 links in the area
originatingL1LSPBufferSize <= MTU
and for all L2 links in the domain
originatingL2LSPBufferSize <= MTU
The original thought was that operators could decrease the originat-
ing Buffer size when dealing with smaller MTUs, but would not need to
increase ReceiveLSPBufferSize beyond 1492.
With the definition of new information to be advertised in LSPs, such
as the Traffic Engineering TLVs, the limited space of the LSP data-
base which may be generated by each router (256 * 1492 bytes at each
level) has become an issue. Given that modern networks with MTUs
larger than 1492 on all links are not uncommon, one method which can
be used to expand the LSP database size is to allow values of
ReceiveLSPBufferSize greater than 1492.
Allowing ReceiveLSPBUfferSize to become a configurable parameter
rather than an architectural constant must be done with care: if any
system in the network does not support values larger than 1492 or one
or more link MTUs used by IS-IS anywhere in the area/domain is
smaller than the largest LSP which may be generated by any router,
then full propagation of all LSPs may not be possible.
The steps below are recommended when changing ReceiveLSPBufferSize.
(1) Set the ReceiveLSPBufferSize to a consistent value throughout
the network.
(2) The implementation should not enable IS-IS on circuits which
do not support an MTU at least as large as the originating
BufferSize at the appropriate level.
(3) Include a originatingLSPBufferSize TLV when generating LSPs,
as described in section 9.8 of [3].
(4) When receiving LSPs, check for an originatingLSPBufferSize
TLV, and report the receipt of values larger than the local
value of ReceiveLSPBufferSize through the defined Notifica-
tions and Alarms.
(5) Report the receipt of a PDU larger than the local ReceiveL-
SPBufferSize through the defined Notifications and Alarms.
(6) Do not discard large PDUs by default. Storing and processing
them as normal PDUs may help maintain coherence in a misscon-
figured network.
Steps 1 and 2 are enough by themselves, but the consequences of
mismatch are serious enough and difficult enough to detect, that
steps 3-6 are recommended to help track down and correct problems.
> SelvarajR wrote:
>
> > Hi,
> > I guess the latest 10589v2 address this by defining new TLV.
> > But apologies in advance that I'm not well sure about that.
> > The idea is that all the ISIS process in the domain
> agreeing upon for the
> > least MTU in the domain. All ISIS process should advertise
> their least
> > interface MTU(among on which ISIS is enabled, ofcourse) in
> their LSPs. Then,
> > each ISIS process shall scan there LSP data base and select
> the least MTU
> > among those advertised in the LSP, including its own LSP.
> This least MTU
> > shall be used as the LSPBufferSize. If there is any change
> in the current
> > LSPBufferSize then the ISIS process shall restart.
> >
> > For this all the ISIS process should support the new TLV.
> > This mechanism may have quite few number of ISIS process
> restart as an
> > overhead.
> > No Pain No Gain ;)
> > I guess this may solve the problem.
>
> yes, there is a proposal hanging, other people are better
> informed than
> me. It was forwarded to this list or it's on my or maybe
> jeff's plate to
> get it forwarded to this list via a liason if I'm not mistaken.
> I better go and check my to-do list ;-)
>
> - -tony
>
>
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>
From dasnabendu@yahoo.com Sat Apr 27 09:08:27 2002
From: dasnabendu@yahoo.com (nabendu das)
Date: Sat, 27 Apr 2002 01:08:27 -0700 (PDT)
Subject: [Isis-wg] Integrated IS-IS in distributed architecture
Message-ID: <20020427080827.24516.qmail@web13208.mail.yahoo.com>
hi all,
I have few concerns regarding running IS-IS in
distributed architecture.
In case of distributed architecture, generally
we have several routing engines within a router, where
each of the routing engine act as an independent
router internally. So we need to run IS-IS internally
among the routing engines to make control information
consistent among the routing engines. We can make some
changes to run it or can add up new PDU type that will
be propagated only internally. But as each of the
routing engines are generating there own LSPs then how
can we synchronise the sequence no.s among the routing
engines because to the outside world, the router
should appear as a single entity. It should appear as
a single router only. So the sequnce nos also should
be kept synchronized because each routing engines can
not put there own MAC address in the LSPID, as in that
case all the routing engines will be treated as
independent router. this can be handled by putting the
same MAC address for all the LSPs generated by all the
routing engines. but then what about Sequence no. this
also should be synchronized.
PLz help in this regard.
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
From prz@net4u.ch Sat Apr 27 22:09:56 2002
From: prz@net4u.ch (Tony Przygienda)
Date: Sat, 27 Apr 2002 14:09:56 -0700
Subject: [Isis-wg] Integrated IS-IS in distributed architecture
References: <20020427080827.24516.qmail@web13208.mail.yahoo.com>
Message-ID: <3CCB13A4.4020601@net4u.ch>
nabendu das wrote:
>hi all,
> I have few concerns regarding running IS-IS in
>distributed architecture.
> In case of distributed architecture, generally
>we have several routing engines within a router, where
>each of the routing engine act as an independent
>router internally. So we need to run IS-IS internally
>among the routing engines to make control information
>consistent among the routing engines. We can make some
>changes to run it or can add up new PDU type that will
>be propagated only internally. But as each of the
>routing engines are generating there own LSPs then how
>can we synchronise the sequence no.s among the routing
>engines because to the outside world, the router
>should appear as a single entity. It should appear as
>a single router only. So the sequnce nos also should
>be kept synchronized because each routing engines can
>not put there own MAC address in the LSPID, as in that
>case all the routing engines will be treated as
>independent router. this can be handled by putting the
>same MAC address for all the LSPs generated by all the
>routing engines. but then what about Sequence no. this
>also should be synchronized.
>
Nabendu,
First, this list is not the right forum to discuss this topic, we should
be concerned
here with the interoperability aspects _between_ systems and not internal
implementation details like this one.
Second, you have or make a lot of assumptions of what your system looks
internally like. Many people solve the problem differently and their
architectures
vary widely from yours. A distributed system is a vague concept in terms of
routing protocols and many people choose to replicate or partition the
functionality of the protocol very differently from what you suggest. I can
recommend some of the modern books on distributed operating systems or
databases to give you food for thoughts.
And, looks like your company (and I don't assume yahoo has this problem ;-)
may be in some need of a good system architect ;-)
-- tony
From amir@cwnt.com Sun Apr 28 16:25:53 2002
From: amir@cwnt.com (Amir Hermelin)
Date: Sun, 28 Apr 2002 18:25:53 +0300
Subject: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Message-ID:
Manral,
Let me relate to some points mentioned in this dialogue.
* WRT extended capabilities TLV: this new TLV was included in draft-hermelin-ext-lsp-frags-02.txt, but was removed in subsequent versions due to lack of need. I can re-add it to the draft, or maybe a separate draft would be better. Lets have opinions from the group.
* We have previously considered your option of using same sys-id and frag-num, add new tlv in body. I withdrew from that mainly due to the numerous problems it introduces, most of which have been pointed out by Mike. I guess for the sake of brevity he didn't outline all of them - but it does change the update process, to my knowledge significantly. If you've mentioned code-changes, I believe your method would impose significant code changes in multiple processes.
* You've referred to the two modes in the draft - note that they are completely independent. Furthermore, mode 1 imposes no changes whatsoever to the spf process, and is completely compatible with older routers.
* WRT transitioning: note section 7 of the draft, first paragraph:
"it is possible to not upgrade every router in the network,
if the extended information is not routing information, but rather
data that is of use to only a subset of routers (e.g. optical
switches using ISIS could carry optical-specific information in
extended LSPs)"
This isn't possible with the other method.
* Again note section 7. It lists a very easy (and safe) method of transitioning the network.
* WRT partition repair and att bit: this is only a suggestion, and doesn't have any serious consequences whether you follow it or not.
* And finally, WRT SPF changes: Mode 2 of the draft doesn't pose any real changes to SPF, only to way LSPs are "grouped". In that regard, this is exactly the same as in your proposition.
I very much welcome your comments (especially since they livened up the discussion :-).
--
Amir Hermelin < mailto:amir@cwnt.com>
Charlotte's Web Networks Inc. < http://www.cwnt.com>
> -----Original Message-----
> From: Manral, Vishwas [mailto:VishwasM@netplane.com]
> Sent: Thursday, April 25, 2002 10:30 AM
> To: 'mike shand'
> Cc: 'isis-wg@spider.juniper.net'
> Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
> Maybe we could get someone elses views too, of what they
> feel. That would
> help. ;-)
>
> The idea of extended option in IIH is good, and may be nice for the
> exp_lsp_fragment draft too(and same with domain wide etc too).
>
> Thanks again,
> Vishwas
>
> -----Original Message-----
> From: mike shand [mailto:mshand@cisco.com]
> Sent: Thursday, April 25, 2002 12:47 PM
> To: Manral, Vishwas
> Cc: 'isis-wg@spider.juniper.net'
> Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
> At 02:46 25/04/2002 -0400, Manral, Vishwas wrote:
> >Hi Mike,
> >
> >I actually thought over it, and simplified things a bit
> further, so that we
> >never have to send both entry TLV's at one time.
> >
> >1. All routers use small LSP numbers at init time.
> >2. As routers with new functionality come up, they need to
> send the same
> >value in header and TLV LSP numbers. They need to be ready
> to accept the
> >"extended LSP entry TLV. We however still send the old LSP entry TLV.
> >3. Once all routers have the capability, we start using
> different values in
> >LSP number in the header and the TLV(extended LSP number)
> and use only
> >extended LSP entry TLV.
>
> I think you need a multi stage migration process.
>
> 1. Deploy new software everywhere which understands the new
> TLVs, and sends
> the same LSP number in both the LSP header and the extended
> TLV, but still
> only sends the old LSP entry TLV.
>
> 2. Once you have all routers with the new software, you can
> go to each
> router in turn and tell it to use new LSP entries instead of old.
>
> 3. Once you have all routers doing this, you can start using
> extended LSP
> numbers (i.e. different values in the TLV and the header).
>
> It would probably be wise to include some capability bits in
> the IIHs to
> prevent forming adjacencies with old routers once you have
> started using
> extended LSP numbers.
>
>
> But, note that this is a complex process and requires changes
> to all the
> update process code AND the SPF process code to recognize the
> additional
> LSP numbers, AND the hello processing code (if we want to make it
> reasonably safe).
>
> I'd MUCH rather confine the changes to the SPF.
>
> Mike
>
>
> >Does this sound ok? ;-)
> >
> >Thanks,
> >Vishwas
> >
> >-----Original Message-----
> >From: mike shand [mailto:mshand@cisco.com]
> >Sent: Wednesday, April 24, 2002 7:55 PM
> >To: Manral, Vishwas
> >Cc: 'isis-wg@spider.juniper.net'
> >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
> >
> >
> >At 10:07 24/04/2002 -0400, Manral, Vishwas wrote:
> > >Hi folks,
> > >
> > >As I have not got the reply to my mail, I will try and
> restate(I guess I
> > >wasn't clear) what the proposal is.
> > >
> > >The idea is to have a new TLV called LSP Number TLV, which
> contains a 32
> >bit
> > >LSP number. The new TLV is propagated in all LSP's and
> overrides the LSP
> > >Number field in the header.
> > >
> > >To migrate to this scheme, as long as all the routers in
> the network do
> not
> > >support the new TLV, we use the same value in LSP number
> field in the
> >header
> > >as well as the TLV. Once all the routers in the network
> support the new
> >TLV,
> > >we can actually use the value of the LSP number TLV and
> ignore the LSP
> > >number field in the header.
> > >
> > >The solution in this scheme seems to be a logical
> extension to the limit
> > >caused by an 8 bit LSP number field, using a 32 bit
> sequence number,
> rather
> > >than the scheme where we need multiple system id's and
> then equating the
> > >ID's.
> > >
> > >The advantages of the scheme relative to the other scheme is: -
> > >
> > >a) We use a simple migration scheme rather than a two step
> highly complex
> > >scheme.
> > >b) We need not worry about any change to routing table
> calculations.
> > >c) No taking care of attached bit.
> > >d) No taking care of partition bit.
> > >e) We need not worry about which links use what system
> id(as in the other
> > >scheme) and hence a lot of configuration.
> > >f) The amount of code changes are minimal.
> > >
> > >Regarding Mike's comment(I hope I got it right, Mike?)
> what happens when
> a
> > >new router that does not support the functionality comes
> up. Although the
> > >assumption with the other drafts like domain-wide and wide
> metrics is
> that
> > >once we migrate to a scheme, we will not try and bother
> about the older
> > >scheme, the same problem would occur in the other draft
> too if a new
> router
> > >came up after we had migrated to method 2, and someone did
> not understand
> > >the ISIS Alias TLV described there. Routing loops could
> very easily occur
> > >there.
> >
> >Where do you put the extended numbers in xSNPs? Or are you
> proposing a new
> >"extended" LSP entry TLV? What do you do for migration? send both?
> >
> >Even if you do this, if you have a router which doesn't
> understand the new
> >stuff and you are using the extended number space, you will
> get perpetual
> >re-transmission if you have two LSPs with the same "natural"
> number but
> >different extended numbers sent to a non-participating
> router. It will only
> >ACK one of them. et.c etc.
> >
> > Mike
> >
> >
> > >Any comments/criticism invited.
> > >
> > >Thanks a lot,
> > >Vishwas
> > >
> > >-----Original Message-----
> > >From: Manral, Vishwas [mailto:VishwasM@netplane.com]
> > >Sent: Tuesday, April 23, 2002 8:51 PM
> > >To: 'mike shand'
> > >Cc: 'isis-wg@spider.juniper.net'
> > >Subject: RE: [Isis-wg] Regarding
> draft-ietf-isis-ext-lsp-frags-00.txt
> > >
> > >
> > >Hi Mike,
> > >
> > >Thanks for the reply.
> > >
> > >I do not understand if we have migrated to a bigger LSp
> number, why we
> >would
> > >bring in a router that still uses a smaller LSP number,
> even when we know
> >it
> > >could create problems. This problem can occur in all cases
> of migration
> > >a) to domain wide
> > >b) wide metrics
> > >
> > >I do not see why we should introduce a two pronged method
> to do something
> > >which we can do pretty easily with just a TLV change, when similar
> > >approaches have been taken for other cases. Even in domain
> wide if a
> router
> > >came in which did not use external reachability in cases
> of L1 area the
> >same
> > >problem would occur. I do not find the reason convincing
> enough to be
> > >rejected. ;-)
> > >
> > >Thanks,
> > >Vishwas
> > >
> > >-----Original Message-----
> > >From: mike shand [mailto:mshand@cisco.com]
> > >Sent: Tuesday, April 23, 2002 6:13 PM
> > >To: Manral, Vishwas
> > >Cc: 'isis-wg@spider.juniper.net'
> > >Subject: Re: [Isis-wg] Regarding
> draft-ietf-isis-ext-lsp-frags-00.txt
> > >
> > >
> > >I'm not sure I fully understand this proposal. I assume
> that when you
> > >actually start using extended numbers you still need to
> invent additional
> > >system ID's for the extra "fragments" so that the update
> process can
> > >distinguish them. In which case it is semantically identical to the
> current
> > >scheme.
> > >
> > >Or are you proposing changing the update process so that
> it looks at the
> > >new TLV? I guess that must be what you have in mind. This
> has fairly
> > >serious consequences if you have migrated to extended
> numbers, but you
> then
> > >introduce a router which doesn't understand the new update
> process. I
> > >thought we had already considered and rejected solutions
> of this type.
> > >
> > > Mike
> > >
> > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
> > > >Hi Amir/Stefano/Mike,
> > > >
> > > >I read thru ur draft and had an alternate idea in mind.
> I wanted to
> know
> > > >what you thought of it.
> > > >
> > > >Using the LSP number a 32 bit(or 16 bit as desired)
> quantity in TLV: -
> > > >
> > > >The idea is to have a new TLV, which tells the actual
> LSP number. The
> LSP
> > > >number in the psudonode-id is not used. The changes required are
> minimum.
> > >We
> > > >anyway scan thru TLV's for authentication information,
> we can find the
> >LSP
> > > >number TLV then. We instead use this TLV.
> > > >
> > > >To migrate to such a method all we need to do is to, use same LSP
> numbers
> > >in
> > > >the header and the TLV, and once all routers recognize
> the TLV, we
> >actually
> > > >can use different numbers. This does not create any backward
> >compatibility
> > > >issues and so we dont need two methods. In this case we
> do not need to
> > >worry
> > > >about Attached bit, Partition repair bit or change to
> SPF calculations
> >etc.
> > > >The solution also seems a logical extension, to the
> constraint caused
> by
> >8
> > > >bit LSP number value. Rather than a solution that has
> multiple system
> >id's
> > > >which is like fooling the IS to believe all the systems
> are the same.
> > > >
> > > >Thanks,
> > > >Vishwas
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>
From Russ White Mon Apr 29 02:31:26 2002
From: Russ White (Russ White)
Date: Sun, 28 Apr 2002 21:31:26 -0400 (EDT)
Subject: [Isis-wg] Re: a few comments on ietf restart isis draft
In-Reply-To: <20020426062545.B3FB11DCC6C@prattle.redback.com>
Message-ID:
Then perhaps we should recommend them for p2p links.
> retries, at least the mechanism in the current draft, only
> solves some easy cases, such as the re-start IIHs get lost on
> p2p links. Let's see what can happen on a LAN: assume we have
> routers A, B, C and D on the LAN. A is the re-start router. A
> sends out a re-start IIH on the LAN, only C and D get it.
> There is a way for A to know B is on the LAN by looking the
> re-start ACKs sent back by C and D(assume they didn't get
> lost). B should be listed as one of the neighbors of C and D.
> should we retry?
-- In the case where you are the dis, then you need to send the
retries to all of the is' on the network. In that case, any which
receive two would just ignore the subsequent ones.
-- In the case where you're not the dis, you're primary concern
is the dis (obviously your dropping out isn't going to effect who
the dis is if you're not currently the dis), so retries should
directed at the dis, I would think. The rest of the adj's can be
straightened out as needed.
Does this help your broadcast network case any?
:-)
Russ
__________________________________
riw@cisco.com CCIE <>< Grace Alone
From mshand@cisco.com Mon Apr 29 09:53:06 2002
From: mshand@cisco.com (mike shand)
Date: Mon, 29 Apr 2002 09:53:06 +0100
Subject: [Isis-wg] About MTU?
In-Reply-To: <001001c1ece6$b598ae80$2006040a@future.futsoft.com>
References: <3CC8A7E9.E759A617@redback.com>
Message-ID: <4.3.2.7.2.20020429094715.04125dd0@jaws.cisco.com>
At 11:23 26/04/2002 +0530, SelvarajR wrote:
>Hi,
>I guess the latest 10589v2 address this by defining new TLV.
>But apologies in advance that I'm not well sure about that.
>The idea is that all the ISIS process in the domain agreeing upon for the
>least MTU in the domain. All ISIS process should advertise their least
>interface MTU(among on which ISIS is enabled, ofcourse) in their LSPs. Then,
>each ISIS process shall scan there LSP data base and select the least MTU
>among those advertised in the LSP, including its own LSP. This least MTU
>shall be used as the LSPBufferSize. If there is any change in the current
>LSPBufferSize then the ISIS process shall restart.
The problem with "solutions" of this type, (everyone advertises their
requirements and we select the best one dynamically) is that they are very
sensitive to problems caused by introduction of new routers (deliberately
or accidentally), partitioning (so that some demanding router is not seen
for a while) and then recovery (so that it pops back up again), and area
merging etc. etc.
Nice though "automatic" configuration may be, I can't help feeling that
only the network designer/operator really knows what is required, and
attempts by the protocol to second guess this on the fly, on the basis of
incomplete information, are ultimately doomed to failure.
Not that I'm a pessimist or anything :-)
Mike
ps. WARNING about potential misconfiguration is one thing. "Correcting" it
is another.
>For this all the ISIS process should support the new TLV.
>This mechanism may have quite few number of ISIS process restart as an
>overhead.
>No Pain No Gain ;)
>I guess this may solve the problem.
>
>Selva.
>
>| -----Original Message-----
>| From: isis-wg-admin@spider.juniper.net
>| [mailto:isis-wg-admin@spider.juniper.net]On Behalf Of Tony Przygienda
>| Sent: Friday, 26 April 2002 6:36 AM
>| To: Ravindra Sunkad
>| Cc: Jeff Learman; Wang xuepu; isis-wg@juniper.net
>| Subject: Re: [Isis-wg] About MTU?
>|
>|
>| Ravindra Sunkad wrote:
>|
>| > If an implementation brings down IS-IS on interfaces with
>| MTU < LSP_BUF_SIZE this problem
>| > will not arise.
>| >
>| >
>| > not good enough, the problem is transitive, you may have
>| interface with MTU 4096,
>| > your LSP_BUF_SIZE is 1024
>| > and you receive from your neighbor an LSP with size 2048
>| since his LSP_BUF_SIZE is set to 2048
>| >
>| > -- tony
>|
>| _______________________________________________
>| Isis-wg mailing list - Isis-wg@spider.juniper.net
>| http://spider.juniper.net/mailman/listinfo/isis-wg
>|
>
>***************************************************************************
>This message is proprietary to Future Software Limited (FSL)
>and is intended solely for the use of the individual to whom it
>is addressed. It may contain privileged or confidential information
>and should not be circulated or used for any purpose other than for
>what it is intended.
>
>If you have received this message in error, please notify the
>originator immediately. If you are not the intended recipient,
>you are notified that you are strictly prohibited from using,
>copying, altering, or disclosing the contents of this message.
>FSL accepts no responsibility for loss or damage arising from
>the use of the information transmitted by this email including
>damage from virus.
>***************************************************************************
>_______________________________________________
>Isis-wg mailing list - Isis-wg@spider.juniper.net
>http://spider.juniper.net/mailman/listinfo/isis-wg
From tli@procket.com Tue Apr 30 01:31:43 2002
From: tli@procket.com (Tony Li)
Date: Mon, 29 Apr 2002 17:31:43 -0700
Subject: [Isis-wg] Integrated IS-IS in distributed architecture
In-Reply-To: <20020427080827.24516.qmail@web13208.mail.yahoo.com>
References: <20020427080827.24516.qmail@web13208.mail.yahoo.com>
Message-ID: <15565.58863.825353.642170@alpha-tli.procket.com>
Whatever you decide to do, the rest of the world shouldn't ever know about
it.
;-)
Tony
nabendu das writes:
| hi all,
| I have few concerns regarding running IS-IS in
| distributed architecture.
| In case of distributed architecture, generally
| we have several routing engines within a router, where
| each of the routing engine act as an independent
| router internally. So we need to run IS-IS internally
| among the routing engines to make control information
| consistent among the routing engines. We can make some
| changes to run it or can add up new PDU type that will
| be propagated only internally. But as each of the
| routing engines are generating there own LSPs then how
| can we synchronise the sequence no.s among the routing
| engines because to the outside world, the router
| should appear as a single entity. It should appear as
| a single router only. So the sequnce nos also should
| be kept synchronized because each routing engines can
| not put there own MAC address in the LSPID, as in that
| case all the routing engines will be treated as
| independent router. this can be handled by putting the
| same MAC address for all the LSPs generated by all the
| routing engines. but then what about Sequence no. this
| also should be synchronized.
|
| PLz help in this regard.
|
| __________________________________________________
| Do You Yahoo!?
| Yahoo! Health - your guide to health and wellness
| http://health.yahoo.com
| _______________________________________________
| Isis-wg mailing list - Isis-wg@spider.juniper.net
| http://spider.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 naiming@redback.com Tue Apr 30 21:30:27 2002
From: naiming@redback.com (Naiming Shen)
Date: Tue, 30 Apr 2002 13:30:27 -0700
Subject: [Isis-wg] Re: a few comments on ietf restart isis draft
In-Reply-To: Mail from mike shand
dated Wed, 24 Apr 2002 14:53:26 BST
<4.3.2.7.2.20020424135645.04152420@jaws.cisco.com>
Message-ID: <20020430203027.5C4A3F2C44@prattle.redback.com>
Mike,
] >
] > I would change "DO NOT" into "MUST" here.
]
] I think, given the various scenarios, we need a bit of flexibility here. My
] intent was that the whole thing was "fail safe". i.e. if the restarting
] router didn't come back up properly, the neighbors would drop their
] adjacencies as if it had just plain failed. I didn't want the restarting
] to delay the normal recovery.
]
] However, I understand that some implementations may not be able to get back
] up within this time, especially for short hello times, and that some
] measure of "hello I'm back, could you just give me a little extra time to
] get my act together" would be helpful. I like Nischal's suggestion here.
]
Ok, if the restarting router does not come back, then it can not even
send out this IIH, thats fine. There should not be any delay here. If it
does send out the re-start IIH, let's trust it. Since the neighbors have no
way to judge if its a good or bad re-start.
My take on this is that, we either want to help this re-start neighbor
or we don't want to help this neighbor. If we do decide to help, lets help
it fully. And the re-starting router knows better how long it need to
take for recovery. The "fail safe" measure we need is to prevent this
neighbor repeatedly re-start, and that can be an implementation issue
and/or a configuration issue(e.g. user can decide only allow 5 re-start
helps). A router can be instructed to load new image, try three times
max, if all fail, then default back to the old image. In this case,
we want to make sure the 4th re-start will have enough time.
]
] > I think we should not even retry. This graceful restart is
] > not meant to be bullet proof. If the IIHs happen to get lost,
] > we just have a bad day. This is also the same problem if you
] > have multiple neighbors on the same LAN. Your IIH can be lost
] > to one of the neighbors, but as soon as you receive from
] > other neighbors and complete the CSNPs, the T1 will be cancelled.
] > But you have no way to know, that one neighbor didn't
] > receive your re-start IIH, and it will reset the adjacency.
] > The current scheme does not cover that case, and I think its
] > not worth to have retries in general. Thus actually we don't
] > even need the T1.
]
] I'm not sure. I didn't like the idea that we may be stalled waiting for
] multiple retries, but OTOH it goes against the grain to design a protocol
] which "fails" on the loss of a single packet :-)
]
] I guess the question is how many times will we sit around waiting for a
] response when we will never get one, as opposed to the times when we
] genuinely loose a packet and this allows us to re-start when we otherwise
] wouldn't.
Retry is fine as long as it leaves to the implementation for the N retries,
the N can also be zero. As I mentioned in another email exchange, the
current retry seems only cover the p2p case, the LAN case is more
complicated. If we lose IIHs, even in normal cases, we will drop
adjacencies. I don't feel particularly bad when this re-start IIH
get lost:-) the worst case is this adjacency is dropped during the
restart, it helps reducing unnecessary flooding also:-)
]
] Any other opinions?
]
] > I would be very careful setting OL bit here. T3 times out just
] > means we are sending out normal IIHs, that should not affect
] > anything even we have not acquired all the LSPs from neighbors
] > or we haven't finished our SPF.
] >
] > The goal of this graceful restart is to do non-stop forwarding,
] > if we send out our LSPs with OL on, it's not non-stop forwarding
] > any more. Yes our SPF has not finished yet, so what's the hurry?
] > why not let it to finish? Its much better to delay sending out
] > our LSPs(assume topology has not changed during re-start) since
] > routers in the area has our old LSPs containing the same
] > information, than to send out LSPs immaturely with OL bit set.
]
] The point is that we have time that we are prepared to run headless. That
] time has expired. We may be generating all sorts of loops and confusion (or
] we may not of course - we don't know). What do we do? Continue to screw up
] the traffic, or admit defeat and take ourselves out? I suggest that the
] only honest thing to do is the latter. We COULD do this by dropping all our
] adjacencies and getting our neighbors to sends LSPs saying we had gone
] away. However it seems cleaner simply to set our overload bit. This is
] after all what we would expect to do if we were coming up without re-start
] and we we were using the OL bit in this way.
]
But "That time" is defined mainly for timeout the adjacencies, its the
time when we start to send out "normal" IIHs. This has a little to do
with if we have finished the SPF or not. My point is that, each router
has its own "time" to finish the re-start. Its affected by its
position in the network, its configuration size, does it have a huge
bgp download at the time(not applicable if the implementation have
isis and bgp running on diff CPUs), does someone have a big image
downloading or bulkstats collections at the time, etc. If for example
this "time" is 25 seconds, and at re-start a particular router may
need 27 seconds. Yes, there needs to be a fixed maximum time, say 5
minutes not finished, lets shut the isis down. But only the users can
decide that. If the router has serious problem, i doubt it can properly
send out this OL bit labelled packet, or even read time correctly.
] However, it may be undesirable to actually insist on this behaviour. Maybe
] it should say that if you are following the setting the OL bit when you
] come up stuff, now would be a good time to do it.
]
] > If the re-start router has one hundred IS-IS interfaces, at
] > restart, it will receive 100 copies of the databases from
] > all the interfaces assume all the neighbors can help. We
] > also need to flooding all of them to the other 99 interfaces
] > 100 times.
]
] Um... 100 times? Why? Yes we flood the first copy we see of each LSP to all
] the other 99, but subsequent copies are just acked.
I was just saying a huge number. Yes, if they happen to occur at the
same time, lots of them will cancel each other. But some of them will
not. Say I get LSP X from intf a, flood this to intf b and c. At the
same time I get X from b also(b sent out before it got X from me), but
the SRM is cleared on intf c since I already sent X out. So I need to
flood X from b to intf a and c again. True, definitely not 100 times.
]
] I'm not sure whether these sort of optimizations need to be spelled out in
] the spec. There is some considerable scope for individual implementations
] ingenuity within the basic framework here. I don't think we want to
] over-constrain.
Ok, I agree no need to mention optimization in the draft. Lets leave it to
implementations.
thanks.
- Naiming
From naiming@redback.com Tue Apr 30 21:53:30 2002
From: naiming@redback.com (Naiming Shen)
Date: Tue, 30 Apr 2002 13:53:30 -0700
Subject: [Isis-wg] Re: a few comments on ietf restart isis draft
In-Reply-To: Mail from Russ White
dated Sun, 28 Apr 2002 21:31:26 EDT
Message-ID: <20020430205330.7526ACAB6C@prattle.redback.com>
]
] Then perhaps we should recommend them for p2p links.
fine, but lan has more chance to lose pkts i would think.
]
] -- In the case where you are the dis, then you need to send the
] retries to all of the is' on the network. In that case, any which
] receive two would just ignore the subsequent ones.
how do we decide if the neighbor restarted again, or is doing
retries? even the re-start router is the dis, someone else on
the LAN suppose to serve as a "temp" dis for help. even though
we can put a re-start counter in the re-start IIH saying this
is numberX retry, still how do we know it's due to someone else
on the LAN didn't send ACK, or my ACK actually got lost?
]
] -- In the case where you're not the dis, you're primary concern
] is the dis (obviously your dropping out isn't going to effect who
] the dis is if you're not currently the dis), so retries should
] directed at the dis, I would think. The rest of the adj's can be
] straightened out as needed.
]
] Does this help your broadcast network case any?
]
I think the simplist way is NOT to retry. Simply just sit and wait.
Your neighbor WILL send you a "normal" IIH, since it does not know
you just restarted. Just treat this "normal" IIH as it sends back
the ACK. Ok, what if this neighbor is the DIS or "temp" DIS,
we don't get all the lsps from it? but over other interfaces, we
may get more than enough of them. Ok, what if we only have one
interface? then adjacency reset or not does not affect traffic flow,
since there is only one way to go; Ok, what if all the interface
we lose all the re-start IIHs? then we probably should not being
graceful anymore:-)
- Naiming
From Hema.Malik@vivacenetworks.com Tue Apr 30 23:44:39 2002
From: Hema.Malik@vivacenetworks.com (Hema Malik)
Date: Tue, 30 Apr 2002 15:44:39 -0700
Subject: [Isis-wg] help
Message-ID:
I want to unsubscribe to the mailing list.
-----Original Message-----
From: isis-wg-request@external.juniper.net
[mailto:isis-wg-request@external.juniper.net]
Sent: Sunday, April 28, 2002 6:23 PM
To: isis-wg@spider.juniper.net
Subject: Isis-wg digest, Vol 1 #235 - 7 msgs
Send Isis-wg mailing list submissions to
isis-wg@spider.juniper.net
To subscribe or unsubscribe via the World Wide Web, visit
http://spider.juniper.net/mailman/listinfo/isis-wg
or, via email, send a message with subject or body 'help' to
isis-wg-request@spider.juniper.net
You can reach the person managing the list at
isis-wg-admin@spider.juniper.net
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Isis-wg digest..."
Today's Topics:
1. Re: About MTU? (Tony Przygienda)
2. RE: *SNP replay (Jeff Parker)
3. RE: About MTU? (Jeff Parker)
4. Integrated IS-IS in distributed architecture (nabendu das)
5. Re: Integrated IS-IS in distributed architecture (Tony Przygienda)
6. RE: Regarding draft-ietf-isis-ext-lsp-frags-00.txt (Amir Hermelin)
7. Re: Re: a few comments on ietf restart isis draft (Russ White)
--__--__--
Message: 1
Date: Thu, 25 Apr 2002 22:19:35 -0700
From: Tony Przygienda
Subject: Re: [Isis-wg] About MTU?
To: selvarajr@future.futsoft.com
Cc: "'Ravindra Sunkad'" ,
"'Jeff Learman'" , "'Wang xuepu'"
,
isis-wg@juniper.net
Reply-to: prz@redback.com
SelvarajR wrote:
> Hi,
> I guess the latest 10589v2 address this by defining new TLV. But
> apologies in advance that I'm not well sure about that. The idea is
> that all the ISIS process in the domain agreeing upon for the least
> MTU in the domain. All ISIS process should advertise their least
> interface MTU(among on which ISIS is enabled, ofcourse) in their LSPs.
> Then, each ISIS process shall scan there LSP data base and select the
> least MTU among those advertised in the LSP, including its own LSP.
> This least MTU shall be used as the LSPBufferSize. If there is any
> change in the current LSPBufferSize then the ISIS process shall
> restart.
>
> For this all the ISIS process should support the new TLV. This
> mechanism may have quite few number of ISIS process restart as an
> overhead. No Pain No Gain ;)
> I guess this may solve the problem.
yes, there is a proposal hanging, other people are better informed than me.
It was forwarded to this list or it's on my or maybe jeff's plate to get it
forwarded to this list via a liason if I'm not mistaken. I better go and
check my to-do list ;-)
- -tony
--__--__--
Message: 2
From: Jeff Parker
To: "'Tony Przygienda'" ,
"Les Ginsberg (E-mail)"
Cc: "'RJ Atkinson'" ,
"IS-IS-WG (E-mail)"
Subject: RE: [Isis-wg] *SNP replay
Date: Fri, 26 Apr 2002 10:23:24 -0400
> >(The only other packet I can think of with leverage
> >is changing the priority on a hello to force a
> >DIS election. If I send a duplicate of a hello
> >from a low-status IS with high priority, can't I
> >force all of the machines on a network to swing
> >back and forth between two DISs?)
> >
> I don't remember of the top of my head whether ISIS spec
> prescribes that but many good implementations tend to
> artificially bump their DIS priority significantly when
> elected....
....
> OSPF went the whole nine-yards to get the BDR working.
>
> -- tony
Even if you promote yourself when you become DIS, if someone has a copy
of a valid old packet in which you had low priority, they can send that,
alternating the old with your new copy, and create churn
until the key rolls over.
It was interesting that Les's suggestion yesterday included just
such a low-priority packet when a router reboots.
- jeff parker
--__--__--
Message: 3
From: Jeff Parker
To: "'prz@redback.com'" , selvarajr@future.futsoft.com
Cc: "'Ravindra Sunkad'" ,
"'Jeff Learman'"
, "'Wang xuepu'" ,
isis-wg@juniper.net, "Les Ginsberg (E-mail)"
Subject: RE: [Isis-wg] About MTU?
Date: Fri, 26 Apr 2002 10:27:33 -0400
> It was forwarded to this list or it's on my or maybe
> jeff's plate to get it forwarded to this list via a
> liason if I'm not mistaken. I better go and check my
> to-do list ;-)
>
> - -tony
Right. This is on the "update list"'s plate. I should
have replied earlier. Here is the text I have at present:
the major work is Les' while the errors are mine.
- jdp
8.0 ReceiveLSPBufferSize
Since IS-IS does not allow segmentation of protocol PDUs, Link State
PDUs (LSPs) must be propagated without modification on all IS-IS
enabled links throughout the area/domain. Thus it is essential to
configure a maximum size that all routers can forward, receive, and
store.
This affects three aspects, which we discuss in turn:
(1) The largest LSP we can receive (ReceiveLSPBufferSize)
(2) The size of the largest LSP we can generate
(originatingL1LSPBufferSize and originatingL2LSPBufferSize)
(3) Available Link MTU for supported Circuits (MTU). Note this
may differ from the MTU available to IP clients.
The protocol provides the architectural constant ReceiveLSPBufferSize
with value 1492 bytes, and two private management parameters,
originatingL1LSPBufferSize for level 1 PDUs and
originatingL2LSPBufferSize for level 2 PDUs. The originating Buffer
Size parameters define the maximum size of an LSP that a router can
generate. The protocol directs the implementor to treat a PDU larger
than ReceiveLSPBufferSize as an error.
It is crucial that
originatingL1LSPBufferSize <= ReceiveLSPBufferSize
originatingL2LSPBufferSize <= ReceiveLSPBufferSize
and that for all L1 links in the area
originatingL1LSPBufferSize <= MTU
and for all L2 links in the domain
originatingL2LSPBufferSize <= MTU
The original thought was that operators could decrease the originat-
ing Buffer size when dealing with smaller MTUs, but would not need to
increase ReceiveLSPBufferSize beyond 1492.
With the definition of new information to be advertised in LSPs, such
as the Traffic Engineering TLVs, the limited space of the LSP data-
base which may be generated by each router (256 * 1492 bytes at each
level) has become an issue. Given that modern networks with MTUs
larger than 1492 on all links are not uncommon, one method which can
be used to expand the LSP database size is to allow values of
ReceiveLSPBufferSize greater than 1492.
Allowing ReceiveLSPBUfferSize to become a configurable parameter
rather than an architectural constant must be done with care: if any
system in the network does not support values larger than 1492 or one
or more link MTUs used by IS-IS anywhere in the area/domain is
smaller than the largest LSP which may be generated by any router,
then full propagation of all LSPs may not be possible.
The steps below are recommended when changing ReceiveLSPBufferSize.
(1) Set the ReceiveLSPBufferSize to a consistent value throughout
the network.
(2) The implementation should not enable IS-IS on circuits which
do not support an MTU at least as large as the originating
BufferSize at the appropriate level.
(3) Include a originatingLSPBufferSize TLV when generating LSPs,
as described in section 9.8 of [3].
(4) When receiving LSPs, check for an originatingLSPBufferSize
TLV, and report the receipt of values larger than the local
value of ReceiveLSPBufferSize through the defined Notifica-
tions and Alarms.
(5) Report the receipt of a PDU larger than the local ReceiveL-
SPBufferSize through the defined Notifications and Alarms.
(6) Do not discard large PDUs by default. Storing and processing
them as normal PDUs may help maintain coherence in a misscon-
figured network.
Steps 1 and 2 are enough by themselves, but the consequences of
mismatch are serious enough and difficult enough to detect, that
steps 3-6 are recommended to help track down and correct problems.
> SelvarajR wrote:
>
> > Hi,
> > I guess the latest 10589v2 address this by defining new TLV. But
> > apologies in advance that I'm not well sure about that. The idea is
> > that all the ISIS process in the domain
> agreeing upon for the
> > least MTU in the domain. All ISIS process should advertise
> their least
> > interface MTU(among on which ISIS is enabled, ofcourse) in
> their LSPs. Then,
> > each ISIS process shall scan there LSP data base and select
> the least MTU
> > among those advertised in the LSP, including its own LSP.
> This least MTU
> > shall be used as the LSPBufferSize. If there is any change
> in the current
> > LSPBufferSize then the ISIS process shall restart.
> >
> > For this all the ISIS process should support the new TLV. This
> > mechanism may have quite few number of ISIS process
> restart as an
> > overhead.
> > No Pain No Gain ;)
> > I guess this may solve the problem.
>
> yes, there is a proposal hanging, other people are better
> informed than
> me. It was forwarded to this list or it's on my or maybe
> jeff's plate to
> get it forwarded to this list via a liason if I'm not mistaken.
> I better go and check my to-do list ;-)
>
> - -tony
>
>
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>
--__--__--
Message: 4
Date: Sat, 27 Apr 2002 01:08:27 -0700 (PDT)
From: nabendu das
To: isis-wg@juniper.net
Subject: [Isis-wg] Integrated IS-IS in distributed architecture
hi all,
I have few concerns regarding running IS-IS in distributed
architecture.
In case of distributed architecture, generally
we have several routing engines within a router, where
each of the routing engine act as an independent
router internally. So we need to run IS-IS internally
among the routing engines to make control information consistent among the
routing engines. We can make some changes to run it or can add up new PDU
type that will be propagated only internally. But as each of the routing
engines are generating there own LSPs then how can we synchronise the
sequence no.s among the routing engines because to the outside world, the
router should appear as a single entity. It should appear as a single router
only. So the sequnce nos also should be kept synchronized because each
routing engines can not put there own MAC address in the LSPID, as in that
case all the routing engines will be treated as independent router. this can
be handled by putting the same MAC address for all the LSPs generated by all
the routing engines. but then what about Sequence no. this also should be
synchronized.
PLz help in this regard.
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness http://health.yahoo.com
--__--__--
Message: 5
Date: Sat, 27 Apr 2002 14:09:56 -0700
From: Tony Przygienda
Subject: Re: [Isis-wg] Integrated IS-IS in distributed architecture
To: nabendu das
Cc: isis-wg@juniper.net
nabendu das wrote:
>hi all,
> I have few concerns regarding running IS-IS in distributed
>architecture.
> In case of distributed architecture, generally
>we have several routing engines within a router, where
>each of the routing engine act as an independent
>router internally. So we need to run IS-IS internally
>among the routing engines to make control information consistent among
>the routing engines. We can make some changes to run it or can add up
>new PDU type that will be propagated only internally. But as each of
>the routing engines are generating there own LSPs then how
>can we synchronise the sequence no.s among the routing
>engines because to the outside world, the router
>should appear as a single entity. It should appear as
>a single router only. So the sequnce nos also should
>be kept synchronized because each routing engines can
>not put there own MAC address in the LSPID, as in that
>case all the routing engines will be treated as
>independent router. this can be handled by putting the
>same MAC address for all the LSPs generated by all the
>routing engines. but then what about Sequence no. this
>also should be synchronized.
>
Nabendu,
First, this list is not the right forum to discuss this topic, we should
be concerned
here with the interoperability aspects _between_ systems and not internal
implementation details like this one.
Second, you have or make a lot of assumptions of what your system looks
internally like. Many people solve the problem differently and their
architectures
vary widely from yours. A distributed system is a vague concept in terms of
routing protocols and many people choose to replicate or partition the
functionality of the protocol very differently from what you suggest. I can
recommend some of the modern books on distributed operating systems or
databases to give you food for thoughts.
And, looks like your company (and I don't assume yahoo has this problem ;-)
may be in some need of a good system architect ;-)
-- tony
--__--__--
Message: 6
Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
Date: Sun, 28 Apr 2002 18:25:53 +0300
From: "Amir Hermelin"
To: "Manral, Vishwas"
Cc: , "Amir Hermelin"
Manral,
Let me relate to some points mentioned in this dialogue.
* WRT extended capabilities TLV: this new TLV was included in
draft-hermelin-ext-lsp-frags-02.txt, but was removed in subsequent versions
due to lack of need. I can re-add it to the draft, or maybe a separate draft
would be better. Lets have opinions from the group.
* We have previously considered your option of using same sys-id and
frag-num, add new tlv in body. I withdrew from that mainly due to the
numerous problems it introduces, most of which have been pointed out by
Mike. I guess for the sake of brevity he didn't outline all of them - but it
does change the update process, to my knowledge significantly. If you've
mentioned code-changes, I believe your method would impose significant code
changes in multiple processes.
* You've referred to the two modes in the draft - note that they are
completely independent. Furthermore, mode 1 imposes no changes whatsoever to
the spf process, and is completely compatible with older routers.
* WRT transitioning: note section 7 of the draft, first paragraph: "it is
possible to not upgrade every router in the network,
if the extended information is not routing information, but rather
data that is of use to only a subset of routers (e.g. optical
switches using ISIS could carry optical-specific information in
extended LSPs)"
This isn't possible with the other method.
* Again note section 7. It lists a very easy (and safe) method of
transitioning the network.
* WRT partition repair and att bit: this is only a suggestion, and doesn't
have any serious consequences whether you follow it or not.
* And finally, WRT SPF changes: Mode 2 of the draft doesn't pose any real
changes to SPF, only to way LSPs are "grouped". In that regard, this is
exactly the same as in your proposition.
I very much welcome your comments (especially since they livened up the
discussion :-).
--
Amir Hermelin < mailto:amir@cwnt.com>
Charlotte's Web Networks Inc. < http://www.cwnt.com>
> -----Original Message-----
> From: Manral, Vishwas [mailto:VishwasM@netplane.com]
> Sent: Thursday, April 25, 2002 10:30 AM
> To: 'mike shand'
> Cc: 'isis-wg@spider.juniper.net'
> Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
> Maybe we could get someone elses views too, of what they
> feel. That would
> help. ;-)
>
> The idea of extended option in IIH is good, and may be nice for the
> exp_lsp_fragment draft too(and same with domain wide etc too).
>
> Thanks again,
> Vishwas
>
> -----Original Message-----
> From: mike shand [mailto:mshand@cisco.com]
> Sent: Thursday, April 25, 2002 12:47 PM
> To: Manral, Vishwas
> Cc: 'isis-wg@spider.juniper.net'
> Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
>
>
> At 02:46 25/04/2002 -0400, Manral, Vishwas wrote:
> >Hi Mike,
> >
> >I actually thought over it, and simplified things a bit
> further, so that we
> >never have to send both entry TLV's at one time.
> >
> >1. All routers use small LSP numbers at init time.
> >2. As routers with new functionality come up, they need to
> send the same
> >value in header and TLV LSP numbers. They need to be ready
> to accept the
> >"extended LSP entry TLV. We however still send the old LSP entry TLV.
> >3. Once all routers have the capability, we start using
> different values in
> >LSP number in the header and the TLV(extended LSP number)
> and use only
> >extended LSP entry TLV.
>
> I think you need a multi stage migration process.
>
> 1. Deploy new software everywhere which understands the new
> TLVs, and sends
> the same LSP number in both the LSP header and the extended
> TLV, but still
> only sends the old LSP entry TLV.
>
> 2. Once you have all routers with the new software, you can
> go to each
> router in turn and tell it to use new LSP entries instead of old.
>
> 3. Once you have all routers doing this, you can start using
> extended LSP
> numbers (i.e. different values in the TLV and the header).
>
> It would probably be wise to include some capability bits in
> the IIHs to
> prevent forming adjacencies with old routers once you have
> started using
> extended LSP numbers.
>
>
> But, note that this is a complex process and requires changes
> to all the
> update process code AND the SPF process code to recognize the
> additional
> LSP numbers, AND the hello processing code (if we want to make it
> reasonably safe).
>
> I'd MUCH rather confine the changes to the SPF.
>
> Mike
>
>
> >Does this sound ok? ;-)
> >
> >Thanks,
> >Vishwas
> >
> >-----Original Message-----
> >From: mike shand [mailto:mshand@cisco.com]
> >Sent: Wednesday, April 24, 2002 7:55 PM
> >To: Manral, Vishwas
> >Cc: 'isis-wg@spider.juniper.net'
> >Subject: RE: [Isis-wg] Regarding draft-ietf-isis-ext-lsp-frags-00.txt
> >
> >
> >At 10:07 24/04/2002 -0400, Manral, Vishwas wrote:
> > >Hi folks,
> > >
> > >As I have not got the reply to my mail, I will try and
> restate(I guess I
> > >wasn't clear) what the proposal is.
> > >
> > >The idea is to have a new TLV called LSP Number TLV, which
> contains a 32
> >bit
> > >LSP number. The new TLV is propagated in all LSP's and
> overrides the LSP
> > >Number field in the header.
> > >
> > >To migrate to this scheme, as long as all the routers in
> the network do
> not
> > >support the new TLV, we use the same value in LSP number
> field in the
> >header
> > >as well as the TLV. Once all the routers in the network
> support the new
> >TLV,
> > >we can actually use the value of the LSP number TLV and
> ignore the LSP
> > >number field in the header.
> > >
> > >The solution in this scheme seems to be a logical
> extension to the limit
> > >caused by an 8 bit LSP number field, using a 32 bit
> sequence number,
> rather
> > >than the scheme where we need multiple system id's and
> then equating the
> > >ID's.
> > >
> > >The advantages of the scheme relative to the other scheme is: -
> > >
> > >a) We use a simple migration scheme rather than a two step
> highly complex
> > >scheme.
> > >b) We need not worry about any change to routing table
> calculations.
> > >c) No taking care of attached bit.
> > >d) No taking care of partition bit.
> > >e) We need not worry about which links use what system
> id(as in the other
> > >scheme) and hence a lot of configuration.
> > >f) The amount of code changes are minimal.
> > >
> > >Regarding Mike's comment(I hope I got it right, Mike?)
> what happens when
> a
> > >new router that does not support the functionality comes
> up. Although the
> > >assumption with the other drafts like domain-wide and wide
> metrics is
> that
> > >once we migrate to a scheme, we will not try and bother
> about the older
> > >scheme, the same problem would occur in the other draft
> too if a new
> router
> > >came up after we had migrated to method 2, and someone did
> not understand
> > >the ISIS Alias TLV described there. Routing loops could
> very easily occur
> > >there.
> >
> >Where do you put the extended numbers in xSNPs? Or are you
> proposing a new
> >"extended" LSP entry TLV? What do you do for migration? send both?
> >
> >Even if you do this, if you have a router which doesn't
> understand the new
> >stuff and you are using the extended number space, you will
> get perpetual
> >re-transmission if you have two LSPs with the same "natural"
> number but
> >different extended numbers sent to a non-participating
> router. It will only
> >ACK one of them. et.c etc.
> >
> > Mike
> >
> >
> > >Any comments/criticism invited.
> > >
> > >Thanks a lot,
> > >Vishwas
> > >
> > >-----Original Message-----
> > >From: Manral, Vishwas [mailto:VishwasM@netplane.com]
> > >Sent: Tuesday, April 23, 2002 8:51 PM
> > >To: 'mike shand'
> > >Cc: 'isis-wg@spider.juniper.net'
> > >Subject: RE: [Isis-wg] Regarding
> draft-ietf-isis-ext-lsp-frags-00.txt
> > >
> > >
> > >Hi Mike,
> > >
> > >Thanks for the reply.
> > >
> > >I do not understand if we have migrated to a bigger LSp
> number, why we
> >would
> > >bring in a router that still uses a smaller LSP number,
> even when we know
> >it
> > >could create problems. This problem can occur in all cases
> of migration
> > >a) to domain wide
> > >b) wide metrics
> > >
> > >I do not see why we should introduce a two pronged method
> to do something
> > >which we can do pretty easily with just a TLV change, when similar
> > >approaches have been taken for other cases. Even in domain
> wide if a
> router
> > >came in which did not use external reachability in cases
> of L1 area the
> >same
> > >problem would occur. I do not find the reason convincing
> enough to be
> > >rejected. ;-)
> > >
> > >Thanks,
> > >Vishwas
> > >
> > >-----Original Message-----
> > >From: mike shand [mailto:mshand@cisco.com]
> > >Sent: Tuesday, April 23, 2002 6:13 PM
> > >To: Manral, Vishwas
> > >Cc: 'isis-wg@spider.juniper.net'
> > >Subject: Re: [Isis-wg] Regarding
> draft-ietf-isis-ext-lsp-frags-00.txt
> > >
> > >
> > >I'm not sure I fully understand this proposal. I assume
> that when you
> > >actually start using extended numbers you still need to
> invent additional
> > >system ID's for the extra "fragments" so that the update
> process can
> > >distinguish them. In which case it is semantically identical to the
> current
> > >scheme.
> > >
> > >Or are you proposing changing the update process so that
> it looks at the
> > >new TLV? I guess that must be what you have in mind. This
> has fairly
> > >serious consequences if you have migrated to extended
> numbers, but you
> then
> > >introduce a router which doesn't understand the new update
> process. I
> > >thought we had already considered and rejected solutions
> of this type.
> > >
> > > Mike
> > >
> > >At 05:06 23/04/2002 -0400, Manral, Vishwas wrote:
> > > >Hi Amir/Stefano/Mike,
> > > >
> > > >I read thru ur draft and had an alternate idea in mind.
> I wanted to
> know
> > > >what you thought of it.
> > > >
> > > >Using the LSP number a 32 bit(or 16 bit as desired)
> quantity in TLV: -
> > > >
> > > >The idea is to have a new TLV, which tells the actual
> LSP number. The
> LSP
> > > >number in the psudonode-id is not used. The changes required are
> minimum.
> > >We
> > > >anyway scan thru TLV's for authentication information,
> we can find the
> >LSP
> > > >number TLV then. We instead use this TLV.
> > > >
> > > >To migrate to such a method all we need to do is to, use same LSP
> numbers
> > >in
> > > >the header and the TLV, and once all routers recognize
> the TLV, we
> >actually
> > > >can use different numbers. This does not create any backward
> >compatibility
> > > >issues and so we dont need two methods. In this case we
> do not need to
> > >worry
> > > >about Attached bit, Partition repair bit or change to
> SPF calculations
> >etc.
> > > >The solution also seems a logical extension, to the
> constraint caused
> by
> >8
> > > >bit LSP number value. Rather than a solution that has
> multiple system
> >id's
> > > >which is like fooling the IS to believe all the systems
> are the same.
> > > >
> > > >Thanks,
> > > >Vishwas
> _______________________________________________
> Isis-wg mailing list - Isis-wg@spider.juniper.net
> http://spider.juniper.net/mailman/listinfo/isis-wg
>
--__--__--
Message: 7
Date: Sun, 28 Apr 2002 21:31:26 -0400 (EDT)
From: Russ White
Reply-To: Russ White
To: Naiming Shen
cc: mike shand , isis-wg@spider.juniper.net
Subject: Re: [Isis-wg] Re: a few comments on ietf restart isis draft
Then perhaps we should recommend them for p2p links.
> retries, at least the mechanism in the current draft, only solves some
> easy cases, such as the re-start IIHs get lost on p2p links. Let's see
> what can happen on a LAN: assume we have routers A, B, C and D on the
> LAN. A is the re-start router. A sends out a re-start IIH on the LAN,
> only C and D get it. There is a way for A to know B is on the LAN by
> looking the re-start ACKs sent back by C and D(assume they didn't get
> lost). B should be listed as one of the neighbors of C and D.
> should we retry?
-- In the case where you are the dis, then you need to send the retries to
all of the is' on the network. In that case, any which receive two would
just ignore the subsequent ones.
-- In the case where you're not the dis, you're primary concern is the dis
(obviously your dropping out isn't going to effect who the dis is if you're
not currently the dis), so retries should directed at the dis, I would
think. The rest of the adj's can be straightened out as needed.
Does this help your broadcast network case any?
:-)
Russ
__________________________________
riw@cisco.com CCIE <>< Grace Alone
--__--__--
_______________________________________________
Isis-wg mailing list - Isis-wg@spider.juniper.net
http://spider.juniper.net/mailman/listinfo/isis-wg
End of Isis-wg Digest
From naiming@redback.com Wed Apr 10 06:53:35 2002
From: naiming@redback.com (Naiming Shen)
Date: Tue, 09 Apr 2002 22:53:35 -0700
Subject: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02
In-Reply-To: Mail from stefano previdi
dated Wed, 10 Apr 2002 03:02:32 +0200
<200204100102.DAA12879@strange-brew.cisco.com>
Message-ID: <20020410055335.B18F21DCC6C@prattle.redback.com>
] On Tuesday 09 April 2002 23:41, Naiming Shen wrote:
] > If one is going to make it a 64-bit tag, it maybe good to make it
] > a variable size(n x 32bits) to accommodate future "crazy" applications.
]
] after some thoughts and discussions it came out that the best
] way is probably to define one subTLV for 32bits tags and another
] subTLV for 64bits ones.
]
that works for me too. if someone later on need a different one, they
just need to have a third subTLV, say 256 bits wide...
thanks.
] s.
- Naiming
From naiming@redback.com Wed Apr 10 06:53:35 2002
From: naiming@redback.com (Naiming Shen)
Date: Tue, 09 Apr 2002 22:53:35 -0700
Subject: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02
In-Reply-To: Mail from stefano previdi
dated Wed, 10 Apr 2002 03:02:32 +0200
<200204100102.DAA12879@strange-brew.cisco.com>
Message-ID: <20020410055335.B18F21DCC6C@prattle.redback.com>
] On Tuesday 09 April 2002 23:41, Naiming Shen wrote:
] > If one is going to make it a 64-bit tag, it maybe good to make it
] > a variable size(n x 32bits) to accommodate future "crazy" applications.
]
] after some thoughts and discussions it came out that the best
] way is probably to define one subTLV for 32bits tags and another
] subTLV for 64bits ones.
]
that works for me too. if someone later on need a different one, they
just need to have a third subTLV, say 256 bits wide...
thanks.
] s.
- Naiming
From naiming@redback.com Wed Apr 10 06:53:35 2002
From: naiming@redback.com (Naiming Shen)
Date: Tue, 09 Apr 2002 22:53:35 -0700
Subject: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02
In-Reply-To: Mail from stefano previdi
dated Wed, 10 Apr 2002 03:02:32 +0200
<200204100102.DAA12879@strange-brew.cisco.com>
Message-ID: <20020410055335.B18F21DCC6C@prattle.redback.com>
] On Tuesday 09 April 2002 23:41, Naiming Shen wrote:
] > If one is going to make it a 64-bit tag, it maybe good to make it
] > a variable size(n x 32bits) to accommodate future "crazy" applications.
]
] after some thoughts and discussions it came out that the best
] way is probably to define one subTLV for 32bits tags and another
] subTLV for 64bits ones.
]
that works for me too. if someone later on need a different one, they
just need to have a third subTLV, say 256 bits wide...
thanks.
] s.
- Naiming
From naiming@redback.com Wed Apr 10 06:53:35 2002
From: naiming@redback.com (Naiming Shen)
Date: Tue, 09 Apr 2002 22:53:35 -0700
Subject: [Isis-wg] RE: 64-bit tags in draft-martin-neal-policy-isis-admin-tags-02
In-Reply-To: Mail from stefano previdi
dated Wed, 10 Apr 2002 03:02:32 +0200
<200204100102.DAA12879@strange-brew.cisco.com>
Message-ID: <20020410055335.B18F21DCC6C@prattle.redback.com>
] On Tuesday 09 April 2002 23:41, Naiming Shen wrote:
] > If one is going to make it a 64-bit tag, it maybe good to make it
] > a variable size(n x 32bits) to accommodate future "crazy" applications.
]
] after some thoughts and discussions it came out that the best
] way is probably to define one subTLV for 32bits tags and another
] subTLV for 64bits ones.
]
that works for me too. if someone later on need a different one, they
just need to have a third subTLV, say 256 bits wide...
thanks.
] s.
- Naiming