Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Wed, 4 Feb 2004 10:35:56 -0700

Sina,

Note it is important to be able to cost a multi-area adjency differently
for each area, plus set the authentication parameters. I don't see a
need to tweak the interval/delay timers???

As for,

>->Note RFC 2328 Section 8.2 OSPF protocol packet processing
>->normally does not involve comparing neighbor IDs.

>Do you mean that we cannot support
>today two VL over the same link to two different neighbors?

Currently VL OSPF protocol packets are accepted in 8.2 step (2)
regardless of who the neighbor is.

->A better ? is why anyone would ever use a VL? However, if one
->was into VLs, I suppose he/she might want to build a VL to
->backup the shared link, hoping that, should the link break,
->the VL can find another multi-hop virtual path between the
->two nodes for area 0 transit traffic. As for why the shared
->link has a primary non-zero backbone area versus an area 0
->primary area, that's easy. It needs to be of type other than
->p-t-p because of the non-backbone area's many routers that
->share the link's netwwork.

Actually this is a weak example unless the transit area has equal cost
multipaths between the two neighbors available for the VL that includes
a single hop path carrying a multi-area adjacency. Costing of the VL and
the MA also plays a role. My ignorance is showing here. I have only
found one useful application of VLs; and it wasn't partition repair.

>In all case this should be handled at
>the configuration level and not OSPF packet processing.

I don't recommend trying to make this work by tweaking OSPF packet
processing. I was recommending that you don't allow the configuration of
MAs and VLs over the same transit area on the same ABR. Subtle
incompatibilities are often overlooked by network implementors.

Pat

---

From: Sina Mirtorabi <[email-masked]>
Date: Wed, 4 Feb 2004 17:10:43 -0800

Pat,

->
->Sina,
->
->Note it is important to be able to cost a multi-area adjency
->differently for each area, plus set the authentication
->parameters. I don't see a need to tweak the interval/delay timers???

Sure, each multi-area adj will have its own Interface data structure

->
->As for,
->
->>->Note RFC 2328 Section 8.2 OSPF protocol packet processing normally
->>->does not involve comparing neighbor IDs.
->
->>Do you mean that we cannot support
->>today two VL over the same link to two different neighbors?
->
->Currently VL OSPF protocol packets are accepted in 8.2 step
->(2) regardless of who the neighbor is.

You should be looking at the beginning of the section 8.2 where we do
validity check for IP and OSPF header. Further it states if the packet
is Hello it should be processed as in section 10.5 where you do consider
an active neighbor or create one based on IP address or neighbor router
ID.

When your receive a packet you do associate it with a neighbor therefore
it is implicit that if you have different neighbor there is no
conflict....

->>In all case this should be handled at
->>the configuration level and not OSPF packet processing.
->
->I don't recommend trying to make this work by tweaking OSPF
->packet processing. I was recommending that you don't allow
->the configuration of MAs and VLs over the same transit area
->on the same ABR.

Ok so we are in agreement that this should be handled at the config
level

Sina