Re: [OSPF] [OSPF-SR] Regarding graceful restart behavior with change in SR informaiotn carrying LSA
Veerendranatha Reddy Vallem <veerendranatharv@huawei.com> Tue, 30 May 2017 05:46 UTC
Return-Path: <veerendranatharv@huawei.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F453128DF2; Mon, 29 May 2017 22:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51UbWcI58y31; Mon, 29 May 2017 22:46:47 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D62D120727; Mon, 29 May 2017 22:46:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHN99156; Tue, 30 May 2017 05:46:43 +0000 (GMT)
Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 30 May 2017 06:46:41 +0100
Received: from BLREML501-MBB.china.huawei.com ([10.20.5.200]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Tue, 30 May 2017 11:16:34 +0530
From: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-ospf-segment-routing-extensions@ietf.org" <draft-ietf-ospf-segment-routing-extensions@ietf.org>
CC: OSPF WG List <ospf@ietf.org>
Thread-Topic: [OSPF] [OSPF-SR] Regarding graceful restart behavior with change in SR informaiotn carrying LSA
Thread-Index: AQHS2LQGn4zkBsbfPUqaamx8ipl8RKIMWLpQ
Date: Tue, 30 May 2017 05:46:33 +0000
Message-ID: <73BFDDFFF499304EB26FE5FDEF20F788508BE5F2@blreml501-mbb>
References: <D551EFD9.B18F5%acee@cisco.com>
In-Reply-To: <D551EFD9.B18F5%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.152.243]
Content-Type: multipart/alternative; boundary="_000_73BFDDFFF499304EB26FE5FDEF20F788508BE5F2blreml501mbb_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0202.592D0744.0041, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 36564e5be037daffc28dfcda252c0a41
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/YWIFDvg5ZdaZXnzqW5a5izaG_wY>
Subject: Re: [OSPF] [OSPF-SR] Regarding graceful restart behavior with change in SR informaiotn carrying LSA
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 May 2017 05:46:49 -0000
Dear Acee, Thanks for the confirmation. I am little bit confused about Strict LSA checking behavior. Please help me to understand the behavior in following case. RestartHelperStrictLSAChecking: Whether it will be applicable to only Prefix/Link attribute Opaque LSAs or it will be applicable for other opaque LSAs like RI and TE LSAs also. (All LSAs in DB) Some of existing implementations will not consider opaque LSA changes as topology change by default. So whether we need to consider opaque Type (7 or 8) change only as topology change by default. Regards, Veerendranath From: Acee Lindem (acee) [mailto:acee@cisco.com] Sent: 30 May 2017 01:15 To: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com>; draft-ietf-ospf-segment-routing-extensions@ietf.org Cc: OSPF WG List <ospf@ietf.org> Subject: Re: [OSPF] [OSPF-SR] Regarding graceful restart behavior with change in SR informaiotn carrying LSA Hi Veeru, I think that changes to Prefix/Link Attribute LSAs must be considered as a topology change for purposes of RestartHelperStrictLSAChecking. If this were to be covered, it should have been in RFC 7684. Although RFC 3623 doesn’t really specify what constitutes a topology change. However, perhaps we could add a note in this draft. Thanks, Acee From: OSPF <ospf-bounces@ietf.org<mailto:ospf-bounces@ietf.org>> on behalf of Veerendranatha Reddy Vallem <veerendranatharv@huawei.com<mailto:veerendranatharv@huawei.com>> Date: Monday, May 29, 2017 at 5:41 AM To: "draft-ietf-ospf-segment-routing-extensions@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensions@ietf.org>" <draft-ietf-ospf-segment-routing-extensions@ietf.org<mailto:draft-ietf-ospf-segment-routing-extensions@ietf.org>> Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>> Subject: [OSPF] [OSPF-SR] Regarding graceful restart behavior with change in SR informaiotn carrying LSAs Dear Authors, In OSPFv2: I am requesting for your clarification regarding change in Opaque Type 7 and Opaque Type 8 LSAs (LSA origination/flush or modify) need to consider for OSPFv2 GR exit case or not. As per my understanding these LSAs will not be topology LSAs for OSPF, so it may not require to consider these LSAs for GR case. I am requesting for your confirmation. Also in OSPFv3: SR information is carried in new extension LSAs, which can carry both topology and attribute information. In this case, whether we need to consider LSA change for Graceful restart or not. I am requesting for your confirmation. Regards, Veerendranath
- Re: [OSPF] [OSPF-SR] Regarding graceful restart b… Acee Lindem (acee)
- Re: [OSPF] [OSPF-SR] Regarding graceful restart b… Veerendranatha Reddy Vallem
- Re: [OSPF] [OSPF-SR] Regarding graceful restart b… Acee Lindem (acee)
- Re: [OSPF] [OSPF-SR] Regarding graceful restart b… Veerendranatha Reddy Vallem