Re: [Rift] Final pass on readability/normative ...

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 23 January 2020 09:53 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96412022A for <rift@ietfa.amsl.com>; Thu, 23 Jan 2020 01:53:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 header.b=H1HNkNRZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Xq+pJk0Y
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 bopP8NOg15Er for <rift@ietfa.amsl.com>; Thu, 23 Jan 2020 01:53:24 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BCB12020A for <rift@ietf.org>; Thu, 23 Jan 2020 01:53:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=62964; q=dns/txt; s=iport; t=1579773204; x=1580982804; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HaHefljQcslG+C1qjDuOZFbWaMKplO4+jnNUrclhhMI=; b=H1HNkNRZNlo8+qAD+/iDZYPLOMgGdh0KfKD3FVyjfFGKb+zLkTm9gBTq 6sqgjGGDUoqdoIjr7WRRAZZxuXiL9LkT3j4cK4/OuYviJhss5bN9RdApP Wg56UrWY182zV32xXspclLUvDS+EkVbjkRRkQxZ8YR3f/9YfgUVUWINhz Q=;
IronPort-PHdr: 9a23:EqDNPBzP4XDNyQjXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AvBwAjbCle/4QNJK1fBhwBAQEBAQcBAREBBAQBAYF7gSUvJCwFbFggBAsqhBKDRgOLC4JfiWGOLoFCgRADVAkBAQEMAQEfDgIBAYRAAheCByQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAxIICQQGEwEBJQ0FAQ8CAQgRBAEBFgsBBgMCAgIfERQJCAIEDgUIGoMFgX1NAy4BAgyiJwKBOYhhdX8zgn8BAQWFCg0LggwDBoE4hRuGfBqBQT+BEAFHUYF7PoIbSQEBA4EbHxgQGAwHCQmCUTKCLI4PgkaFXokoS45uRAqCOYdAikuERIJHiAqQJpdAgiKQBAIEAgQFAg4BAQWBaSKBWHAVgydQGA2IAQwXg1CFFIU/dIEpihMBJwKCGQEB
X-IronPort-AV: E=Sophos;i="5.70,353,1574121600"; d="scan'208,217";a="424092950"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jan 2020 09:53:22 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 00N9rMA7020235 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jan 2020 09:53:22 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 03:53:21 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 04:53:20 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 23 Jan 2020 03:53:19 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cIzYBRHdzMCuiUJO8MKR3MS32QiPK+zUnOe/rKaH435yfNIMBW49LAva3C0hH30EQweIBtIn5+wtpXUtqtmFieHiyA4NaHJfcQYYfFmC5qHvo5iPdzR5YRilmSpkpl8UdmP9JBHmBecsrx1s9koihbbVc3rBWGT6xyfmT7KONnnt6esZlMopGd8NTeDMFtHIrX9Dypqm5TY0ZIav5bhfnXOwl/IJYXkVEQCYqVBQYcLGEO1782SRPLKhQNorWQ8eVEtVz2ROt0hCchYqIWOxLmexd1S8P3VBuzyLknWcpXULxiX66J2YjudSJQZqopEOujqG26NepidMHXaIR3aZMw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HaHefljQcslG+C1qjDuOZFbWaMKplO4+jnNUrclhhMI=; b=RrpUMGyQsFTfDMgT8Zc6tSp7EHRB66a0NyZPzAewN4DOOlDzMTagoMyUL3MOswmOYvX1MDyQrcEf+O492vqAKLbnReDlHxNYBPYxX7mAWtwRV1E1KVfK6z7/RsnDW3agydPtCEbtwRAdcBQMWCBAnbbKFavsEp+n+sr54oklr2I0vNsJhaE6UV0lK3OSdu3sCafhmXQfGqeB4d6puuMl/YtFuBv+/BORictxkdoClayzlwbX/KVXGB8OozEbMgDbjqkeno8q9rKly4UqSjj11IlaUUQ/mC0yL072T64YYW49qrhcsZkdDhD81/Eyfv8HptAk63yebZtHDgnQwFK4VA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HaHefljQcslG+C1qjDuOZFbWaMKplO4+jnNUrclhhMI=; b=Xq+pJk0YwvbsO6vOSJR0Vzk7IMq5uGhCdyUP+/w8reT1X+V8cV2PyFEpAz8RfxXDNx7jecA6Eyh6JYQWI/EYvc90jGgOCll2zRGSdPw4ZIhJm/PKKTKqBcQ8fYJH8/0xb2me+usDBElJRikXJG9ZsOC2w6WkYY36FCmvt74Iq08=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4365.namprd11.prod.outlook.com (52.135.38.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.23; Thu, 23 Jan 2020 09:53:18 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2644.027; Thu, 23 Jan 2020 09:53:18 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tony Przygienda <tonysietf@gmail.com>
CC: "rift@ietf.org" <rift@ietf.org>
Thread-Topic: [Rift] Final pass on readability/normative ...
Thread-Index: AQHVrlkD26MeEFPSo0Kd+sHHMEpUmKexXyYAgA5HkoCAAAWGIIAfrrRQgAFD0cA=
Date: Thu, 23 Jan 2020 09:52:10 +0000
Deferred-Delivery: Thu, 23 Jan 2020 09:51:33 +0000
Message-ID: <MN2PR11MB3565EAA5EE6B1433B686625FD80F0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CA+wi2hPV7GvA7unqded=WYf2DDm0CnWCx0ygGjD2G2JpNwJhTg@mail.gmail.com> <MN2PR11MB356573C857961433E29D35FAD8580@MN2PR11MB3565.namprd11.prod.outlook.com> <CA+wi2hP-C4LtO1T0t=vON6Wv55PS_DU9JrtUrsnBFMw+hR5qaA@mail.gmail.com> <BYAPR11MB3558E4A0178B5CC92D20D6D2D8530@BYAPR11MB3558.namprd11.prod.outlook.com> <MN2PR11MB356571D181C7130CC84A5E37D83F0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356571D181C7130CC84A5E37D83F0@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:d60:aaf3:e8aa:949a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e2e0f59b-1d01-45b9-706b-08d79fea12fd
x-ms-traffictypediagnostic: MN2PR11MB4365:
x-microsoft-antispam-prvs: <MN2PR11MB43654AB0470E114D6886DB22D80F0@MN2PR11MB4365.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 029174C036
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(136003)(366004)(396003)(199004)(189003)(71200400001)(2906002)(316002)(86362001)(55016002)(4326008)(7696005)(6666004)(478600001)(53546011)(6506007)(66574012)(186003)(8936002)(30864003)(8676002)(66946007)(9686003)(81166006)(81156014)(76116006)(6916009)(33656002)(66556008)(5660300002)(66476007)(66446008)(52536014)(64756008)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4365; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lDaqiNxnWSQ66eMYDG7mMDjgWzC6KTJhUa+LDNEZ6uhX8rTC6I1f//7FoKms6LQFuM+73T3DOD0YfHEMoEpI5ZzhE1HiMocDz3nx2Emd6RcQYgCzMRzyj+wDzI7hODBV7NNgw9+FMdF96fse3dAgPa1JITH9LGGcGg2m5YlAYnhAANcvThyjwkybYkLmwt0jxD3bnC5WpE7H//5EnSjR9eopSQQtfbk2o7JCdPvXp9E1GpdTUUUlXZ8eRkJO5TyaywVU6ruSETbABbpadIpJihpJgSwbQRJGuMQ9YsEOqRQjW4LfmQNH0v9HLWukc0f0ssXk7cSvwOQhHCRqdFq336ZBt4vu0vVPdcCZVQZxwlKoOLaDjLjFRQ5IWJW2st+Ds7UD79XJXp6+d4ta9K4y56a+C0A2wTx1SW5yLH8t80e7+Xwr4/UN3/BRCiO78BiO+XI71t4DX9YYzkpPdBKZn7hjsyM0WA7j8IptjWI54n5xOy7jYwJ/Hcel3t6K+LT1jwlhJcbgLCeTtODDw+bOjQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565EAA5EE6B1433B686625FD80F0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e2e0f59b-1d01-45b9-706b-08d79fea12fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 09:53:18.4048 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZoUBhDdQOPobGSL0wX5v+mioHoFXeVFURrM5EuL0oy0oQGkHmV+6zU2053CB0Yc1WnQzkooA6OG5+UD6zIiFYg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4365
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/cS4beicAozjnLmUMOSgS_4nCjkE>
Subject: Re: [Rift] Final pass on readability/normative ...
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 09:53:28 -0000

Hi again Tony

More below, restarting page 54. Note that I am a PC user. On a iphone, the message I already sent appears to disappear after the line though it can be expended. Note that both this and the previous comment sets are pretty long and please make sure you see it all.


   Every North TIE is flooded northbound, providing a node at a given
   level with the complete topology of the Clos or Fat Tree network
   underneath it,

-> (unless we define that under is south, which is OK with me, you may want to change as below)

   Every North TIE is flooded northbound, providing a node at a given
   level with the complete topology of the Clos or Fat Tree network
   that is reachable southwards of it,


may be
   routed directly towards the node advertising that prefix rather than
   sending the packet to a node at a higher level.

->

will be
   routed directly towards one of the southward neighbors advertising that prefix rather than
   sending the packet to a node at a higher level.


prefix South TIEs
->
Prefix South TIEs


In table 3 “flood always” is subject to the flooding relay procedure. Should we have an (*) to mention that ?
Also it would help to express in the TIE, TIDE and TIRE definitions that the TIE may be reflooded but TIRE and TIDE that are sent are only self-generated, never forwarded.
The current way of saying that they are like ISIS CSCP / PSNP forces the reader to get knowledge of ISIS and that should not be needed.


P. 57 4.2.3.7
What you mean by purging may be obvious for many but it wouldn’t hurt to add text, like:

<new>
When a destination exit the network, residual stale routes may exist in the network till there lifetime expire.
</new>
  RIFT does not purge information that has been distributed by the
   protocol.  Purging mechanisms in other routing protocols have proven
   to be complex and fragile over many years of experience.  Abundant
   amounts of memory are available today even on low-end platforms.  The
   information will age out and all computations will deliver correct
   results if a node leaves the network due to the new information
   distributed by its adjacent nodes.


4.2.3.8.  Southbound Default Route Origination

“Southbound Default Route” reads weird since the route is Northwards. What about:

4.2.3.8.  Default Route Southbound Advertisement


About:
“
   A node originating a southbound default route MUST install a default
   discard route if it did not compute a default route during N-SPF.
“
->
“
   A node originating a southbound advertisement of a default route MUST install a default
   discard route if it did not compute a default route during N-SPF. “

Worth noting (should we add text?):

- This applies also to a smaller prefix that aggregate the fabric if the fabric is not connected to the Internet
- A leaf may advertise a default route northwards. That route has precedence over the discard route.
- A ToF that loses connectivity to the all the leaves  advertising a default route northwards must stop advertising the default route.



“
A node SHOULD send out LIEs that grant flood repeater status
       before LIEs that revoke it on flood repeater set changes to
       prevent transient behavior where the full coverage of grand
       parents is not guaranteed.

“
This one is hard to swallow. What about:
“
Upon a change of the flood repeater set, a
A node SHOULD send out LIEs that grant flood repeater status to
the nodes that are promoted to that status before it sends LIEs
that revoke the status to the nodes that are demoted. This is
done to  prevent transient behavior where the full coverage of
grand parents is not guaranteed.
“

4.  A node receiving a TIE originated by a node for which it is not a
       flood repeater does NOT re-flood such TIEs to its neighbors
       except for rules in Paragraph 6

note sure what “does NOT” mean in terms of BCP 14

4.   A node receiving a TIE originated by a node for which it is not a
       flood repeater SHOULD NOT re-flood such TIEs to its neighbors
       except for rules in Paragraph 6. Re-flooding may saturate the
       fabric to no avail.


5.  The indication of flood reduction capability MUST be carried in
       the node TIEs and CAN be used to optimize the algorithm to
       account for nodes that will flood regardless.

CAN is not listed in BCP 14. Why not MAY?

  6.  A node generates TIDEs as usual but when receiving TIREs or TIDEs
       resulting in requests for a TIE of which the newest received copy
       came on an adjacency where the node was not flood repeater it
       SHOULD ignore such requests on first and first request ONLY.


Same goes for ONLY.

   6.  A node generates TIDEs as usual but when receiving TIREs or TIDEs
       resulting in requests for a TIE of which the newest received copy
       came on an adjacency where the node was not flood repeater it
       SHOULD ignore such requests on first and first request ONLY.


Maybe
“
SHOULD ignore such requests on the first request and only on the first request.
”

Note that it might be simpler that a node syncs TIRE/TIDE with its FRs before it attempts to do so with others.


Need a global change to remove “super-spine”.
In particular in the text below a 3 level is assumed, but we could do 4 or more, couldn’t we?


   More difficult is a condition where a node floods a TIE north towards
   a super-spine, then its spine reboots, in fact partitioning
   superspine from it directly and then the node itself reboots.

   ->

   More difficult is a condition where a node (e.g., a leaf) floods a TIE north towards
   a grand-parent (e.g., a ToF node), then its parent (e.g., a ToP node) reboots, isolating
   the node from the grand-parent level, and then the node itself reboots.



With this I reached 4.2.4. I’ll try the review that section soon.

Take care,

Pascal


From: Pascal Thubert (pthubert)
Sent: mardi 7 janvier 2020 16:57
To: 'Tony Przygienda' <tonysietf@gmail.com>
Cc: rift@ietf.org
Subject: RE: [Rift] Final pass on readability/normative ...

Hello Tony:

As promised:


      Superspine/Aggregation or Spine/Edge Levels:  Traditional names in
      5-stages folded Clos for Level 2, 1 and 0 respectively.  Level 0
      is often called leaf as well.  We normalize this language to talk
      about leafs, spines and top-of-fabric (ToF).

I believe we should reword this, maybe as below:

      Superspine vs. Aggregation or Spine vs. Edge or Leaf:  Traditional level
      names in  5-stages folded Clos for Level 2, 1 and 0 respectively.  We
      normalize this language to talk about top-of-fabric (ToF), top-of-pod (ToP)
      and leaves.


   De-aggregation/Disaggregation:  Process in which a node decides to
      advertise certain prefixes it received in North TIEs to prevent
      black-holing and suboptimal routing upon link failures.

Suggestion:

   De-aggregation/Disaggregation:  Process in which a node decides to
      advertise more specific prefixes Southwards, either positively to
      attract the corresponding traffic, or negatively to repel it.
      Disaggregation is performed to prevent black-holing and suboptimal
      routing to the more specific prefixes.


   Bandwidth Adjusted Distance (BAD):  This is an acronym for Bandwidth
      Adjusted Distance.  Each RIFT node calculates the amount of
      northbound bandwidth available towards a node compared to other
      nodes at the same level and modifies the default route distance
      accordingly to allow for the lower level to adjust their load
      balancing towards spines.

Removing the first sentence:

   Bandwidth Adjusted Distance (BAD):  Each RIFT node calculates the
      amount of northbound bandwidth available towards a node compared
      to other nodes at the same level and modifies the default route distance
      accordingly to allow for the lower level to adjust their load
      balancing towards spines.



   North SPF (N-SPF):  A reachability calculation that is progressing
      northbound, as example SPF that is using South Node TIEs only.

I think it is confusing to call the northbound computation a SPF since it is a 1 hop calculation. Relates to the next point:



   We present here a detailed outline of a protocol optimized for
   Routing in Fat Trees (RIFT) that in most abstract terms has many
   properties of a modified link-state protocol
   [RFC2328<https://tools.ietf.org/html/rfc2328>][ISO10589-Second-Edition] when "pointing north" and distance
   vector [RFC4271<https://tools.ietf.org/html/rfc4271>] protocol when "pointing south".  While this is an
   unusual combination, it does quite naturally exhibit the desirable
   properties we seek.


I’d replace "pointing north" with computing southbound routes and reciprocally for "pointing south" with computing northbound routes.


PoD-ToP
->
ToP
(twice)


|H<
  ->
|o<


LIEs SHOULD be sent with a TTL of 1
->
LIEs SHOULD be sent with an IPv4 Time to Live (TTL) / IPv6 Hop Limit (HL) of 1

(same addition suggested in 4.2.3.1 for LIE)

Nodes in the spine are configured with "any" PoD which has the same
   value "undefined" PoD hence we will talk about "undefined/any" PoD.
   This information is propagated in the LIEs exchanged.

“Nodes in the spine” is unclear; do you mean ToF nodes? My understanding is that: ToF nodes MUST be configured with “undefined”, ToP MUST NOT be configured with “undefined”, and a leaf node MAY be configured with “undefined”, in which case the leaf node learns from its ToP parents. (If I’m correct) maybe we should say just that?


This will not affect the correctness of the protocol expect preventing detection of certain miscabling cases.
-> s/expect/except/
This will not affect the correctness of the protocol except preventing detection of certain miscabling cases.


normally the top spines in a PoD
->
normally the ToP nodes


4.2.2.1.  LIE FSM

Maybe listing the states in after the first sentence would be useful for the reader? Also introduce HAL, HALS and HAT acronyms before using them?
Also, the terms “lie” and “cleanup” are found in lowercase, maybe change all relevant to uppercase


“More precisely, a spine node represents two different”
Should we remove “spine” from  the sentence? Or define it?
Same goes for the use of “Spine xxx”, should we call them ToP xxx?


4.2.3.  Topology Exchange (TIE Exchange)

Maybe indicate that TIEs are exchanged only in 3-ways?




Suggestion to add an “instance nb” to the TIE so we can build multiple RIBs like in RPL over a same topology, e.g.; to serve different tenants.



More tomorrow, starting at 4.2.3.3.1.5

All the best

pascal



From: RIFT <rift-bounces@ietf.org<mailto:rift-bounces@ietf.org>> On Behalf Of Tony Przygienda
Sent: dimanche 8 décembre 2019 22:21
To: rift@ietf.org<mailto:rift@ietf.org>
Subject: [Rift] Final pass on readability/normative ...

Only IESG outstanding reviewer's comments on the spec are @ this point in time improving general readability & fine comb on normative captions (plus going to format -v3 with pictures is up to me)

I have some volunteers already that are starting on reading sections & polishing, I'm calling here for more ;-) If you'd like to review a section for readability & check normative language please contact me and I'll synchronize. Resolution is X.Y or X.Y.Z section with exception of small stuff like Examples maybe.

On offer honorable mention in the acknowledgements section ;-)

Idea would be to have a -10 (hopefully last one) with pictures & review incorporated before next IETF.

thanks

-- tony