Re: I-D ACTION:draft-mirtorabi-ospf-tunnel-adjacency-00.txt

Don Goodspeed <dgoodspe@EXCITE.COM> Wed, 11 June 2003 23:29 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 TAA09338 for <ospf-archive@LISTS.IETF.ORG>; Wed, 11 Jun 2003 19:29:51 -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 <12.00A0ECC0@cherry.ease.lsoft.com>; Wed, 11 Jun 2003 19:29:51 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45346950 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Jun 2003 19:29:49 -0400
Received: from 207.159.120.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 11 Jun 2003 19:29:42 -0400
Received: by xmxpita.excite.com (Postfix, from userid 110) id CAC2E3D25; Wed, 11 Jun 2003 19:29:40 -0400 (EDT)
Received: from [64.47.48.10] by xprdmailfe10.nwk.excite.com via HTTP; Wed, 11 Jun 2003 19:29:40 EST
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4
MIME-Version: 1.0
X-Sender: dgoodspe@excite.com
X-Mailer: PHP
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20030611232940.CAC2E3D25@xmxpita.excite.com>
Date: Wed, 11 Jun 2003 19:29:40 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Don Goodspeed <dgoodspe@EXCITE.COM>
Subject: Re: I-D ACTION:draft-mirtorabi-ospf-tunnel-adjacency-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Sina, Peter,

Just got done reading the draft and had a few questions/comments.
On the whole, this looks like a solid proposal.

1. Encapsulation (section 4): Should section a) be a "should"?
Could it be acceptable to always encapsulate?

2. Section 4 clause b, last sentence.  "all implementation" should
be plural.

3. Areas: clarify what to call the area that is not the transit area.
In section 5, call out that the TA is announced as an unnum p2p link
in <insert term here>, as opposed to the TTA as it could be read.
Maybe "associated area" or "native area"?

4. Section 5, Link Data - is this the IP address used to transmit
the TA data over, or could it be a loopback interface?

5. Should we call out that the TTA and the "native area" cannot
be the same area?  I did not see this prohibition anywhere.

6. Cost of the TA - for using the TTA intra-area cost, do you propose
using a special metric setting (zero?) or a separate field/toggle for
allowing this (admin cost/oper cost?).

7. Consistency in sections 6 thru 9 in reference to [1].  Section 6
does not even contain a reference.  In all sections, should you call
out section numbers?  Do you intend the interface and adjacency FSMs
to adhere to the regular ones or the virtual ones?

Thanks,
Don

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!