Subject: [Isis-wg] help

From: Hema Malik <[email-masked]>
Date: Tue, 30 Apr 2002 15:44:39 -0700

I want to unsubscribe to the mailing list.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Sunday, April 28, 2002 6:23 PM
To: [email-masked]
Subject: Isis-wg digest, Vol 1 #235 - 7 msgs

Send Isis-wg mailing list submissions to
	[email-masked]

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
	[email-masked]

You can reach the person managing the list at
	[email-masked]

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 <[email-masked]>
Subject: Re: [Isis-wg] About  MTU?
To: [email-masked]
Cc: "'Ravindra Sunkad'" <[email-masked]>,
   "'Jeff Learman'" <[email-masked]>, "'Wang xuepu'"
<[email-masked]>,
   [email-masked]
Reply-to: [email-masked]

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 <[email-masked]>
To: "'Tony Przygienda'" <[email-masked]>,
   "Les Ginsberg (E-mail)"
	 <[email-masked]>
Cc: "'RJ Atkinson'" <[email-masked]>,
   "IS-IS-WG (E-mail)"
	 <[email-masked]>
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 <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Cc: "'Ravindra Sunkad'" <[email-masked]>,
   "'Jeff Learman'"
	 <[email-masked]>, "'Wang xuepu'" <[email-masked]>,
   [email-masked], "Les Ginsberg (E-mail)" <[email-masked]>
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.

<EOT>

> 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  -  [email-masked] 
> http://spider.juniper.net/mailman/listinfo/isis-wg
> 

--__--__--

Message: 4
Date: Sat, 27 Apr 2002 01:08:27 -0700 (PDT)
From: nabendu das <[email-masked]>
To: [email-masked]
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 <[email-masked]>
Subject: Re: [Isis-wg] Integrated IS-IS in distributed architecture
To: nabendu das <[email-masked]>
Cc: [email-masked]

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" <[email-masked]>
To: "Manral, Vishwas" <[email-masked]>
Cc: <[email-masked]>, "Amir Hermelin" <[email-masked]>

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:[email-masked]>
Charlotte's Web Networks Inc.     < http://www.cwnt.com>

> -----Original Message-----
> From: Manral, Vishwas [mailto:[email-masked]]
> Sent: Thursday, April 25, 2002 10:30 AM
> To: 'mike shand'
> Cc: [email-masked]'
> 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:[email-masked]]
> Sent: Thursday, April 25, 2002 12:47 PM
> To: Manral, Vishwas
> Cc: [email-masked]'
> 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:[email-masked]]
> >Sent: Wednesday, April 24, 2002 7:55 PM
> >To: Manral, Vishwas
> >Cc: [email-masked]'
> >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:[email-masked]]
> > >Sent: Tuesday, April 23, 2002 8:51 PM
> > >To: 'mike shand'
> > >Cc: [email-masked]'
> > >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:[email-masked]]
> > >Sent: Tuesday, April 23, 2002 6:13 PM
> > >To: Manral, Vishwas
> > >Cc: [email-masked]'
> > >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  -  [email-masked] 
> http://spider.juniper.net/mailman/listinfo/isis-wg
> 

--__--__--

Message: 7
Date: Sun, 28 Apr 2002 21:31:26 -0400 (EDT)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Naiming Shen <[email-masked]>
cc: mike shand <[email-masked]>, [email-masked]
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

__________________________________
[email-masked] CCIE <>< Grace Alone

--__--__--

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

End of Isis-wg Digest
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg