Re: ospf-tunnel-adjacency-00.txt

Sina Mirtorabi <sina@CISCO.COM> Sun, 22 June 2003 18:24 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15086 for <ospf-archive@LISTS.IETF.ORG>; Sun, 22 Jun 2003 14:24:11 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A28EAF@cherry.ease.lsoft.com>; 22 Jun 2003 14:24:10 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 46245640 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 22 Jun 2003 14:24:08 -0400
Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 22 Jun 2003 14:24:07 -0400
Received: from smirtoraw2k03 (sjc-vpn4-827.cisco.com [10.21.83.58]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h5MIO6T05001 for <OSPF@PEACH.EASE.LSOFT.COM>; Sun, 22 Jun 2003 11:24:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Message-ID: <000101c338eb$770f0950$f2ce7243@amer.cisco.com>
Date: Sun, 22 Jun 2003 11:24:05 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Sina Mirtorabi <sina@CISCO.COM>
Subject: Re: ospf-tunnel-adjacency-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <000c01c33821$21c6f8b0$f2ce7243@amer.cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Vivek,

->
->Hi,
->
->1)Section 2 and Section 4
->--------------------------
->Data packet forwarding between the two ABRs is different from a
->VL in that the packets are tunneled if the TA path spans
->multiple hops.
->
->This removes the requirement for routers internal to the transit area
->to have the TA area's unsummarised intra-area routes.
->
->Why was tunneling chosen over this requirement ?

Because of summarization.

->Any specific advantage?

In case of TransitCapability type solution your summarization over
transit area need to be ignored. For VL this may not be a big deal as VL
can be only through non-backbone area therefore, not summarizing
internal-backbone area into a transit area is not important ( internal
backbone route are small compared to other areas and it _only_ affect
the transit area )

In case of TA your transit area can be backbone therefore you will lose
all the advantage of summarization of a non-backbone area into the
backbone area which will further affect all other areas

->
->2)Section 5
->-----------
->TA is announced as an unnumbered point-to-point link
->
->If TA is unnumbered point to point why Link Data is not
->"interface's     MIB-II ifIndex value"

There might be confusion regarding unnumbered vs numbered

When you have numbered link that means you assign an IP address to this
link this would translate while announcing adj to add a _stub_ link with
{ Link-ID = IP address & Link Data = IP mask }

As in VL, It is not because you set the Link Data in your adjacency to
an IP address ( vs ifIndex) that your link become numbered

->On a hindsight "why was virtual link itself described
->as unnumbered point to point?"
->Could have been numbered point to point ??
->Any specific advantage because of that ?

The link is unnumbered because you do not have any IP address assign
hence you do Not add a Stub link information in your adjacency.

VL does have an associated IP address ( used as source of IP address for
sending control packet and discovered once you find an intra-area path
to the other end of VL) and the neighbor associated IP address which is
used to send control packet to the other end of VL.

->
->3)Section 10
->------------
->If there is not at least one IP address belonging to
->Transit area or TTA and the virtual link or TA is configured,
->a router could advertise any of its attached IP address as a
->stub link (Link ID set to the router's own IP interface
->address, Link Data set to the mask 0xffffffff) to the transit area.
->
->Not very clear? Why was this required?

As for VL, If your ABRs do not have any numbered link in the transit
area, you cannot calculate the virtual interface's IP address and the
virtual neighbor's IP address which is needed to send unicast control
packet and your VL or TA will fail

If the ABR advertise any of its attached address as /32 into the transit
area you make available an IP address in the transit area for VL or TA
to be operational

thanks
Sina


->
->thanks,
->vivek
->