Subject: FW: I-D Action: draft-white-openfabric-00.txt

From: "Russ White" <[email-masked]>
Date: Mon, 6 Mar 2017 21:24:17 -0500

FYI.

:-)

Russ

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, March 3, 2017 1:38 PM
> To: [email-masked]
> Subject: I-D Action: draft-white-openfabric-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
>         Title           : OpenFabric
>         Authors         : Russ White
>                           Shawn Zandi
> 	Filename        : draft-white-openfabric-00.txt
> 	Pages           : 13
> 	Date            : 2017-03-03
> 
> Abstract:
>    Spine and leaf topologies are widely used in hyperscale and cloud
>    scale networks.  In most of these networks, configuration is
>    automated, but difficult, and topology information is extracted
>    through broad based connections.  Policy is often integrated into the
>    control plane, as well, making configuration, management, and
>    troubleshooting difficult.  OpenFabric is an adaptation of an
>    existing, widely deployed link state protocol, Intermediate Sytem to
>    Intermediate System (IS-IS) that is designed to:
> 
>    o  Provide a full view of the topology from a single point in the
>       network to simplify operations
> 
>    o  Minimize configuration of each router (or switch) in the network
> 
>    o  Optimize the operation of IS-IS within a spine and leaf fabric to
>       enable scaling
> 
>    This document begins with an overview of OpenFabric, including a
>    description of what may be removed from IS-IS to enable scaling.  The
>    document then describes an optimized adjacency formation process; an
>    optimized flooding scheme; some thoughts on the operation of
>    OpenFabric, metrics, and aggregation; and finally a description of
>    the changes to the IS-IS protocol required for OpenFabric.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-white-openfabric/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-white-openfabric-00
> 
> 
> 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

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 7 Mar 2017 06:13:47 +0100

hi russ,

couple of comments / questions.

1)
---
   OpenFabric implementations MUST NOT be mixed with standard IS-IS
   implementations in operational deployments.  OpenFabric and standard
   IS-IS implementations SHOULD be treated as two separate protocols.
---

any hard feelings about using MI as a way of guaranteeing that the two
protocols are shielded from each other ?

2) Modified Adjacency Formation

rather than doing the "only one adjacency is up" (which we did prior to
the graceful-restart SA bit) - suggest to use the graceful-restart 'SA'
bit, such that a node can bring up the adjacency without generating a
new LSP. The LSP can then be generated if the initial-sync is done
(and the new LSP arrival rate indicates that the dust is settling)
such that the LSP may get released.

3) Flooding Optimization
it looks to me you have re-invented the OLSR MPR set.
https://tools.ietf.org/html/rfc3626#section-8.2
perhaps you may want to add a reference.

/hannes

On 3/7/17 3:24, Russ White wrote:
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 7 Mar 2017 05:37:25 +0000

Russ -

Could you also clarify who sets the "DNR" bit in an LSP and when?
Is it the originator or one or more of the receivers? And does it have the same state  when flooded on all links or does it vary from link to link?

If the state of the bit is modified as part of the flooding I don't see how this works since it would also require recalculation of the checksum/authentication hash - and the LSP would no longer "look like" the original.

   Les

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Hannes
> Gredler
> Sent: Monday, March 06, 2017 9:14 PM
> To: Russ White; [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] FW: I-D Action: draft-white-openfabric-00.txt
> 
> hi russ,
> 
> rather than doing the "only one adjacency is up" (which we did prior to the
> graceful-restart SA bit) - suggest to use the graceful-restart 'SA'
> bit, such that a node can bring up the adjacency without generating a new
> LSP. The LSP can then be generated if the initial-sync is done (and the new
> LSP arrival rate indicates that the dust is settling) such that the LSP may get
> released.
> 
> 3) Flooding Optimization
> >> From: I-D-Announce [mailto:[email-masked]] On Behalf
> >> Of [email-masked]
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Russ White" <[email-masked]>
Date: Tue, 7 Mar 2017 08:33:47 -0500

> If the state of the bit is modified as part of the flooding I don't see
how this
> works since it would also require recalculation of the
> checksum/authentication hash - and the LSP would no longer "look like" the
> original.

You are correct -- I missed this. It kept naggling in the back of my mind
that I wanted this to be a part of the packet, not the lsp, but I couldn't
think why. The DNR bit needs to be in the packet header, but there are no
bits there. Any ideas?

:-)

Russ

---

From: "Russ White" <[email-masked]>
Date: Tue, 7 Mar 2017 08:36:15 -0500

> protocols are shielded from each other ?

Very good idea -- want to suggest text?

> rather than doing the "only one adjacency is up" (which we did prior to
the
> LSP arrival rate indicates that the dust is settling) such that the LSP
may get

This is a really good idea, actually... Again, you want to suggest text? :-)

> perhaps you may want to add a reference.

Very close -- but there's a tiny bit more optimization because of the fixed
topology than can be wrung out of that and/or the other MANET drafts. I
should actually add ref's to all of them, thanks for pointing this out.

:-)

Russ

---

From: Hannes Gredler <[email-masked]>
Date: Tue, 7 Mar 2017 14:38:58 +0100

hi russ,

> think why. The DNR bit needs to be in the packet header, but there are no

functional MAC addresses ?

All-L2-IS-DNR
All-L1-IS-DNR

/hannes

---

From: "Russ White" <[email-masked]>
Date: Tue, 7 Mar 2017 09:24:42 -0500

> functional MAC addresses ?

Yes -- this is a good idea... 

:-)

Russ