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

"Naiming Shen (naiming)" <naiming@cisco.com> Wed, 03 October 2018 22:34 UTC

Return-Path: <naiming@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 EBDB4126F72 for <lsr@ietfa.amsl.com>; Wed, 3 Oct 2018 15:34:29 -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 NRRQqF9sAv_F for <lsr@ietfa.amsl.com>; Wed, 3 Oct 2018 15:34:27 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B99B130DC7 for <lsr@ietf.org>; Wed, 3 Oct 2018 15:34:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34424; q=dns/txt; s=iport; t=1538606067; x=1539815667; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BcHfyLRu7zr2BqtdDQeOU3jfDYsYK3P+7eep+rU/bTY=; b=KxI2RjbcOpKePXVGGlynIUxWVldZqSP1t7XNes0MLqtx0pPQfK1cAoIj Q9MRYLfEXE08RZFfoWGOAHqgUxlyfwN4KNxeCPEjBxwgt06ECrqXrEBzY 6erm/y/3gQ2uxO+tBogiabg4mkL3fq9+81zeF3ffvdxYnZ9zdkstD919l I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAAB3Q7Vb/4MNJK1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYIOZn8oCoMrP4gVjgEliGKNeoF6CxgBCoEzAYMVAhe?= =?us-ascii?q?ECSE0GAEDAQECAQECbRwMhTgBAQEBAwEBChdLBAcQAgEGAhEDAQIhBwMCAgI?= =?us-ascii?q?fBgsUCQgCBA4FCRKDBgGBHUwDFQ+JZZtNgS6EKwEHBz2CQQ2CUYshF4IAgRE?= =?us-ascii?q?BJwwTgkyCVjoLAQEBAQEBFoETVAYQCIJDMYImAohSA4UxhVokiR0sCQKGR4Z?= =?us-ascii?q?Ygx0XgUpLhBeDC4UKgSGMF3GBD4cTAhEUgSUNEDiBVXAVGiEqAYJBCYsNhT5?= =?us-ascii?q?vAYx1gR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,337,1534809600"; d="scan'208,217";a="180148850"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Oct 2018 22:34:26 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w93MYPsE025816 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Oct 2018 22:34:26 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 3 Oct 2018 17:34:25 -0500
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1395.000; Wed, 3 Oct 2018 17:34:25 -0500
From: "Naiming Shen (naiming)" <naiming@cisco.com>
To: Tony Przygienda <tonysietf@gmail.com>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] I-D Action: draft-shen-isis-spine-leaf-ext-06.txt
Thread-Index: AQHUW2k8yw0Ay1sPg0yOv7ddi7SXOw==
Date: Wed, 3 Oct 2018 22:34:25 +0000
Message-ID: <5EBC75A7-6683-46CD-8531-5B80BE98439B@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.156.165.62]
Content-Type: multipart/alternative; boundary="_000_5EBC75A7668346CD85315B80BE98439Bciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1_FZnQi6W60VKerlaTV9g7tOFA4>
Subject: Re: [Lsr] 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:34:30 -0000

Hi Tony,

Thanks for the comments on the document. Lets see if we can work to resolve
some of the issues (i think mainly auto-tier’ing). Some replies inline.

On Oct 2, 2018, at 5:21 PM, Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>> wrote:

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") ...

Sure.

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)

I think my original thinking was that, only real ‘bottom leaf’ nodes have true fixed connections to servers,
any other layer above that, probably can ‘re-route’ to the lower tier ‘spine nodes’ to reach the final leaf node.
But you are right, in multiple link down cases, if that needs to be handled, we should extend this in general.

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 ;-)

R normally is respond to the L from the neighbor, but can be set manually. Yes, lot people have concern about the
‘B’, we should take it out for now.

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

Sure.

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)

Lets talk more on a proper scheme.

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+-+
   +-+           +-+          +-+          +-+


Right. this portion needs to be beefed up, to specify the multiple link down behavior in general.

Best Regards,
- Naiming

--- 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
_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr