Re: [OSPF] [OSPF-SR] Regarding graceful restart behavior with change in SR informaiotn carrying LSA

"Acee Lindem (acee)" <acee@cisco.com> Tue, 30 May 2017 14:55 UTC

Return-Path: <acee@cisco.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 DF447128990; Tue, 30 May 2017 07:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 7YOmGtmuDgi9; Tue, 30 May 2017 07:55:44 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A07127B57; Tue, 30 May 2017 07:55:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20451; q=dns/txt; s=iport; t=1496156143; x=1497365743; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=s2b6l7jQ71tpwDE1bRpr2HkheCNzMBL8jLxLb0mHk70=; b=UDN5/9cMpOFZM4u2YVGBZWKnkmfpGEyhqPUVKZGbQdQykDxkUpRDHL+Z ge+vFGavwgbpMYgdZiv9Uj5vNzAKdED+HvE4tLCFQAdiS6Dr7xk020dvJ 8kzt+7qI1zFq2zmbgIoEHOaAZMkMsKET3ocE3s8UYwohOgjkgfqN0lBw1 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DzAACFhy1Z/5xdJa1cGQEBAQEBAQEBAQEBBwEBAQEBgm5nYoENB4NrihiRaZBBhTiCD4YkAhqCNj8YAQIBAQEBAQEBayiFGAEBAQEDIwo6EhACAQgRAwEBASQEAwICAjAUCQgCBAENBYlGZK0VgiaLSgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2IQIMghQkGEIJcgmAFlnmHKgGTJ4IGhTyKNZRNAR84gQp0FUaFOIFKdohGgQ0BAQE
X-IronPort-AV: E=Sophos;i="5.38,418,1491264000"; d="scan'208,217";a="251450570"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 May 2017 14:55:42 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v4UEtgRM004708 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 May 2017 14:55:42 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 30 May 2017 10:55:41 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 30 May 2017 10:55:41 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Veerendranatha Reddy Vallem <veerendranatharv@huawei.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: AQHS2LQGn4zkBsbfPUqaamx8ipl8RKIMWLpQgACfaAA=
Date: Tue, 30 May 2017 14:55:41 +0000
Message-ID: <D552FF60.B1955%acee@cisco.com>
References: <D551EFD9.B18F5%acee@cisco.com> <73BFDDFFF499304EB26FE5FDEF20F788508BE5F2@blreml501-mbb>
In-Reply-To: <73BFDDFFF499304EB26FE5FDEF20F788508BE5F2@blreml501-mbb>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: multipart/alternative; boundary="_000_D552FF60B1955aceeciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/iKTZJdyXFpgLDyNi-SxkdET_mk4>
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 14:55:46 -0000

Hi Veeru,

From: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com<mailto:veerendranatharv@huawei.com>>
Date: Tuesday, May 30, 2017 at 1:46 AM
To: Acee Lindem <acee@cisco.com<mailto:acee@cisco.com>>, "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: RE: [OSPF] [OSPF-SR] Regarding graceful restart behavior with change in SR informaiotn carrying LSA

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.

Any change that impacts the data plane should be considered a topology change. Note that, in practice, most implementations default RestartHelperStrictLSAChecking to false and do not put a lot of emphasis on granular determination of whether or not an LSA change could impact the data plane. In the case of Prefx/Link attribute LSAs, most attributes do impact the data plane.

Thanks,
Acee



Regards,
Veerendranath

From: Acee Lindem (acee) [mailto:acee@cisco.com]
Sent: 30 May 2017 01:15
To: Veerendranatha Reddy Vallem <veerendranatharv@huawei.com<mailto:veerendranatharv@huawei.com>>; 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: 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