Subject: question on link state routing protocols

From: Melinda <[email-masked]>
Date: Wed, 01 May 2013 18:04:04 -0700

Dear all:

May I ask one simple question in link state routing protocol?

Was link state information accumulated and cause the size of signaling 
message larger and larger?

i.e. the path is: a->b->c->d->e->f

node a knows b's link state because of 1-hop neighbors, but can node f 
also know a,b,c,d,e's link states?
If so,  the information then keeps accumulation, the size of message 
received at f must be too large,right?

Thanks for your answer in advance.

Best,
Melinda

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 2 May 2013 12:16:00 +0200

Dear Melinda,

For ALL *Link State (LS) Routing Protocols* in the IETF, the protocol
design depends on the Applicability Statement, or Use-Case. Users of
protocols SHOULD read that section carefully (hope not to be general
purpose use-case, which makes me confused in some WGs, and may users
be as well). I don't know your use-case and don't know which network
technology using that protocol, so answers may vary.

my comments below;

> May I ask one simple question in link state routing protocol?

Any question is always important/welcomed as long as related to IETF
progress, but few editors may not follow questions from reviewers or
users which needs to be fixed. It will be nice if an author of one
IETF LS routing protocol I-D/RFC answers your question related to that
protocol as example.
> message larger and larger?

IMHO, Yes that could be if the protocol allows that, but I expect that
no protocols will let the message become very large compared to the
first message LS information transmitted in such network.
> also know a,b,c,d,e's link states?

IMHO, Yes F-router needs to know LSs to find out which route to use,
some protocols may use information of neighbor discovery or clustering
protocols

> received at f must be too large,right?

Yes that is right, but what is the definition of too large, let us let
the router to decide what is large or not (as the designer defines
these things in the I-D or RFC).
> Thanks for your answer in advance.

No problem, thanks for your discussion. If we don't discuss or comment
on every thing in IETF then how can we progress.

Best Regards
AB