Re: [OSPF] draft-ietf-ospf-ospfv3-graceful-restart-03

Acee Lindem <acee@cisco.com> Thu, 04 May 2006 22:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FblsL-0000lI-Rq; Thu, 04 May 2006 18:00:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FblsK-0000lD-Hr for ospf@ietf.org; Thu, 04 May 2006 18:00:44 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FblsK-0000pk-7d for ospf@ietf.org; Thu, 04 May 2006 18:00:44 -0400
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 04 May 2006 15:00:43 -0700
X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="1801551533:sNHT26817012"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k44M08ZG022640; Thu, 4 May 2006 15:00:43 -0700 (PDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 18:00:38 -0400
Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 18:00:37 -0400
Message-ID: <445A7985.80408@cisco.com>
Date: Thu, 04 May 2006 18:00:37 -0400
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vivek Dubey <vivek_ospf@rediffmail.com>
Subject: Re: [OSPF] draft-ietf-ospf-ospfv3-graceful-restart-03
References: <20060503035846.17006.qmail@webmail45.rediffmail.com>
In-Reply-To: <20060503035846.17006.qmail@webmail45.rediffmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 May 2006 22:00:38.0041 (UTC) FILETIME=[2D460890:01C66FC6]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Vivek,

Ok - if I explain the problem in section 2.3 as I did below (only more
elegantly :^), will that eliminate your concern? Since, heretofore, this 
is are
only WG Last Call comment, I'm compelled to address it.

Thanks,
Acee

Vivek Dubey wrote:

>Acee,
>I agree/understand the, reasons to keep Interface-Id same across restarts.
>But the current phrasing seems to imply that reason for preserving Interface-Id is to keep "the pre-restart and post-restart LSAs same".
>
>The phrasing used in explanation below is more clear.
>
>Thanks
>Vivek
>
>
>On Wed, 03 May 2006 Acee Lindem wrote :
>  
>
>>Vivek,
>>
>>Vivek Dubey wrote:
>>
>>    
>>
>>>Section 3.2:
>>>If this were not the case, the pre-restart and post-restart LSAs wouldn't be the same and the restart would be disruptive.
>>>
>>><vivek> If "post-restart" here means "after router undergoing restart has exited/exiting graceful-restart", it is supposed to reoriginate LSAs as per Section 2.3 RFC 3623. Description in Section 2.3 RFC 3623 does not mandate the contents to be same. Than why do pre-restart and post-restart LSAs need to be same?
>>>
>>>Preservation of Interface IDs have more to do with figuring out whether restarting router has re-established all its adjacencies.
>>> 
>>>      
>>>
>>Since the interface ID is in the link data for OSPFv3 router LSAs, a change in interface ID
>>could result in a mismatch between neighbor adjacency state for the restarting router and
>>the pre-restart router LSA. Synchronizing the change across the restarting router and
>>the helping routers would be very difficult (if not next to impossible) and would probably
>>result in unreachability or premature graceful restart termination. It is much better for the
>>restarting router to preserve this state across restarts.
>>
>>Hope this helps,
>>Acee
>>
>>    
>>
>>>-Vivek
>>>
>>>
>>> 
>>> 
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>OSPF mailing list
>>>OSPF@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/ospf
>>> 
>>>      
>>>
>
>  
>

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf