Re: [Lsr] Fwd: I-D Action: draft-shen-isis-spine-leaf-ext-06.txt

"Acee Lindem (acee)" <acee@cisco.com> Wed, 03 October 2018 22:11 UTC

Return-Path: <acee@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875C0130DC3 for <lsr@ietfa.amsl.com>; Wed, 3 Oct 2018 15:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.955
X-Spam-Level:
X-Spam-Status: No, score=-14.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 D2h2MiftYMVm for <lsr@ietfa.amsl.com>; Wed, 3 Oct 2018 15:11:49 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFF312F295 for <lsr@ietf.org>; Wed, 3 Oct 2018 15:11:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41568; q=dns/txt; s=iport; t=1538604709; x=1539814309; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ilaA/Ej6nw7YNmpI5wmoBCPhXxLzNiWAiGjBY6JlqM4=; b=R5fplmom9biC3MIsMGwyd3OOqvqZWwIUkGY/C38iEW2Bk9a3J6RKTT6T k0fzKmEJmGvFpljnQycNNznx/n8ulIy80zzzj7jVXl0wjxrX6D9tsoYzL J62B/+gP/ExAzhpRxl9BtjUlr8Bxft1CuEWWT9oFW5PoqBuaidLy9in2y c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADgPbVb/4MNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYEXd2Z/KAqDaogVjiaIYo16gXoLGAEKgTMBgxUCF4Q?= =?us-ascii?q?JITQYAQMBAQIBAQJtHAyFOAEBAQEDAQEhSwQHEAIBCBEDAQIhAQYDAgICHwY?= =?us-ascii?q?LFAkIAgQBDQUJEoMGAYEdTAMVD6U/gS6EKwEHBz2CQA2CUYshF4IAgREBJx+?= =?us-ascii?q?CTIJWOgsBAQEBAQEWgRNUBhAIgkMxgiYCiFV1hDyFWiSJHSwJAoZHhliDHRe?= =?us-ascii?q?BSkuEF4MLhQqBIYwXcYEPhxMCERSBJQ0QOIFVcBUaISoBgkEJiw2FPm8BjHW?= =?us-ascii?q?BHwEB?=
X-IronPort-AV: E=Sophos;i="5.54,337,1534809600"; d="scan'208,217";a="180555905"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 22:11:48 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w93MBl8Z011855 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Oct 2018 22:11:47 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 3 Oct 2018 18:11:46 -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.1395.000; Wed, 3 Oct 2018 18:11:46 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Tony Przygienda <tonysietf@gmail.com>, "Naiming Shen (naiming)" <naiming@cisco.com>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Fwd: I-D Action: draft-shen-isis-spine-leaf-ext-06.txt
Thread-Index: AQHUB0IIPvqnKA+UbESxAXgYsT9EG6UNkrOAgAEquQA=
Date: Wed, 3 Oct 2018 22:11:46 +0000
Message-ID: <19888D4C-6A61-4B2F-9A57-7451FD7C26CB@cisco.com>
References: <152935329146.3026.18428625239542386417@ietfa.amsl.com> <80AF5D6B-4D3E-4EC3-87FE-05F7F7B4CAD5@cisco.com> <CA+wi2hN13QJMtmDmW-655OrWSZ6O4U4WbU1nFjF3CmCSfB380Q@mail.gmail.com>
In-Reply-To: <CA+wi2hN13QJMtmDmW-655OrWSZ6O4U4WbU1nFjF3CmCSfB380Q@mail.gmail.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.116.152.197]
Content-Type: multipart/alternative; boundary="_000_19888D4C6A614B2F9A577451FD7C26CBciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.141, xch-rtp-001.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/YBlih7JQUzeJtJJSJBoLcWldm_I>
Subject: Re: [Lsr] Fwd: I-D Action: draft-shen-isis-spine-leaf-ext-06.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Oct 2018 22:11:54 -0000

Hi Tony, et al,

I think this flooding enhancement is mature and is sufficiently defined to request WG adoption and intend to do so soon. Since it is a DC point solution it doesn’t really conflict with the other flooding reduction proposals.

Thanks,
Acee

From: Lsr <lsr-bounces@ietf.org>; on behalf of Tony Przygienda <tonysietf@gmail.com>;
Date: Tuesday, October 2, 2018 at 8:22 PM
To: "naiming=40cisco.com@dmarc.ietf.org"; <naiming=40cisco.com@dmarc.ietf.org>;
Cc: "lsr@ietf.org"; <lsr@ietf.org>;
Subject: Re: [Lsr] Fwd: I-D Action: draft-shen-isis-spine-leaf-ext-06.txt

Gave it a read (markedly improved on -03 I think I read last), had chat with authors, rough summary for the list so we keep track:

