headers
Abhishek Verma | 7 Jan 2005 09:30
Picon

Flooding LSPs and HELLOs

Hello,

In link state protocols like ISIS we flood whatever LSPs that we get
from our neighbors to our other neighbors, so that everybody fills in
the pieces of a big jig-saw puzzle and everyone comes up with a
consistent view of the network. Do we then flood all the HELLOs also
that we recieve from our neighbors. I believe we dont. Please correct
me if i am wrong.

We, thus only flood the LSPs that we receive from our neighbors to the
adjacent routers and nothing else.

Thanks,
Abhishek

--
Class of 2004
Institute of Technology, BHU
Varanasi, India
Permalink | Reply | 2 comments |
headers
Hannes Gredler | 7 Jan 2005 09:42
Favicon
Gravatar

Re: Strange p2p adjacencies

On Tue, Dec 28, 2004 at 04:36:20PM +0530, Abhishek Verma wrote:
| Hi,
| 
| In broadcast media by default we form both L1 and L2 adjacencies and
| never one L1/L2 adjacency. So we can have 2 kinds of adjacencies in
| broadcast media - L1 only and L2 only. Two routers can either have any
| one of these or both of these.
| 
| But why in point-to-point do we have either (i) L1 only (ii) L2 only
| and (iii) L1/L2.
| 
| Why dont we have two adjacencies L1 and L2 between two p2p links? Why
| do we have just one L1/L2 adjacency?

on p2p links there is just one IIH codepoint (17) shared for
L1/L2 hellos - contrary to bcast media where there is 
a dedicated codepoint per Level (15,16);

/hannes
Permalink | Reply | 0 comments |
headers
Hannes Gredler | 7 Jan 2005 09:46
Favicon
Gravatar

Re: Strange p2p adjacencies

On Tue, Dec 28, 2004 at 06:26:52PM +0530, Abhishek Verma wrote:
| Hemanth,
| 
| This tells me why we can have only one kind of adjacency in P2P links.
| And thanks for that!
| 
| But why is this so? Why has ISIS been so designed? Why do we then have
| 2 kinds of adjacencies in Broadcast media?
| 
| Any clues?

the original idea was to save bandwidth on low-bandwidth links;

given that most IS-IS adjacencies these days run on fat pipes
and control-plane processors have suffiecient CPU 
IMHO the once optimization does more harm (e.g. confusion about
per-Level passwords etc.) than good.

/hannes
Permalink | Reply | 1 comment |
headers
hemanthbs | 7 Jan 2005 09:53
Favicon

RE: Flooding LSPs and HELLOs


Hi,

          Yes we flooding only the LSPs. In link state
protocols(ISIS,OSPF) all routers in the network should have identical
information about the network(other routers), that is there should be a
synchronization of the databases between all routers in the network.
This is achieved with the help of flooding.i.e we flood the LSPs on all
links except the one we received on.
         Hellos are not flooded.Hellos are significant only w.r.t to a
pair of routers connected on that particular link(P2P) or set of routers
(on LAN). Their main purpose is to establish & maintain peers.

bye

S.Hemanth Balaji.
Software Engineer.
Huawei Technologies India Pvt Ltd.
Bangalore, India.

-----Original Message-----
From: isis-wg-bounces <at> ietf.org [mailto:isis-wg-bounces <at> ietf.org] On
Behalf Of Abhishek Verma
Sent: Friday, January 07, 2005 2:00 PM
To: ISIS-WG (E-mail)
Subject: [Isis-wg] Flooding LSPs and HELLOs

Hello,

In link state protocols like ISIS we flood whatever LSPs that we get
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hannes Gredler | 7 Jan 2005 09:48
Favicon
Gravatar

Re: Flooding LSPs and HELLOs

On Fri, Jan 07, 2005 at 02:00:28PM +0530, Abhishek Verma wrote:
| Hello,
| 
| In link state protocols like ISIS we flood whatever LSPs that we get
| from our neighbors to our other neighbors, so that everybody fills in
| the pieces of a big jig-saw puzzle and everyone comes up with a
| consistent view of the network. Do we then flood all the HELLOs also
| that we recieve from our neighbors. I believe we dont. Please correct
| me if i am wrong.

there is no notion of flooding for IIHs, see
IIHs are not "flooded" as they always have a
link-local meaning and are not significant on other ends
of teh network;

| We, thus only flood the LSPs that we receive from our neighbors to the
| adjacent routers and nothing else.

not to forget the self-originated LSPs of course which are flooded to
all the neighbors;

/hannes
Permalink | Reply | 0 comments |
headers
Abhishek Verma | 7 Jan 2005 12:33
Picon

Re: Strange p2p adjacencies

Hi Hannes,

> the original idea was to save bandwidth on low-bandwidth links;

I fail to understand as to how this can result in saving the bandwidth
on low-bandwidth links? In fact it now makes things even worse. With
having two kinds of adjacecnies in broadcast networks arent we
utilizing more bandwidth.

