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

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

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

Note RFC 2328 Section 8.2 OSPF protocol packet processing normally does
not involve comparing neighbor IDs. You may be digging a worm hole here
and I don't feel VLs are worth it.

>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.

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.

I recommend you make the two features incompatible. Folk who use this
feature probably won't use VLs.

Pat

---

From: Sina Mirtorabi <[email-masked]>
Date: Tue, 3 Feb 2004 20:00:01 -0800

Pat,

->>Yes it can be distinguished, because in this case you do not
->have the
->>same neighbor as the VL is multiple hop away
->
->Note RFC 2328 Section 8.2 OSPF protocol packet processing
->normally does not involve comparing neighbor IDs. You may be
->digging a worm hole here and I don't feel VLs are worth it.

What you say above is irrelevant, Do you mean that we cannot support
today two VL over the same link to two different neighbors? This is
exactly the same, i.e two different neighbors

->
->>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.
->
->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.
->
->I recommend you make the two features incompatible. Folk who
->use this feature probably won't use VLs.

There is no incompatibility in general except when you configure VL and
multi-area adj between the _same_ neighbors (which further can happen
only if your VL is single hop).  In all case this should be handled at
the configuration level and not OSPF packet processing.

Sina

---

From: Acee Lindem <[email-masked]>
Date: Wed, 4 Feb 2004 10:08:48 -0500

Sina, Pat,

In summary,

   1. We need to document that changes to packet processing
       to use area ID for determining the interface corresponding
       to a packet.

   2. There is ambiguity in demuxing the packet if one defines a
       virtual link in same area as an interface with a both a
       backbone adjacency and a transit area adjacency (assuming
       this is the best path through the transit area).

       Solutions Include:

         1. Using other fields in the OSPF or IP packet header to
             determine the appropriate interface.
         2. Don't bring up the virtual link if the best path is over
             a P2P interface associated with a multi-area adjacency (this
             could be done by flagging the router route during the transit
             area's intra-area SPF).
         3. Add configuration checking to disallow a virtual link in an
             area with a multi-area adjacency shared with the backbone.
         4. Simply document the problem and tell people not to do it (this
             probably isn't good since the hello packets for the virtual link
             will be associated with the backbone and most likely
             prevent an adjacency from being formed over either path).

         I like #2 or #3. I don't really like #1 since I can't come up
         with a solution that works for packet types other than hello.

Thanks,
Acee

---

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

Acee,

->Sina, Pat,
->
->In summary,
->
->   1. We need to document that changes to packet processing
->       to use area ID for determining the interface corresponding
->       to a packet.
->
->   2. There is ambiguity in demuxing the packet if one defines a
->       virtual link in same area as an interface with a both a
->       backbone adjacency and a transit area adjacency (assuming
->       this is the best path through the transit area).
->
->       Solutions Include:
->
->         1. Using other fields in the OSPF or IP packet header to
->             determine the appropriate interface.
->         2. Don't bring up the virtual link if the best path is over
->             a P2P interface associated with a multi-area
->adjacency (this
->             could be done by flagging the router route
->during the transit
->             area's intra-area SPF).
->         3. Add configuration checking to disallow a virtual
->link in an
->             area with a multi-area adjacency shared with the
->backbone.
->         4. Simply document the problem and tell people not
->to do it (this
->             probably isn't good since the hello packets for
->the virtual link
->             will be associated with the backbone and most likely
->             prevent an adjacency from being formed over either path).
->
->         I like #2 or #3. I don't really like #1 since I can't come up
->         with a solution that works for packet types other than hello.

The potential conflict can happen ( assuming there is VL and multi-area
adj between the same neighbor)  as a result of a conflicting
configuration. Therefore option #3 looks to me the natural and easiest
place to handle this.
The prevention of such a conflicting configuration is totally acceptable
as multi-area adj and single hop VL provide the same functionality...

Thanks
Sina

->
->
->
->Thanks,
->Acee
->
->----- Original Message -----
->From: "Sina Mirtorabi" <[email-masked]>
->To: <[email-masked]>
->Sent: Tuesday, February 03, 2004 11:00 PM
->Subject: Re: draft-mirtorabi-ospf-multi-area-adj-00.txt
->
->
->> Pat,
->>
->> ->>Yes it can be distinguished, because in this case you do not
->> ->have the
->> ->>same neighbor as the VL is multiple hop away
->> ->
->> ->Note RFC 2328 Section 8.2 OSPF protocol packet processing
->normally
->> ->does not involve comparing neighbor IDs. You may be
->digging a worm
->> ->hole here and I don't feel VLs are worth it.
->>
->> What you say above is irrelevant, Do you mean that we
->cannot support
->> today two VL over the same link to two different neighbors? This is
->> exactly the same, i.e two different neighbors
->>
->> ->
->> ->>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.
->> ->
->> ->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.
->> ->
->> ->I recommend you make the two features incompatible. Folk who use
->> ->this feature probably won't use VLs.
->>
->> There is no incompatibility in general except when you configure VL
->> and multi-area adj between the _same_ neighbors (which further can
->> happen only if your VL is single hop).  In all case this should be
->> handled at the configuration level and not OSPF packet processing.
->>
->> Sina
->