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

From: Tony Przygienda <[email-masked]>
Date: Tue, 2 Oct 2018 17:21:51 -0700

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=
[email-masked]> 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: [email-masked]
> *Subject: **I-D Action: draft-shen-isis-spine-leaf-ext-06.txt*
> *Date: *June 18, 2018 at 1:21:31 PM PDT
> *To: *<[email-masked]>
> *Reply-To: [email-masked]
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Oct 2018 22:11:46 +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 <[email-masked]> on behalf of Tony Przygienda <[email-masked]>
Date: Tuesday, October 2, 2018 at 8:22 PM
To: "naiming=[email-masked]" <naiming=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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

   +-+           +-+          +-+          +-+

On Mon, Jun 18, 2018 at 1:30 PM Naiming Shen (naiming) <naiming=[email-masked]<mailto:[email-masked]>> wrote:

Hi LSR’er,

Regards,
- Naiming

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-shen-isis-spine-leaf-ext-06.txt
Date: June 18, 2018 at 1:21:31 PM PDT
To: <[email-masked]<mailto:[email-masked]>>
Reply-To: [email-masked]<mailto:[email-masked]>

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

Abstract:

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

[email-masked]<mailto:[email-masked]>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: "Naiming Shen (naiming)" <[email-masked]>
Date: Wed, 3 Oct 2018 22:34:25 +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 <[email-masked]<mailto:[email-masked]>> wrote:

Sure.

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.

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.

Sure.

e) 3.4:

Lets talk more on a proper scheme.

   +-+           +-+          +-+          +-+

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

Best Regards,
- Naiming

--- tony

Hi LSR’er,

Regards,
- Naiming

Begin forwarded message:

Abstract:

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/>.