Re: [Rift] AD Review draft-ietf-rift-rift-16 (§4.2.3 thru §4.2.3.2)

Jordan Head <jhead@juniper.net> Mon, 13 March 2023 14:27 UTC

Return-Path: <jhead@juniper.net>
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 42ED3C06F226; Mon, 13 Mar 2023 07:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.905
X-Spam-Level: **
X-Spam-Status: No, score=2.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b="G4TjtI6b"; dkim=pass (1024-bit key) header.d=juniper.net header.b="OXEngZw6"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFunNP2jXRck; Mon, 13 Mar 2023 07:27:35 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A849C14F6EC; Mon, 13 Mar 2023 07:27:02 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 32D8xNpH007470; Mon, 13 Mar 2023 07:27:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=akL9ikleSOtLRxVwYQDOwPpzBTfted8ylDMnuqUKDHg=; b=G4TjtI6b7bAQpWuR3lxJlurC5wlMko/BHTGTqL9DQuYXVkAgXPKxgDNa+Hm48zuLlHat W08uDMU1MGjXaKcl66mySWhzBXkdyMTzIki1eeXJDlkssxxaO+ANZ0QuIv5UfYCKSnPQ sKjF4Zi+EUmrwF302r8S9lg+iJ5r5GfRJOZrBMUbpSuAtL4WlDHGWMbnClcH/Y9WZS7Z X6Y5Zy30dVYITyp/pwflmwpKzATqETks41H8VyoABaNjGVjoGcM/WzaOp9DpCL+M2QhQ WlM7wxgunG4E2gkcHW1FzKoHEW7+i6aYB9mnA3f83bRgrKCs8XlvvkFGIt/IU/y375xp WA==
Received: from mw2pr02cu002-vft-obe.outbound.protection.outlook.com (mail-westus2azlp17013032.outbound.protection.outlook.com [40.93.10.32]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3pa0ta0hj9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Mar 2023 07:27:00 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NtSidl8BEtI0SCdcMeteafUXaNrb+KU8qYhqu1NIC7qO6jFN5/xgnAcqNchS1kp1rmkKzn3D5ODPUcvglyDYdxPR70Zlbl1PgA/uaTtDr/9ZWdleQx5S9tkyEU/o0rzuxW3vL6Aci0y4ZVN6D9sCh0VQei8fIwKDU2FADpn1tkItLepulFPC+Fyw4CenaMw7fapgfa44YWv9M5FwYVmVy+gCYAJSlw0zHNseDaOIr5ChC8Lh9YVS0V4wKcEuv3uFXi8c0/zwh71N6xn+3fqMaEI13NkuxDYB5aZJiHr4effRon+ErRrCW22vpSqncZBvcOeva6+CiahItZPM6R0eeA==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=akL9ikleSOtLRxVwYQDOwPpzBTfted8ylDMnuqUKDHg=; b=Z66yzTZzflMVT/r482r6uFgHlfpT7IKJJozDJYYxn/faeNK2vnn5yAxuZmnm5EpKW57rYJ1N/4LkgSPas2OKkuJ8NXnubLusaa8KJolmNjXslceS+zC62RNvDr7U2cw/wZC4IhM0GLa90VBO3h2rVed37QryuE8SNAXRSE+JS2iWBa/wdTZe/7Bzr9xXnnNehAnX42ipxjABR79eJ7HIRgipeWztjBn+TP5yOFfFbN8QcM9ka7q0EOMZGCqgec1iqDveilRSd/Q/g0CGmhD/eZslCAB/u6eXFaA5OFNCZ9TDuy6smhQxyK5dM9AlGBDx6Y8YsTO+sz8QeREmKM+wCg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=akL9ikleSOtLRxVwYQDOwPpzBTfted8ylDMnuqUKDHg=; b=OXEngZw68N4O0guVa8bJC4I+8uCidDyj2z3hxCPojRrU9YRlH8XkYqWE5q3u8NI6IEd+FXWbRBIiwnBGKKR7y5BwDeN2+GBC2tk99YP01Va/WieU1MYNzfmZpmTtuCOC3DzMqc0lojkMuBRRnLsii6hphAHOT+W3H0Ga6t3le6w=
Received: from BL0PR05MB5362.namprd05.prod.outlook.com (2603:10b6:208:67::16) by DS0PR05MB9174.namprd05.prod.outlook.com (2603:10b6:8:c6::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.26; Mon, 13 Mar 2023 14:26:57 +0000
Received: from BL0PR05MB5362.namprd05.prod.outlook.com ([fe80::9aab:bbdf:73ae:82e6]) by BL0PR05MB5362.namprd05.prod.outlook.com ([fe80::9aab:bbdf:73ae:82e6%7]) with mapi id 15.20.6178.024; Mon, 13 Mar 2023 14:26:56 +0000
From: Jordan Head <jhead@juniper.net>
To: Tony Przygienda <tonysietf@gmail.com>, Alvaro Retana <aretana.ietf@gmail.com>
CC: "draft-ietf-rift-rift@ietf.org" <draft-ietf-rift-rift@ietf.org>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, "rift-chairs@ietf.org" <rift-chairs@ietf.org>, "rift@ietf.org" <rift@ietf.org>
Thread-Topic: [Rift] AD Review draft-ietf-rift-rift-16 (§4.2.3 thru §4.2.3.2)
Thread-Index: AQHZP6scRnCC0BdIzUuEh5V7lHGaPa7bWmQAgB1S8IA=
Date: Mon, 13 Mar 2023 14:26:56 +0000
Message-ID: <9E793876-1ABA-414E-81D5-C771B09BBFE8@juniper.net>
References: <CAMMESsyNYGGz10G=u6jwdM+1hmJMmnpd4W_75iyN4ZwNLQRPiw@mail.gmail.com> <CA+wi2hN5Yq=H-6zfA5WiFMQV6qbt0Y=Qvo62BoVFOt0rgkREFw@mail.gmail.com>
In-Reply-To: <CA+wi2hN5Yq=H-6zfA5WiFMQV6qbt0Y=Qvo62BoVFOt0rgkREFw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.70.23021201
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=6f894372-a7cf-4d81-8b9d-bc51bc32356b; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2023-03-13T14:24:40Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL0PR05MB5362:EE_|DS0PR05MB9174:EE_
x-ms-office365-filtering-correlation-id: f238bfc7-85db-4fe8-e82a-08db23cf000b
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1Zj+9DMeJjE/uJsef0saw0robXFHrD6iso+JduPkK+EHUwjR/wEmp+zg2mmEvx8qU+nsuVFUGUNGDEVvQd54KWctoeeSvIugrDRmjD2aI9rP1kis8xjOHuo8N+Yd7HAcuTgIrUzv6o8EVVBg0zviQuS3EGHyVScGbCF0EgHxXbD3RW1EAHQf2faTX4levf38+DI2rC8yvmQJNn6bSEUY8iGVv1xAp3JI6ozUm8gfgB1iz2JOtXlQHZamMCK80QMNxd3mukmv/DyrNplwLvwXilReYpsAfH189rY8v8Qsizuqb/5wd+92X24vvj7DZXfrFN9fBkFqvtPYCoQgKVE0+t9AU9A+4ZM+RpR1f52ZjdJOVip9dhPtTfoygcYaDokwPAr8wA3H6yQlsFonDnS4TlgpVLwfFLRiQ+fa3LBu7StTLFRKYc/QBGEX5U82ci/pDpT7nIPp1iU+XyJgYFXlEK55R7vioNu5lusIZ6YQvJcEbf35NlajieiHJ0UpTj3z1ZWELnI+KjWQ7Fb/v9Rvw6Cd2wm2Z1mWYggmfpZofgtef1FDyA4ld9AqrQe9XE0kVL70/BlCUh+7CvIK+b1olriSeCKiwqI35vrJyXbfNk+fuvLRSQsDxxtuWWEk8srP0yVg37jK9sGOiwOVzYSNdxTbdzjqcDzY9flBke81VfIaCot972g1g5aOvgxguj/qBKvw+U720uVgbLes2ikJ+RoLqLXYllZYQ4RdrFF7BVm4UKoh18pH2bFuOtsum37G
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5362.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(39860400002)(376002)(366004)(346002)(136003)(396003)(451199018)(38070700005)(86362001)(33656002)(122000001)(38100700002)(36756003)(8936002)(2906002)(41300700001)(30864003)(5660300002)(54906003)(4326008)(186003)(6506007)(26005)(6512007)(110136005)(316002)(83380400001)(53546011)(2616005)(66446008)(66556008)(91956017)(6486002)(478600001)(66476007)(66946007)(76116006)(71200400001)(64756008)(21314003)(45980500001)(579004)(559001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 9aB8Cz5pDti1g6FTvtzTLaA/UTw0jcJ/phRedSUahysZeCf+nQsC48WPBfwtX4YArIP+1aHo+cWJZbw81yQ5d5eLlSCBiAbDkr0oeNS5CMYQo7wbm4yAOHDYEGBDQBHAWPcghCiY+qdIlXlMAWIM2nFF0VN6ZuNySj9fjRbju8A7FhuDrq08Uua7zVvT6N7ICzKTxYFMVEpczzSW4zuGcu0LY6g7Oy0qdz2Vb6Zwnio9EEZF5TM7RjRF2wgkNrGWQpXeXjhWktcobk1hmV/RmgZdVDt/vB33Ra45Kl+zW3YstW7QIvn5pJmx1X0Bhu7N6fXInePMc3HqtwQplDwvbSeWlGYbC77PNH/ryd0baGI45SaiBmK1wP/5YQ0wvR5en5EW0X4AMvWg4zbA/C3Ti53ak2/Bu3VYGUWLCjt7NqmBHZ1eTndmxst+vdCylh5xMjyf6/ItJixzEqTbxfRYsmk2A2EAuveS9g1HZQ/2gQ1N1Pg0n0+P0yAuXBJqTOi3GKdNkCORGxhjUeKDcpmm8dXb6SEsgWr2eZLmY4ORLs7P569GKBeO/P1CrMCTvHctMZj9yvADuY7ZcEFiirzI8YmAKRyzk4p2ccSuEQiYT33q7rU9Wrluvy5V53P/7CvHw5XLkY2L5NGwX28k49w8YvBmQh3A4+ZS5X5JrsY1pfx5Gd6LXaK6bLLmnIvnolaK8IiUjrMYNube1LgosukYbOZu/7bR4uwOkwUZ2ypwj7hTZVlBD4KwChD05r52vpSgisGFT2pmywTv+dRRvorDa0WfYZyPgo8WkkyKjK99XPM58q4cs/T2JHZpVAcmJz0xVxVnXfGXwVqI3HW+EOjJRaL5NjiixSplwsXpAnvE1ePIYDtaC9U3gdsuY8bHNCl+M5vgftHc1HeF04z8Bnafc/c2CjGqcryGmpOdZt1KGGlpl8AM+7wzM5AjWNQ43Ab2U7yZgUbnD5ZR7TcoZ9vQ9sp7K4wCipMEsa2fvNC9CZOJPkmh9jlJgG4dTaFYpEfUJn8eRX/qdKkYFBiT33QIG2yrN/Fw2rU5QQShljCp5GgEskJHXnQq+cRRa8ihKNthr71H9OhB1OsCrXV2jkJrUFKMcWZXZDGNDm0OF0BwcazcngNT+HpRkve0WhRB/ga9QeTidR5acR/ZjNeFpp/8ntD9qInKa5Y/A9cTus6au0f3wrvAH3eVwOj25J0d62HJ5ybDnnZUokhRCjtaPSqXWFjNRgUB+D7paVNnIdrAnMDOe8Jzaj5Oiy+4JArYt7Ll8O9Ych9lHkflhr8cin6ga4X6UD6S2Cu+8xxSIlJ5ePZJx4YZdfgt6RTzY5+nDbwqoZlkmZBBa3kJ5wYXvSuYuLoLxKu7+DiC1BNzYQ8M5yi9jcwUlSGZNyz3M1G2ot3T16W2VXqWGZW6yDwQCMW7X4rsjMY5TzuDy6Uro7RxyTfTFaG0/L9aZjVREMKoDGJ3AuImlf8APOA3J81yopM9ZcG7awL1O2LpQJumwjagRvBHY8gXve5/sB/cA5RpLTgVPk6gR3vtA+OJsVv4Ly8eEtAjP76Cb9Oomx/ac3Ux0DUDnvjNlnKFhr0sRGx5myi3
Content-Type: multipart/alternative; boundary="_000_9E7938761ABA414E81D5C771B09BBFE8junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5362.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f238bfc7-85db-4fe8-e82a-08db23cf000b
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2023 14:26:56.8420 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jR83g4SW9Tt3GUEiAoZFX6d31mGtA68RAVw4tx6Ig3AUG+Rp1TII1/ihW6lmx9pwKbsY7SmW8mOeKv7rAsZdjA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR05MB9174
X-Proofpoint-GUID: bc4HExJ-fYO-ocqY-n4GLt-Smy7Zx-6R
X-Proofpoint-ORIG-GUID: bc4HExJ-fYO-ocqY-n4GLt-Smy7Zx-6R
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-03-13_07,2023-03-13_02,2023-02-09_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 clxscore=1015 impostorscore=0 priorityscore=1501 malwarescore=0 phishscore=0 lowpriorityscore=0 spamscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2303130114
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/4SM7ZC0Kzj1kj9K5tNY4BxecVhE>
Subject: Re: [Rift] AD Review draft-ietf-rift-rift-16 (§4.2.3 thru §4.2.3.2)
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 13 Mar 2023 14:27:39 -0000

Alvaro,

Comments inline as jhead>>

Thanks

From: Tony Przygienda tonysietf@gmail.com<mailto:tonysietf@gmail.com>
Date: Wednesday, February 22, 2023 at 1:39 PM
To: Alvaro Retana aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>
Cc: Jordan Head jhead@juniper.net<mailto:jhead@juniper.net>, draft-ietf-rift-rift@ietf.org<mailto:draft-ietf-rift-rift@ietf.org> draft-ietf-rift-rift@ietf.org<mailto:draft-ietf-rift-rift@ietf.org>, EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>, rift-chairs@ietf.org<mailto:rift-chairs@ietf.org> rift-chairs@ietf.org<mailto:rift-chairs@ietf.org>, rift@ietf.org<mailto:rift@ietf.org> rift@ietf.org<mailto:rift@ietf.org>
Subject: Re: [Rift] AD Review draft-ietf-rift-rift-16 (§4.2.3 thru §4.2.3.2)

[External Email. Be cautious of content]

missed all reply

catching up on reviews today ...


On Mon, Feb 13, 2023 at 2:00 PM Alvaro Retana aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com> wrote:
Hi!

This message covers §4.2.3 to the end of §4.2.3.2.

Alvaro.



2207    4.2.3.  Topology Exchange (TIE Exchange)

2209    4.2.3.1.  Topology Information Elements
...
2214       The TIE exchange mechanism uses the port indicated by each node in
2215       the LIE exchange as `flood_port` in `LIEPacket` and the interface on
2216       which the adjacency has been formed as destination.  TIEs MUST be
2217       sent with an IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) of
2218       either 1 or 255 and also MUST be ignored if received with values
2219       different than 1 or 255.  This prevents RIFT information from
2220       reaching beyond a single L3 next-hop in the topology.  TIEs SHOULD be
2221       sent with network control precedence unless an implementation is
2222       prevented from doing so [RFC2474].

[major] "This prevents RIFT information from reaching beyond a single
L3 next-hop in the topology."

This is not completely true for TTL = 1.  It is true that the TIE
cannot be forwarded beyond the local subnet.  But it is not true that
a TIE cannot be forwarded *into* the local subnet.  This is one of the
attack vectors that are left open -- these are the same concerns as
with the LIEs.

? RIFT works on p2p links which are always an L3 next hop. Hence
the subnet is 2 routers only (be it v4, v6 or v6 LLC)

    jhead>> I had mentioned that we added references, but Tony pointed out the obvious in that this doesn't apply as links are P2P only. I pulled those back out.


2224       TIEs contain sequence numbers, lifetimes and a type.  Each type has
2225       ample identifying number space and information is spread across
2226       possibly many TIEs of a certain type by the means of a hash function
2227       that an implementation can individually determine.  One extreme
2228       design choice is a prefix per TIE which leads to more BGP-like
2229       behavior where small increments are only advertised on route changes
2230       vs. deploying with dense prefix packing into few TIEs leading to more
2231       traditional IGP trade-off with fewer TIEs.  An implementation may
2232       even rehash prefix to TIE mapping at any time at the cost of
2233       significant amount of re-advertisements of TIEs.

[major] "TIEs contain sequence numbers, lifetimes and a type."

There is one TIE, but multiple types of TIEElements, right?  And each
TIE carries only one TIEElement at a time, right?

If so, then "information is spread across possibly many TIEs of a
certain type" should say "across multiple TIEElements", or maybe
"across multiple TIEs with the same TIEElement type", or something
like that.

ok, I like your last suggestion

    jhead>> Fixed using your last suggestion.


[major] "...information is spread across possibly many TIEs of a
certain type by the means of a hash function that an implementation
can individually determine."

Does the receiver need to know the hash function?  I'm hoping the answer is No.

answer is No. Each node is completely free to choose how it spreads the
info across TIEs of same type.


The rest of this paragraph only talks about prefixes.  Even if
possibly less common, I assume that the ability to spread information
applies to all TIEElement Types.  Is that true?  If so, please be
explicit -- and maybe keep the text about prefixes as an example.

RIFT being very symmetrical this applies to _all_ tie types. we can mention that, giving more examples
I think is counter productive.

    jhead>> Added that this applies to ALL TIEElement types, but we removed the prefix example.


[major] Please remove comparisons or references to other protocols:
"BGP-like behavior...traditional IGP".

ack

    jhead>> Already fixed as per previous comments.


...
2238    4.2.3.2.  Southbound and Northbound TIE Representation
...
2248       The North TIEs hold all of the node's adjacencies and local prefixes
2249       while the South TIEs hold only all of the node's adjacencies, the
2250       default prefix with necessary disaggregated prefixes and local
2251       prefixes.  Section 4.2.5 explains further details.

[minor] I know I should go look at §4.2.5, but the description of
doesn't seem correct:

"North TIEs hold all of the node's adjacencies and local prefixes"

"South TIEs hold only" -- "only" seems to indicate less information --
"all of the node's adjacencies, the default prefix with necessary
disaggregated prefixes and local prefixes".   So the South TIEs have
more information.

Maybe it's a matter of eliminating "only".

Yes, south ties hold less information. The text is correct. North TIEs are
really a full link state database of the node (since we have north flooding)
while south is a "compressed" view with mostly just default prefix




2253       The TIE types are mostly symmetric in both directions and Table 3
2254       provides a quick reference to main TIE types including direction and
2255       their function.  The direction itself is carried in `direction` of
2256       `TIEID` schema element.

[major] The TIE types (the table says "TIE-Types", please be
consistent) in the table are not the same as the types defined in the
schema:

ok, let's remove the table and refer to schema only

    jhead>> The "TIE-Types" table has been removed and we now refer to the schema.


/** Type of TIE.
*/
enum TIETypeType {
    Illegal                                     = 0,
    TIETypeMinValue                             = 1,
    /** first legal value */
    NodeTIEType                                 = 2,
    PrefixTIEType                               = 3,
    PositiveDisaggregationPrefixTIEType         = 4,
    NegativeDisaggregationPrefixTIEType         = 5,
    PGPrefixTIEType                             = 6,
    KeyValueTIEType                             = 7,
    ExternalPrefixTIEType                       = 8,
    PositiveExternalDisaggregationPrefixTIEType = 9,
    TIETypeMaxValue                             = 10,
}

See my comment above about differentiating between the types of TIEs
(shown in the table) and the types of TIEElements (defined in the
schema).  As is, the terminology is confusing because TIE types seem
to have two different meanings. (The last sentence in this section
also uses the same confusing terminology.)

A simplistic interpretation indicates that a TIE type is the same as
the corresponding TIEElement type, but with a direction.

yes, that's one way to see it, a TIE has a type and the type forces the according
schema element




2258           +=========================+=================================+
2259           | TIE-Type                | Content                         |
2260           +=========================+=================================+
2261           | Node North TIE          | node properties and adjacencies |
2262           +-------------------------+---------------------------------+
2263           | Node South TIE          | same content as node North TIE  |
2264           +-------------------------+---------------------------------+
2265           | Prefix North TIE        | contains nodes' directly        |
2266           |                         | reachable prefixes              |
2267           +-------------------------+---------------------------------+

[nit] s/nodes'/node's

    jhead>> Table removed.


2268           | Prefix South TIE        | contains originated defaults    |
2269           |                         | and directly reachable prefixes |
2270           +-------------------------+---------------------------------+

[minor] "directly reachable prefixes"

The text above, and a definition in the schema, use "local prefixes"
instead.  Please be consistent.

ok, yes, let's align the terminology to the schema

    jhead>> Table removed.


2271           | Positive Disaggregation | contains disaggregated prefixes |
2272           | South TIE               |                                 |
2273           +-------------------------+---------------------------------+
2274           | Negative Disaggregation | contains special, negatively    |
2275           | South TIE               | disaggregated prefixes to       |
2276           |                         | support multi-plane designs     |
2277           +-------------------------+---------------------------------+
2278           | External Prefix North   | contains external prefixes      |
2279           | TIE                     |                                 |
2280           +-------------------------+---------------------------------+
2281           | Key-Value North TIE     | contains nodes northbound KVs   |
2282           +-------------------------+---------------------------------+
2283           | Key-Value South TIE     | contains nodes southbound KVs   |
2284           +-------------------------+---------------------------------+

2286                                 Table 3: TIE Types

[major] The table doesn't include all the TIEElement types + direction.

as I said, let's remove it and refer to schema only to prevent copies

    jhead>> Table removed.

2288       As an example illustrating a databases holding both representations,
2289       the topology in Figure 2 with the optional link between spine 111 and
2290       spine 112 (so that the flooding on an East-West link can be shown) is
2291       considered.  Unnumbered interfaces are implicitly assumed and for
2292       simplicity, the key value elements which may be included in their
2293       South TIEs or North TIEs are not shown.  First, in Figure 15 are the
2294       TIEs generated by some nodes.

2296              ToF 21 South TIEs:
2297              Node South TIE:
2298                NodeElement(level=2, neighbors((Spine 111, level 1, cost 1),
2299                (Spine 112, level 1, cost 1), (Spine 121, level 1, cost 1),
2300                (Spine 122, level 1, cost 1)))
2301              Prefix South TIE:
2302                SouthPrefixesElement(prefixes(0/0, cost 1), (::/0, cost 1))

[major] s/NodeElement/NodeTIEElement/g
In order to match the schema.

ok

    jhead>> Fixed.

[major] s/SouthPrefixesElement/PrefixTIEElement/g



[major] For the prefixes, "cost" is used.  However, the schema uses
"metric" in the PrefixAttributes structure:

ok, yeah, can do.

    jhead>> Fixed all instances of SouthPrefixesElement and NorthPrefixesElement.


/** Distance of the prefix. */
2: required common.MetricType            metric
        = common.default_distance;

Note that NodeNeighborsTIEElement uses different language to refer to
the same thing:

/**  Cost to neighbor. Ignore anything larger than `infinite_distance`
and `invalid_distance` */
3: optional common.MetricType               cost
            = common.default_distance;


The terminology section defines cost, but not metric.  Please be consistent.

The definitions are:

   Cost:  The term signifies the weighted distance between two neighbors.

   Distance:  Sum of costs (bound by infinite distance) between two nodes.

cost = sum of metrics. We should include that in the glossary. Having said that

cost to neighbor should be metric really and adjusted (since it's not sum).



There is clearly some type of circular definition between the cost
("weighted distance") and the distance ("sum of costs").  ??

yeah, I don't want to go full tilt math definitions where topology defines those terms strictly but
we should unify the terms here

metric = how far is something in one hop
cost = sum of metrics = distance


Also, note that "weighted" is only used in this definition -- except
when referring to weighted ECMP or UCMP.


    jhead>> Per Tony's comments, I've added a definition for metric and unified the definitions.

        Metric: The cost between two neighbors exactly one layer 3 hop away from each other.

        Cost: The sum of metrics between two nodes.

        Distance: The sum of costs (bound by infinite distance) between two nodes.


2304              Spine 111 South TIEs:
2305              Node South TIE:

2307                NodeElement(level=1, neighbors((ToF 21, level 2, cost 1,
2308                            links(...)),
2309                (ToF 22, level 2, cost 1, links(...)),
2310                (Spine 112, level 1, cost 1, links(...)),
2311                (Leaf111, level 0, cost 1, links(...)),
2312                (Leaf112, level 0, cost 1, links(...))))

[minor] Why aren't the links included in the ToF 21 TIEs?  I know that
they are optional -- it just looks inconsistent.

oversight or optimizing space. Jordan, pls check

    jhead>> Fixed.


2313              Prefix South TIE:
2314                SouthPrefixesElement(prefixes(0/0, cost 1), (::/0, cost 1))

2316              Spine 111 North TIEs:
2317              Node North TIE:
2318                NodeElement(level=1,
2319                neighbors((ToF 21, level 2, cost 1, links(...)),
2320                (ToF 22, level 2, cost 1, links(...)),
2321                (Spine 112, level 1, cost 1, links(...)),
2322                (Leaf111, level 0, cost 1, links(...)),
2323                (Leaf112, level 0, cost 1, links(...))))
2324              Prefix North TIE:
2325                NorthPrefixesElement(prefixes(Spine 111.loopback)

[major] s/NorthPrefixesElement/PrefixTIEElement/g

yeah, stuff changed over time


     jhead>> Fixed.


2327              Spine 121 South TIEs:
2328              Node South TIE:
2329                NodeElement(level=1, neighbors((ToF 21,level 2,cost 1),
2330                (ToF 22, level 2, cost 1), (Leaf121, level 0, cost 1),
2331                (Leaf122, level 0, cost 1)))

[minor] The links are not shown here...

same. simplification.


    jhead>> Fixed.


...
2362       For node TIEs to carry more adjacencies than fit into an MTU, the
2363       element `neighbors` may contain different set of neighbors in each
2364       TIE.  Those disjoint sets of neighbors MUST be joined during
2365       corresponding computation.  Nevertheless, in case across multiple
2366       node TIEs

[nit] "node TIEs"

Some places capitalize "Node TIEs" -- please be consistent.

ack

    jhead>> I've adjusted everything to "Node TIE", "Node South TIE", "Node North TIE", etc.


[nit] s/fit into an MTU/fit into an MTU-sized packet

    jhead>> Fixed.

[nit] s/contain different set/contain a different set

    jhead>> Fixed.


[major] "MUST be joined during corresponding computation"

How?  Given that this is a Normative requirement, you should indicate
how.  I get that this is a simple operation -- nonetheless, it should
be specified.  See more below

Which "corresponding computations"?  I'm assuming that joining
(considering multiple sets of neighbors as one) should be done for
all.  IOW, are there specific cases where it is (not) needed?

tons of them that are touching node TIEs, reachability, checks on all kind of algorithms. Explained in the document throughtout

Join has to be done for all. Join is bits tricky, we should probably be normative as you say

run over all TIEs sorted on IDs and join all found copies together
    jhead>> New normative TIE Ordering addresses this.

2368       1.  `capabilities` do not match *or*

2370       2.  `flags` values do not match *or*

2372       3.  same neighbor repeats in multiple TIEs with different values

2374       the behavior is undefined and a warning SHOULD be generated after a
2375       period of time.

[major] "behavior is undefined and a warning SHOULD be generated"

So, when joining (required above), what should a node do if a specific
"neighbor repeats in multiple TIEs with different values".  I know
you're saying that the behavior is undefined, but what happens to that
neighbor?  Is it still considered "during corresponding computation"?
Which version?

It seems to me that generating a warning implies that the node keeps
working -- I just don't understand which state it uses going forward.

The same concerns apply to `capabilities` and `flags`.

well, we can say, sort based on TIE ID and use last found.

    jhead>> Discussed this with Tony and we ended up adjusting things a bit. "the behavior is undefined and a warning SHOULD be generated after a period of time." now reads:

        "Since the receiving node cannot control the arrival order of TIEs, it is expected that an implementation will use the value of any of the valid TIEs it received."


[major] "a warning SHOULD be generated after a period of time"

How long is that period?  Is there a timer somewhere?

impossible to specify, maybe we should say "generated after a configurable period of time" ?

    jhead>> We have removed this as part of the previous edit. Consider that this sort of behavior may be normal in some cases (e.g. reconfiguration).

2377       The element `miscabled_links` SHOULD be repeated in every node TIE,
2378       otherwise the behavior is undefined.

[major] "SHOULD be repeated"

When is it ok to not repeat it?  It seems like the answer is "never",
otherwise the behavior is undefined.  Why is this behavior recommended
and not required?

I see, from the schema, that `miscabled_links` is optional, which
means that it would be used only if any links are miscabled.  I can't
find a place that talks about what is considered a miscabled link (I
seem to remember having this discussion before) -- the only other
mention of "miscabled" is in §4.2.7.3, so (even if there's no explicit
mention) it looks like it (or perhaps the whole ZTP section) might be
a good enough reference.

Suggestion>
   If the fabric is miscabled (Secion xxx), the element `miscabled_links`
   MUST be repeated in every Node TIE.  If it isn't, the behavior is
   undefined.

BTW, which behavior is undefined?  I can't find a place that talks
about the effect of miscabling.

Also, no warning is needed in this case?

Miscabling is purely operational help, that's also why it's "SHOULD"

An implementation may NOT do anything. And miscabling is impossible to
define, different people have different opinions what is miscabled and an
implemention is free to choose what it considers "miscabled". Classical would
be subnet mismatch (the simplest case) but e.g. all ISIS implementations
include a knob to override it.

So, nothing to specify on the wire except "SHOULD include miscabled" AFAIS.

    jhead>> This now reads:

      The `miscabled_links` element SHOULD be included in every Node TIE, otherwise the behavior is undefined.


2380       A top of fabric node MUST include in the node TIEs in
2381       `same_plane_tofs` element all the other ToFs it is aware of through
2382       reflection.  To prevent MTU overrun problems, multiple node TIEs can
2383       carry disjoint sets of ToFs which can be joined to form a single set.
2384       This element allows nodes in other planes that are on the multi-plane
2385       ring with this node to have information describing the complete plane
2386       and with that all ToFs in a multi-plane fabric are aware of all other
2387       ToFs which can be used further to form input to complex multi-plane
2388       elections.

[major] "A top of fabric node MUST include...in `same_plane_tofs`
element all the other ToFs..."

The requirement seems to indicate that "all the other ToFs" have to be
included in the element, but that is not strictly true because the set
can be divided into subsets...

Suggestion>
   A ToF none MUST include all the other ToFs it is aware of
   through reflection.  The `same_plane_tofs` element is used
   to carry this information.

ack. yes, agreed.

     jhead>> Fixed.


[major] "can be joined to form a single set"

This text is not a requirement (as was the text above about joining
neighbor sets).  Should it be?  Why would it be different?

yeah, it should be normative

    jhead>> Yes, as Tony says. Text now reads:

        ...multiple Node TIEs can carry disjointed sets of ToFs which MUST be joined to form a single set...

[nit] "...can be used further to form input to complex multi-plane elections."

It would be nice to reference where that is specified.

this is in auto-evpn and auto-fabric drafts. I don't think we should reference those.

Maybe we can just kick the whole sentence here.

    jhead>> Removed.


2390       Different TIE types are carried in `TIEElement`.  Schema enum
2391       `common.TIETypeType` in `TIEID` indicates which elements MUST be
2392       present in the `TIEElement`. In case of mismatch the unexpected
2393       elements MUST be ignored.  In case of lack of expected element in the
2394       TIE an error MUST be reported and the TIE MUST be ignored.  The
2395       element `positive_disaggregation_prefixes` and
2396       `positive_external_disaggregation_prefixes` MUST be advertised
2397       southbound only and ignored in North TIEs.  The element
2398       `negative_disaggregation_prefixes` MUST be aggregated and propagated
2399       according to Section 4.2.5.2 southwards towards lower levels to heal
2400       pathological upper level partitioning, otherwise traffic loss may
2401       occur in multiplane fabrics.  It MUST NOT be advertised within a
2402       North TIE and ignored otherwise.

[minor] "Different TIE types are carried in `TIEElement`."

See my comment earlier about the types of TIEs and how the terminology
is confusing.  The last paragraph in the next section also mentions
"TIE types".

ok

    jhead>> I concede that the general-speak phrase "TIE types" might be a bit overloaded and could be interpreted as different things, but for the average reader (likely an operator) it almost has to be or we risk forcing them to worry about every single schema element. Contextual scope is key, if I'm thinking about flooding scopes, "TIE type" means North or South, but if I'm thinking about information within a TIE, "TIE type" means node, negative, key-value, etc. Lastly, if I zoom in even more, maybe I care about those "types" in a compounding sense (e.g. Northbound Key-Value TIE).

    But if I'm an implementor, I _do_ care about the schema because I need to know how to construct individual TIEs. I care that `TIETypeType` in `TIEID` dictates which components of `TIEElement` MUST be present. In short, the normative declarations in the spec provide that (for implementors).


[major] "Schema enum `common.TIETypeType` in `TIEID` indicates which
elements MUST be present in the `TIEElement`."

No -- TIETypeType is just an enum, it doesn't indicate any required elements.

yes, it does. When it's set on the TIEID the type determines what is carried in the `TIEElement`


[major] "In case of mismatch...In case of lack of expected element..."

The schema says that all the parts of TIEElement are optional:

/** Single element in a TIE. */
union TIEElement {
    /** Used in case of enum common.TIETypeType.NodeTIEType. */
    1: optional NodeTIEElement     node;
    /** Used in case of enum common.TIETypeType.PrefixTIEType. */
    2: optional PrefixTIEElement          prefixes;
    /** Positive prefixes (always southbound). */
    3: optional PrefixTIEElement   positive_disaggregation_prefixes;
    /** Transitive, negative prefixes (always southbound) */
    5: optional PrefixTIEElement   negative_disaggregation_prefixes;
    /** Externally reimported prefixes. */
    6: optional PrefixTIEElement          external_prefixes;
    /** Positive external disaggregated prefixes (always southbound). */
    7: optional PrefixTIEElement
            positive_external_disaggregation_prefixes;
    /** Key-Value store elements. */
    9: optional KeyValueTIEElement keyvalues;
} (python.immutable = "")


I see that each of the parts *TIEElement has required elements in it.
The text above talks about required elements in TIEElement which is
not correct.  They are required elements in the optional components
(*TIEElement) of TIEElement.  Please be precise.


ok, you're splitting hairs AFAIS but fine. As I said the TIEType on the TIEID
indicates WHICH of those opetional elements MUST be set and there is text
saying what to do on mismatches. AFAIS spec is sufficient but we can
do more "precise" verbiage.


[minor] "unexpected elements MUST be ignored"

Is it just unexpected or also unknown?  I guess unknown are
unexpected, but this sentence talks about a mismatch, indicating that
there are specific yes/no elements (not unknown).

what is "unknown". The treatement of not understood TIETypes is
described AFAIR (flood on),


[major] "The element `positive_disaggregation_prefixes` and
`positive_external_disaggregation_prefixes` MUST be advertised
southbound only and ignored in North TIEs."

These elements are optional, so the "MUST" doesn't work.

they are "MUST" when the TIE Type is set accordingly as
explained in previous paragraph. I think writing
a whole novel repeating all the causality/normative chain that is logically compiled during
the text of the spec on every condition will not be particualrly productive.


Suggestion>
   The `positive_disaggregation_prefixes` and
   `positive_external_disaggregation_prefixes` elements MAY be
   advertised in South TIEs and MUST be ignored if advertised
   in North TIEs.

that breaks the spec. It's _not_ a may, in case positive disaggreagtion
is needed, the stuff MUST be advertised southbound.



[major] "The element `negative_disaggregation_prefixes` MUST be
aggregated and propagated according to Section 4.2.5.2 southwards
towards lower levels to heal pathological upper level partitioning,
otherwise traffic loss may occur in multiplane fabrics. It MUST NOT be
advertised within a North TIE and ignored otherwise."

- §4.2.5.2 doesn't mention this element (or PrefixTIEElement)
explicitly.  The specification seems to be in §4.2.5.2.2.

- s/aggregated/disaggregated

        jhead>> Essentially we mean "summarized" (consider 2 disaggregated contiguous /24s, we just advertise as a single negative /25) That said, we removed the "aggregated and" as it doesn't really add anything as we point to the normative computation anyway.

- "MUST be aggregated and propagated according to Section 4.2.5.2"

§4.2.5.2.2 doesn't require the behavior (MUST), it recommends it
(SHOULD).  Instead of making both sentences use the same word, please
specify the behavior only once.  §4.2.5.2.2 seems like the right
place.

- "...to heal pathological upper level partitioning, otherwise traffic
loss may occur in multiplane fabrics."

If the specification is somewhere else, then this explanation should
be there too.

there is a whole section on negative disaggregation in the intro and previous
comment applies as well, i.e. it is a MUST _if_ negative disaggregation happens.
If we missed that negative MUST be computed & propagated then we need to fix that in
context.
Again, we cannot write every time the whole
causality chain repeating the whole context as in (well, if _this_ applies and _this_ is set and as said before, this is true, then you MUST do that).
Either the reader keeps the correct context (i.e. we have negative disaggreagation scenario _and_ the tie ID type is set correctly _and_ direction is this, THEN) or otherwise every sentence will become 1/2 spec repeated.



Suggestion>
   The `negative_disaggregation_prefixes` elements MAY be
   advertised in South TIEs and MUST be ignored if advertised
   in North TIEs.

again, AFAIS, that breaks the spec since you consider only the context of packet format and not the operational condition.




Juniper Business Use Only