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

From: Don Goodspeed <[email-masked]>
Date: Wed, 11 Jun 2003 19:29:40 -0400

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!

---

From: Sina Mirtorabi <[email-masked]>
Date: Thu, 12 Jun 2003 09:09:40 -0700

Don

Thanks for the comments, please see in line

->-----Original Message-----
->From: Mailing List [mailto:[email-masked]] On
->Behalf Of Don Goodspeed
->Sent: Wednesday, June 11, 2003 4:30 PM
->To: [email-masked]
->Subject: Re: I-D ACTION:draft-mirtorabi-ospf-tunnel-adjacency-00.txt
->
->
->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?

It could be acceptable

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

yes

->
->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"?

Yes we can use "associated area", that is the area for which TA is
configured

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

As for VL, Link Data is set to the virtual interface's IP address, which
is the interface through which TA control packet are sent, however I
would imagine that if one set it to a loopback ( as long as it belongs
to transit area ) it should be fine

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

Yes it need to be explicitly mentioned

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

By default the advertised cost of the TA is the intra-area cost to TA
endpoint, if you manually set the cost you will overwrite this cost and
advertise this configured cost for your TA adjacency. As for any
interface the cost must be greater than zero.

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

Yes, we can mention this in the next version

-> Do you intend
->the interface and adjacency FSMs to adhere to the regular
->ones or the virtual ones?

Virtual

Thanks
Sina
->
->Thanks,
->Don
->
->_______________________________________________
->Join Excite! - http://www.excite.com
->The most personalized portal on the Web!
->