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 ->
- ospf-tunnel-adjacency-00.txt Vivek Dubey
- Re: ospf-tunnel-adjacency-00.txt Sina Mirtorabi