Subject: [manet] Comment on draft-spagnolo-manet-ospf-wireless-interface-00

From: Richard Ogier <[email-masked]>
Date: Tue, 16 Dec 2003 22:31:45 -0800

I have a comment regarding
draft-spagnolo-manet-ospf-wireless-interface-00

Suppose router A is an edge router (with both a wireless interface
and a wired interface) that is configured as a stub, and router B
is a neighbor of A with only a wireless interface.
Also suppose that router A has received "outside" LSAs originated
from outside the wireless subnet, which it does not forward to
router B (since it is a stub).  Further suppose that *all* routers in
the network (including non-wireless routers) are in the same area.

There appears to be a problem, because OSPF assumes that all routers
in the same area have the same link-state information for the area,
but routers A and B have different information.
To reach a destination outside the wireless subnet, router B will
use the default route and thus forward the packet to router A.
Since router A has more information than router B, router A will
compute the shortest path to the destination, which might happen
to go through router B, thus forming a routing loop.
(The draft states that the routing table is calculated as in OSPF.)

If instead, an OSPF stub area is configured which includes only the
wireless routers, with router A as an area border router, this problem
is avoided, because in OSPF, router A would use only backbone summary
LSAs to compute routes to destinations outside the area, and thus
would not send the packet back into the wireless area.

Am I missing something?  Why don't you simply use an OSPF stub area
to avoid flooding outside LSAs within the wireless subnet
(as per Section 12.4.3.1 of RFC 2328)?

Also, I should point out that there has been some discussion on
the OSPF list regarding how to approach the problem of extending
OSPF to support MANETs.

http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0312&L=ospf

Regards,
Richard

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Tao Lin" <[email-masked]>
Date: Wed, 17 Dec 2003 01:45:58 -0500

A quick comment on the stub area in OSPF.

Can we define that an OSPF stub area includes only interfaces in the same
physical medium?  For example, wireless 802.11b interfaces can belong to one
OSPF area (or multiple areas if there are too many 802.11b wireless cards)
and wired network cards using IEEE 802.3 can form their own OSPF areas.  In
other words, it will be better if an OSPF stub area does not cross different
physical mediums.

Just my 2 cents.  Welcome discussions.

Thanks.

 Tao Lin
 Ph.D. Candidate
 Laboratory for Advanced Networking (VT-LAN)
 ECE Department
 Virginia Tech

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 17 Dec 2003 13:31:12 +0200

Richard/Tao,

I haven't read the draft-spagnolo completely yet. However there are various
ways the things can be done here, stub area I am not sure is a possible
method.

Stub Area prevents AS Scope LSA's to be flooded into an area, however no new
LSA types have been defined in spagnolo. You probably are talking about
totally stubby area(which is not a OSPF standard thing - though the new NSSA
RFC/MIB's defines a configureable flag to allow summary LSA's into stub and
NSSA areas or not).

Don't see how stub area helps at all. However the way to do it could be to
configure the cost from A to B to be 0xFFFFF(like in stub router). That way
all traffic from B goes out via A, and no transit traffic goes out from A to
B, but those destined to those networks themselves. No change s needed in
the routing table calculations at all.

Let me know if I am clear and you agree.

Thanks,
Vishwas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Tao
Lin
Sent: Wednesday, December 17, 2003 8:46 AM
To: Richard Ogier; [email-masked]
Subject: Re: [manet] Comment on
draft-spagnolo-manet-ospf-wireless-interface-00

Thanks.

 Tao Lin
 Ph.D. Candidate

----- Original Message -----
From: "Richard Ogier" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 17, 2003 1:31 AM
Subject: [manet] Comment on draft-spagnolo-manet-ospf-wireless-interface-00

> http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0312&L=ospf

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.551 / Virus Database: 343 - Release Date: 12/11/2003

---

From: "Philippe Jacquet" <[email-masked]>
Date: Wed, 17 Dec 2003 14:41:55 +0100

I am not completely expert in OSPF but it seems that this problem is not
specific to wireless links. I don't know how OSPF solves this. If there is
an alternative route from A doesn't it means that A may have received the
forbidden LSA via this route?

Philippe

---

From: Richard Ogier <[email-masked]>
Date: Wed, 17 Dec 2003 08:22:10 -0800

Vishwas,

>LSA types have been defined in spagnolo. You probably are talking about
I referred to Section 12.4.3.1 of RFC 2328, which states:

"Area border routers connecting to a stub area can originate 
summary-LSAs into the area according
to the Section 12.4.3's algorithm, or can choose to originate only a 
subset of the summary-LSAs,
possibly under configuration control.  The fewer LSAs originated, the 
smaller the stub area's link state
database, further reducing the demands on its routers' resources."

So a "totally stubby area" is indeed allowed by the standard.  Maybe I 
should have made this more clear.

>Don't see how stub area helps at all. 
>
I don't know why you say this, but it works (i.e., no routing loops), 
and it reduces LSA traffic in the area.

>However the way to do it could be to
If you change the cost from A to B to be 0xFFFFFF (LSinfinity), then how 
can even intra-area traffic
use this link?

Richard

---

From: "Tao Lin" <[email-masked]>
Date: Wed, 17 Dec 2003 11:24:19 -0500

Vishwas,

What I suggested is to prevent the unnecessary LSA updates between
interfaces in the wireless side and wired side (and avoid the loop problem).