a) As overall observation the disaggregation via leafs requesting from spines (more about that later ;-) is a very important rewrite in this version to ensure correctness in case of properly routing on fabrics that are missing links on bringup (the "you-cannot-know-that-you-don't-know-something-you-never-knew-before") ...
b) 3.2 paragraph on extension working in multiple levels seems to imply that the spine level will not need disaggregation to next spine level up (if leaf extension is used spine to higher level spine). The solution is fully recursive and necessary so that may benefit from a paragraph or so. Additionally, two things need consideration
    i) spines will need to know what up and what is down in such scenario. Possiblity is either configure levels on spines directly or per interface the L-capability
  ii) Flooding needs to be clarified that all the topology floods north but every level needs to generate a default route south
  iii) deployment like that allows for valley-free-routing and with that doesn't have to follow ECMP (more on that a bit down)
c) 3.3: The flags are a pot-pourri of non-orthogonal stuff. T-bit seems to  indicate Tier is valid but value 15 is invalid anyway, no explaination what R & L set @ same time mean, cat T be set with L? B IMO is dangerous and superfluous, it's used as "i'm a leaf, if you a leaf, route through me". leafs have basically no topology info @ can start happily loop the fabric pointing at each other or running triangles on the fabric ... I suggest removing the B-bit and go to the original "overload leafs"  (which RIFT happily adopted BTW ;-)
d) 3.3.2: CS-LSP without explanation is cryptic even for deep ISIS junkies, pls refer to 7356?  My opinion didn't change, craming the stuff into hellos is a fragile design
e) 3.4:
  i) computing "distance from the top" is a first, optimistic approach and viable only if one is willing to assume miscabling never happens (what if couple leafs are @ different distances) and worse, does not consider fabrics with PoDs of differnt heights (a reality for some people)
ii) unequal cost sharing works if all levels repeat the leaf-spine pattern since we have valley-free-routing. If the spine levels are running flat-ISIS the traffic may show up in a point where it will bow-tie the fabric to get to destination (I think it can loop as well but need to think more and possibly I'm wrong since leafs should never be transits)
f) 3.4.1: The section is incomplete, following example needs consideration for it to work correctly (unless disregarded) . sorry for crappy drawing. if A wants to properly disaggregate it needs to request A, B and either C or D

   +-+           +-+          +-+          +-+
+--+A|           |B+-+     ++-+C+--+       |D+-+
|  +++           +++ |      | +++  |       +++ |
|   |             |  |      |  |   |        |  |
|   |  +----------+  |      |  |   |        |  |
|   |  |             |      |  |   |        |  |
|   |  | +---------------------+   |        |  |
|   |  | |           |      |      |        |  |
|   |  | | +--------------------------------+  |
|   |  | | |         |      |      |           |
+-----------------+  +---------+  ++--------+  |
    |  | | |      |         |  |            |  |
   +++ | | |     +++        | +++          +++ |
   |1+-+-+-++    |2|        +-+3|          |4+-+
   +-+           +-+          +-+          +-+
--- tony

On Mon, Jun 18, 2018 at 1:30 PM Naiming Shen (naiming) <naiming=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:

Hi LSR’er,

A new version of spine-leaf is-is draft is posted. The main change
is adding a new bit from ‘link-attribute’ sub-tlv to indicate there is
no need to flood out on this interface, used by the spine nodes
and for the case where the spine nodes are part of the dynamic
flooding domain.

Please review and comment.

Regards,
- Naiming


Begin forwarded message:

From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Subject: I-D Action: draft-shen-isis-spine-leaf-ext-06.txt
Date: June 18, 2018 at 1:21:31 PM PDT
To: <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
Reply-To: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>


A New Internet-Draft is available from the on-line Internet-Drafts directories.


       Title           : IS-IS Routing for Spine-Leaf Topology
       Authors         : Naiming Shen
                         Les Ginsberg
                         Sanjay Thyamagundalu
Filename        : draft-shen-isis-spine-leaf-ext-06.txt
Pages           : 18
Date            : 2018-06-18

Abstract:
  This document describes a mechanism for routers and switches in a
  Spine-Leaf type topology to have non-reciprocal Intermediate System
  to Intermediate System (IS-IS) routing relationships between the
  leafs and spines.  The leaf nodes do not need to have the topology
  information of other nodes and exact prefixes in the network.  This
  extension also has application in the Internet of Things (IoT).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-shen-isis-spine-leaf-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-shen-isis-spine-leaf-ext-06
https://datatracker.ietf.org/doc/html/draft-shen-isis-spine-leaf-ext-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-shen-isis-spine-leaf-ext-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp..ietf.org/internet-drafts/<ftp://ftp.ietf.org/internet-drafts/>

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr