[Isis-wg] Fwd: A question regarding IS-IS Segment Routing Extensions

"Stefano Previdi (sprevidi)" <sprevidi@cisco.com> Thu, 23 February 2017 14:21 UTC

Return-Path: <sprevidi@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD856129868 for <isis-wg@ietfa.amsl.com>; Thu, 23 Feb 2017 06:21:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 hMjOFUllEyG0 for <isis-wg@ietfa.amsl.com>; Thu, 23 Feb 2017 06:21:08 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0701297CA for <isis-wg@ietf.org>; Thu, 23 Feb 2017 06:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3984; q=dns/txt; s=iport; t=1487859668; x=1489069268; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=Z4hfsY8+xNYg232pZ3XuPonjkQWBHke1Fv/ItoO8xMQ=; b=OnSLFtsdgw4nmPjrA0Vzj3UpjotPI2Kz1+QjdXlqmsK0ppxaiTM0BfTR mbxRNpRMk4uSKBcpTFbSF09aqq+0VKZj7dR1uuYkugSHmvV73HlfItn74 bY1oBzemc6lVwn3JTWiNAm5gffgibXNJyZtZBuzEdpLGjFRxKusWAUhy2 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BaAQB0765Y/5pdJa1dGQEBAQEBAQEBAQEBBwEBAQEBg1CBageDVIoIkVuVNIINhiICGoMEPxgBAgEBAQEBAQFiKIRwAQEEASMRSgkCAgEZAwECAQICJgICAhQcFQYCCAEBBBOICAOBYgiuEoImi0MBAQEBAQEBAQEBAQEBAQEBAQEBHwWBBoVBggWCaoQmEQEjECOCTC6CMQWcFAGSI4F7iG2GKZMnAR84VSMIVBVPAYQ5HYFhdYkYgSGBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="scan'208";a="388079309"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2017 14:21:06 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1NEL4i9011034 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <isis-wg@ietf.org>; Thu, 23 Feb 2017 14:21:04 GMT
Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Feb 2017 09:21:04 -0500
Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1210.000; Thu, 23 Feb 2017 09:21:04 -0500
From: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
To: "isis-wg@ietf.org list" <isis-wg@ietf.org>
Thread-Topic: A question regarding IS-IS Segment Routing Extensions
Thread-Index: AdKNyy6fYQKN924yQXSA3llgPNQdyQ==
Date: Thu, 23 Feb 2017 14:21:03 +0000
Message-ID: <C55D5026-3D11-41F3-BE40-5A2BE0979948@cisco.com>
References: <8A1CF914-4E63-45E5-97FB-918398973399@cisco.com>
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.61.227.71]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E6B8BB2391576843A0CE2298F052E136@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/16yXty1bbLqdjIqHWIvOQ5oEzEw>
Subject: [Isis-wg] Fwd: A question regarding IS-IS Segment Routing Extensions
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 14:21:09 -0000


> Begin forwarded message:
> 
> From: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
> Subject: Re: A question regarding IS-IS Segment Routing Extensions
> Date: February 23, 2017 at 3:16:20 PM GMT+1
> To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> Cc: "draft-ietf-isis-segment-routing-extensions@ietf.org" <draft-ietf-isis-segment-routing-extensions@ietf.org>, "isis@ietf.org" <isis@ietf.org>, "spring@ietf.org" <spring@ietf.org>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Ron Sdayoor <Ron.Sdayoor@ecitele.com>, Rotem Cohen <Rotem.Cohen@ecitele.com>
> 
> 
>> On Feb 23, 2017, at 1:08 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:
>> 
>> Hi all,
>> My colleagues and I have a couple of questions about some behavioral aspects of IS-IS Segment Routing (SR) extensions.
>> 
>> Suppose that we have an IS-IS domain where some routers run IS-IS with SR extensions, and some routers run “vanilla” IS-IS for IPv4.
>> 1.       What is supposed to happen when router A that runs IS-ISD without SR extensions establishes an adjacency with router B that runs IS-IS with SR extensions. Our expectations are that:
>> a.       An adjacency between A and B would be allowed to progress to its FULL state. Is that correct?
> 
> 
> yes.
> 
> 
>> b.      B will distribute all SR-related TLVs and sub-TLVs to A. Is that correct?
> 
> 
> yes.
> 
> 
>> c.       A will silently discard all SR-related TLVs and sub-TLVs it has received from B. Is that correct?
> 
> 
> yes. However “discard” is not the right term. “ignore” is the right one.
> 
> 
>> 2.       What is supposed to happen if IS-IS adjacency between A and B reaches its FULL state, and then SR extensions are enabled in A. We expect that:
>> a.       It is possible to enable SR extensions in A without resetting its adjacency with B (or any other adjacent router). Is that correct?
> 
> 
> yes.
> 
> 
>> b.      Once B learns that SR capabilities of A have changed, it floods its LSP database with all SR-related TLVs and sub-TLVs to A. Is that correct?
> 
> 
> LSDBs are not flooded again if there’s no change in adjacency state.
> 
> Link state protocols work such that each router (SR capable or not) is supposed to keep the entire LSDB (even the TLVs it doesn’t understand). When suddenly SR is enabled, the router re-read its LSDB and process the SR TLVs/Sub-TLVs accordingly.
> 
> 
>> A brief scan of the draft did not yield answers to any of the questions above.
> 
> 
> because this is not related to SR but to the normal behavior of link-state routing.
> 
> 
>> Timely feedback would be very highly appreciated.
> 
> 
> hope this helps.
> s.
> 
> 
>> 
>> Regards, and lots of thanks in advance,
>> Sasha
>> 
>> Office: +972-39266302
>> Cell:      +972-549266302
>> Email:   Alexander.Vainshtein@ecitele.com
>