Assume an OSPF area crosses different mediums, say one wireless and the
other wired, via nodes which have both wired and wireless interfaces.  All
the interfaces that belong to one OSPF area maintain the same copies of LSA
database.  Therefore, there will be many LSA updates from one physical
medium domain to the other.  However, since those nodes with wired and
wireless interfaces, name them boarder gateways, are always the gateways
between nodes in different mediums, there is no need to pass LSA updates
from one physical domain to the other, especially when the channel capacity
in wireless side is limited.  Those boarder gateways can tell nodes in one
domain the corresponding costs to destinations in the other domain and then,
every node can calculate proper shortest path tree without any loop problem.
This can make the control protocol more efficient and there is no loop
problem as Richard pointed out.

I understand what you suggested, but it seems that you are aiming at a
different aspect.

Thanks,

 Tao

----- Original Message ----- 
From: "Vishwas Manral" <[email-masked]>
To: "'Tao Lin'" <[email-masked]>; "'Richard Ogier'" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, December 17, 2003 6:31 AM
Subject: RE: [manet] Comment on
draft-spagnolo-manet-ospf-wireless-interface-00

> Subject: [manet] Comment on

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 17 Dec 2003 22:20:28 +0200

Richard,

I guess the MIB has the option of totally disabling the summary LSA
injection, which came from the NSSA RFC. However as you pointed out, we
could achieve the same by using the range 0.0.0.0/0 and make it
donotAdvertize.

Ok. Router LSA metric is only 16 bits, so the MaxMetric is 0xFFFF not
0xFFFFFF. If you check RFC3137, the states that the RFC allows

      1) Making other routers prefer routes around router X while
         performing the Dijkstra calculation.

      2) Allowing other routers to reach IP prefixes directly connected
         to router X.

So instead of putting a MaxMetric in the Router LSA for a particular
link(wireless interface) instead of all the links of the router the same can
be achieved.

I guess this method should solve the purpose.

Cheers,
Vishwas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Richard Ogier
Sent: Wednesday, December 17, 2003 6:22 PM
To: [email-masked]
Cc: 'Tao Lin'; [email-masked]
Subject: Re: [manet] Comment on
draft-spagnolo-manet-ospf-wireless-interface-00

Vishwas,

Richard

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.551 / Virus Database: 343 - Release Date: 12/11/2003

---

---

From: Yasuhiro Ohara <[email-masked]>
Date: Thu, 18 Dec 2003 23:53:11 +0900 (JST)

Hi, Philippe

From: "Philippe Jacquet" <[email-masked]>
Subject: Re: [manet] Comment on draft-spagnolo-manet-ospf-wireless-interface-00
Date: Wed, 17 Dec 2003 14:41:55 +0100

> forbidden LSA via this route?

Do you mean router B by A, don't you ? (because the router B is the one
assumed not to have enough LSAs in the Richards's story.)

Let's expand Richard's example:

                         N1
   ---- A .... B .... C ----

where A, B, C are routers, wired link is illustrated as ----,
and wireless link is illustrated as .... . N1 indicates
the address prefix of the right side link of C.

B may not have C's LSA or N1's network-LSA (Intra-Prefix LSA
in case of OSPFv3) because the draft specifies the way that
the database synchronization is not done on wireless link
(i.e. both side link of B). So B will either forwards traffic
destined to N1 to A or simply drops, according to whether B have
default route (assume it is destined to A's direction if exists).

So, only having alternative link(s) does not mean that the router
will have all LSA in the case of the draft.

The Richards question seems very reasonable for me (and maybe
for other people who knows OSPF).

regards,
yasu

---

From: "Philippe Jacquet" <[email-masked]>
Date: Thu, 18 Dec 2003 18:08:04 +0100

Dear Yasu,

I was just asking because I am really ignorant on some specific aspects of
OSPF;-) If I understand correctly previous discussions, then it seems that
our original proposal may have problems if we allow some edge routers of the
same wireless networks to be stub and other not to be. I tend to agree with
this. What about if stub wireless networks have only one edge router, which
is stub, as it is stated in RFC 2328?

Philippe
----- Original Message -----
From: Yasuhiro Ohara <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, December 18, 2003 3:53 PM
Subject: Re: [manet] Comment
ondraft-spagnolo-manet-ospf-wireless-interface-00

---

From: Yasuhiro Ohara <[email-masked]>
Date: Fri, 19 Dec 2003 02:25:48 +0900 (JST)

> is stub, as it is stated in RFC 2328?

But then how do you support the case below ?

  Internet ---- A .... B .... C ---- D

How do you define the point "one edge router" to be ?
In the case above, B would have to recognize A as edge rather
than C, and C would have to detect that itself is not edge.

OSPF's stub area defines the only-one edge point by the node
from whom the default route is originated. So I guess it's
simpler (and so better) to leave the spec not to define
Manet part of the network, and let the user form it
by configuring ordinary stub area.

regards,
yasu

---

From: Yasuhiro Ohara <[email-masked]>
Date: Fri, 19 Dec 2003 02:36:43 +0900 (JST)

> by configuring ordinary stub area.

If you meant "How about to use normal (rfc2328's) stub area",
then I might just misunderstand what you said ...

I wanted to say "defining new restriction for special case (i.e. Manet)"
should be avoided if possible. We should utilize the existing scheme
as far as possible, shouldn't we ? (as it tends to lead some new
problems ...)

regards,
yasu

---

From: Richard Ogier <[email-masked]>
Date: Thu, 18 Dec 2003 10:10:54 -0800

>as far as possible, shouldn't we ? (as it tends to lead some new

I agree.  That is exactly the point I was making.   And this goes for 
other aspects of OSPF, not just
stub areas.  For example, it is not necessary to define a new message 
type for flooding LSAs, as
discussed in my draft 
 http://www.ietf.org/internet-drafts/draft-ogier-manet-ospf-extension-00.txt

We should probably be having this discussion on the OSPF list:
     http://peach.ease.lsoft.com/scripts/wa.exe?A1=ind0312&L=ospf

Regards,
Richard