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 protected]> 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 protected]
> *Subject: **I-D Action: draft-shen-isis-spine-leaf-ext-06.txt*
> *Date: *June 18, 2018 at 1:21:31 PM PDT
> *To: *<[email protected]>
> *Reply-To: *[email protected]
>
>
> 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 protected]
> 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 protected]
> https://www.ietf.org/mailman/listinfo/lsr
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