Or did you mean that having an L1/L2 adjacency was because of lower
bandwidth requirements!

> 
> given that most IS-IS adjacencies these days run on fat pipes
> and control-plane processors have suffiecient CPU
> IMHO the once optimization does more harm (e.g. confusion about
> per-Level passwords etc.) than good.
> 
> /hannes
> 

--

-- 

--
Class of 2004
Institute of Technology, BHU
Varanasi, India
Permalink | Reply | 0 comments |
headers
appallar | 8 Jan 2005 08:42

Re: Re: Strange p2p adjacencies

Hello,

 In a broadcast medium, there could be multiple routers connected, hence we need to know which routers are L1
and which are L2 so we have two types of hellos to keep track of all L1 and L2 routers, where as in p2p network,
we have only one system on the other end, hence we need to know the system type of the neighbor and have
adjacency as L1 or L2 or L12.

Suryanarayana 

"Hannes Gredler"<hannes <at> juniper.net> wrote:
On Tue, Dec 28, 2004 at 06:26:52PM +0530, Abhishek Verma wrote:
| Hemanth,
| 
| This tells me why we can have only one kind of adjacency in P2P links.
| And thanks for that!
| 
| But why is this so? Why has ISIS been so designed? Why do we then have
| 2 kinds of adjacencies in Broadcast media?
| 
| Any clues?

the original idea was to save bandwidth on low-bandwidth links;

given that most IS-IS adjacencies these days run on fat pipes
and control-plane processors have suffiecient CPU 
IMHO the once optimization does more harm (e.g. confusion about
per-Level passwords etc.) than good.

/hannes
(Continue reading)

Permalink | Reply | 0 comments |
headers
JP Vasseur | 13 Jan 2005 00:14
Picon
Favicon

Fwd: WG Action: Path Computation Element (pce)

FYI,

JP.

Begin forwarded message:

> From: The IESG <iesg-secretary <at> ietf.org>
> Date: January 12, 2005 3:39:31 PM EST
> To: IETF-Announce <at> ietf.org
> Cc: pce <at> ietf.org, Adrian Farrel <adrian <at> olddog.co.uk>, JP Vasseur 
> <jvasseur <at> cisco.com>
> Subject: WG Action: Path Computation Element (pce)
>
> A new IETF working group has been formed in the Routing Area. For 
> additional
> information, please contact the Area Directors or the WG Chairs.
>
> Path Computation Element (pce)
> ================================
>
> Current Status: Active Working Group
>
> Chair(s):
> Adrian Farrel <adrian <at> olddog.co.uk>
> JP Vasseur <jvasseur <at> cisco.com>
>
> Routing Area Director(s):
> Bill Fenner <fenner <at> research.att.com>
> Alex Zinin <zinin <at> psg.com>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
JP Vasseur | 13 Jan 2005 00:14
Picon
Favicon

[mpls] Fwd: WG Action: Path Computation Element (pce)

FYI,

JP.

Begin forwarded message:

> From: The IESG <iesg-secretary <at> ietf.org>
> Date: January 12, 2005 3:39:31 PM EST
> To: IETF-Announce <at> ietf.org
> Cc: pce <at> ietf.org, Adrian Farrel <adrian <at> olddog.co.uk>, JP Vasseur 
> <jvasseur <at> cisco.com>
> Subject: WG Action: Path Computation Element (pce)
>
> A new IETF working group has been formed in the Routing Area. For 
> additional
> information, please contact the Area Directors or the WG Chairs.
>
> Path Computation Element (pce)
> ================================
>
> Current Status: Active Working Group
>
> Chair(s):
> Adrian Farrel <adrian <at> olddog.co.uk>
> JP Vasseur <jvasseur <at> cisco.com>
>
> Routing Area Director(s):
> Bill Fenner <fenner <at> research.att.com>
> Alex Zinin <zinin <at> psg.com>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
JP Vasseur | 13 Jan 2005 00:14
Picon
Favicon

[mpls] Fwd: WG Action: Path Computation Element (pce)

FYI,

JP.

Begin forwarded message:

> From: The IESG <iesg-secretary <at> ietf.org>
> Date: January 12, 2005 3:39:31 PM EST
> To: IETF-Announce <at> ietf.org
> Cc: pce <at> ietf.org, Adrian Farrel <adrian <at> olddog.co.uk>, JP Vasseur 
> <jvasseur <at> cisco.com>
> Subject: WG Action: Path Computation Element (pce)
>
> A new IETF working group has been formed in the Routing Area. For 
> additional
> information, please contact the Area Directors or the WG Chairs.
>
> Path Computation Element (pce)
> ================================
>
> Current Status: Active Working Group
>
> Chair(s):
> Adrian Farrel <adrian <at> olddog.co.uk>
> JP Vasseur <jvasseur <at> cisco.com>
>
> Routing Area Director(s):
> Bill Fenner <fenner <at> research.att.com>
> Alex Zinin <zinin <at> psg.com>
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane