Subject: Re: FW: Last call comments on draft-ietf-ospf-shortcut-abr-02.txt

From: Deepak Dandekar <[email-masked]>
Date: Fri, 14 Jan 2005 06:22:43 -0500

Hello,
Can someone, please, let me know the existing state of the draft. I tried
searching for it on the OSPF IETF web-page, (http://www.ietf.org/html.
charters/ospf-charter.html) but could not get any information.

thanks,
Deepak.

On Thu, 1 Feb 2001 17:24:03 -0500, Moy, John <[email-masked]>
wrote:

>-----Original Message-----
>From: Moy, John
>Sent: Thursday, February 01, 2001 5:23 PM
>To: 'Alex Zinin'
>Subject: RE: Last call comments on draft-ietf-ospf-shortcut-abr-02.txt
>
>
>Alex-
>
>Here is an attempt to state a couple of my previous
>comments more clearly.
>
>>> 1. In Step 2 of the memo's Section 3.3 (staring at the
>>> bottom of page 8), I think that instead of
>>> "and the ABR has a backbone connection", you really
>>> meant "and the calculating router has a backbone connection".
>>> However, I don't think that either is right; instead the phrase
>>> should simply be deleted. You shouldn't be doing the
>>> shortcut behavior unless all ABRs in the area agree, regardless
>>> of whether they are connected to the backbone, or you
>>> risk permanent routing loops.
>
>>The idea is to shortcut through non-bb areas by default if
>>the calculating router has no bb attachment (and hence does not
>>announce the routes any further, and does not form a loop, so it
>>is safe), and not to shortcut through them by default if
>>the calculating box has a bb attachment.
>
>It is OK to automatically request to shortcut if you have no
>backbone connection. But if the other ABRs attached to the area
>don't agree (as evidenced by bit S in their router-LSAs being
>clear), you shouldn't *perform* the shortcut calculation. If you
>do, you risk creating permanent routing loops. You can see this by
>modifying some of the network diagrams that you used to demonstrate
>the black holes created by non-backbone-attached ABRs. In some
>topologies, doing a shortcut without cooperation of the other ABRs
>turns the black hole into a routing loop.
>
>>> 2. For the same reason, Step 3 of RFC 2328's Section 16.3
>>> should be modified (you text starting at the end of page
>>> 9) only if ShortcutCapability is TRUE for the area
>>> whose summary-LSA is being considered.
>
>>Do you mean make sure the functionality is not changed
>>if the summary-LSAs are considered because of the area's
>>TransitCapability flag?
>
>Yes. This gets back to the previous point. You can't start
>shortcutting (that is, changing the behavior of Section 16.3)
>unless all the other ABRs agree (ShortcutCapability
>is TRUE).
>
>John

---

From: Acee Lindem <[email-masked]>
Date: Fri, 14 Jan 2005 08:19:58 -0500

>charters/ospf-charter.html) but could not get any information.
Hi Deepak,
This draft expired without making it through the standards process. I 
seem to remember the idea
was somewhat interesting but there must not have been a strong enough 
requirement. You can find
expired drafts at:

   http://www.watersprings.org/

Hope this helps,
Acee