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

From: "Pat Murphy - (650)329-4044" <[email-masked]>
Date: Tue, 3 Feb 2004 17:01:01 -0700

Acee,

>This draft is simpler than yours in that there is no relationship between
>the secondary adjacencies and the primary adjacency other than they
>share same link.

That was clear when I read the draft and I am not objecting to the
simplification. My OSPF knowledge is getting a little stale so please be
patient while I catch up. What I meant to say was don't you need to process
OSPF protocol packets differently than RFC 2328 Section 8.2?  No where in
this section and RFC 2328's Section 1.2 definition of interface does Area Id
factor into an interface definition, only addressing.  What is your
rationale for not updating the OSPF protocol packet processing? It sounds
like, from your Section 6, that you are stretching the definition of an OSPF
interface to include a configuration parameter, namely Area ID.

Also I believe these unnumbered point-to-point adjacencies are incompatible
with VLs. E.g. suppose a layer 2 interface is configured with Area 1 and
broadcast network type plus Area 0 and point-to-point network type. If there
also exists an Area 0 virtual link configured across Area 1 to another ABR
several hops away, is it always possible to distinguish the Area 0 OSPF
packets destined for the virtual interface from those destined for the Area
0 point-to-point interface? If not, I recommend you make the two features
incompatible. VLs are pretty much useless, so its not a major point for me.
As for TAs there is some feature there. You would be safe if the protocol
packets arrived inside the tunnel. However its OK with me if these features
are simply incompatible.

Pat

---

From: Sina Mirtorabi <[email-masked]>
Date: Tue, 3 Feb 2004 18:34:18 -0800

Pat,

->
->Acee,
->
->>This draft is simpler than yours in that there is no relationship
->>between the secondary adjacencies and the primary adjacency
->other than
->>they share same link.
->
->That was clear when I read the draft and I am not objecting
->to the simplification. My OSPF knowledge is getting a little
->stale so please be patient while I catch up. What I meant to
->say was don't you need to process OSPF protocol packets
->differently than RFC 2328 Section 8.2?  No where in this
->section and RFC 2328's Section 1.2 definition of interface
->does Area Id factor into an interface definition, only
->addressing.  What is your rationale for not updating the OSPF
->protocol packet processing? It sounds like, from your Section
->6, that you are stretching the definition of an OSPF
->interface to include a configuration parameter, namely Area ID.

Area-ID is part of Interface Data Structure and is already defined to
associate a packet with the corresponding area ( i.e VL). I agree with
you that the packet processing need to be spelled out explicitly

->
->Also I believe these unnumbered point-to-point adjacencies
->are incompatible with VLs. E.g. suppose a layer 2 interface
->is configured with Area 1 and broadcast network type plus
->Area 0 and point-to-point network type. If there also exists
->an Area 0 virtual link configured across Area 1 to another
->ABR several hops away, is it always possible to distinguish
->the Area 0 OSPF packets destined for the virtual interface
->from those destined for the Area 0 point-to-point interface?

Yes it can be distinguished, because in this case you do not have the
same neighbor as the VL is multiple hop away

->If not, I recommend you make the two features incompatible.
->VLs are pretty much useless, so its not a major point for me.
->As for TAs there is some feature there. You would be safe if
->the protocol packets arrived inside the tunnel. However its
->OK with me if these features are simply incompatible.

If you have a 1 hop VL configured and also configure multi-area
adjacency between the _same_ neighbors then there might not be a way to
associate the receiving packet to VL or multi-area adj although you
could use TTL to distinguish. The question is actually why you want to
use a one hop VL and also a multi-area adj between two nodes. They
provide the same functionality and one should not need to configure both
at the same time between the two same nodes.

Sina

->
->Pat
->